[Hyperledger Fabric v2.0] Transaction Workflow

Transaction Workflow

Phase 1: Proposal

Phase 1 에서는 application 과 peer 들 간에 이루어지는 내용으로 orderer 와는 관계 없이 진행됨

Phase 1 에서는 오직 각기 다른 endorsing peer 들에게 chaincode 호출 결과 제안에 대한 동의를 요청 만을 고려 함

Phase 1 시작을 위해, 어플리케이션들은 transaction proposal 을 생성하여 승인을 위해 peer 들에게 전달함

전달 받은 endorsing peer 들은 독립적으로 transaction proposal 을 활용하여 chaincode 를 실행하고 이를 통해 transaction proposal response 를 생성함

• 해당 과정에서 ledger 로 기록은 없음, 그러나 서명 후 application 으로 전달 할 뿐

application 에서 충분한 signed proposal respose 를 수신하면 phase 1은 종료됨

detail process

Application은 proposed ledger 를 업데이트 할 peer 들을 선택함

• 이는 chaincode 에 정의 된 endorsement policy 에 의해서 peer 가 결정
• 해당 내용에 대해 ledger 반영이 필요한 organization 들은 필수로 다른 peer 들이 ledger 에 반영 하기 전에 proposed ledger 를 승인 해야 함

peer 들은 proposal response 에 승인을 함;

• digital signature 추가
• 전체 payload 에 대해 개인키로 서명

Phase 1은 application 이 충분한 peer 들로부터 signed proposal response 를 받으면 끝이 남

• 서로 다른 peer 들은 서로 다른 signed proposal response 를 응답 할 수 있음
• 이는 곧 동일한 transaction proposal 에 대한 inconsistent transaction response 가 됨, 이에는 다음과 같은 이유 때문;
  • 서로 다른 peer 들이 ledger 의 서로 다른 state 에 대해서 서로 다른 시간에 생성
  • 이는 곧 non-deterministic 한 chaincode 실행 결과를 의미
  • 각 peer 들은 자신의 실행 결과가 non-deterministic 한 지 알 수 없음
  • 그렇기 때문에, 트랜잭션 응답은 모아서 비교를 통해 non-deterministic 이 발생하기 전에 잡아야 함

Phase 1 마지막에는, application 은 inconsistent transaction respose 들을 필요시 삭제하여 트랜잭션 워크플로우를 조기 종료 할 수 있음

• application 에서 inconsistent transaction response 를 ledger 에 반영하려 시도한다면 이는 추후에 거절됨

Phase 2: Ordering and packaging transactions into blocks

• Orderer 는 application들 로부터 endorsed transaction proposal response 을 받음

• 그 후에 transaction 들을 block 으로 채워 넣음

For more details about the ordering and packaging phase, check out our conceptual information about the ordering phase.

Phase 3: Validation and commit

Phase 2 가 끝나면 orderer 들은 아래와 같은 역할에 책임이 있음

• proposed transaction 의 업데이트 내용 수집
• ordering : 블록에 넣을 트랜잭션 주문하기
• packaging : 주문한 트랜잭션들은 블록에 모으기
• ready for distribution : 채널의 peer들에게 block 배포 준비

이 후에 transaction workflow 의 마지막 단계는 다음과 같다

• distribution : 블록 배포
• validation : orderer가 배포한 블록에 대한 peers 의 검증 -> 이를 통해 ledger 에 반영 할 수 있음이 결정

모든 peer 는 검증된 블록에 담긴 모든 트랜잭션들에 대해서 ledger 에 반영 하기 전에 이 트랜잭션과 관련된 모든 organization 들에 의해 지속적인 승인 받은 것을 확실히 해야 함

이에 실패한 트랜잭션들은 차후에 확인을 위해 유지는 되지만 ledger 에 반영되지는 않음

detail process

Phase 3은 orderer 가 연결 된 모든 peer 들에게 블록을 배포 하면서 시작됨

연결된 peer 들은 신규 생성 블록의 사본을 orderer 로부터 받게 됨

각 peer 들은 해당 신규 블록 처리를 독립적으로 하지만 채널상 다른 모든 peer 들과 동일하게 처리함

이를 통해 ledger 가 지속적인 유지 가 됨

• c.f.) 모든 peer 들이 orderer 와 직접 연결될 필요는 없음; peer 들은 ordere 로 부터 받은 신규 블록을 다른 peer 들 에게 전달 할 수 있음 (gossip protocol)

블록을 받은 peer 는 순서에 따라 블록에 있는 각 트랜잭션들을 처리함 :

• 해당 트랜잭션에 승인이 필요한 organization 들로부터 받은 승인을 검증
  • 이는 chaincode 의 endorsement policy 에 따름
  • 검증이란, 동일한 outcome 혹은 result 에 대한 확인
  • 해당 검증에 실패하면, peer 는 해당 트랜잭션을 거절 할 수 있음
• 검증이 완료 되었다면, peer 는 자신의 ledger 에 반영
  • ledger 에 반영하기 위해, 트랜잭션이 propose 된 시점과 현재 시점 사이에 ledger state 상에 호환성을 검사 (a ledger consistency check)
    • 호환성 검사에 실패 할 수 있음, 다른 트랜잭션이 동일한 state 에 대해 업데이트를 일으 킬 수 있기 때문
    • 하지만 이 또한 channel 관점에서 consistency 가 유지 된다고 봄 (channel 상의 모든 peer 가 동일한 검증 절차를 진행 했기 때문)
• ledger 반영까지 이루어지면, 실패한 트랜잭션들은 audit purpose 로 유지를 하되 ledger 에 반영하지는 않음
  • 이 뜻은, peer 들이 보유한 block 의 내용물은 거의 동일하되 다만 각 트랜잭션에 대해 valid 혹은 invalid 태그만 다를 뿐임

Phase 3 에서는 chaincode 를 실행하지 않음, 이는 phase 1 에서만 함. 이를 통해 얻을 수 있는 특징

• 모든 peer 가 chaincode 를 알 필요가 없음, endorsing node 들만 알 뿐
• chaincode 의 실행 결과물(transaction proposal response)만 채널 상의 모든 peer 들에게 공유 될 뿐
• 이러한 endorsing peer 구조를 통해 scalabiliy 와 confidentiality 를 높일 수 있음

peer 들이 ledger 에 반영하게 되면 peer 들은 적절한 event 를 발생 시킴: block event,block transaction event, chaincode event

• block event : 블록의 모든 내용을 담고 있음
• block transaction event : 요약 내용 예를 들어, 블록의 각 트랜잭션의 validated 혹은 invalidated 와 같은 정보
• chaincode event : 체인코드가 실행되면서 생성

Application 들은 이러한 이벤트들을 등록하여 알림 받을 수 있음

​

요약하자면, phase 3 에서는 orderer 에 의해 생성된 신규 블록을 ledger 에 지속적인 반영을 할 수 있는지 확인함