용어 사전

원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/glossary.html

• Anchor Peer
  • 'gossip 프로토콜' 에서 사용되는 개념으로~ 서로다른 organization의 peer간에도 알수있도록 하게합니다.
  • anchor-peer 관련 업데이트 정보가 포함된 'configuration block'가 커밋이 되면,
  • peer들는 해당 anchor-peer에게 접근하여... 이 anchor-peer가 알고있는 '모든 peer들'을 알수있게 됩니다.
  • 각 organization 마다, 적어도 하나의 peer가 anchor-peer에게 접속하기만 하면~ anchor-peer 역시 이 channel의 '모든 peer들'을 알수있게 되는것 입니다.
  • 'gossip 프로토콜' 이 계속 진행이 되는동안, peer는 자신이 모르는 어떤 peer 가 있는지? 계속 묻게 됩니다.
  • 이런 과정으로 해당 channel에 '공통된 membership' 관계가 잘 유지 될수있는것 입니다.
  • 예를들면,
    • 한 channel에 A,B,C 3개의 organization이 있습니다.
    • anchor-peer:C 에게 peer:A 가 접근을 하면서~ A 관련 정보를 이야기해줍니다.
    • 이후, peer:B 도 anchor-peer:C 에게 접근을 하게되면~ A 관련 정보도 듣게 됩니다.
    • 이 시점이 되면, A 와 B 는 C 없이도~ membership 정보를 직접교환하게 됩니다.
  • organization 간의 커뮤니케이션은 'gossip 프로토콜' 으로 이루어지기 때문에~ 'channel configuration' 에 최소 하나의 anchor-peer는 정의해주어야 하는것 입니다.
  • "고가용성 및 여분(redundancy)" 을 위해서, 'anchor-peer 집합'을 구성하는것도 추천 합니다.
• ACL(Access Control List)
  • ACL은 특정 'peer 리소스'에 관한, Access 정책 입니다.
  • ACL은 'channel configuration' 에 설정 합니다.
  • 즉, 'channel configuration block' 에 기록이 되있는 거죠. (그... 표준적인 config update 방식으로 수정 가능)
  • ACL은 key-value 쌍의 형식인데, key='리소스' & value='channel policy' 입니다.
    • 예) lscc/GetDeploymentSpec : /Channel/Application/Readers
    • chaincode의 "GetDeploymentSpec API"는 "/Channel/Application/Readers" 만 호출이 가능
  • configtx.yaml 에 잘 설정 하세요. ㅎ
• Block
  • block은 "순서화된 transaction 집합"이라고 볼 수 있습니다.
  • 아시는것처럼, 앞(preceding) 과 뒤(subsequent) block이 연결되있습니다.
  • block은 orderer가 만들고, peer가 검증합니다.
• Chain
  • ledger의 chain이란, (block으로 연결된 구조의) 'transaction log' 입니다.
  • peer는 orderer에게 block를 받고, 해당 transaction이 (보증정책 및 동시성위반) 유효/무효 한지? 표시합니다.
  • 이후, peer는 이런 block을 하나씩 chain에 붙여넣습니다.
• Chaincode
  • Smart-Contract 입니다.
• Channel
  • private blockchain에서는 channel이라는 개념으로 "데이터 격리 및 기밀유지"를 합니다.
  • channel에 참여하는 peer들은 상호간에 ledger가 공유됩니다.
  • 그리고 거래 당사자들은 옳바르게 인증이 되어야 합니다.
  • channel 관련 정보는 'configuration block'에 기록 됩니다.
• Commit
  • channel의 각 peer는 block을 검증하고, 'ledger 복제본'에 커밋(write/append)을 합니다.
• Concurrency Control Version Check
  • "동시성제어버젼 확인"은 channel의 peer간에 상태를 동기화하는 방법 입니다.
  • peer는 병렬적으로 transaction을 실행하고... (ledger 커밋하기 전) 실행하는동안 데이터가 안바꼈는지? 확인 합니다.
  • 만약에 데이터가 바꼈다면, "동시성제어버젼 위반"이 발생하면서~ 해당 transaction은 '무효'로 ledger에 표식 됩니다.
  • 이렇게되면 결과적으로 'world-state database'에 해당값이 업데이트 되지않습니다.
• Configuration Block
  • channel의 'member 및 정책'을 정의하는 configuration 데이터 블록.
  • (channel 혹은 '전체 네트워크' 관련) configuration에 수정시, 새로운 'config-block'을 chain에 적절하게 붙여넣으면 됩니다.
  • 기본적으로 'genesis-block' 내용에 +delta가 추가된 데이터 입니다.
• Consensus
  • transaction 순서 및 정확성을 확인하는 등... block 구조화에 이루어지는 전반적인 흐름을 포괄.
• Consenter set
  • Raft 에서, orderer-node는 channel의 consensus에 적극적으로 참여하는데...
  • system-channel의 orderer-node 중에는... 해당 channel의 소속이 아닐수있음.
  • 해당 channel의 concenter-set으로 이를 관리함.
• Consortium
  • blockchain-network에서 orderer 없이 참여한 organization들 입니다.
  • peer만으로 channel을 형성하고 참여하는 organization이란 의미죠.
  • blockchain-network에는 여러개의 consortium이 있을수 있지만, 대부분 단일 consortium 입니다.
  • channel 생성시에, 참여하는 organization은 특정 consortium으로 미리정의 해두어야 합니다.
  • 하지만... consortium으로 정의하지 않는 organization을 기생성된 channel에 추가될수는 있습니다.
• Current State
  • World-State를 보삼...
• Dynamic Membership
  • Hyperledger Fabric 에서는 '전체 네트워크'에 영향없이 member, peer-node, orderer-node 등의 '추가/제거'를 지원 합니다.
  • Dynamic Membership은 비지니스 관계가 조정되고, 각종 요소들의 '추가/제거'에 아주 핵심적입니다.
• Endorsement
  • 특정 peer-node가 chaincode의 transaction을 실행하고, 해당 proposal에 관한 응답을 하는 프로세스를 의미합니다.
  • proposal에 관한 응답에는 'chaincode 실행 메세지', '결과(rw-set)', '이벤트', 'peer 서명'이 포함 됩니다.
  • 각 chaincode에는 특정 보증-peer를 명시하는 "보증 정책"을 가지고 있습니다.
• Endorsement Policy
  • 특정 chaincode으로 발생하는 transaction을 꼭 실행해야하고 보증받아야하는 peer-node 를 명시합니다.
  • "보증 정책"은 최소한 보증받아야하는 보증-peer 갯수를 등등을 정의합니다.
  • "보증 정책"은... (고의든 아니든) 보증-peer의 오류를 감안해야 합니다.
  • 제출된 transaction은 보증정책을 만족한뒤에, 커밋할 peer에 의해 유효함을 표식받게됩니다.
  • 'install 및 instantiate' 관련 transaction 에도 "보증 정책"이 정의되어 집니다.
• Follower
  
  • Raft같은 리더기반 consensus 프로토콜에서, leader-node를 복제하는 node를 의미합니다.
  • Raft에서 follower-node는 leader-node로 부터 "heartbeat 메세지"를 받습니다.
  • 그래서 leader-node가 "heartbeat 메세지"를 못보내게 되면, follower-node들은 leader-node를 재선출 합니다.
• Genesis Block
  
  • ordering-service를 초기화하는 config-block 으로, chain의 첫 block 입니다.
• Gossip Protocol
  
  • gossip 데이터 전파 프로토콜은 3가지 기능을 수행합니다.
  • 1) peer 감지 와 channel membership 을 관리합니다.
  • 2) channel의 모든 peer에게 ledger 데이터를 전파 합니다.
  • 3) channel의 모든 peer의 ledger 상태를 동기화 합니다.
• Hyperledger Fabric CA
  
  • Hyperledger Fabric CA는 디폴트 CA 컴포넌트 으로, PKI 기반의 인증서를 발급합니다.
  • CA는 '루트 인증서(rootCert)'를 각 member에게 발급을 하고, '등록 인증서(ECert)'를 각 인가된 user에게 발급 합니다.
• Initialize
  
  • chaincode application을 initialize하는 메쏘드.
• Install
  
  • peer의 파일 시스템에 chaincode를 옮기는 과정.
• Instantiate
  
  • 특정 channel에 chaincode application을 초기화 하는 과정.
  • instantiate 이후에 (install 된 chaincode를 가지고 있는) peer만 chaincode 호출을 받을수있습니다.
• Invoke
  
  • chaincode 함수를 호출하는데 사용 합니다.
  • 즉, client application에서 transaction proposal을 peer에게 보네서~ chaincode를 촉발 시킵니다.
  • peer는 chaincode를 실행할것이고, 해당 proposal 관해 '보증한 응답'을 client application에 리턴 합니다.
  • client application는 "보증 정책"을 만족하는 충분한 'proposal 응답'을 받을것이고, transaction 결과(순서-검증-커밋)를 제출 할것입니다.
  • client application는 transaction 결과를 제출하지 않도록 할수도있습니다.
  • 예를들어, ledger를 단순히 조회하는 쿼리를 촉발할 경우처럼~ client application는 일반적으로 read-only transaction 저출하지 않습니다. (감사용 목적의 ledger는 예외)
  • invoke 에는 'channel 아이디' 및 'chaincode 함수' 및 '아규먼트'가 포함됩니다.
• Leader
  • (Raft 같은 리더기반) 'consensus 프로토콜' 에서 leader는 새로운 'log 항목'을 수집하고, follower orderer-node에게 복제를 하고, 항목이 커밋되는 시점을 관리 합니다.
  • 특별한 타입의 orderer가 아닙니다. 특정상황에 orderer가 하는 하나의 역할 입니다.
• Leading Peer
  • 각 organization 은 '복수의 peer'을 구성할수있습니다. 그리고 channel당 하나 이상의 leading-peer가 있어야 합니다.
  • leading-peer는 organization를 대표해서, orderer와 통신을 하는것 입니다.
  • orderer는 leading-peer에게 block을 전달하고, leading-peer는 다른 peer들에게 배포합니다.
• Ledger
  
  • ledger는 'blockchain' 과 'state database(world-state)' 이렇게 두가지의 파트로 구성됩니다.
  • 'blockchain'는 불변의 ledger 입니다. 즉, chain에 한번 추가된 block은 불가역적 인것 입니다.
  • 이와대조적으로 'state database(world-state)'는 key-value 쌍의 현재상태이고, transaction에 의해 추가-수정-삭제 됩니다.
  • 네트워크의 각 channel마다, 논리적인 ledger가 하나씩 있다고 생각하시면 쉽습니다.
  • 실직적으로는 channel의 각각에 peer마다, ledger 사본이 consensus 과정을 통해~ 잘 유지되는것 입니다. 
  • "Distributed Ledger Technology(DLT)"가 바로 이런 개념의 원장인것 입니다. 
• Log entry
  
  • "Raft ordering service"의 기본작업 단위로써, log-entry는 leader에서 -> follower으로 분배 됩니다.
  • 한 log를 이루는 각 항목을 log-entry라고 하는것 입니다.
  • 한 log의 항목과 그 순서가 모든 member에게 동의 받으면, 그 log는 일관성이 있다고 판단되어 집니다.
• Member
  
  • "Organization" 을 참고하삼.
• Membership Service Provider
  
  • MSP는 client 및 peer가 Hyperledger Fabric에 참여하도록 자격증명을 제공하는, 추상개념의 시스템 입니다.
  • client는 그들의 자격증명을 transaction 인증에 사용 합니다.
  • peer는 그들의 자격증명을 transaction 보증 인증에 사용 합니다.
  • 시스템의 "transaction 처리 구성요소"와 밀접에 연관되어 있어 보이지만, 
  • "transaction 처리 구성요소" 의 핵심을 고치지 않더라도~ 쉽게 대체구현을 플러그인 하는 인터페이스화를 목표로 하고 있습니다.
• Membership Services
  
  • 허가형 blockchain-network에서 identity를 인증 -인가-관리 하는것을 의미 합니다.
  • peer 및 orderer 에서 돌아가는 membership-service 코드가 "blockchain 작업"의 인증 및 인가 처리를 합니다.
  • MSP 추상개념으로 PKI 기반으로 구현되어 있습니다.
• Ordering Service
  
  • block에 transaction의 순서를 정하는 node 집합을 의미 합니다.
  • ordering-service는 peer 프로세스와 독립적으로 존재하면서, 모든 channel에 transaction을 선착순( first-come-first-serve)으로 순서화 합니다.
  • ordering-service 프로세스 구현체를 플러그인 할수있도록 되어있습니다. (SOLO, Kafka, Raft, ...)
  • ordering-service는 네트워크 전체에 공통으로 엮여있고, 각 member 관련 암호화된 identity를 포함 합니다.
• Organization
  
  • "members" 와 같은 의미로 불리며, organization는 blockchain-network 에 초대되어 합류하게 됩니다.
  • 한 organization 은 그들의 MSP를 네트워크에 추가하면서 합류하게 되게 됩니다.
  • 해당 MSP는 네트워크의 다른 member가 확인을 할수있는 방법을 정의하는것 입니다. (해당 organization의 서명 등)
  • MSP 내에서 한 identity의 특정 접속권한은 organization이 네트워크에 합류할때 합의된 정책에 따라 결정 됩니다.
  • organization는 큰 다국적 기업이 될 수도 있고, 작은 개인이 될 수 도 있습니다.
  • organization의 최종 transaction endpoint 는 peer 이고, organization이 모여서 consortium을 이룹니다.
  • 네트워크의 모든 organization는 members 이지만, 모든 organization이 한 consortium의 소속은 아닙니다.
• Peer
  
  • ledger를 유지하고 (R/W 작업을 수행하는) chaincode 컨테이너를 돌리는 네트워크 요소 입니다.
  • peer는 members에 의해 소유되고 관리됩니다.
• Policy
  
  • 정책은 identity의 속성으로 구성되는 표현식입니다. (예: Org1.Peer , Org2.Peer)
  • blockchain network 상의 리소스의 접근제한을 하는 용도 입니다.
  • 즉, ACL을 통해서~ 누가 channel을 R/W 할수있는지? 누가 특정 chaincode를 사용할수있는지? 를 나타네는것 입니다.
  • 정책은 "ordering-service 부트스랩" 및 "channel 생성" 하기전, 'configtx.yaml'에 정의 하거나~ chaincode를 instantiate시에 명시합니다...
• Private Data
  
  • 각 peer의 private-database에 저장되는 '기밀데이터'는, 논리적으로 'ledger 데이터'와는 분리되어 있습니다.
  • '기밀데이터' 접근은 private-data collection 정의에 따라, 하나 또는 몇개의 organization으로 제한됩니다.
  • 인가되지않은 organization은 "private-data Hash값"을 가지기는 하는데, transaction의 증거로 사용하는거 같습니다.
  • 또한 개인정보보호를 위해서, (private-data자체가 아닌) "private-data Hash값"이 ordering-service으로 가고~
  • 그래서 orderer으로 부터도 기밀유지를 할수있는것 입니다.
• Private Data Collection (Collection)
  
  • 만약 한 channel에서 둘이상의 특정 organization이 자기들끼리 '기밀데이터'를 관리하고 싶을수있습니다.
  • 이렇게 collection에 몇몇 organization 부분집합을 정의해서, 그들만의 private-data를 거래할수있는것 입니다.
• Proposal
  
  • channel의 특정 peer에게 보증을 요청하는것 입니다.
  • 각각에 proposal은 instantiate하거나 invoke(R/W)하는 요청입니다.
• Query
  
  • query는 chaincode으로 ledger의 현상태를 읽기만 하고, 쓰지는 않는것 입니다.
  • chaincode 함수으로 ledger의 특정 key를 조회하는 것 이죠.
  • query는 ledger의 상태를 바꾸지 않기 때문에, client에서 transaction 제출할 필요가 없습니다. (순서-검증-커밋 필요없음)
  • 일반적이진 않지만, client에서 강제적으로 transaction 제출할수는 있습니다. (특정시점 ledger상태에 관한, 감사 증명하는용)
• Quorum
  
  • transaction이 처리되기 위해, proposal을 확인해줘야 하는 member의 최소 정족수.
  • 모든 승락자 node들의 다수가 되어야 합니다. (5개의 node가 있다면, 3개는 승락해야 정속수가 됩니다.)
  • 어떻한 이유에서든 node의 정족수가 불능하게 된다면, R/W를 하거나 새로운 log커밋이 불가하게 됩니다.
• Raft
  • v1.4.1에서 새롭게 crash-fault-tolerant(CFT)인 ordering-service가 제공됩니다.
  • (자세한 'Raft 프로토콜' 원리는 잘 찾아 보셈)
  • Raft는 "leader follower 모델" 입니다.
  • leader는 channel당 하나씩 선출이 되고, follower는 그의 결정,판단을 복제 합니다.
  • 기본적으로 'Kafka 프로토콜'에 비해서 구축 및 운영이 쉬운것이 장점 입니다.
  • 각각의 참여하는 organization이 '분산 ordering-service'로써 노드 기증하기도 용이합니다.
• Software Development Kit (SDK)
  
  • Hyperledger Fabric client SDK가 chaincode 개발자에가 잘 제공 됩니다.
  • ...
  • ...
  • ...
• Smart Contract
  
  • smart-contract는 코드 입니다. (blockchain network 외부의 client에 의해 호출됨)
  • world-state의 key-value쌍의 집합을 접근하고 수정하는 코드입니다.
  • Hyperledger Fabric에서는 smart-contract를 chaincode라고 부릅니다.
  • chaincode는 peer-node들에 install 되고, 하나 또는 몇몇개의 channel에 instantiate 됩니다.
• State Database
  
  • 현재의 상태정보는 state-database에 저장되어서, 효과적으로 chaincode가 읽고 조회 할수있습니다.
  • levelDB 나 couchDB 으로 제공이 됩니다.
• System Chain
  
  • 시스템 차원에서 blockchain network 설정을 정의하는 config-block을 가지게 됩니다.
  • 시스템체인은 ordering-service에서 동작을 하고, channel과 비슷한하고, 초기화 설정정보를 가집니다. (MSP정보, 정책, 기타설정, ... )
  • (새로운 organizatino이 참여하거나 orderer-node가 추가되는 등) 네트워크 전역적인 변경하면, 해당 config-block이 시스템체인에 추가 됩니다.
  • ;
  • 시스템체인은 channel 혹은 channel그룹 에 대한 공통된 묶음 이라고 생각 할 수 있습니다. (뭔말?)
  • 예를들어, 금융기관들은 그들에 컨소시엄을 형성을~ 시스템체인으로 할수있습니다.
  • 그리고 그들은 조율된 다양한 사업적 아젠다를 기준으로 channel을 만들어 가면 됩니다.
• Transaction
  
  • invoke하거나 instantiate한 결과이고, 이 결과는 순서-검증-커밋 을 위해서~ 제출이 되어집니다.
  • invoke는 ledger의 데이터를 R/W하는 요청 입니다.
  • instantiate는 channel에 chaincode를 초기화 하는 요청 입니다.
  • 바로 client에서 invoke 및 instantiate 요청에 대한 -> '보증-peer'의 응답을 모아서 -> transaction으로 패키징하고 -> 순서-검증-커밋 을 위해 제출합니다.
• World State
  
  • 어

-끝-