Monad
이 글을 리뷰해주시고, 피드백 해주신 모나드 팀과 모나드 커뮤니티 여러분게 감사의 말씀을 전합니다.
EVM은 블록체인 시장에서 가장 강력한 내러티브로 자리잡았다. EVM을 지원하는지의 여부가 블록체인 성공을 좌우하는 정도였고, 아직도 우리는 EVM의 시대에 산다고 해도 과언이 아니다.
모나드는 그러한 EVM이란 내러티브와 컨센서스 딴에서의 최신 기술들을 접목하고 변형하여 이더리움 생태계의 방대한 커뮤니티를 흡수하면서도, 모놀리틱 블록체인으로써 방대한 확장성을 가져가고자 한다.
모나드는 파이프라인 컨센서스, 트랜잭션 실행, 스테이트 엑세스, 그리고 트랜잭션 병렬처리까지 진행하여 10,000 TPS(Transaction per second)와 싱글 슬랏 파이널리티를 구현하는 것을 목표하고 있다.
최근에 등장한 레이어1 모놀리틱 블록체인들 중에서 EVM을 채택한 경우는 모나드가 거의 최초이기 때문에 런칭 이후에 어떤 방식으로 블록체인이 성장할지 매우 기대가 되는 부분이다.
Ethereum Virtual Machine(이하 EVM)과 이더리움의 스마트 컨트랙트 언어인 솔리디티가 세상에 등장한지도 이젠 10년이 되어간다. 물론 이들이 등장하자마자 강력한 영향력을 가졌던 것은 아니지만, 무려 10년이라는 굉장히 긴 시간동안 다양한 개발 사례들과 함께 거대한 개발자 생태계를 구축하면서 이제는 블록체인 시장에서 가장 강력한 내러티브가 되었다고 해도 과언이 아니다. 심지어“어떤 체인이 EVM호환(EVM-Compatible)가능한가?”는 지난 레이어 1 블록체인 전쟁에서도 가장 중요한 기준중에 하나였을 정도다.
EVM 생태계를 끌어안아서 성공한 블록체인들도 굉장히 많다. EVM의 원조인 이더리움을 제외하고도 BSC, Polygon, Tron, Avalanche, Fantom과 같은 레이어1 블록체인들(물론 폴리곤은 이제 완벽하게 레이어2로 전환할 계획을 가지고 있지만 여태까지는 레이어1이라고 봐도 무방할 것이다)과 현재 가장 영향력 있는 레이어2 블록체인은 Base, Arbitrum, Optimism등도 전부 EVM생태계를 포용해서 단시간에 폭발적인 성장을 이룩했다.
DeFiLlama 에 따르면 TVL(total value locked)기준에서도 무려 1위부터 8위까지가 전부 EVM 기반 체인들로 구성되어있다. 그야말로 지금은 EVM 시대인 것이다(물론 필자가 글을 쓰고 있는 이 시점에도 다양한 가상 머신들이 생기고 있다. 이들에 대해서 더 자세히 알고 싶다면 Xpara가 작성한 글을 참고하시라) 그리고 필자가 오늘 소개할 이 체인은, 이러한 EVM 대세론을 좀 더 강화시켜줄 수 있는 블록체인이라고 사료된다. 심지어 여태까지 EVM 호환 체인들과 다른 방법론을 제시하고 있어서 EVM 생태계에도 새로운 바람을 불러일으킬 것이라고 기대되는 이 체인, 바로 모나드(Monad)다.
이더리움은 단언컨데 가장 성공한 블록체인이고, 가장 견고한 커뮤니티와 생태계를 보유하고 있다. 하지만 이러한 이더리움이 가지지 못한 것이 있으니. 그건 바로 “확장성”이다. 물론 지금 이더리움 자체적으로도 확장성을 확보하기 위해 부단한 노력을 하고있으나, 샤딩이 아닌 롤업으로 노선을 바꾸면서 이더리움이 자체적으로 방대한 확장성을 가지는 미래는 그리기 어려워졌다. 그런데 만약에 우리가 알고있는 이더리움이 다른 평행 세계에서 10,000 TPS를 달성했다고 생각해보자. 얼마나 즐거운 일일까? 필자가 모나드를 처음 마주했을 때 딱 그런 생각이 들었다. 물론 모나드와 이더리움은 굉장히 많은 차이점이 있지만, 확장성과 EVM 커뮤니티의 방대함을 둘 다 가져가려 한다는 점에서 이러한 상상을 해보았다.
모나드의 어떤 점이 이더리움과 닮았고, 어떤 점이 또 다를까?
우선, EVM Bytecode Compatibility라는 말을 이해하기 위해선 Bytecode에 대해서 알아야 할 필요가 있다. 이더리움의 스마트 컨트랙트는 솔리디티와 같은 프로그래밍 언어로 작성되지만, 이들이 이더리움 네트워크에 실행되기 전에는 반드시 EVM Bytecode로 컴파일링 되어야 한다. Bytecode여야만 가상머신이 이해할 수 있기 때문이다. 즉, 어떤 블록체인이 EVM Bytecode Compatible 하다고 한다면, 그 뜻은 해당 블록체인이 Bytecode들을 이더리움의 EVM과 동일하게 실행할 수 있다는 뜻이라고 받아들일 수 있다.
즉 모나드는 Full EVM Bytecode Compatible하기 때문에, 과거에 실행되었던 이더리움의 트랜잭션을 모나드의 트랜잭션 실행 환경에 옮겨와서 처리하더라도 같은 결과를 얻을 수 있다(상하이 포크 기준으로 모든 opcodes들을 지원한다) .
어찌보면 필자가 위에서 언급한 것과 비슷하다고 생각할 수 있지만, 이것은 조금 다르다. 이더리움 RPC(Remote Procedure Call) 호환성을 가지고 있다는 것은 이더리움의 RPC 리퀘스트를 정확하게 받아내고 이더리움 RPC 사양에 있는 것과 동일한 엔드포인트를 가지고 있다는 것이기 때문에 간단하게 말하면 이더리움 생태계에 만들어져있는 다양한 툴들을 자유롭게 활용할 수 있다는 뜻이다. 더 쉽게 설명하면, 모나드는 이더리움 RPC 호환이 되기 때문에 이더스캔이나 메타마스크 같은 이더리움 생태계의 유용한 툴들과 자유롭게 상호작용 할 수 있다는 뜻이다. 이 외에도 주소로 이더리움과 같이 ECDSA(타원 곡선 디지털 서명 알고리즘)을 사용하고, 트랜잭션 포맷역시 이더리움을 따른다.
물론 모나드가 이더리움과 닮은 점만 있느냐, 그것은 또 아니다.
밑에서 더 자세하게 후술하겠지만, 모나드와 이더리움은 컨센서스 메커니즘부터 다르다. 우선 이더리움은 Casper FFG Proof of Stake와 Ghost fork-choice rule을 합친 Gasper 라는 컨센서스 메커니즘을 사용하고, 모나드는 HotStuff와 Diem BFT의 변형이라고 볼 수 있는 자체적인 컨센서스 메커니즘인 MonadBFT(이하 모나드BFT)를 사용한다. 넓게 보면 같은 PoS 계열이라고 볼 수 있지만 작동 방식부터가 다르다. 오히려 모나드는 컨센서스 메커니즘 측면에선 앱토스와 더 닮아있다고 볼 수 있다(앱토스 역시나 Diem BFT에서 파생된 AptosBFT를 사용하고 있으니 말이다).
트랜잭션 처리 방식도 매우 다르다. 이 역시 좀 더 자세하게 후술하겠지만, 모든 트랜잭션들을 직렬로 처리하는 이더리움과 다르게 모나드는 트랜잭션들을 병렬로 처리하는데에 초점을 맞췄다. 또한 클라이언트가 Go로 만들어진 이더리움과 달리 모나드의 클라이언트는 퍼포먼스에 초점을 둔 블록체인 답게 c++과 러스트로 만들어졌다. 마지막으로 트랜잭션의 수행 과정도 다른데. 이것도 후술하겠지만, 이더리움에선 트랜잭션의 연산이 합의 전에 이루어지는 반면, 모나드에선 합의 이후에 연산이 이루어진다. 이러한 차이점들이 일어난 부분들을 세밀하게 살펴보면 모나드가 이더리움과 다른 점은 블록체인의 퍼포먼스 향상을 위해서 어쩔 수 없이 수정해야하는 부분들에 있다고 볼 수 있다.
세이(Sei), 수이(Sui), 그리고 앱토스(Aptos). 이들 모두 트랜잭션들을 병렬처리 할 수 있고(또는 예정이고), 블록체인의 속도를 최대치로 끌어올린 블록체인들로 평가받는다. 하지만 모나드가 흥미로운 점은 바로 이더리움의 장점과 이들의 장점을 교묘하게 잘 섞었다는 부분일 것이다. 세이, 수이, 그리고 앱토스는 EVM 생태계를 선택하지 않았다(이 역시 후술하겠지만, EVM은 보안상 여러가지 문제들이 있기 때문이다). 세이는 WASM을, 수이와 앱토스는 MOVE라는 자체적인 언어와 VM를 선택해서 이더리움과 완벽하게 독립적인 노선을 선택한 반면, 모나드는 EVM을 선택했다(이들이 앞으로 어떤 미래를 그려나갈지 지켜보는 것도 모놀리틱 블록체인을 좋아하는 입장에서는 매우 흥미로운 부분이 될 것이다). 물론 미래를 예상할 수는 없겠지만, 모나드는 이들보다 더 빠른 속도로 개발자들을 모을 수 있지 않을까?
그래서 필자는 모나드를 10,000 TPS를 달성한 이더리움이라고 평가한 것이다. 물론, 이더리움 커뮤니티 구성원 전부가 모나드를 반길지는 모르는 일이다. 하지만 EVM 호환이라고 하면 모두가 롤업 체인들만 상상하고 구상하던 요즘, 모놀리틱 블록체인의 방식을 EVM 기반으로 구현한다는 것 자체만으로도 관심을 가져볼만하다.
자, 이제 모나드의 구체적인 기술들을 하나씩 살펴보도록 하자.
결국 모나드의 빠른 확장성은 컨센서스 메커니즘에서 비롯된다. 물론 모나드BFT역시 Aptos BFT나 Diem BFT가 그렇듯 기존의 BFT방식에서 변형되어 발전된 형태의 BFT라고 볼 수 있다. 한 번 모나드BFT의 세부 특성들을 파해쳐보자.
Source: Diem BFT
우선 모나드 BFT의 세부적인 특성들을 파악하기 위해서는 모나드 BFT에서 어떤 방식으로 컨센서스를 진행하는지를 이해하는 것이 필요하다. 우선 쉬운 이해를 위해 몇 가지 단어들을 정의해보자:
A Quorum Certificate (또는 QC): 네트워크의 정족수(2/3)가 이전 블록의 유효성을 증명한다면 발급되는 증명서
A Timeout Certificate (또는 TC): 네트워크의 정족수(2/3)가 이전 블록의 유효성을 증명하지 않았다면 발급되는 증명서(제 시간에 네트워크 정족수가 올바른 블록 프로포절을 받지 못했다면 발급되는)
편희를 위해 초기 라운드를 K라운드, 그 이후 라운들를 K+1, K+2로 명명하고, K라운드에 대한 QC는 QC, 그 다음 라운드의 QC를 QC(K+1), QC(K+2)라고 하겠다. 초기 라운드 이전 라운드의 QC또는 TC는 QC(K-1), 또는 TC(K-1)과 같은 방식으로 표기하도록 하겠다.
모나드BFT 는 라운드를 아래와 같이 진행한다:
모든 라운드는 리더가 있고, 리더가 라운드를 진행한다. 리더는 주기적으로 미리 결정되어 라운드마다 할당되는 방식이다.
각각의 라운드는 두 부분으로 나뉜다: 1) 리더가 다른 벨리데이터들에게 블록 프로포절을 전달하는 부분과 2)벨리데이터가 투표를 한 메시지를 다음 라운드의 리더에게 전달하는 부분.
만약 모든 것이 순조롭게 진행돼서 네트워크에 문제가 없이 메시지가 전달되었다면, 메시지가 전달되는 과정은 하나(리더)에서 다수(벨리데이터)에서 다시 하나(다음 라운드의 리더)로 전달되는 선형 소통 과정(linear communication)을 거친다. 하지만 벨리데이터가 리더로부터 제때 프로포절을 받지 못한다면 리더를 제외하고 다른 벨리데이터들과 소통하여 다음 라운드로 진행해야 하기 때문에 네트워크가 교차검증 과정(Quadratic communication)을 거쳐야한다.
블록 프로포절은 새로운 블록과 더불어 이전 라운드의 투표 정보를 가지고 있고, 이 두 가지를 프로포절에 포함시켰기 때문에 모나드 BFT를 파이프라인(나중에 후술할 것)메커니즘이라고 부른다.
만약 벨리데이터가 올바른 프로포절을 받았다면, 이들은 다음 라운드 리더에게 YES라고 적힌 투표를 전달한다. 만약 YES라고 적힌 표가 정족수(2/3)를 넘었다면 다음 라운드의 리더는 이 전 라운드의 프로포절에 대한 QC를 발급한다. 만약 이 반대의 경우, 벨리데이터가 올바르지 않은 프로포절을 받았다면, 타임아웃 메시지를 작성하여 다른 벨리데이터들에게 전부 전파한다. 만약 이들중 아무나 정족수(2/3)가 넘는 타임아웃 메시지를 전달받았다면, 해당 타임아웃 메시지를 TC로 만들어서 다음 라운드의 리더에게 전달한다. 해당 TC는 벨리데이터들이 봤던 가장 최근 QC에 대한 정보도 담는다.
이와 같이 K+1의 리더는 이전 라운드의 상황에 따라 QC를 발급하거나 TC를 전달받거나 할 것이다. 그리고 나면 K+1의 리더는 새로운 프로포절을 만드는데 해당 프로포절은 (1) 새로운 블록에 대한 트랜잭션들과 (2)가장 최근 라운드의 QC(성공적인 상황에선 이전 라운드의 QC, 타임아웃 상황에선 TC안에 있는 가장 최근에 성공했던 라운드의 QC에 대한 정보를 포함시킨다) 그리고 (3) 만약 이전 라운드가 타임아웃이었다면 TC를 포함해야한다.
K+2 라운드의 벨리데이터가 K+1라운드의 QC를 전달 받았다면, 그 떄야 비로소 라운드K의 프로포절이 올바르다고 판단하고 확정짓는다. 좀 더 자세히 봐보면:
라운드 K에 대한 QC를 가지고 있는 벨리데이터는 적어도 정족수 이상이 라운드 K에서 YES로 투표했다는 증명을 할 수 있다.
하지만 그냥 QC만 가지고 있어서는 K라운드 블록에 대한 확정을 지을 순 없다. 왜냐하면 자신을 제외한 다른 벨리데이터들도 같은 결과값을 가지고 있는지 확신할 수 없기 때문이다. 그래서 아직까지 트랜잭션들을 실행하기엔 안전하지 않다.
해서 해당 QC를 K+2 라운드까지 들고서 결과를 지켜보는 것이다. 만약 K+2라운드에 벨리데이터들이 K+1에 대한 QC를 받았다면 이는 반대로 말해서 K라운드의 벨리데이터가 자신을 제외한 다른 벨리데이터들 까지도 정족수 이상이 YES했다고 검증할 수 있기 때문이다(애초에 K+1의 QC가 발급되려면 K+1라운드에서 각각 벨리데이터들이 이전 라운드에서 정족수 이상이 YES로 투표했다는 사실을 전달했어야 하기 때문에).
위에서도 언급했듯, 모나드 BFT에는 컨센서스 마다 라운드가 있다. 그리고 각각의 라운드에 두 개의 과정(phase)을 거쳐야 한다. 첫 번째 과정에선 컨센서스에서의 리더가 투표자들에게 메시지를 보내고, 두 번째 과정에선 리더에게 서명된 답장을 보내서 합의를 확정짓는 과정이 바로 그것들이다. 여기서 흥미로운 점은 바로 HotStuff와의 다른점이다. 원래 HotStuff의 경우는 세 개의 과정을 거치는데 이러한 방식은 합의 과정에서 레이턴시를 많이 발생시키기 때문에 모나드 BFT는 과정을 두 개로 줄였다. 이렇게 모나드 BFT가 과정을 두 개로 줄일 수 있었던 이유는 네트워크가 좋지 않은 상황을 겪을 때엔(리더가 보낸 프로포절을 받을 수 없다던지, 정해진 시간내에 프로포절을 받지 못하였던지 할 때) 다른 노드들과 직접 소통하는 방식으로 해당 라운드를 건너뛸 수 있기 때문이다.
선형 소통 방식(Linear Communiation)과 교차검증 소통(Quadratic Communication) 방식의 차이점: 교차검증 소통 방식에서는 리더가 각각의 노드들에게 제안을 전파한 후 이 제안을 검증한 투표 데이터를 자신을 제외한 모든 노드에 전파를 해야만 하기 때문에 노드 수에 따라 약 n²의 네트워크 비용이 발생한다.(리더의 제안 전파 n 각각의 노드에서 다른 노드들로 투표 데이터 전파 n), 하지만 선형 소통 방식의 경우 다음 라운드의 리더에게만 전파하기 때문에 약 n의 네트워크 비용만 발생한다는 것이 장점이다(리더의 제안 전파 n 다음 라운드 리더에게만 투표 데이터 전파 1) 이를 통해 선형 소통 방식에서는 블록체인의 처리량과 지연 시간을 개선할 수 있다.
네트워크에 문제가 없다면 Monad BFT는 선형 소통 방식을 사용하기 때문에, 위에서 언급했듯 단일 라운드에선 노드들끼리 리더가 악의적인지에 대한 교차검증을 할 수 없다. 해서 K+2라운드에서 블록을 확정짓는 것이다.
Source: HotStuff
파이프라이닝은 간단히 이야기 하면, 컨센서스의 모든 과정을 하나의 라운드에서 처리하는 것이 아니라 여러 라운드에 걸쳐 나눠서 처리하는 것을 이야기 한다. 예를 들어서 N라는 블록이 있고 그 다음 블록이 N+1블록이라고 해보자. 리더가 보낸 메시지에 정족수의 투표자들이 투표를 해서 QC(Quorum Certificate)을 N블록에서 만들었다고 하더라도, 반드시 N블록에서 해당 QC를 확정지을 필요는 없고 N+1에 넘길(piggyback)수 있다.
Monad BFT의 과정이나 방법론은 대부분 Diem BFT와 유사한 것으로 보인다. 하지만 Diem BFT에서 없던 부분들도 있는데, Shared Mempool, Deferred Execution, Carriage cost와 Reserve Balance가 바로 그것들이다.
멤풀(Mempool)이란 메모리(Memory)와 풀(Pool)의 약자로, 노드들이 아직까지 검증하지 않은 정보들을 담아놓는 메커니즘이다. 즉, 트랜잭션들이 블록에 담기기 전에 모여있는 일종의 대기실이라고 볼 수 있다. 보통 블록체인에서 모든 노드들이 다 같은 멤풀을 가지고 있지는 않다. 그래서 모나드의 경우 노드들이 같은 데이터를 가지고 있지 않은 경우에는 가십 프로토콜을 사용하여 데이터를 요청하고 받는 형식으로 멤풀에 있는 정보들을 공유한다. 현재 모나드는 간단한 가십 프로토콜을 사용하여 멤풀을 공유하지만, 추후에는 브로드캐스트 트리(Broadcast Tree, 노드들이 서로간에 직접 소통하지 않고, 트리라는 구조를 통해 메시지를 전달하여 중복되는 전파과정 없이 서로간에 메시지를 전파할 수 있도록 하는 구조)라는 방식으로 통신 방법을 바꿔서 멤풀 데이터를 공유하는 과정을 더 효율화 할 예정이다.
노드들이 멤풀을 공유하는 것 역시 모나드의 확장성과 연관이 있다. 모나드는 10,000개의 트랜잭션을 1초에 처리해야하는 부담을 가지고 있다. 예를 들어서 개당 500바이트에 달하는 트랜잭션을 10,000개 담은 블록이 있다고 한다면 이 블록의 크기는5MB일 것이다. 이정도 크기의 블록은 네트워크 대역폭에 큰 부담이다. 모나드는 이 문제를 해결하기 위해서 블록마다 발급되는 프로포절(매 라운드마다 리더가 발급하는)들이 트랜잭션 전체를 가리키지 않고 오직 해시만 가리키는 방식으로 대역폭의 부담을 줄인다(트랜잭션의 용량이 500 바이트라면, 해시의 용량은 32바이트 이기 때문에). 컨센서스 과정에서 블록 프로포절이 트랜잭션 전체를 가리키지 않고 해시들만 가르키기 때문에 모든 벨리데이터들은 프로포절에 투표하고 해당 프로포절을 확정짓는 과정에서 트랜잭션 멤풀을 서로 공유하고 있어야 한다. 그러면 블록 프로포절에 모든 데이터를 올리지 않더라도 블록 프로포절을 효과적으로 전파할 수 있기 때문이다.
모나드의 특이한 점중 하나라고 볼 수 있는 부분이 바로 트랜잭션 연산과 합의를 분리시켜서 합의의 과정을 좀 더 효율적으로 만들었다는 부분일 것이다. 우리가 모듈러 블록체인에 대해서 공부할 때 배웠겠지만 연산과 합의는 조금 다른 부분들이 있다. 합의(Consensus)는 트랜잭션들을 어떻게 블록에 담을 것인지를 논의하는 것이라면, 연산(execution)은 해당 트랜잭션들이 실제로 실행되어 상태에 변화를 주어야만 한다. 즉 모나드에선 합의를 진행하는 리더와 벨리데이터들이 프로포절에 투표는 할지언정, 해당 트랜잭션들이 어떻게 실행하는지는 알지 못한다.
모나드가 연산과 합의를 분리한 이유가 무엇일까? 우선 이더리움의 이야기를 해보자. 이더리움의 경우 합의 전에 연산을 먼저 하는 방식을 채택했다. 즉, 이더리움의 합의 과정에선 1) 블록에 있는 트랜잭션들에 동의를 해야하고 2) 해당 트랜잭션들을 연산하고 나서 발생한 머클 루트에 대해서도 동의를 해야한다. 즉, 이더리움에선 리더가 프로포절을 공유하기 전에 모든 트랜잭션들을 연산하고 공유해야하며, 다른 벨리데이터들도 프로포절에 투표하기 전에 트랜잭션들을 연산해야한다는 번거로움이 있다. 이러한 경우엔 가스 리밋도 굉장히 보수적으로 산정해야하고, 합의에 주어진 시간도 매우 촉박해진다.
모나드는 이러한 문제를 해결하기 위해서 연산과 합의를 분리한다: 노드들이 K블록의 트랜잭션들을 연산할 때, 독립적으로 K+1블록에 대한 합의를 같이 진행한다. 이렇게 되면 실행이 컨센서스를 따라가기만 하면 되기 때문에 블록 타임에 맞는 가스 예산을 가져갈 수 있다는 장점이 있다. 이러한 분리가 가능한 이유는 트랜잭션의 순서를 정하는 과정에서 대다수의 노드들이 합의했다면, 결과값 역시나 이미 결정되었다고(Determined) 봐도 무방하기 때문이다.
하지만 이렇게 연산과 합의를 분리하고 병렬로 처리하게 되었을 때 드는 의문이 있다. “상대값을 업데이트 하지 않은 상태로(실행이 컨센서스를 따라가는 구조이기 때문에) 트랜잭션의 순서를 정한다고 가정했을 때, 만약 가스 비용이 없는 유저의 트랜잭션 까지 담을 수 있지 않나? 이러한 경우엔 DDOS 공격을 피할 수 없지 않을까?” 이러한 문제를 해결하기 위해서 도입한 개념이 바로 Carriage Cost이다.
Carriage cost는 말 그대로 ‘운송 비용’이다. 모나드는 연산과 합의를 분리한 만큼, 트랜잭션에 비용을 메기는 것도 굉장히 특이한데. 보통은 트랜잭션을 ‘실행’할 때 비용을 지불하지만, 모나드에선 트랜잭션 실행 비용과 운송 비용을 분리하였다. 이러한 경우 트랜잭션을 전달하는데 필요한 수수료는 있지만, 실행하는데에 필요한 수수료가 없을 때 그냥 트랜잭션을 실패처리한다. 이렇게 해서 유저가 돈이 없음에도 계속해서 트랜잭션을 전송하려는 시도를 막을 수 있다.
또 노드들은 각 계정들마다 Reserve Balance라는 것을 만들어서 운송 비용에만 쓰일 수 있는 잔고를 별도로 마련한다. Reserve Balance를 만든 이유는, 오직 값을 지불한 트랜잭션만이 블록에 담길 수 있도록 하기 위해서다.
우리는 여태까지 모나드의 컨센서스 매커니즘을 알아보았다. 그렇다면 모나드는 어떤 방식으로 트랜잭션들을 처리할까? 모나드의 트랜잭션 처리 방식은 크게 두 꼭지로 나뉜다: 트랜잭션 병럴 처리와 MonadDb가 바로 그것들이다. 이들을 하나씩 한 번 살펴보자.
여기에 두 종류의 트랜잭션이 있고, 각각의 트랜잭션을 아래와 같이 명명하겠다:
Transaction A는 A라는 계정이 B라는 계정으로부터 모나드 토큰을 전송받는 트랜잭션이다.
Transaction B는 A라는 계정이 C라는 계정에게 모나드 토큰을 전송하는 트랜잭션이다.
만약에 이 두 트랜잭션들이 순차적으로 처리되는 것이 아니라 병렬로 처리된다고 생각해보면(Transaction B가 Transaction A가 끝나기 전에 시작되는),아마 이렇게 병렬초 처리된 후, A라는 계정의 잔고는 순차적으로 처리됐을 때의 잔고와 다를 수 있다. 그리고 이것은 트랜잭션 실행 오류로 이어질 수 있다.
모나드는 이러한 문제를 해결하기 위해서 STM(Software Transactional Memory)방식과 STM에 있는 OCC(Optimistic Concurrency Control)에서 차용한 방식을 사용한다. OCC라는 용어에서 알 수 있듯, 모나드는 트랜잭션을 병렬처리 하는 과정에서 모든 작업이 유효하다고 가정하고 실행을 먼저 시킨 다음에 검증 과정에서 문제가 발생하면 재실행 하는 방식으로 트랜잭션을 병렬처리한다. 이렇게 해서 처리한 결과는 순차적으로 처리됐을 때의 결과와 같아야 한다(모나드는 트랜잭션을 병렬처리 하면서도, 트랜잭션 결과로 인해서 업데이트 된 상태값들은 순차적으로 병합돼서 병렬 처리된 트랜잭션이 유효한지 아닌지 검증한다). 즉, 모나드는 트랜잭션을 병렬처리 하기 전에 트랜잭션들의 연관성을 미리 검증한뒤 처리하는 것이 아니라, 우선 트랜잭션을 먼저 처리해보고 문제가 생겼을 때 그 때의 정보를 이용해서 트랜잭션 처리를 다시 진행한다.
이렇게 하는 이유는, 미리 트랜잭션의 연관성을 확인하고 실행하는 것보다 실행한 뒤에 문제가 생기면 그 때의 정보를 바탕으로 트랜잭션을 다시 실행하는 것이 결과적으로 더 효율적이기 때문이다.
현재 모나드는 좀 더 선제적인 방식으로 트랜잭션 재실행을 진행할 방법들을 연구하고 있다.
우선 MonadDb에 대해서 알기 전에 알아야 할 개념이 있는데, 그것은 바로 Asnychronous I/O(input/output)(이하 async i/o)이다. 기존에는 트랜잭션들의 입력값과 결과값을 처리할 때 해당 처리 결과를 기다려야 했는데 async i/o에서는 트랜잭션의 입력값과 결과값의 결과를 기다리지 않고 CPU가 다른 트랜잭션들의 처리도 같이 한다. 기존 이더리움의 데이터베이스들은 async i/o를 지원하지 않는 반면 MonadDB는 async i/o를 지원하기 때문에 트랜잭션을 처리함에 있어서 큰 효율성을 재고할 수 있다.
Source: Monad
모나드는 설명만 보더라도 굉장히 기술적으로 많은 고민을 해야하는 블록체인이기 때문에 모나드 팀 역시나 수많은 기술자들로 이루어져있다. 우선 CEO인 Keone만 보더라도 유명 트레이딩 회사인 점프 트레이딩에서 HFT(High Frequency Trading)팀을 이끌었던 기술자고, James역시나 점프 트레이딩에서 트레이딩 시스템을 개발하던 개발자였다. 블록체인 코어를 개발하는 대부분의 개발자들은 레이턴시가 낮고 빠르게 연산이 가능한 플랫폼을 만들던 개발자 출신들이기 때문에 상당부분 모나드의 비전과 일치하는 경력들을 가지고 있다.
Source: Monad Medium
모나드는 올해 2월에 약 $19M 규모의 시드 라운드 투자를 Dragonfly, Shima Capital, Fianlity Capital, Credibly Neutral등으로부터 받아냈다. 눈의 띄는 부분은 엔젤 투자자인데 Flashbot의 Strategy Lead인 Hasu와 스시스왑을 만든 0xMAKI와 같은 영향력 있는 업계 리더들에게도 투자를 받아서 큰 관심을 받았다.
모나드가 이렇게 세간의 관심을 받는 이유는 사실 명확하다. 업계의 가장 강력한 내러티브인 EVM을 지원하면서도 인프라 딴에서 가장 발전된 기술들인 Diem BFT와 HotStuff 를 변형하고 발전시킨 Monad BFT와 트랜잭션 병렬처리를 사용하여 네트워크의 확장성을 확보했기 때문이다. 방대한 개발자 커뮤니티와 그들이 활동할 수 있는 충분한 확장성과 리소스가 준비되고 있는 것이다. 현재 대부분의 롤업 체인들이 이더리움의 확장성 솔루션이라고 나오고 있지만, 이더리움의 블록 공간 부족등의 이유로 사실상 높은 속도는 보장해주지 못하고 있는 것을 보면, EVM을 지원하는 고성능 모놀리틱 블록체인의 등장은 블록체인 시장의 판도를 한 번 더 뒤흔들 수 있는 신호탄이 될지도 모른다.
물론, 모나드가 해결해야하는 문제들도 여전히 있다. 위에서 언급했듯, 트랜잭션 병렬처리를 좀 더 원활하게 만들기 위해서 연구해야하는 부분들도 많이 있을 것이고, EVM 자체적인 문제들(특히 보안적인 문제들)도 여전히 존재한다. 대부분의 신규 레이어1 모놀리틱 블록체인들이 EVM이 아닌 다른 가상 머신을 선택한 이유도 분명히 존재하기 때문이다.
하지만 모나드 팀이 그 사실을 모르고서 블록체인을 준비중이진 않을 것이기 때문에, 앞으로 모나드가 모놀리틱 블록체인 시장, 더 나아가 블록체인 업계에 어떠한 영향력을 행사할지 매우 기대되는 부분이다. 최신의 기술과 가장 강력한 내러티브가 만나서 만들어진 괴물, 모나드는 과연 레이어1 시장의 부흥을 다시 이끌 수 있을까?
이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.
