하이퍼레저 패브릭 - Orderer

Ordering?

Orderer

1. 트랜잭션 제출
분산 애플리케이션이 트랜잭션 보증을 담당하는 Endorsing peer에게 트랜잭션을 제출 ~ 해당 트랜잭션이 가리키는 체인코드 실행
• DApp은 트랜잭션을 Endorsing peer에게 제출
• 트랜잭션을 받은 Endorsing peer들은 Proposal 값을 바탕으로 체인코드를 시뮬레이션 함
• 올바른 결괏값이 나온다면 Endorsing peer는 자신의 Identity를 이용해 서명한 디지털 인증서와 Read/Write set을 함께 DApp에 전송

2. 블록 패키징(Block Packaging)
트랜잭션 제출 과정에서 제출한 트랜잭션을 orderer가 수집하여 순서대로 정렬한 후 최신 블록을 생성
• DApp은 전달받은 Read/Write set과 Endorsing peer의 디지털 인증서를 트랜잭션과 함께 orderer에 전송
• orderer는 해당 트랜잭션을 순서대로 정렬한 후 최신 블록을 생성
• orderer은 자신이 속한 채널의 모든 트랜잭션을 순서대로 정렬한 후 채널별로 블록을 생성함
Ordering service
• Apache 소프트웨어 재단에서 개발한 Kafka 분산 메시징 시스템을 이용해 구현됨 → Raft
• Kafka
• 대표적인 Pub-Sub(Publish-Subscribe) 모델
• Consumers가 Producer로부터 Topic 단위로 구분된 메시지를 수신하는 분산 메시징 시스템
• Producer는 Broker로 구성된 카프카 클러스터(Kafka cluster)로 Topic 메시지를 전달하면 카프카 클러스터는 Topic 메시지를 파티션에 순차적으로 정렬
• Topic 메시지는 여러 파티션에 복사되어 저장 → 특정 파티션을 담당하는 Broker에 장애가 발생하더라도 다른 Broker의 파티션으로부터 손실된 정보를 불러올 수 있음 → 안정성 향상
• Topic별로 일정 시간이 경과하거나 일정 크기 이상의 메시지가 들어오면 해당 Topic에 대한 메시지를 Consumer에게 전달
• 각 채널의 분산원장이 카프카의 Topic으로 처리
• orderer는 Producer, peer는 Consumer

3. 검증
orderer가 생성한 최신 블록을 각 조직의 peer들에게 전달하고, 최신 블록을 전달받은 peer는 해당 블록이 올바르게 생성됐는기 검증하는 과정
• orderer가 자신이 생성한 최신 블록을 각 조직의 Leader peer에게 전달
• Leader peer는 orderer로부터 전달받은 최신 블록을 자신이 속한 채널의 peer들에게 배포
• 최신 블록을 받은 peer들은 불록에 포함된 결괏값이 정상인지, 각각의 트랜잭션 결괏값이 보증 정책에 부함하는 등의 검증 작업을 수행 후, 문제가 없을 경우 자신의 로컬 저장소에 저장된 블록체인에 최신 블록을 추가하고 World state 데이터베이스를 업데이트
 

트랜잭션 Flow와 Orderer

1. Proposal(제안)
이 프로세스의 자세한 설명은 Peer 문서에 정리

1. 트랜잭션을 블록으로 주문 및 패키징
• 이 단계에서 애플리케이션 클라이언트는 승인된 트랜잭션 Proposal 응답을 포함하는 트랜잭션을 Ordering Service 노드에 제출한다.
• Ordering Service는 3단계에서 최종 유효성 검사 및 커밋을 위해 궁극적으로 채널의 모든 Peer에게 배포될 트랜잭션 블록을 생성한다.
• Orderer 노드는 여러 애플리케이션 클라이언트로부터 동시에 트랜잭션을 수신한다. → Orderer는 제출된 트랜잭션 배치를 정렬하고, 블록으로 패키징한다.
• 채널 configtx.yaml의 BatchSize, BatchTimeout에 따라 블록 크기 및 최대 경과 시간이 달라진다.
• 블록은 Orderer의 Ledger에 저장되고 채널에 참여한 모든 Peer들에게 배포된다.

1. 유효성 검사 및 커밋
• 트랜잭션 WorkFlow의 세번째 단계는, Orderer에서 Peer로, Ledger에 커밋될 수 있는 블록의 배포 및 유효성 검사를 포함한다.
• Orderer은 연결된 모든 Peer에게 블록을 배포한다. 모든 Peer가 Orderer에게 연결될 필요는 없다 → Gossip 프로토콜을 사용
• 채널의 각 Peer은 블록의 각 트랜잭션을 검증하여 조직의 Peer가 승인했는지, 승인이 일치하는지, 최근에 커밋됐는지 확인한다.
• 검증이 성공적으로 완료하면, 각 Peer들은 자신의 Ledger 사본에 블록을 추가한다. 프로세스가 완료되면, 연결된 애플리케이션에 트랜잭션이 처리되었음을 알릴 수 있다.
 

Ordering Service 구현 - Raft

Raft

• .NET의 etcd Raft 프로토콜 구현을 기반으로 하는 주문 서비스

• 내결함성(여러 서버들 중 일부 서버에 장애가 발생하더라도 기능을 유지)하는 특성을 가진다.

• 리더 및 팔로워 모델을 따른다. 리더는 채널당 하나씩 선출된다.
 

Leader-Follower

Log Replication

• 클라이언트로 부터 새로운 요청이 전달되면, 리더는 로컬에 해당 로그를 저장하고 로그를 복제하여(AppendLogEntry) 팔로워 노드들에게 전송한다. 모든 로그는 고유한 인덱스 값을 갖는다.

• 요청의 순서가 올바른 경우, 팔로워는 해당 로그를 복제하고 성공 응답을 리더에게 전달한다.

• 요청 순서가 올바르지 않거나 장애가 생긴 경우, 팔로워는 nextIndex 를 실패 응답에 실어서 리더에게 전달한다. 리더는 nextIndex 값을 보고 팔로워들의 상태를 파악하고 밀린 로그들을 팔로워에게 다시 진행하여 복구를 진행한다.

• 과반수 이상의 노드에서 성공 응답이 도착하면, 리더가 마지막으로 해당 로그를 커밋하고, 클라이언트에게 성공 응답을 전송한다.

Election

• 리더는 클라이언트로부터 새로운 요청이 없더라도, 지속적으로 팔로워에게 AppendLogEntry 를 전송하여 자신이 살아있음을 알린다. 만약 리더에 문제가 생겨, 팔로워가 ElectionTimeout 시간만큼 AppendLogEntry를 받지 못한 경우, 팔로워는 리더가 되기 위한 후보자, Candidate으로 전환된다.