Hyperledger Fabric 거래처리 방식

Hyperledger Fabric 거래 처리 방식 비교

하이퍼레저 패브릭은 기존의 다른 블록체인 시스템과 거래 처리 방식에 있어서 차이가 있습니다.

기존 블록체인 시스템과의 처리방식 비교

기존 블록체인에서는 Transaction Pool(혹은 Mem Pool) 같은 메리상에서 트랜잭션들을 한데 모으고, 그 순서대로 처리한 후 블록 안에 기록해두는 것이 일반적인 방식인데 패브릭에서는 조금 다릅니다. 먼저 피어(Peer)에게서 실행을 해본 후 실행 결과를 받아서 그것을 Orderer 서비스에 보냅니다. 그런 후 commit을 하여 장부(Ledger) 내용을 다시 피어에게 공유하는 순서로 진행됩니다.

1. 거래보증
2. 거래들의 순서 정렬
3. 거래 확정

Endorsing Peer

이렇게 맨 처음 피어에게 트랜잭션을 실행해 보는 특정 피어를 Endorsing Peer라고 합니다. 그런 후 실행결과를 ReadSet, WriteSet 형태로 가져옵니다. 하이퍼레저에서 트랜잭션이라고 하면 체인 코드의 실행을 의미합니다. 이런 프로그램은 결국 어떤 상태 값을 read혹은 write 하는 것이 목적입니다. 따라서 이렇게 변화된 내용들을 가져오는 것입니다. 

만약 read의 경우에는 여러번 수행되어도 상관이 없지만 write 같은 경우는 어떻게 되어야 할까요? 하이퍼레저는 write 같은 경우 한 블록 내에 한번의 트랜잭션 때만 실행되도록 합니다. 그래서 연속으로 변경되어야 한다면 그 다음 블록 때 수행되도록 처리하였습니다.

패브릭 트랜잭션 처리 순서 흐름도

Membership Services Provider

패브릭은 허가형 블록체인입니다. 그래서 허가를 해준다는 기능 자체가 필요합니다. 누가나 참여가능한 공개형 블록체인과는 다른 점이죠. 이렇게 승인을 계속 확인하는 별도의 서비스 제공자가 존재하는데 이른 MSP(Membership Services Provider)라고 합니다.

하이퍼레저 패브릭 아키텍쳐

패브릭의 트랜잭션 처리를 MSP와 연관지어 모듈들의 관계를 정리해보면 위의 그림과 같습니다. 이렇게 구분된 모듈들은 Docker 같은 컨테이너 환경으로 각각을 실행할 수 있습니다.

그래서 하이퍼레저는 동작시키는 것이 상대적으로 복잡하고 어렵지만, 모듈단위로 실행 및 확장이 가능한 장점이 있습니다.