사전 고지: 본 글은 단순 정보 제공을 위해 작성되었고 투자, 법률, 자문 등 어떤 부분에 대해서도 책임을 지지 않습니다. 특정 자산에 대한 투자를 추천하는 것이 아님을 밝히며, 본문의 내용만을 바탕으로 투자에 대한 의사결정을 내리지 마십시오.

Review: Ethan Lee

본 글은 A41에서 기획하는 앱토스 시리즈의 6편으로, 다른 편을 읽고 싶으시다면 아래의 리스트를 확인해주시기 바란다. 글이 서로 연관되어있기 때문에 처음부터 차례대로 읽어보시는 것을 추천드린다.

1편: Introducing Aptos — 모놀리틱 블록체인의 새로운 패러다임

2편: AptosBFT — 확장성과 보안의 합의 할고리즘

3편: Move — 안정적인 구조 속에서 빠르게 실행하라.

4편: 추가적인 확장성을 위한 기술들

5편: Block STM - 어떻게 앱토스는 트랜잭션을 병렬처리 하는가

6편: Narwhal - 앱토스의 멤풀 프로토콜

7편: 앱토스의 토크노믹스와 거버넌스, 그리고 생태계 소개

세 줄 요약

1. 기존 블록체인의 멤풀은, 데이터를 한 번 전파하고, 그 데이터를 블록에 담아서 다시 또 전파 해야한다는 이중 전파(Double Transmissions)의 문제를 가지고 있다.

2. 그럼에도 불구하고 멤풀은 블록체인이 비가역적 특성을 가지고 있기 때문에, 트랜잭션을 안전하게 검증하기 위해서라도 반드시 필요한 메커니즘이다.

3. Narwhal은 독자적인 멤풀 레이어를 구축하여 블록체인의 이중 전파의 문제를 해결하면서도, 멤풀 메커니즘의 효율화를 통하여 기존 컨센서스 메커니즘들의 확장성을 비약적으로 확장시키고자 한다.

1. 멤풀이란 무엇일까: 멤풀의 중요성과 문제점.

앱토스의 멤풀 프로토콜인 나왈(Narwhal)에 대해서 이야기를 꺼내기 전에 먼저 이해해야 하는 개념이있다. 멤풀(Mempool)이 바로 그것이다. 멤풀이란 메모리(memory)와 풀(pool)의 약자로, 노드들이 아직 검증하지 않은 정보들을 담아놓는 메커니즘이라고 이해하면 쉽다. 좀 더 간단하게 이야기 하면, 트랜잭션들이 블록에 담기기 위해서 기다리고 있는 ‘대기실'과도 같은 개념이다.

(멤풀과 블록체인의 관계에 대해서 도식화 한 것 | 출처)

여기서 한 가지 명확하게 해야 하는 것은, 모든 노드들이 다 같은 시간대에 같은 멤풀을 가지고 있는 것은 아니며 각각의 노드들이 관리해야 하는 멤풀이 존재한다는 사실이다. 만약 노드들마다 가지고 있는 멤풀이 다르다면, 각각의 노드들은 트랜잭션들에 대해서 어떤 방식으로 합의를 할까?

우선, 유저들이 트랜잭션을 발생시키면, 노드가 트랜잭션을 받아서 검증한 후(서명이 맞는지, 트랜잭션을 발생시킨 주소가 트랜잭션을 실행시킬 수 있을만한 자금을 가지고 있는지 등등) 해당 노드의 멤풀에 저장한다 (편의를 위해서 지금 유저가 발생시킨 트랜잭션을 트랜잭션 A라고 칭하겠다).

그리고 해당 노드는 트랜잭션A를 다른 노드들에게 전파하고, 그 노드들은 트랜잭션 A를 아까 노드와 같이 검증하고, 검증이 완료되면 자신들의 멤풀에도 트랜잭션 A를 담고 다른 노드들에게도 전파한다. 그리고 나서는 리더(BFT에서는 리더가 될 것이고, POW에선 마이닝 노드가 될 것이다)가 트랜잭션 비용을 많이 낸 순서대로 새로운 블록에 트랜잭션들을 담고, 해당 블록을 또 네트워크 전체에 전파해서 모든 노드들이 해당 블록을 받아내면 트랜잭션이 성공적으로 처리가 되었다고 볼 수 있다.

트랜잭션이 블록체인에 전파되는 과정을 보면서 우리가 알 수 있는 사실은, 트랜잭션이 성공적으로 처리되기 위해선 약 두 번의 네트워크 전파 과정(트랜잭션을 검증하고 다른 노드들에게 전파하고, 그 트랜잭션이 담긴 블록을 전파해야하는 과정을 거친다)을 거쳐야 한다는 점이다. 사실 이런 부분은 멤풀이 가져다주는 비효율성이라고 이야기 할 수 있을 것이지만 그럼에도 불구하고 블록체인에 멤풀이 필요한 이유는 블록체인이 비가역적인 속성을 가지고 있기 때문이다. 한 번 블록에 담겨서 전파되면 해당 블록에 담긴 트랜잭션은 되돌릴 수 없기에, 바로 블록에 추가되는 것보다는 멤풀을 통해서 트랜잭션들을 검증하는 과정을 추가해서 안정성을 확보하는 것이다(트랜잭션이 멤풀에 있을 때는 아직 합의를 이루기 전이므로, 트랜잭션을 변경할 수 있다).

지금까지 멤풀 때문에 생기는 이중 전파의 문제와 멤풀이 블록체인에 필요한 이유를 알아보았다. 그렇다면 멤풀을 유지하면서, 멤풀이 가져다주는 비효율성을 해결할 수는 없을까? Narwhal은 이러한 근본적인 질문에서 시작된 멤풀 프로토콜이다.

2. Narwhal은 블록체인의 이중 전파 문제(Double Transmissions)문제를 어떻게 해결할까

(나왈의 멤풀 블록과 Certificate을 이루는 구조 | 출처: Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus)

나왈의 백서를 보면, 이중 전파의 문제를 해결하면서도 더 효율적인 멤풀 메커니즘을 가지기 위해 나왈에 약 다섯 가지 속성들을 도입했다고 설명하고 있다:

트랜잭션 단위가 아닌 블록 단위(멤풀 블록이라고 부름)로 전파한다:

BFT에서 리더는 전 라운드의 Certificate(이하 ‘증명서')들도 전부 담아두는 해당 블록에 대한 해시값을 제안하고, 다른 밸리데이터들은 해당 해시값이 맞는 블록을 가리키고 있는지에 대한 검증을 진행한다.

멤풀 블록을 꾸준히 전파함으로써 리더가 증명서를 만들 수 있게 된다:

해당 증명서는 멤풀 블록을 언제든 다운로드 가능하다는 것을 정명하는 기능을 하고(블록들의 해시값과 밸리데이터 정족수 서명을 담는다) 이를 통해 멤풀 블록의 존재를 보장 받을 수 있다.
그렇다면 증명서는 어떻게 만들어질 수 있을까? 우선, 위에서 설명한 멤풀 블록이 먼저 있어야 한다. 그리고 해당 멤풀 블록이 2f+1개의 서명을 받게 되면 BFT의 리더가 해당 멤풀 블록에 대한 증명서를 발행하게 되는 것이다.

멤풀 블록에 인과관계를 알 수 있는 정보를 담는다:

(나왈의 라운드 진행을 도식화 한 것 | 출처:Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus)

멤풀 블록엔 다양한 정보들(트랜잭션 리스트와 서명들)이 담기는데, 그중에 과거 멤풀 블록에 대한 증명서도 담아서 현재 멤풀 블록과 이전 멤풀 블록간의 관계성을 만들어내고, 해당 라운드의 증명서는 해당 라운드의 블록에 대한 존재를 보장하기 때문에 증명서를 통해 그 이전 라운드의 모든 정보들을 가리킨다고 할 수 있다.
예시: R라운드가 현재 라운드고 R-1라운드가 이전 라운드라고 했을 때, 각각의 라운드마다 블록과 증명서가 존재할 것인데, R라운드의 블록은 R-1, R-2,...그 이전 라운드의 증명서를 가지고 있을 것이고, R라운드의 증명서는 R라운드의 블록해시를 저장하여 블록의 존재를 보장해주기 때문에 R라운드의 증명서는 R라운드 이전에 있는 데이터들을 보장해준다고 할 수 있다.

라운드 방식의 멤풀 블록 과정을 통해, 공정성을 확보한다:

멤풀 프로토콜에서도 밸리데이터들마다 퍼포먼스가 다를 수 있는데, 퍼포먼스가 좋은 밸리데이터가 너무 빠른 속도로 멤풀 블록 생성 라운드를 진행하게 된다면, 퍼포먼스가 느린 밸리데이터는 해당 프로토콜에 참여하기 어렵기 때문에 나왈의 모든 블록 생산 과정은 라운드 방식으로 진행되며 이를 통해 선량한 밸리데이터가 이전 라운드를 종료하기 전 까지는 다음 라운드를 진행하지 않을 수 있게 된다.

Worker와 Primary 구조를 통해, 효율화를 추구한다:

(나왈에서 단일 밸리데이터가 유저에게 트랜잭션을 받는 모습을 형상화 한 것| 출처: Protocol Labs)

멤풀 밸리데이터 안에는 worker라는 개념과 primary라는 개념이 있는데, 하나의 엔티티가 멤풀 트랜잭션을 전파하는 것이 아닌, 다양한 workers들이 하나의 밸리데이터에 있으면서 각각의 트랜잭션을 소화한다. 이로써 밸리데이터는 방대한 양의 트랜잭션들을 소화해낼 수 있는 구조이다.

즉 정리하면, 나왈은 멤풀 트랜잭션을 트랜잭션 단위로 전파하는 것이 아닌, 블록 단위로 전파하고, 해당 블록에 대한 검증이 완료되면 증명서를 발행하여 멤풀 블록에 담긴 트랜잭션의 유효성을 검증할 수 있다. 만약 밸리데이터들이 나왈을 통해 발행된 증명서를 가지고 있다면, 결국 이들은 전부 같은 트랜잭션 히스토리를 가지고 있을 것이기에 증명섬만 있다면 기존에 블록체인 밸리데이터들이 했던 것처럼 트랜잭션 마다 전파해야하는 비효율적인 과정을 건너뛰고서 안전하게 트랜잭션을 받아볼 수 있는 것이다.

또한 나왈은 별도의 멤풀 프로토콜이기 때문에 합의 과정에서 문제가 생기더라도 독자적으로 계속해서 멤풀 블록을 생성할 수 있어서 합의 프로토콜에 문제가 생기더라도(liveness가 보장되지 않거나, 리더가 비잔틴일 때(악의적일 때)) 블록체인 네트워크의 레이턴시 문제는 생기겠지만, 평균적인 생산성에는 큰 영향을 주지 않을 수 있다는 장점이 있다. 마지막으로 밸리데이터 내부적으로 workers들을 두기 때문에 트랜잭션을 훨씬 더 빠르게 소화할 수 있어서 나왈을 적용하면 확장성의 비약적인 개선을 이뤄낼 수 있다.

(별 표시 되어있는 게 나왈을 사용했을 때를 나타내고, + 표시는 worker의 수를 늘렸을 때의 퍼포먼스를 나타낸다 | 출처: Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus)

나왈은 말 그대로 멤풀만을 위한 프로토콜이기 때문에, 다른 합의 알고리즘과 함께 사용될 수 있다. 현재 앱토스가 공식적으로 어떤 방법론을 채택할지는 모르지만, 한 가지 확실한 것은 현재 Aptos BFT에도 나왈을 적용할 수 있으며 이를 통해서 Aptos BFT로도 비약적인 확장성 증가가 가능하다는 것이다. Aptos BFT와 가장 퍼포먼스가 비슷한 HotStuff(위 그림에서는 HS로 표현됨) BFT를 기준으로 나왈을 적용했을 때 약 1.5초에서 2초의 레이턴시가 발생하고 트랜잭션 처리량은 초당 약 140,000개를 처리할 수 있다고 나온다.

물론 이 퍼포먼스는 어디까지나 백서상 테스트를 진행했을 때의 기준이고 실제로 메인넷 환경에서는 어떤 퍼포먼스가 달성될지는 지켜봐야 할 것이지만, 나왈을 도입했을 때 앱토스 네트워크 자체적으로 비약적인 성장을 이룰 수 있을 것으로 사료된다.

3. 나왈로 날개를 단 앱토스는 과연 모놀리틱 블록체인의 전성시대를 되찾을 수 있을까?

2023년은 레이어2의 시대라고 해도 과언이 아니다. 옵티미즘의 OP Stack을 이용한 코인베이스의 베이스 체인을 시작으로, 아비트럼도 자체적인 토큰을 런칭한데다가 다양한 프로젝트들이 이더리움과 비트코인 위에 네트워크를 쌓는 형태로 자신들의 블록체인을 구축하고 있다. 시장의 수요가 새로운 레이어1이 아닌, 존재하는 탄탄한 네트워크 위에 자기들의 네트워크를 구축하고 있는 쪽으로 기운 것이다.

앱토스는 이러한 흐름 속에서도 “새로운 레이어1의 시대”를 외치고 있다. 이들이 새로운 레이어1으로써 시장에서 살아남기 위해선, 1) 약속한 확장성을 달성해야하고 2) 네트워크 자체적인 문제가 없어야 할 것이다. 솔라나도 방대한 처리량을 내세워 이더리움의 점유율을 가져왔지만, 결국 네트워크에 지속적인 문제들이 생기면서 사람들의 신뢰를 잃었던 전례가 있었지 않나(물론 지금은 점프 트레이딩이 구축하고 있는 파이어댄서를 통해 다시 한 번 도약을 노리고 있지만). 그렇기 때문에 앱토스의 나왈 적용과, 그 이후의 네트워크 퍼포먼스가 어떻게 변화할지에 대해 관심 있게 지켜볼 필요가 있다(특히 나왈은 컨센서스와 분리돼서 멤풀을 관리하기 때문에 네트워크의 확장성 향상과 더불어 안정성도 확보할 수 있다는 점에서 매우 기대가 된다).

과연 앱토스는 솔라나가 가지고 있었던 단점들을 보완하면서도 레이어 1 시장의 신흥 강자가 될 수 있을까? 앞으로 앱토스의 확장성이 어떤 방식으로 발전할지 지켜보는 것도 아주 중요한 관전 포인트가 될 거 같다.

Narwhal- All for Mempool

[앱토스 시리즈] #6: Narwhal - 앱토스의 멤풀 프로토콜