안녕하세요?

이번 글에서는 변화된 Hyperledger Fabric v1.0의 아키텍처에 대해서 알아보고자 합니다.

Hyperledger Fabric의 영문 문서들은 다음의 링크에서도 지속적으로 업데이트되고 있으니 참조하세요. Fabric 기술문서
최종 Fabric v1.0이 발표되기 전까지 아키텍처를 설명하는 문서의 내용이 변경되고 있습니다. 최종 GA 되긴 전엔 설명의 내용이 다소 변경될 수 있습니다.

1. Fabric v0.6 아키텍처

Fabric v0.6의 아키텍처를 되돌아 보면 Membership Service, Peer로 구성되어 있었습니다.
Membership Service는 사용자에 대한 enroll 및 관련 인증서를 생성,조회 등을 담당하는 컴포넌트였고,
Peer 에서 블록체인 개념에서 필요한 작업들(합의 알고리즘, 체인코드, 이벤트, 원장 관리 등)을 수행했었습니다.

2. Fabric v1.0 아키텍처

Fabric v1.0 의 컨셉은 다음과 같습니다

  • 트랜잭션에 서명(Endorsement)하여 비즈니스 프로세스에 반영
  • 개인정보 보호 및 기밀유지 지원
  • 참여자 수와 트랜잭션 처리량(TPS) 조절
  • 비결정적(non-deterministic) 트랜잭션 제거
  • 플러그인 방식의 데이터 스토어(원장관리를 위한 DB)
  • Fabric과 체인코드의 동적 업그레이드 지원
  • SPF(Single Point of Failure)를 제거하고 멀티플 멤버쉽 서비스를 가능하게 함

그 중 가장 큰 변화는 Peer의 역할입니다. 이전 버전에서 모든 역할을 하나의 Peer 즉, Validating Peer 에서 수행하던 것을 다음과 같이 두 가지의 역할로 나눠서 수행합니다.

  • Endorsing Peer ( Endorser )
  • Ordering-service-node ( Orderer )


[출처] : https://jira.hyperledger.org/browse/FAB-37

위의 그림에서 보는 것처럼 새로운 버전인 Fabric v1.0 에서는 SDK의 역할이 더욱 커집니다.
이전 버전에 있던 REST API는 없어지고 grpc 또는 CLI를 통해서 블록체인 서버와 통신을 하며 다소 복잡해진듯이 보이는 트랜잭션의 흐름을 가지고 있습니다.

트랜잭션 흐름을 아주 간략하게 설명하면 다음과 같습니다.

  1. 최초 Client가 블록체인에 트랜잭션 수행을 위한 Proposal을 합니다.
  2. Proposal은 Endorse Peer에서 수행됩니다.
  3. Endorser들은 Poroposal을 endorsement policy에 의거해 Validate하여 서명을 한 뒤 Proposal response를 Client에게 보냅니다.
  4. 서명된 proposal response를 받은 Client는 트랜잭션을 수행합니다.
  5. 트랜잭션은 모든 채널에 대해서 Orderer가 받아서 트랜잭션의 순서대로 정렬을 합니다.
  6. Orderer에 의해 정렬된 트랜잭션은 해당 채널을 통해 다시 Peer로 보내져서 최종적으로 원장으로 저장됩니다.

위의 흐름에서 Endorse는 비결정적인 트랜잭션을 제거하여 결정적인 트랜잭션만 처리하도록 하는 역할을 하게되며,
Orderer는 Fabric v0.6 에서 Validating Peer 가 수행했던 PBFT와 비슷한 SBFT와 같은 합의 알고리즘을 수행합니다.(정확히 PBFT는 아닙니다)

또한, 채널이라는 개념이 추가되는데 채널은 실제 체인코드가 디플로이되고 트랜잭션이 실행되는 구간입니다. 즉 아래와 같이 두개의 채널(파란선, 붉은선) 각각 다른 비즈니스 로직을 담고 있는 체인코드가 실행되며,
채널이 생성될 때 해당하는 Peer를 지정할 수 있습니다.
아래 그림에서와 같이 같기 다른 조직에서 동작하고 있는 Peer를 하나의 채널로 통합하게 되면 동일한 비즈니스 로직이 돌아가는 환경이 됩니다.
채널이라는 개념을 통해 비즈니스적인 확장성을 제공해 줄 수 있으리라고 판단됩니다.

Ordering Service는 다음의 설정 옵션을 가지고 있습니다.

  • SOLO : 싱글 노드로 설정
  • Kafka / Zookeeper : 1:n 노드로 Crash Fault Tolerance 제공하며, 홀수 노드를 권장함.
  • SBFT (Future) : 1:n 노드로 Byzantine Fault Tolerance 제공

3. 정리하며

이번 글은 새롭게 GA될 Fabric v1.0 의 아카텍처 중 표면적인 컴포넌트 들에 대해서 간략히 설명을 하였습니다.
변화된 컴포넌트만 해도 그리고 그에 따른 트랜잭션의 흐름만 대략봐도 많은 부분에 대해서 변화가 있었고 그 말은 공부할 내용이 많아졌다고 느껴집니다.
앞으로는 좀 더 상세하게 트랜잭션의 흐름을 설명하면서 각 컴포넌트의 역할에 대해서 이해하는 시간을 가지려고 합니다.

앞으로도 이어질 내용 기대바랍니다.