Hyperledger Fabric: Transaction Flow

이번 포스팅에서는 Hyperledger Fabric의 transaction이 어떻게 생성되고 ledger에 최종적으로 commit되는지 이해가 잘 되도록 예시를 들어 설명되어 있는 글을 Hyperledger Fabric doc에서 발견해서 번역해보았다. 원본 링크: https://hyperledger-fabric.readthedocs.io/en/release-1.2/txflow.html

Scenario

상품 거래를 하는 시나리오를 가지고 어떻게 transaction이 발생하고 ledger에 commit되는지 그 과정에 대해서 설명하려고 한다. 예시로 사용할 시나리오에서는 A, B라는 두 명의 client가 있고 각각은 당근을 사고 팔려고 한다. client A, B 각각 자신의 네트워크에 피어를 가지고 있고 그 네트워크를 통해 각각의 transaction을 보내고 ledger에 기록한다.

Assumptions

이 시나리오에서는 channel이 세팅되어있다고 가정한다. 그리고 어플리케이션의 user들은 각 organization의 CA에 register & enroll하고 cryptomaterial materal을 생성했다. 그리고 user들은 이것을 이용해서 network authentication에 사용한다.

각 피어들에게 chaincode (당근 시장의 초기 상태를 나타내는 key & value pair들이 포함되어있다.)가 installed되었고 channel에 instantiated되었다. chaincode에는 transaction instructions set이 정의되어있다. Endorsement policy 또한 이 chaincode에 세팅되어 있고 이 때 policy는 모든 transaction에 대해서 피어 A, B 모두 endorse해야한다고 정의된다.

1. Client A initiates a transaction

먼저 구매자인 client A가 당근을 구매하겠다는 request를 보낸다. 이 때 이 request는 peerA와 peerB를 타겟으로 삼는다. 왜나하면 channel이 만들어질 때 정의된 endorsement policy에 따르면 모든 피어들이 transaction에 대해서 endorse 해야하기 때문이다.

그 다음, transaction proposal이 생성된다. SDK를 사용하고있는 어플리케이션에서는 SDK API 함수를 이용해서 transaction proposal을 생성한다. 이 proposal은 chaincode를 invoke 해달라는 요청인데, 결과적으로 이 proposal을 이용해서 ledger를 읽거나 쓸 수 있다. 여기서 사용하는 SDK는 transaction proposal을 gRPC를 통해 전송될 수 있는 포맷으로 패키징하는 역할을 해준다. 그리고 이 패키징에 user의 cryptographic credential을 이용해서 이 transaction proposal의 유일한 signature를 만들게 된다.

2. Endorsing peers verify signature & execute the transaction

그 다음 단계로 endorsing peer들은 이전 단계에서 만들어진 transaction proposal을 받게 되는데 다음과 같은 사항들을 확인한다.: (1)첫 번째로 이전 단계에서 만들어진 transaction proposal들이 잘 만들어졌는지 확인하고 그리고 (2)똑같은 transaction proposal이 이전에 요청되었는지도 확인한다. (replay-attack protection) (3) 세 번째로 signature가 유효한지 MSP를 이용해서 확인하고 (4) 마지막으로 요청을 전송한 submitter(현재 시나리오에서는 Client A이다.)가 현재 channel에 proposed operation을 할 수 있는 권한을 가지고 있는지 확인한다. 다시 말하면 submitter가 현재 channel의 Writers policy를 충족하는지 확인한다.

endorsing peer들은 transaction에서 invoke 되고 있는 chaincode의 함수 인자를 가지고 다시 chaincode를 현재 데이터베이스 상태에 대해서 실행시킨다. 그리고 그것들을 실행시킨 결과로 response value, read set 그리고 write set을 만들게 된다. 그런데 중요한 점은 chaincode의 함수를 실행시켜본 것이지 그 결과를 이용해서 ledger를 업데이트 시킨 것은 아니다. 아까 말한 세 가지 결과와 endorsing peer의 signature를 합쳐서 proposal response를 만들고 이것을 다시 SDK에 전송하게 된다. 어플리케이션에서는 payload를 파싱해서 사용하면 된다.

MSP
MSP는 client로부터 전달되는 transaction request들을 피어들로 하여금 검증할 수 있게 해주고 transaction를 검증한 결과에 대해서 sign 할 수 있게 해주는(endorsement) peer component이다. 이 때 writing policy는 channel이 생성될 때 정의되고 어떤 user들이 channel에 transaction을 제출할 수 있는지 명시한다.

3. Proposal responses are inspected

어플리케이션에서는 endorsing peer의 signature들을 검증하고 proposal response들을 가지고 서로 같은지 비교한다. 이 때 chaincode가 ledger를 조회하는 작업만 했다면 어플리케이션에서는 조회 결과만 확인하고 transaction을 Ordering Service에 제출하지 않는다.

만약 client 어플리케이션이 transaction을 Ordering Service에 ledger를 업데이트 시키기 위해 제출하려면 endorsement policy가 충족되었는지(peerA와 peerB 모두 endorse해야한다.)를 먼저 확인해야한다. 만약 어플리케이션 단에서 response를 확인하지 않고 unendorsed한 transaction을 보내거나 혹은 endorsement policy를 충족시키지 않는 transaction을 제출하게되면 commit validation 단계에서 reject 하게 된다.

4. Client assembles endorsements into a transaction

어플리케이션은 transaction proposal과 “transaction message”의 response를 Ordering Service에 보내게 된다. 그리고 transaction은 read/write set, endorsing peer의 signature들과 channel ID를 포함하고 있다. 이 때 Ordering Service는 transaction 전체를 살펴볼 필요가 없다. Ordering Service에서는 단순히 네트워크 상의 모든 channel에서 transaction을 받고 channel에 따라서 정렬한 다음 channel 별로 block을 생성하면 된다.

5. Transaction is validated and committed

위에서 생성된 block은 해당 channel의 모든 피어들에게 전송된다. 그리고 block에 있는 transaction들은 endorsement policy를 충족시키는지 검증하게되고 read set들에 대해서는 ledger state에 변화가 생기지 않았는지 확인한다. 이 검증 결과에 따라서 block의 transaction들은 valid나 invalid라는 태그를 달게된다.

6. Ledger updated

마지막으로 모든 피어들은 channel의 chain에 block을 연결시키게 되고 valid한 transaction의 write set들은 database에 commit된다. 그리고 client application에 transaction이 chain에 붙었다는 event가 전파되고 그 transaction이 검증된 것인지 아닌지도 알리게 된다.