[Sui Research] 2. 아키텍처 및 컨센서스 엔진

Published in

Decipher Media ｜디사이퍼 미디어

21 min readJun 26, 2022

본 게시글은 병렬 처리 Layer 1 블록체인 Sui에 대해 분석합니다. Sui분석 글은 시리즈로 게시되었으며, 본 글을 읽기 전 Sui의 개요 및 Move를 다룬 1편을 먼저 읽으시는 것을 추천드립니다. 이번 글에서는 Sui의 아키텍처 및 컨센서스 엔진에 대해 다루며, 같은 프로그래밍 언어인 Move를 사용하는 병렬처리 블록체인 Aptos와 비교합니다.

Author
신우진(@pangyoalto)
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By 정재환

[Sui Research]

Sui 개괄 및 Move 언어와의 연관성
아키텍처 및 컨센서스 엔진

Intro
Sui 아키텍처
Sui 컨센서스 엔진 — Narwhal
Sui 컨센서스 엔진 — Tusk
Aptos의 병렬 처리 방식
마무리

Intro

많은 블록체인은 사용량이 많아지면 제한된 throughput으로 인하여 사용자에게 더 높은 트랜잭션 수수료가 부과됩니다. 이는 유저에게 나쁜 사용자 경험을 줄 수 있고, 특히 게임이나 Defi와 같은 서비스에는 비싸지고 느려져 치명적일 수 있습니다.

Sui는 밸리데이터의 처리 능력이 높아지면 처리할 수 있는 네트워크 용량이 커지도록 설계가 되어 있습니다. 이는 사용량이 늘어나더라도 밸리데이터의 수가 증가하면 적은 수수료로 사용자에게 서비스를 제공할 수 있음을 의미합니다. 또한 22년 3월 19일 기준, 8코어 M1 맥북 프로에서 돌아가는 single-worker 밸리데이터가 120,000 TPS를 처리할 수 있다고 Sui는 밝혔습니다. 실제로 Sui가 메인넷을 런칭해야 알 수 있겠지만, 위 수치의 절반만 실제 서비스에서 나오더라도 엄청난 TPS가 아닐 수 없습니다.

이것이 가능한 이유는 Sui의 아키텍처 덕분입니다. Sui는 다른 블록체인들과 달리 트랜잭션 대부분을 병렬로 처리를 할 수 있어 리소스를 효율적으로 활용하고 throughput을 높일 수 있습니다. 실제 합의과정을 거치는 트랜잭션의 수가 많지 않기 때문입니다.

이번 글에서는 병렬처리를 가능하게 하는 Sui의 아키텍처와 좀 더 효율적인 합의를 만드는 컨센서스 엔진에 대해 알아볼 것입니다. 또한 이를 또 다른 병렬 처리 블록체인인 Aptos와 비교하여 두 체인이 트랜잭션 병렬처리에 접근하는 방식이 어떻게 다른지 분석할 것입니다.

2. Sui 아키텍처

분산 시스템은 머신 간 메시지를 주고받는데 시간이 추가로 걸릴 수 밖에 없습니다. 이에 따라서 각 머신은 자신에게 온 메시지가 얼마나 걸렸는지 알 수 없으므로 자신이 받은 이벤트 간 순서를 정확히 알기 어렵습니다.

비트코인이나 이더리움 등 블록체인 대부분은 전체 머신(노드)가 같은 상태를 유지하기 위해서 모든 트랜잭션의 순서를 정한 블록을 공유합니다. 이렇게 모든 이벤트의 순서가 정해져서 놓인 것을 total order라고 합니다.

반면 이벤트의 모든 순서가 정해져 있지 않지만, 일부 이벤트 간 순서를 정할 수 있는 상황이 있습니다. 예를 들어 A, B, C 이벤트가 있을 때 머신이 A가 B보다 먼저 일어났고, A가 C보다 먼저 일어났다는 것을 알고 있다고 합시다. 머신은 A, B, C 전체 이벤트의 순서는 정할 수 없지만, A가 가장 먼저 일어난 이벤트라는 사실은 알 수 있습니다. 또한 이벤트 B와 C가 같은 객체를 공유하지 않는다면, 머신이 B와 C의 순서를 어떻게 배치하던 상관 없이 같은 결과를 만들어 낼 수 있을 것입니다. 이렇게 부분적으로 이벤트의 순서를 배치할 수 있는 것을 casual order라고 합니다. Sui는 이 casual order를 이용하여 트랜잭션 실행을 병렬화합니다.

Sui가 casual order를 사용할 수 있는 이유는 Move를 사용하기 때문입니다. Move로 객체를 다루기 때문에 객체의 소유권 메타데이터를 확인할 수 있습니다. 밸리데이터가 객체의 소유자를 알 수 있으면, 특정 트랜잭션을 실행할 때 해당 트랜잭션과 관련 없는 트랜잭션을 찾을 수 있어 병렬로 실행할 수 있습니다.

소유권 이야기를 좀 더 해보자면, 오브젝트들은 하나의 주소에 의해서 소유가 되지만, 각 주소는 여러 오브젝트들을 가질 수 있습니다. 트랜잭션을 보낸 주소는 해당 주소가 소유한 객체와 공유 객체, 그리고 해당 객체들이 소유한 객체들만 트랜잭션 내에서 사용을 할 수 있습니다. 만약 트랜잭션 내에서 해당 주소가 소유한 객체만을 사용한다면, 해당 트랜잭션은 다른 트랜잭션과 병렬로 실행해도 문제가 없을 것입니다.

따라서 Sui는 특정 사용자만 수정이 가능한 소유된 객체(owned objects)와 여러 사용자가 수정이 가능한 공유 객체를 구별합니다. 즉, 소유된 객체만을 가진 트랜잭션은 casual order 될 수 있는 트랜잭션입니다. Sui가 합의 프로토콜을 공유 객체를 처리하는 트랜잭션에 적용을 하므로, 소유된 객체만 처리하는 트랜잭션은 매우 짧은 시간 안에 처리가 될 수 있습니다.

Sui가 트랜잭션을 처리하는 과정을 위 그림으로 정리할 수 있습니다. 사용자가 보낸 트랜잭션은 밸리데이터들에게 총 두 번 공유가 됩니다.

트랜잭션 유효성 검사(Process Transaction)
트랜잭션 증명서 발급 (Process Certificate)

1번 단계와 2번 단계 사이에서 객체의 소유권을 확인하여 total order가 필요한 트랜잭션인지를 구별합니다. Total order가 필요한 트랜잭션들은 따로 합의 과정을 거치고 2번 단계를 진행하게 됩니다.

각 단계에서 클라이언트는 전체 밸리데이터가 스테이킹한 토큰 수의 2/3 이상의 찬성을 받아야 합니다. Sui는 DPOS 시스템으로 운영되고 있기에, 1/3 이상의 지분을 가진 악의적인 노드들이 있다면 정상 작동하지 않기 때문입니다. DPOS는 많은 블록체인이 도입하고 있는 합의 프로토콜이며 대표적으로 tendermint 엔진을 들 수 있습니다.

Sui가 타 DPOS 블록체인과 다른 점은 트랜잭션을 개별 검증한다는 것입니다. 앞에서 예로 든 Tendermint는 블록을 단위로 합의 과정을 거칩니다.

Tendermint 합의 과정(Source: Tendermint docs)

Sui는 트랜잭션을 개별 검증함으로써 레이턴시를 줄일 수 있었습니다. 개별 검증은 트랜잭션들을 배치로 검증할 때보다 비효율적이라는 단점이 있는데, Sui는 대부분 트랜잭션이 casual order를 할 수 있는 점을 이용해 해당 트랜잭션들은 순서 합의를 포기함으로써 성능을 대폭 높였습니다.

여기까지 읽으셨으면 한 가지 의문점이 드셨을 것입니다. Casual order도 관련 있는 트랜잭션 간 순서를 정해줘야 하기 때문입니다. 앞서 Sui는 소유된 객체만 가지고 있는 트랜잭션을 casual order를 할 트랜잭션으로 분류한다고 했었습니다. Sui는 트랜잭션을 처리할 때 트랜잭션 발신자 주소에 잠금을 겁니다. 따라서 같은 계정에서 보낸 여러 트랜잭션을 동시에 처리하지 않기 때문에 해당 계정에서 발신한 casual order 트랜잭션은 별도의 합의 과정 없이 즉시 처리가 가능합니다.

3. Sui 컨센서스 엔진 — Narwhal

Sui의 높은 throughput은 트랜잭션의 병렬 처리만 만들어내는 것이 아닙니다. Sui는 효율적인 블록 생성 및 전파를 위한 컨센서스 엔진을 만들어내었습니다.

Sui의 컨센서스 엔진은 Narwhal and Tusk 논문을 바탕으로 구현이 되었습니다. 컨센서스 엔진은 Narwhal과 Tusk라는 두 개의 레이어로 구성이 되어 있습니다. Narwhal은 mempool 프로토콜을 다루는 레이어고, Tusk는 블록 간 정렬을 담당하는 컨센서스 레이어입니다.

현재 많이 사용되고 있는 컨센서스 프로토콜들은 1) 트랜잭션을 mempool에 공유를 하고 2) 트랜잭션이 블록에 담기면 다시 블록을 공유합니다. 이는 같은 트랜잭션 내용이 두 번 공유가 되어 비효율적입니다.

Narwhal은 처음부터 트랜잭션들을 블록에 담아 공유해 트랜잭션들이 두 번 공유가 되는 상황을 방지했습니다. 또한 Narwhal이 블록의 가용성을 보장하는 역할에서 끝내고, 블록의 순서를 정해주는 역할을 Tusk로 넘기면서 Throughput을 증가시켰습니다.

먼저 mempool 레이어인 Narwhal을 구체적으로 살펴봅시다.

Source: youtube — ConsensusDays / Narwhal and Tusk

위 사진에서 보이는 Primary와 Worker들은 같은 밸리데이터에서 실행이 되고 있습니다. 각 밸리데이터는 각자의 Narwhal mempool을 가집니다. 밸리데이터의 각 worker는 자신이 받은 트랜잭션들을 요약한 digest를 생성해 같은 밸리데이터의 primary로 보내고, 자신이 처리한 트랜잭션은 Batch에 담아 다른 노드로 보냅니다. 블록은 Worker들이 가지고 있는 Batch를 합친 것이고, 각 Worker는 병렬적으로 실행이 됩니다. Primary가 받은 digest들은 하나의 블록 헤더로 만들어집니다.

즉, 밸리데이터가 하나의 mempool 블록을 만드는 대신, 밸리데이터가 여러 worker 머신들을 운영해 batches라고 불리는 Mempool 서브 블록들을 공유하는 것입니다. 이는 병렬 처리를 가능하게 해 scale out을 할 수 있게 만들어줍니다.

이제 Narwhal에서는 Primary끼리 블록 헤더를 통해 의사결정을 합니다. 블록 헤더는 메타데이터만 가지고 있으므로 mempool을 가볍게 유지할 수 있습니다.

Narwhal은 각 라운드가 진행되고, 라운드가 끝날 때마다 블록의 가용성이 보장됩니다. 그 과정을 이제 간단히 알아보겠습니다.

먼저 블록 헤더를 다른 밸리데이터들에게 제시합니다. 블록 헤더를 받은 밸리데이터들은 블록 헤더의 해시가 가리키는 블록이 가용성이 보장되는지 확인합니다. 확인하는 방법은 직접 다운로드를 하는 것입니다.

밸리데이터가 해당 블록 헤더가 가리키는 블록이 가용성이 보장됨을 확인하면, 블록 헤더를 제시한 밸리데이터에게 응답합니다. 2f+1 이상의 밸리데이터로부터 검증받으면, 증명서(certificate)을 발행할 수 있습니다. 증명서도 블록 헤더처럼 블록에 비해 매우 가벼운 용량을 가지고 있습니다.

증명서가 발급되면, 다음 라운드의 블록들은 해당 증명서를 포함해야 합니다. 증명서는 하나의 블록을 가리키고, 그 블록은 이전 증명서들을 포함하고 있으므로, 블록은 casual history를 담는 셈이 됩니다.

각 블록은 최소 2f+1 개의 증명서를 가지고 있어야 합니다. 비잔틴 장애 허용 조건에서 정직한 밸리데이터는 f+1개 이상이므로, 어떠한 블록도 최소 하나의 정직한 밸리데이터의 증명서를 가지게 됩니다. 이 때문에 악의적인 밸리데이터끼리 정직한 밸리데이터를 제외해 라운드를 마무리 짓고 넘어갈 수는 없습니다.

결과적으로 Narwhal은 블록 전파를 한 번만 하고, 합의 과정은 비교적 사이즈가 작은 증명서를 이용함으로써 앞서 이전 mempool의 문제점으로 지적되었던 트랜잭션이 두 번 공유되는 것을 막았습니다. 또한 블록을 Worker가 서브 블록으로 나누어 처리함으로써 자원의 효율성 또한 높였습니다.

4. Sui 컨센서스 엔진 — Tusk

앞서 보았던 Narwhal은 mempool 프로토콜로 블록의 가용성을 보장해주는 프로토콜입니다. 블록의 순서를 정해주려면 컨센서스 프로토콜이 필요합니다.

Sui가 컨센서스 엔진 설계 시 참고한 Narwhal and Tusk 논문에서는 Tusk라는 컨센서스 프로토콜을 제시합니다.

Source: Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus

해당 논문에서는 Narwhal mempool 위에 Hotstuff와 같은 부분 동기화 컨센서스 프로토콜을 사용할 수도 있지만, Tusk와 같은 비동기 컨센서스 프로토콜을 사용한다면 Narwhal을 최대 throughput으로 블록을 공유하고 검증하여 사용할 수 있다고 주장합니다.

비동기 컨센서스 프로토콜은 네트워크 끊김과 같은 비동기적 상황이 닥쳤을 때나 DDOS 공격으로부터 안정성을 유지할 수 있습니다.

Tusk 컨센서스 프로토콜은 비동기 컨센서스 프로토콜일 뿐만이 아니라 zero message async consensus입니다. 컨센서스 엔진이 메시지를 보내지 않고도 트랜잭션을 total order로 바꿀 수 있는 프로토콜이라는 의미입니다.

Tusk가 어떻게 이를 가능하게 했는지 간단하게 알아봅시다.

Tusk 알고리즘은 모든 밸리데이터가 Narwhal이 구성한 DAG 로컬 뷰를 보지만, 공유된 무작위성을 사용해 total order를 결정합니다.

Tusk는 wave라는 단위를 사용합니다. Wave는 3개의 연속적인 라운드로 구성됩니다.

첫 번째 라운드의 밸리데이터가 블록을 제안합니다. Narwhal에서 보았듯이, 블록이 여러 블록에 대한 증명서를 가지고 있음으로 casual history를 제안하는 것과 같습니다.
두 번째 라운드의 밸리데이터들은 자신이 가지고 있는 블록에 해당 블록을 포함함으로써 투표를 진행합니다.
세 번째 라운드의 밸리데이터들은 무작위성을 생성해 리더의 블록을 선출합니다.

그림으로 보면 좀 더 이해가 쉬울 것입니다.

라운드 3에서 만든 무작위성으로 라운드 1의 L1이 리더로 선발이 되었습니다. 리더 선출은 두 라운드 이전 라운드의 블록을 리더로 선발합니다.

일단 리더가 선발되면, 해당 리더가 얼마나 많은 노드와 연결이 되었는지 확인합니다. 최소 f+1개의 노드와 연결이 되어 있어야 하며, L1은 한 개의 노드와 연결이 되어 있으므로 리더 선발에서 더 나아가지 못하고 마무리됩니다.

이후 새로운 wave가 돌아 5번째 라운드에서 3번째 라운드의 블록을 리더로 선발합니다. 이번에는 L2가 2개의 블록과 연결이 되었으므로 f+1 이상의 노드와 연결이 되어 있어야 함을 충족합니다. 이제 이 리더는 커밋이 될 수 있습니다.

리더가 선발되고 조건을 만족하면, 선발된 리더와 이전에 커밋된 리더 사이에 커밋이 미처 되지 못한 리더가 있는지 확인합니다. 조건을 만족하는 리더가 발견되면, 재귀적으로 수행해 조건을 만족하는 리더부터 순서대로 커밋을 합니다.

위 그림에서는 L1이 커밋이 되지 못했으므로, L1이 확인이 되고 L1을 커밋합니다. 이후 L2가 커밋이 됩니다.

각 리더는 서브 DAG를 가지고 있고, 서브 DAG간 순서를 정해주는 것에 성공하였습니다. 이 과정에서 Tusk는 무작위성만 공유를 했을 뿐, 노드간 메시지를 교환하지 않았습니다. 각자의 노드는 자신의 로컬 뷰에서 판단을 합니다.

블록 리더 간 정렬이 된 후, 각 밸리데이터는 미리 정해진 결정론적 방법으로 다시 리더의 casual history를 정렬합니다. 아쉽게도, 논문에서는 이 방법에 대한 논의까지는 하지 않았습니다. 또한 Sui의 docs 및 white paper도 이 부분에 대해서 다루지 않고 있어 실제로 컨센서스 엔진을 어떻게 구현하고 있는지 알 수 없습니다.

Tusk가 비동기적 컨센서스 프로토콜이면서 추가적인 메시지 비용을 사용하지 않는다는 방법을 제시했고 Sui가 이를 적용해 좀 더 나은 컨센서스 엔진을 만들려고 한다고 이해하면 될 것 같습니다.

5. Aptos의 병렬 처리 방식

구 Facebook, 현 Meta의 Libra 프로젝트는 2019년 런칭하고 Diem이라는 이름으로 변경이 되어 운영되고 있었으나 2022년 1월 말 종료되었습니다. 이 Diem 팀에서 4명의 개발자가 나와 Mysten Labs를 설립하고 개발한 체인이 바로 Sui입니다. Mysten Labs를 창업한 팀 말고도 전 Diem/Novi(Meta의 Wallet 프로젝트)의 엔지니어들이 창업한 회사가 하나 더 있는데, 바로 aptoslabs입니다. 이 회사는 Aptos라는 체인을 선보였습니다.

Aptos와 Sui는 같은 팀에서 나온 엔지니어들이 만든 체인인 만큼 비슷한 점이 많습니다. 두 체인 다 병렬처리 모놀로식 체인을 표방하고 있고, Move를 사용합니다. 이러한 공통점의 이유는 Diem이 Move를 사용했었기 때문입니다.

그러면 차이점은 무엇이 있을까요? 가장 큰 차이점은 Sui와 Aptos는 다른 객체 모델을 사용한다는 것입니다. 앞서 Sui는 객체의 소유권 데이터를 확인하여 공유 객체를 사용하는 트랜잭션과 소유된 객체만을 사용하는 트랜잭션을 구분한다고 말씀드렸습니다. 이를 통해 소유된 객체만 사용하는 트랜잭션은 순서 합의 과정을 생략함으로써 병렬 처리 엔진을 구현할 수 있었습니다.

Aptos는 Block-STM 기술을 바탕으로 병렬 처리 엔진을 구현했습니다. Block-STM은 Diem에서 발표한 기술입니다. Sui의 엔지니어들도 Diem 출신이므로 영향을 받았겠지만, Block-STM을 발전시켜 적용한 것은 Aptos입니다.

Block-STM은 컴퓨터 과학에서 메모리 충돌을 감지하고 관리하기 위해 발전한 Software Transactional Memory(STM) 기술을 블록체인에 적용한 기술입니다. STM은 트랜잭션이 실행되는 동안 메모리 접근을 기록하고 실행 이후 상태를 검증함으로써 메모리 충돌을 감지하였습니다. 이 개념을 Block-STM은 블록 안 트랜잭션들에 적용함으로써 동시 실행시 충돌이 나는 트랜잭션을 감지합니다.

조금 더 자세하게 말하면, 트랜잭션의 실행 결과로 나온 read-set과 write-set을 검증하여 트랜잭션을 재실행해야 하는지 확인합니다. Read-set은 메모리 위치와 해당 메모리에 기록한 트랜잭션으로 구성된 쌍을 모아놓은 것입니다. Write-set은 메모리 위치와 해당 메모리 위치에 저장된 값을 쌍으로 모아놓은 것입니다. 쉽게 말하면 Read-set은 트랜잭션이 읽을 메모리에 대한 정보이고, write-set은 트랜잭션의 실행 결과로 업데이트가 될 메모리에 대한 정보입니다.

Block-STM은 트랜잭션을 검증할 때, 트랜잭션의 read-set을 다시 읽어온 것과 트랜잭션의 가장 최근 실행으로 얻은 read-set을 비교합니다. 만약 다르다면, 트랜잭션을 abort시키고 재실행시킵니다.

Block-STM은 다음을 보장합니다.

READLAST(k) : 트랜잭션 k가 실행될 때마다, 트랜잭션 k가 읽어서 얻은 값은 그 이전 트랜잭션 중 가장 높은 순위의 트랜잭션 j에 의해서 얻은 값입니다(j<k). i>k인 트랜잭션 i의 실행 결과는 트랜잭션 k에 영향을 미치지 않습니다.
VALIDAFTER(j,k) : j<k인 모든 j,k에 대해서 트랜잭션 k의 read-set 검증은 트랜잭션 j가 실행 완료된 뒤에 수행됩니다.

Block-STM을 쉽게 이해할 수 있도록 Chainlink Labs의 Dahlia Malkhi님이 제시한 예를 들어보겠습니다.

block B에 10개의 트랜잭션이 들어있다(Tx1, Tx2, ..., Tx10)
트랜잭션간 의존성으로 인한 partial order는 다음과 같다.
(Tx1 -> Tx2는 Tx1이 Tx2보다 먼저 실행 완료가 되어야 한다는 의미입니다)Tx1 -> Tx2 -> Tx3 -> Tx4
Tx3 -> Tx6
Tx3 -> Tx9

시스템이 4개의 병렬 스레드가 있고, 각 트랜잭션은 하나의 시간 단위에서 처리가 완료된다고 가정을 해봅시다. 이제 트랜잭션들은 다음 순서로 실행이 됩니다.

Source: Block-STM: Accelerating Smart-Contract Processing

Tx1, Tx2, Tx3, Tx4가 각각 쓰레드에서 병렬 실행됩니다.

2. 실행 이후 read-set 검증을 해 Tx2, 3, 4가 실패합니다(abort).

2–1. 실패한 트랜잭션의 write-set을 ABORTED로 기록합니다. ABORTED가 기록된 메모리를 읽으려는 트랜잭션은 write-set이 재작성이 될 때까지 기다립니다.

3. Tx2, 5, 7, 8이 병렬 실행됩니다. Tx3, 4, 6은 ABORTED로 인해 대기하여 실행되지 않았습니다.

4. Tx3, 10이 병렬 실행됩니다. Tx 4, 6, 9는 ABORTED로 인해 대기합니다.

5. Tx4, 6, 9가 병렬 실행됩니다.

위 예에서 볼 수 있듯이 트랜잭션은 병렬로 실행이 되고, 실행이 된 이후에 검증합니다. 검증은 앞서 말했듯이 read-set을 비교함으로써 수행이 됩니다.

Tx2가 실행이 될 때는 read-set에 트랜잭션 정보가 없었겠지만, Tx2 실행 이후에는 Tx1이 실행이 된 이후이기 때문에 read-set에 Tx1에 대한 정보가 기록되어 있을 것입니다. 두 read-set이 다르므로 Tx2는 ABORTED 됩니다. Tx2가 ABORTED 되었기 때문에 Tx2의 write-set은 ABORTED로 마킹이 되고, 이는 연쇄적으로 Tx3와 Tx4에도 영향을 미칩니다.

Aptos가 적용한 Block-STM은 스레드를 전부 활용하여 많은 트랜잭션을 실행하고 이상이 생기면 재실행하는 접근법을 취하고 있습니다. “이상이 생기면 재실행"하는 부분이 비용이 많이 드는 로직이기 때문에, ABORTED 마킹 등을 도입하여 무작정 재실행하는 것이 아닌 마킹이 없어질 때까지 대기하는 등 재실행 횟수를 줄이는 방법을 적용한 것을 알 수 있습니다.

Sui는 반면 처음부터 공유 객체를 사용하는 트랜잭션을 따로 분리하는 작업을 거칩니다. 이를 통해 병렬로 실행 돼도 상관없는 트랜잭션들만 병렬 실행하고, 공유 객체를 사용하는 트랜잭션은 비잔틴 합의를 거칩니다.

즉, 간단히 말해 Aptos는 모든 트랜잭션 병렬 실행 후 처리, Sui는 처리 후 선별된 트랜잭션 병렬 실행합니다. 비용이 많이 드는 작업이 Aptos는 나중에, Sui는 처음에 수행이 됩니다. 현재로써는 어떤 접근법이 더 나은 것인지 우열을 가릴 수 없습니다. Sui와 Aptos가 메인넷 런칭을 한다면 어떤 접근법이 더 성능이 좋은지 지켜보는 것도 재미있을 것입니다.

6. 마무리

블록체인 트릴레마를 극복하기 위해 많은 노력이 이어지고 있습니다. 블록체인 트릴레마의 탈중앙성과 보안성을 포기한다면 블록체인을 사용하는 매력이 크게 떨어지기 때문에 탈중앙성과 보안성을 충족하면서 확장성을 개선해야 할 것입니다.

블록체인의 합의, 연산(execution), settlement, 데이터 가용성 역할을 각각 별개의 블록체인으로 나누어 수행하는 모듈러 블록체인 개념이 등장한 것도 이를 해결하기 위함입니다. 각 역할을 전문적으로 수행하는 체인이 수행한다면 확장성이 증가할 수 있을 것입니다. 반면 Sui와 Aptos는 모놀로식 블록체인을 유지하면서 트랜잭션 병렬 처리 기능을 추가하여 확장성을 개선하려고 시도를 하고 있습니다.

Sui는 윗글에서 살펴보았듯 트랜잭션 병렬 처리뿐만 아니라 컨센서스 엔진에서도 좀 더 발전된 모습을 보였습니다. Aptos도 이 글에서는 병렬 처리만 다루었지만 기존 HotStuff 모델을 변형하여 발전된 BFT엔진을 만들고, state-sync 등 성능을 높이기 위한 다양한 방법들을 적용하였습니다.

모듈러 블록체인과 모놀로식 블록체인 대결이 누가 승자로 마무리될지 아직 아무도 알 수 없을 것입니다. 하지만 두 블록체인이 어떻게 문제를 해결해 나가려 하는지 충분히 리서치를 해야 나중에 시장에서 사용이 되거나 외면받았을 때 그 이유를 이해하기 쉬울 것입니다. 미래에 다가올 확장성이 개선이 된 블록체인을 기대하며, 필자는 모놀로식 블록체인 중 가장 기대를 받는 Sui와 Aptos를 꾸준히 팔로업하려 합니다.

References

[Sui Research] 2. 아키텍처 및 컨센서스 엔진

Written by Pangyoalto