Hyperledger Fabric과 다른 블록체인 비교

Hyperledger Fabric(이하 Fabric)은 IBM이 주도하는 오픈소스 블록체인 플랫폼입니다.
다른 블록체인과 비교하였을 때 몇 가지 뚜렷한 차이가 있습니다.
본 문서에서는 일반적인 블록체인과 Fabric의 차이점에 관해 설명합니다.

분산DB의 동기화를 위한 블록체인 활용

일반적인 블록체인의 특성

일반적인 블록체인은 트랜잭션에 큰 의미를 부여합니다.
일정 시간 주기로 트랜잭션을 모아 블록으로 생성합니다.
이때 각 트랜잭션의 유효성을 검증하고,
한 블록에 담길 트랜잭션을 대표하는 Hash를 생성하여 이전 블록의 Hash와 함께 블록 Hash를 생성합니다.
모든 트랜잭션과 블록들이 끈끈하게 연결되어 있기 때문에,
한 개의 트랜잭션만 변경되어도 전체 체인의 값이 변경되게 됩니다.

Fabric의 특성

Hyperledger Fabric은 State DB로 사용되는 Level DB 트랜잭션을 동기화시킬 목적으로 블록체인을 활용합니다.
주기적으로 블록을 생성하고 블록생성 시에 트랜잭션을 검증하는 일반적인 블록체인과 달리,
Fabric은 트랜잭션을 전파하기 전에 체인에 참여한 기관의 Endorser에서 검증을 수행합니다.
프라이빗한 환경에서 사용한다고 가정하여 복잡한 블록생성 방법 대신 Kafka의 메시지 순서보장에 의존하고 있습니다.

합의 알고리즘

일반적인 블록체인의 합의 알고리즘

일반적인 블록체인은 위 그림과 같이 매우 단순한 구성을 갖고 있습니다.
클라이언트가 생성한 트랜잭션에 서명을 하고 이를 노드에 전달하면 노드가 트랜잭션을 검증하고,
다른 노드들에 전파합니다. 일정한 주기로 노드가 트랜잭션들을 모아 블록을 생성합니다.
블록을 생성하는 방식은 합의 알고리즘에 따라 다르지만,
엔터프라이즈 환경을 위해 작성된 블록체인은 RAFT와 같은 방식을 사용하여 빠르게 처리하기도 합니다.

NOTE: RAFT 합의 알고리즘은 전체 노드 중 리더 노드를 선출하여 1개의 노드만 블록을 생성하는 방식입니다.
폐쇄적인 환경에서 권한을 가진 노드만 블록을 생성할 수 있기 때문에,
다수 노드의 합의가 필요한 비트코인의 POW 같은 방식보다 좋은 성능을 보입니다.

Fabric의 합의 알고리즘

낮은 버전의 Fabric은 PBFT와 같은 합의 알고리즘을 제공하였습니다.
현재 버전의 Fabric은 다수의 채널을 구성할 수 있지만,
일반적인 블록체인과 같은 합의 알고리즘은 제공하지 않습니다.
대신 트랜잭션을 전파하기 전 검증하는 Endorsing 과정과 순서 보장을 위한 Message Queue를 활용하여,
검증된 트랜잭션만 전파되는 것을 보장합니다.

타 블록체인과 비교

Fabric은 태생이 Enterprise를 위한 블록체인입니다.
Enterprise 환경에서 어떤 기술들이 필요한지 파악하고, 블록체인 시스템 구성 시 파악된 요구사항들을 잘 반영하였습니다.
또한, 불필요한 기능들을 과감하게 제거하여 일반적인 블록체인과 다른 새로운 블록체인의 모습을 보여주었습니다.

하지만 Enterprise를 너무 의식한 나머지 일부 기능들은 무리하게 추가되었고,
블록체인 고객이라면 당연히 있어야 한다고 생각하는 기능들도 없는 경우가 있습니다.

다음은 Fabric을 검토할 때 고려해야 할 사항들입니다.

용도

일반적인 블록체인과 달리 Fabric은 분산된 DB의 동기화를 위해 만들어진 플랫폼입니다.
트랜잭션의 내용보다는 트랜잭션을 통해 변경된 DB의 최종 결과가 주로 사용됩니다.
만약 어떠한 행위나 문서를 증명하는 트랜잭션 저장을 위해 블록체인을 사용한다면,
일반적인 블록체인이 더 합당한 선택이 될 수 있습니다.
일반적인 블록체인은 트랜잭션의 서명을 사용자가 직접 하므로 사용자의 행위에 대해 증명이 가능합니다.
Fabric은 해당 기능을 구현하기 위해서 별도의 기능을 따로 구현해야 합니다.

성능

위 그림은 Fabric의 트랜잭션 전달 과정을 설명하고 있습니다.
트랜잭션을 전파하기 전 채널에 참여하는 Peer들이 검증하는 단계를 거치게 됩니다.
원격에서 동작하는 Peer가 많으면 많을수록, 네트워크의 성능이 느릴수록 트랜잭션이 전달되기까지 시간이 오래 걸리게 됩니다.
또한 같은 채널에 여러 Peer가 동시에 트랜잭션을 보내려고 할 경우,
순서 보장을 위해서 Orderer 역할을 하는 Kafka의 성능에 영향을 주게 됩니다.

이를 극복하기 위해서 하나의 트랜잭션에 여러 작업을 담아 전달하는 방식 등으로 성능을 올리려는 시도들이 있었습니다.
하지만 이러한 방법은 동일하게 일반적인 블록체인에도 적용할 수 있으며,
Peer가 늘어날수록 떨어지는 TPS는 치명적인 약점이 될 수 있습니다.

Legacy와의 경쟁

Fabric이 처음 나왔을 때는 PBFT 합의 알고리즘과 같은 일반적인 블록체인의 모습을 일부 가지고 있었습니다.
Enterprise 환경을 고려하여 현재는 합의 알고리즘 대신 Endorser와 Message Queue를 활용하고 있습니다.
또한 같은 채널 안에서도 특정 Peer에게만 데이터를 전달하는 Private Data라는 기능도 가지고 있습니다.

이런 복잡한 기능들이 추가되는 이유는 Enterprise 환경에서 Privacy가 중요한 요소이기 때문입니다.
분산된 DB를 위한 블록체인이라는 컨셉으로 출발한 Fabric은 이미 잘 구축된 Legacy에 도전할 수밖에 없게 되었습니다.
따라서 일반적인 블록체인이 가지는 많은 장점을 희생되게 되었습니다.

토큰시스템

블록체인을 도입하려는 일부 고객은 토큰 또는 포인트 시스템 구축을 위해 블록체인을 검토하는 경우가 있습니다.
이는 암호화폐를 통해 블록체인이 유명해진 이유와 크게 상관이 있습니다.
일반적인 블록체인의 경우 화폐 또는 토큰 유통을 고려하여 체인과 Smart Contract가 설계되어 있습니다.

Fabric이 제시한 Enterprise 블록체인의 모습은 화폐가 없는 블록체인입니다.
따라서 화폐도 토큰도 Fabric에는 구현되어 있지 않으며,
화폐 또는 토큰 시스템이 필요할 경우 별도의 Chaincode를 구현해야 하는 부담이 있습니다.

결론

Fabric은 Enterprise 블록체인을 목표로 만들어진 플랫폼입니다.
블록체인을 활용하여 분산된 DB를 동기화시키는 새로운 방식의 활용법을 제시하였습니다.

하지만 다양한 분야에서 다양한 방법으로 사용될 수 있는 블록체인의 기능을 한정 지어 사용하게 되어,
범용적인 블록체인이 되기에는 한계가 있습니다.
일반적인 블록체인들이 합의 알고리즘을 개선하여 성능을 올리고 있는 상황에서,
기대에 못 미치는 성능을 꼭 개선해야 할 점으로 판단됩니다.