아니 그래서 트랜잭션이 어떻게 일어난다구요?

블록체인에서 한 블럭이 더해지는 전 과정에 대해서 살펴봅니다. 트랜잭션 흐름을 살펴보면서, 본 시리즈의 향후 포스팅에서 상세히 다룰 이벤트/메시지 체계와 합의 알고리즘을 살짝 맛보도록 하겠습니다. 여기서 눈여겨 보셔야 할 부분은 Execute-Order-Validate 구조입니다. 다른 플랫폼은 Order-Execute 구조인 것과는 상반됩니다.

아래 포스팅은 HLF 공식 문서 Transaction Flow 페이지를 참고로 작성되었습니다.

출처: https://hyperledger-fabric.readthedocs.io/en/release-1.2/arch-deep-dive.html

Phase 1: Client A가 트랜잭션 요청(transaction proposal)

Client A가 블록체인 네트워크에 트랜잭션을 요청합니다. 예를 들어 중고차를 사고 싶어요!라고 요청을 보낸거죠. 그 거래에 대해서 승인해야 하는 피어가 endorsement policy로 정의되어 있는데, 이 단계에서 그 피어들에게 해당 요청을 전송합니다. 이 피어들에게 transaction proposal이라는 형태로 전송되는데, 클라이언트의 SDK는 이를 gRPC 프로토콜로 전송할 수 있는 프로토콜 버퍼 형태로 변형합니다. 또한 사용자의 신원 정보를 서명 형태로 proposal에 삽입합니다.

이 과정에서 클라이언트가 이벤트를 발생시키면, 피어들이 리슨하고 있다가 이제 그 다음 액션을 취하는 겁니다. 즉 일반적인 pub-sub 구조입니다만, 이 이벤트란 비즈니스 네트워크 모델 파일(.cto)에서 사전에 정의되어야 하며, 특정된 트랜잭션에서만 발생할 수 있다는 점이 다릅니다. 아래 Hyperledger composer documentation의 예시를 한 번 살펴보시죠.

Phase 2: Endorsing peers 가 서명을 확인하고 트랜잭션 실행

Endorsing peer는 일단 트랜잭션을 전달 받으면, 1) 트랜잭션의 형식에 맞게 내용이 잘 채워져있는지 2) 이전에 제출된 적 있었던 트랜잭션은 아닌지 3) 서명이 유효한지(MSP를 통함) 4) 트랜잭션을 제출한 클라이언트가 그럴 권한이 있는지 확인합니다. 이게 확인이 되면, Endorsing peer는 Transaction proposal을 인자로 받아서 체인코드를 실행합니다. State DB의 값에 체인코드가 실제로 실행되며 결과값, read/write set을 반환합니다. 이 시점에는 원장 업데이트는 하지 않고, 반환된 결과값을 proposal response로 클라이언트 SDK로 전송합니다.

Phase 3: Proposal responses 검토

그후 클라이언트 SDK가 Endorsing peer의 서명을 확인한 뒤 각 피어로부터의 proposal response를 비교하는 작업을 거칩니다. 단순한 쿼리 같이 Ordering service가 필요 없는 경우에는 쿼리 결과값을 얻고 프로세스가 종료됩니다. 원장 업데이트와 같은 경우, 클라이언트 차원에서 Endorsement policy에 준하는 proposal response가 왔는지(A, B가 모두 결과를 보냈는지) 검토합니다.

단, 이 단계에서 클라이언트가 endorsement policy를 검토하지 않는다고 해도, committing 단계에서 각 피어가 별도로 검토를 합니다.

Phase 4: 클라이언트가 Transaction 전달

검토가 완료되고 나면 클라이언트가 Transaction message에 proposal과 proposal response를 담아서 Ordering service에 보냅니다. 트랜잭션에는 read/write set이 들어가 있을 것이고, Endorsing peer의 서명과 채널 ID가 포함됩니다. Orderer는 트랜잭션 내용에 관계 없이, 모든 채널에서 발생하는 트랜잭션을 받아서 시간 순서대로 정렬하여 블럭을 생성합니다.

Orderer가 합의하는 방식은 기본적으로 pluggable하나, 지금 시점(2018년 8월 말) 기준으로는 SOLO와 Kafka 두 가지 알고리즘을 제공합니다. SOLO는 개발용이니 차치하고, Kafka는 간단히 이야기하면 in-out order에 특화된 알고리즘입니다. 이에 대해서는 향후 포스팅에서 조금 더 자세히 알아봅시다. 2018년 8월 Hyperledger Seoul Meetup에서도 간단히 다루었는데, 궁금하시다면 이 포스팅의 하단부를 참조하세요.

Phase 5: Committing Peer에서 트랜잭션을 검증하고 커밋

트랜잭션 블럭이 해당 채널의 모든 Committing Peer에게 전달됩니다. 각각의 committing peer는 블럭 내의 모든 트랜잭션이 각각의 Endorsement policy를 준수하는지, world state 값의 read-set 버전이 맞는지(read-set 버전은 트랜잭션 이후에만 변경됨) 확인합니다. 검사 과정이 끝나면 해당 블럭 내의 트랜잭션에는 valid/invalid 값이 태그됩니다.

Phase 6: Ledger updated

출처: https://hyperledger-fabric.readthedocs.io/en/release-1.2/txflow.html

각 피어는 최종 검증을 마친 블럭을 채널 내 체인에 붙입니다. 그리고 유효한 트랜잭션의 경우 write-set이 state DB에 입력됩니다. 일련의 과정이 마무리되면 이벤트를 발생시켜 클라이언트에게 작업 결과에 대해 알립니다.

토론 참가

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다