출처: ASXN; 번역: 진써차이징(Jinse) xiaozou
1. 서론
Monad는 10,000 TPS(초당 10억 개의 가스), 500밀리초 블록 빈도, 1초 확정성을 갖춘 고성능 최적화된 EVM 호환 L1입니다. 이 체인은 EVM이 직면한 몇 가지 문제를 해결하기 위해 처음부터 구축되었습니다. 구체적으로는 다음과 같습니다.
*EVM은 거래를 순차적으로 처리하므로 네트워크 활동이 많은 기간에는 병목 현상이 발생하여 거래 시간이 길어지고, 특히 네트워크 혼잡 기간에는 그 시간이 길어집니다.
* 처리량이 낮고 TPS가 12-15에 불과하며 블록 시간이 12초로 깁니다.
*EVM은 각 거래에 대해 가스 요금을 지불하도록 요구하며, 수수료는 크게 변동합니다. 특히 네트워크 수요가 높을 때 가스 요금이 엄청나게 비쌀 수 있습니다.
2. EVM을 확장하는 이유는 무엇입니까?
Monad는 완전한 EVM 바이트코드와 이더 RPC API 호환성을 제공하므로 개발자와 사용자는 기존 워크플로를 변경하지 않고도 통합할 수 있습니다.
SVM처럼 성능이 더 뛰어난 대안이 있는데 왜 EVM을 확장해야 하는지에 대한 질문이 많이 있습니다. SVM은 대부분의 EVM 구현보다 더 빠른 블록 시간, 더 낮은 수수료, 더 높은 처리량을 제공합니다. 그러나 EVM은 두 가지 주요 요소, 즉 EVM 생태계의 대량 자본과 광범위한 개발자 리소스에서 비롯되는 몇 가지 주요 이점을 제공합니다.
(1) 자본금
EVM은 자본금이 대량, 이더 의 TVL은 520억 달러에 달하고 Solana의 TVL은 70억 달러에 달합니다. Arbitrum과 Base와 같은 L2는 각각 약 25억~30억 달러의 TVL을 보유하고 있습니다. 모나드와 기타 EVM 호환 체인은 최소한의 마찰로 통합되는 표준 브릿지와 타사 브릿지를 통해 온체인 대규모 자본 기반의 혜택을 누릴 수 있습니다. 이 대규모 EVM 자본 기반은 비교적 활발하며 다음과 같은 이유로 사용자와 개발자를 유치할 수 있습니다.
* 사용자는 유동성과 높은 거래량을 선호합니다.
높은 거래량, 수수료, 애플리케이션 가시성을 추구하는 개발자.
(2) 개발자 리소스
이더 의 도구와 응용 암호화 연구는 Monad에 직접 통합되어 다음을 통해 더 높은 처리량과 확장성을 달성합니다.
*애플리케이션
* 개발자 도구(Hardhat, Apeworx, Foundry)
*지갑(래비, 메타마스크, 팬텀)
*분석/인덱스(Etherscan, Dune)
Electric Capital의 개발자 보고서에 따르면 2024년 7월 현재 이더 2,788명의 정규 개발자를 확보하고 Base는 889명, Polygon은 834명을 확보할 것으로 나타났습니다. 솔라나는 664명의 개발자를 보유하여 폴카닷, 아비트럼, 코스모스에 이어 7위를 차지했습니다. 일부에서는 암호화폐 분야의 개발자 총 수가 여전히 적기 때문에 대체로 무시해야 한다고 주장하지만(외부 인재 영입에 리소스를 집중해야 함), "소규모" 암호화폐 개발자 풀 내에 대량 EVM 인재가 있다는 것은 분명합니다. 또한 대부분의 인재가 EVM에서 일하고 대부분의 툴이 EVM에 있다는 점을 감안할 때, 새로운 개발자는 EVM에서 배우고 개발하도록 선택하거나 그렇게 해야 할 가능성이 높습니다. Keone이 인터뷰에서 언급했듯이 개발자는 다음을 선택할 수 있습니다.
* EVM을 위한 휴대용 애플리케이션을 구축하여 멀티체인 배포를 가능하게 하지만 처리량이 제한적이고 수수료가 높습니다.
*Solana, Aptos, Sui와 같은 특정 생태계에서 고성능, 저비용 애플리케이션을 구축합니다.
모나드는 이 두 가지 접근 방식을 결합하도록 설계되었습니다. 대부분의 도구와 리소스는 EVM에 맞춰져 있으므로 해당 생태계 내에서 개발된 애플리케이션을 원활하게 이식할 수 있습니다. 모나드 최적화 덕분에 상대적인 성능과 효율성이 결합되면 EVM은 분명히 강력한 경쟁 장벽이 됩니다.
개발자 외에도 사용자도 익숙한 워크플로를 선호합니다. Rabby, MetaMask, Etherscan과 같은 도구를 통해 EVM 워크플로가 표준이 되었습니다. 이러한 성숙한 플랫폼은 브리지와 프로토콜의 통합을 용이하게 합니다. 또한, 기본 애플리케이션(AMM, 통화시장, 브릿지)을 즉시 실행할 수 있습니다. 이러한 기본적인 요소는 사슬의 지속 가능성과 새로운 응용 분야에 매우 중요합니다.
3. EVM 확장
EVM을 확장하는 주요 방법은 두 가지입니다.
* 체인 외부로 실행을 이동합니다. 모듈 식 아키텍처를 사용하여 롤업을 통해 실행을 다른 가상 머신으로 오프로드합니다.
* 성능 향상: 합의 최적화, 블록 크기 및 가스 한도 증가를 통해 기본 체인 EVM의 성능을 향상시킵니다.
(1) 롤업 및 모듈 아키텍처
Vitalik은 모듈 블록체인 원칙에 따라 2020년 10월에 이더 의 주요 확장 솔루션으로 롤업을 도입했습니다. 따라서 이더 의 확장 로드맵은 실행을 롤업에 위임합니다. 롤업은 이더 보안을 활용하는 오프체인 가상 머신입니다. 롤업은 처리량이 높고 대기 시간이 짧으며 거래 비용이 낮아 실행에 뛰어납니다. 이들의 반복적 개발 주기는 이더 보다 짧습니다. 이더 에서 몇 년 걸리는 업데이트도 롤업에서는 몇 달이면 끝날 수 있습니다. 잠재적 비용과 손실이 더 낮기 때문입니다.
롤업은 특정 탈중앙화 요구 사항을 우회하는 데 도움이 되는 탈출구를 유지하면서 중앙 집중식 순서 사용하여 작동할 수 있습니다. 많은 롤업(Arbitrum, Base, OP Mainnet 포함)이 아직 초기 단계(0단계 또는 1단계)에 있다는 점을 알아두는 것이 중요합니다. 1단계 롤업에서는 사기 증명 제출이 허용 목록에 있는 참여자로 제한되고, 온체인 입증 가능한 버그와 관련이 없는 업그레이드는 사용자에게 최소 30일의 종료 기간을 제공해야 합니다. 0단계 롤업은 권한이 있는 운영자에 의한 가동 중단이나 검열이 발생할 경우 사용자에게 7일 이내에 종료할 수 있는 시간을 제공합니다.
이더 에서는 일반적인 거래 크기가 156바이트이고, 서명에 가장 많은 데이터가 포함됩니다. 롤업을 사용하면 여러 거래를 묶어서 전체 거래 규모를 줄이고 가스 비용을 최적화할 수 있습니다. 간단히 말해, 롤업은 여러 거래를 일괄 처리하여 이더 이더 메인넷에 제출함으로써 효율성을 달성합니다. 이를 통해 온체인 데이터 처리는 줄어들지만, 롤업 연결에 새로운 인프라 요구 사항이 필요하기 때문에 생태계의 복잡성이 증가합니다. 또한 롤업 자체도 모듈 아키텍처를 채택하여 실행을 L3로 옮겨 특히 게임 애플리케이션의 기본적인 롤업 처리량 제한을 해결합니다.
롤업은 이론적으로 이더 상에서 완전한 체인이 되어 브리징과 유동성 단편화를 제거하지만, 현재 구현은 아직 완전히 "완전한" 체인이 아닙니다. TVL의 3대 롤업인 Arbitrum, OP Mainnet, Base는 서로 다른 생태계와 사용자 그룹을 유지하고 있으며, 각각 특정 분야에서 탁월한 성과를 거두지만 포괄적인 솔루션을 제공하지는 못합니다.
간단히 말해, 사용자는 솔라나와 같은 단일 체인을 사용하는 것과 동일한 경험을 얻기 위해 여러 개의 서로 다른 체인에 접속해야 합니다. 이더 생태계에서는 통합된 공유 상태가 부족(블록체인의 핵심 명제 중 하나)하기 때문에 온체인 사용 사례가 크게 제한됩니다. 특히, 경쟁하는 롤업은 유동성과 상태가 단편화되어 있어 서로의 상태를 쉽게 이해할 수 없기 때문입니다. 상태 분열은 롤업과 상태를 연결할 수 있는 브리지와 크로스체인 메시징 프로토콜에 대한 추가적인 필요성을 가져오지만, 몇 가지 단점이 있습니다. 단일 블록체인은 상태를 기록하는 단일 원장이 있기 때문에 이러한 단편화 문제가 발생하지 않습니다.
각 롤업은 최적화 측면과 특정 영역에 초점을 맞추는 측면에서 다른 접근 방식을 취합니다. Optimism은 Superchain을 통해 추가적인 모듈 도입하고, 이를 통해 다른 L2가 스택을 사용하여 빌드하고 수수료를 놓고 경쟁하도록 합니다. Arbitrum은 주로 DeFi, 특히 영구적 및 옵션 거래소 에 중점을 두고 있으며, Xai와 Sanko를 통해 L3로 사업을 확장하고 있습니다. MegaETH와 Base와 같은 새로운 고성능 롤업은 더 높은 처리량 기능을 갖추고 단일 대규모 체인을 제공하는 것을 목표로 등장했습니다. MegaETH는 아직 출시되지 않았으며 Base는 구현 측면에서 인상적이지만 파생상품 거래(옵션과 영구채권) 및 DePIN을 포함한 일부 분야에서는 여전히 부족합니다.
(2) 초기 L2 확장
낙관주의와 중재
1세대 L2는 이더 에 비해 향상된 실행 기능을 제공하지만 최신의 고도로 최적화된 솔루션에 비해 뒤처집니다. 예를 들어, Arbitrum은 초당 37.5개의 거래를 처리하고 Optimism Mainnet은 초당 11개의 거래를 처리합니다. 비교해 보면 Base는 약 80 TPS, MegaETH는 100,000 TPS, BNB Chain은 65.1 TPS, 그리고 Monad는 10,000 TPS를 목표로 하고 있습니다.
Arbitrum과 Optimism 메인넷은 완전한 온체인 오더북 과 같은 매우 높은 처리량 애플리케이션을 지원할 수 없지만 추가 체인 계층(Arbitrum의 경우 L3, Optimism의 경우 Superchain)과 중앙 순서 통해 확장됩니다.
게임의 L3, Xai, 플레이 증명에 초점을 맞춘 Arbitrum은 이러한 접근 방식을 보여줍니다. 이러한 거래는 Arbitrum Orbit 스택을 기반으로 구축되었으며 AnyTrust 데이터 가용성을 활용해 Arbitrum에 결제됩니다. Xai는 67.5 TPS에 도달했고, Proof of Play Apex는 12.2 TPS, Proof of Play Boss는 10 TPS를 기록했습니다. 이러한 L3는 이더 메인넷과 달리 Arbitrum 결제를 통해 추가적인 신뢰 가정을 도입하는 반면, 덜 탈중앙화 데이터 가용성 계층의 잠재적인 과제에 직면합니다. Optimism의 L2(Base, Blast, 그리고 곧 출시될 Unichain)는 이더 결제와 Blob 데이터 가용성을 통해 더 강력한 보안을 유지합니다.
두 네트워크 모두 수평적 확장을 우선시합니다. Optimism은 OP 스택을 통해 L2 인프라, 체인 배포 지원 및 상호 운용성 기능을 갖춘 공유 브리지를 제공합니다. Arbitrum은 특정 사용 사례를 L3로 이전하는데, 특히 게임 애플리케이션은 추가적인 신뢰 가정으로 인해 금융 애플리케이션보다 자본 리스크 낮습니다.
(3) 체인 및 EVM 성능 최적화
대체 확장 접근 방식은 수평이 아닌 수직으로 확장하여 처리량과 TPS를 높이기 위해 최적화 또는 목표 트레이드오프를 수행하는 데 중점을 둡니다. Base, MegaETH, Avalanche, BNB Chain이 이 전략을 구현하고 있습니다.
Base Base는 가스 목표를 점진적으로 늘려 1 Ggas/s에 도달할 계획이라고 발표했습니다. 9월에는 목표를 11Mgas/s로 상향 조정하고 가스 한도를 33Mgas로 늘렸습니다. 최초 블록은 258개의 거래를 처리했고 5시간 동안 약 70TPS를 유지했습니다. 12월 18일까지 가스 목표는 20Mgas/s에 도달했고, 블록 시간은 2초였으며, 각 블록은 40M 가스를 지원했습니다. 이는 Arbitrum의 경우 7 Mgas/s, OP Mainnet의 경우 2.5 Mgas/s와 비교됩니다.
Base는 Solana 및 기타 고처리량 체인의 경쟁자로 등장했습니다. 현재 Base는 활동 면에서 다른 L2를 앞지르고 있습니다. 그 증거로는 다음과 같습니다.
*2025년 1월 현재 월 수수료는 1,560만 달러에 달합니다. 이는 Arbitrum의 7.5배, OP Mainnet의 23배에 달합니다.
* 2025년 1월 기준 누적 거래량은 3억2,970만건에 달하며, 이는 아비트럼(5,790만건)의 6배, OP 메인넷(2,450만건)의 14배에 달합니다. 참고: 볼륨은 조작될 수 있으며 오해의 소지가 있습니다.
Base 팀은 Arbitrum과 Optimism의 모듈 접근 방식과 달리 속도, 처리량, 낮은 수수료를 최적화하여 보다 통합된 경험을 제공하는 데 중점을 두고 있습니다. Base의 활동 및 수익 수치에서 알 수 있듯이 사용자는 보다 통합된 경험을 선호합니다. 또한 Coinbase의 지원과 배포도 도움이 되었습니다.
메가ETH
MegaETH는 EVM과 호환되는 L2입니다. 근본적으로 거래는 전용 순서 노드를 사용하는 하이브리드 아키텍처를 통해 처리됩니다. MegaETH는 기존 Merkle Patricia Trie를 대체하는 새로운 상태 관리 시스템과 결합하여 디스크 I/O 작업을 최소화하는 아키텍처에서 성능 및 보안 작업을 고유하게 분리했습니다.
이 시스템은 EVM과의 완전한 호환성을 유지하고 테라바이트 규모의 상태 데이터를 처리하는 기능을 유지하면서 밀리초 미만의 지연 시간으로 초당 100,000건의 거래를 처리합니다. MegaETH는 데이터 가용성을 위해 EigenDA를 사용하여 세 가지 특수 노드 유형에 기능을 분산합니다.
* 순서: 고성능 단일 노드(100개 코어, 1-4TB RAM)가 트랜잭션 순서 및 실행을 관리하고 빠른 액세스를 위해 RAM에 상태를 보관합니다. 약 10밀리초 간격으로 블록을 생성하고, 블록 검증을 감시하고, 블록체인 상태가 변경됨에 따라 상태 차이를 추적합니다. 순서 정상 작동 중에 합의 오버헤드가 발생하지 않고 병렬 EVM 실행과 우선 순위 지원을 통해 높은 성능을 달성합니다.
* 증명기: 이러한 가벼운 노드(1개 코어, 0.5GB RAM)는 블록 내용을 검증하는 암호화 증명을 계산합니다. 이들은 비동기적으로 그리고 순서 없이 블록을 검증하고, 상태 비저장 검증을 사용하고, 수평적으로 확장하며, 전체 노드 검증을 위한 증명을 생성합니다. 이 시스템은 영지식 증명과 사기 방지를 지원합니다.
* 전체 노드: 중간 수준의 하드웨어(4~8개 코어, 16GB RAM)에서 실행되는 전체 노드는 증명자, 순서, EigenDA를 연결합니다. 이들은 피어투피어 네트워크를 통해 압축된 상태 차이를 처리하고, 트랜잭션을 다시 실행하지 않고 차이를 적용하고, 증명자가 생성한 증명을 사용하여 블록을 검증하고, 최적화된 Merkle Patricia Trie를 사용하여 상태 루트를 유지하고, 19x 압축 동기화를 지원합니다.
(4) 롤업 관련 문제
모나드는 롤업과 근본적으로 다르며, 롤업의 본질적인 단점도 다릅니다. 오늘날 대부분의 롤업은 중앙 집중화된 단일 순서 에 의존하지만, 공유 및 탈중앙화 순서 솔루션이 개발되고 있습니다. 순서 와 제안자를 중앙 집중화하면 운영상의 취약성이 발생합니다. 단일 개체에 의한 제어는 활동성 문제와 검열 저항력 감소로 이어질 수 있습니다. 탈출구가 존재하더라도 중앙 순서 여전히 거래 속도를 조작하거나 MEV를 클레임 하도록 명령할 수 있습니다. 또한 이로 인해 단일 장애점이 발생합니다. 즉, 순서 실패하면 전체 L2 네트워크가 제대로 작동하지 않습니다.
중앙 집중화 리스크 외에도 롤업은 특히 상호 운용성을 중심으로 추가적인 신뢰 가정과 상충을 초래합니다.
사용자는 호환되지 않는 동일한 자산의 여러 형태를 접하게 됩니다. 세 가지 주요 롤업(Arbitrum, Optimism, Base)은 서로 다른 생태계, 사용 사례, 사용자 그룹을 유지 관리합니다. 사용자는 특정 애플리케이션에 액세스하기 위해 롤업을 브리지해야 하며, 프로토콜은 여러 롤업에서 실행되어 브리지 통합과 함께 발생하는 복잡성과 보안 리스크 관리하면서 유동성과 사용자를 부트스트래핑해야 합니다.
추가적인 상호 운용성 문제는 기술적 한계(기본 L2 계층에서 초당 제한된 거래 수)에서 비롯되며, 이로 인해 특히 게임의 경우 모듈 더욱 강화되고 실행이 L3로 이동하게 되었습니다. 중앙집중화는 추가적인 과제를 야기합니다.
Base와 MegaETH와 같은 최적화된 롤업은 중앙 집중식 순서 통해 성능을 개선하고, 합의 요구 사항 없이 거래가 순서 되고 실행됨에 따라 EVM을 최적화하는 것을 보았습니다. 이를 통해 단일 대용량 머신을 사용함으로써 블록 시간을 줄이고 블록 크기를 늘릴 수 있지만, 단일 장애점과 잠재적인 검열 벡터가 생성됩니다.
Monad는 이더 메인넷보다 더 강력한 하드웨어를 요구하여 다른 접근 방식을 취합니다. 이더 L1 검증기에는 2코어 CPU, 4~8GB 메모리, 25Mbps 대역폭이 필요한 반면, 모나드에는 16코어 CPU, 32GB 메모리, 2TB SSD, 100Mbps 대역폭이 필요합니다. Monad의 사양은 이더 에 비해 엄청나게 크지만, Ethereum은 독립적인 검증자를 수용하기 위해 최소한의 노드 요구 사항을 유지합니다. 하지만 Monad가 권장하는 하드웨어는 오늘날 이미 접근 가능합니다.
하드웨어 사양을 넘어, Monad는 노드 분산을 통해 L2보다 더 높은 탈중앙화 달성하기 위해 소프트웨어 스택을 재설계하고 있습니다. L2s가 탈중앙화 희생하고 단일 순서 의 하드웨어 향상을 우선시하는 반면, Monad는 노드를 분산시키는 동시에 소프트웨어 스택을 수정하여 성능을 향상시키고 하드웨어 요구 사항을 늘립니다.
(5) Monad의 EVM 초기 이더 포크 실행을 위해 Go Ethereum 클라이언트를 유지하면서 Avalanche와 같은 합의 메커니즘을 주로 수정했습니다. 이더 클라이언트는 다양한 프로그래밍 언어로 존재하지만, 기본적으로는 원래 디자인을 복제합니다. 모나드는 합의와 실행 구성 요소를 처음부터 다시 구축한다는 점에서 다릅니다.
모나드는 하드웨어 활용 극대화를 우선시합니다. 이와 대조적으로, 이더 메인넷은 독립적인 스테이킹 지원하는 데 중점을 두고 있어 약한 하드웨어와의 호환성이 필요하기 때문에 성능 최적화가 제한됩니다. 이러한 제한은 블록 크기, 처리량 및 블록 시간의 개선에 영향을 미칩니다. 궁극적으로 네트워크의 속도는 가장 느린 검증자에 따라 결정됩니다.
Solana의 접근 방식과 유사하게 Monad는 더 강력한 하드웨어를 사용하여 대역폭을 늘리고 지연 시간을 줄입니다. 이 전략은 사용 가능한 모든 코어, 메모리, SSD를 활용하여 속도를 높입니다. 강력한 하드웨어의 비용이 꾸준히 낮아지고 있기 때문에 품질이 낮은 장치의 성능을 제한하는 것보다 성능이 높은 장치를 최적화하는 것이 더 실용적입니다.
현재 Geth 클라이언트는 단일 스레드 순차 프로세스를 통해 실행됩니다. 블록에는 이전 상태를 새로운 상태로 변환하는 선형적인 순서 의 거래가 포함되어 있습니다. 이 상태에는 모든 계정, 스마트 계약 및 저장된 데이터가 포함됩니다. 거래가 처리되고 검증될 때 상태 변경이 발생하여 계정 잔액, 스마트 계약, 토큰 소유권 및 기타 데이터에 영향을 미칩니다.
거래는 일반적으로 독립적으로 실행됩니다. 블록체인 상태는 여러 계정으로 구성되며, 각 계정은 독립적으로 거래를 수행하며, 이러한 거래는 일반적으로 서로 상호 작용하지 않습니다. 이러한 아이디어를 바탕으로 Monad는 낙관적 병렬 실행을 사용합니다.
낙관적 병렬 실행은 잠재적인 성능 이점을 얻기 위해 병렬로 트랜잭션을 실행하려고 시도합니다. 처음에는 충돌이 없을 것이라고 가정합니다. 여러 거래가 동시에 실행되며, 처음에는 잠재적인 충돌이나 종속성을 고려하지 않습니다. 실행 후, 시스템은 병렬 트랜잭션이 실제로 서로 충돌하는지 확인하고 충돌이 있는 경우 이를 수정합니다.
4. 프로토콜 메커니즘 의 병렬 실행
(1) 솔라나의 병렬 실행
사용자가 병렬 실행에 대해 생각할 때, 일반적으로 Solana와 SVM을 떠올립니다. 이는 액세스 목록을 통해 트랜잭션을 병렬로 실행할 수 있게 해줍니다. 솔라나의 거래는 헤더, 계정 키(거래에 포함된 지시 사항의 주소), 블록 해시(거래가 생성될 때 포함된 해시), 지시 사항, 그리고 거래 지시 사항에 따라 필요한 모든 계정에 대한 서명 배열로 구성됩니다.
각 트랜잭션에 대한 명령은 호출할 프로그램을 지정하는 프로그램 주소, 명령이 읽고 쓰는 모든 계정을 나열하는 계정, 명령 핸들러(명령을 처리하는 함수)와 명령 핸들러에 필요한 추가 데이터를 지정하는 명령 데이터로 구성됩니다.
각 지침에는 관련 계정에 대한 세 가지 주요 세부 정보가 명시되어 있습니다.
* 계정의 공개 주소
*계정에서 거래에 서명해야 하는지 여부
* 지시사항이 계정 데이터를 수정하는지 여부
솔라나는 이러한 지정된 계정 목록을 사용하여 거래 충돌을 미리 식별합니다. 모든 계정이 쓰기 가능 여부에 대한 세부 정보를 포함하여 지침에 지정되므로, 동일한 상태에 쓰는 계정이 하나도 없는 경우 트랜잭션을 병렬로 처리할 수 있습니다.
과정은 다음과 같습니다.
*Solana는 각 거래에서 제공된 계정 목록을 확인합니다.
* 어떤 계정에 기록될 것인지 식별합니다.
* 거래 간 충돌이 있는지 확인하세요(동일한 계정에 쓰고 있나요)
* 동일한 계정에 쓰지 않는 거래는 병렬로 처리되고, 충돌하는 쓰기 작업이 있는 거래는 순차적으로 처리됩니다.
EVM에도 비슷한 메커니즘이 있지만, 이더 액세스 목록을 필요로 하지 않기 때문에 사용되지 않습니다. 사용자는 거래에 액세스 목록을 포함시키기 때문에 더 많은 선불 비용을 지불해야 합니다. 거래 규모가 커지고 비용도 더 많이 들지만, 사용자는 액세스 목록을 지정하면 할인 혜택을 받습니다.
(2) 모나드의 병렬 실행은 솔라나와 다릅니다. 모나드는 낙관적 병렬 실행을 사용합니다. 어떤 거래가 어떤 계정에 영향을 미치는지 식별하고 이를 기반으로 병렬화하는 것(솔라나의 접근 방식) 대신, 모나드는 거래가 서로 간섭하지 않고 병렬로 실행될 수 있다고 가정합니다.
모나드가 트랜잭션을 병렬로 실행하는 경우 트랜잭션이 동일한 지점에서 시작한다고 가정합니다. 여러 거래가 병렬로 실행되는 경우 체인은 각 거래에 대해 보류 중인 결과를 생성합니다. 이 맥락에서 보류 중인 결과는 체인이 거래의 입력 및 출력을 추적하고 이것들이 상태에 어떤 영향을 미치는지를 파악하기 위해 수행하는 회계 작업을 말합니다. 이러한 보류 중인 결과는 원래 거래 순서(즉, 우선 수수료 기준)에 따라 제출됩니다.
보류 중인 결과를 커밋하려면 입력이 여전히 유효한지 확인하기 위해 입력을 검사합니다. 보류 중인 결과에 대한 입력이 변경/수정된 경우(즉, 트랜잭션이 동일한 계정에 액세스하여 서로 영향을 미치기 때문에 병렬로 작동할 수 없는 경우 트랜잭션은 순차적으로 처리됩니다(나중의 트랜잭션은 다시 실행됩니다)). 재실행은 정확성을 유지하기 위해서만 수행됩니다. 결과적으로 거래에 더 많은 시간이 걸리는 것이 아니라, 더 많은 계산이 필요하다는 것입니다.
첫 번째 실행 반복에서 모나드는 다른 트랜잭션과의 충돌이나 종속성을 이미 확인합니다. 따라서 트랜잭션이 두 번째로 실행되면(첫 번째 낙관적 병렬 실행이 실패한 후) 블록의 모든 이전 트랜잭션이 이미 실행되었으므로 두 번째 시도가 성공할 것이 확실합니다. 모나드의 모든 트랜잭션은 서로 의존하지만 단순히 순차적으로 실행되어 다른 병렬화되지 않은 EVM과 동일한 결과를 생성합니다.
모나드는 실행 중에 각 트랜잭션의 읽기 및 쓰기 세트를 추적한 다음, 원래 트랜잭션 순서로 결과를 병합합니다. 병렬로 실행되는 트랜잭션이 오래된 데이터를 사용하는 경우(이전 트랜잭션이 읽은 내용을 업데이트한 경우), 모나드는 병합할 때 이를 감지하고 올바른 업데이트된 상태로 해당 트랜잭션을 다시 실행합니다. 이를 통해 최종 결과가 블록의 순차적 실행과 동일해지고 이더 과 호환되는 의미 체계가 유지됩니다. 이러한 재실행에는 최소한의 오버헤드가 발생합니다. 서명 검증이나 데이터 로딩과 같은 비용이 많이 드는 단계를 처음부터 반복할 필요가 없으며, 종종 필요한 상태가 첫 번째 실행에서 이미 메모리에 캐시되어 있습니다.
예:
초기 상태에서 사용자 A는 100 USDC를 가지고, 사용자 B는 0 USDC를 가지고, 사용자 C는 300 USDC를 가지고 있습니다.
거래는 3가지가 있습니다.
*거래 1: 사용자 A가 사용자 B에게 10 USDC를 보냅니다.
*거래 2: 사용자 A가 사용자 C에게 10 USDC를 보냅니다.
직렬 실행 프로세스 직렬 실행을 사용하면 더 간단하지만 효율성은 떨어집니다. 각 거래는 순서대로 실행됩니다.
* 사용자 A가 먼저 사용자 B에게 10 USDC를 보냅니다.
*그러면 사용자 A가 사용자 C에게 10USDC를 보냅니다.
최종 상태에서는 직렬 실행(비모나드)의 경우:
*사용자 A는 80USDC를 남겼습니다.(B와 C에게 각각 10USDC를 보냄).
* 사용자 B는 10 USDC를 보유하고 있습니다.
* 사용자 C는 310 USDC를 보유하고 있습니다.
병렬 실행 프로세스
병렬 실행을 사용하면 프로세스가 더 복잡해지지만 효율성은 더 높아집니다. 각 거래가 순차적으로 완료될 때까지 기다리지 않고, 여러 거래가 동시에 처리됩니다. 거래는 병렬로 실행되지만, 시스템은 거래의 입력과 출력을 추적합니다. 순차적인 "병합" 단계 동안 트랜잭션이 이전 트랜잭션에 의해 변경된 입력을 사용한 것으로 감지되면 업데이트된 상태를 사용하여 트랜잭션이 다시 실행됩니다.
단계별 과정은 다음과 같습니다.
*사용자 A는 처음에 100 USDC를 가지고 있고, 사용자 B는 처음에 0 USDC를 가지고 있으며, 사용자 C는 처음에 300 USDC를 가지고 있습니다.
* 낙관적 병렬 실행에서는 여러 트랜잭션이 동시에 실행되며, 처음에는 모든 트랜잭션이 동일한 초기 상태에서 작업을 시작한다고 가정합니다.
* 이 경우, 트랜잭션 1과 트랜잭션 2는 병렬로 실행됩니다. 두 거래 모두 사용자 A의 초기 상태가 100 USDC라고 읽습니다.
*거래 1은 사용자 A에서 사용자 B로 10USDC를 보내면서 사용자 A의 잔액 90으로 줄이고 사용자 B의 잔액 10으로 늘리는 것을 계획합니다.
* 동시에, 트랜잭션 2는 사용자 A의 초기 잔액 이 100이며, 10 USDC를 사용자 C에게 이체하여 사용자 A의 잔액 90으로 줄이고 사용자 C의 잔액 310으로 늘리려고 한다는 내용도 읽습니다.
* 체인은 거래를 순서대로 검증하므로, 거래 1이 먼저 확인됩니다. 입력 값이 초기 상태와 일치하므로 제출되고, 사용자 A의 잔액 90이 되고, 사용자 B는 10 USDC를 받습니다.
*체인이 거래 2를 검사할 때 문제가 발견됩니다. 거래 2는 사용자 A가 100 USDC를 가지고 있다고 가정하여 계획되었지만, 사용자 A가 이제 90 USDC만 가지고 있습니다. 이러한 불일치로 인해 거래 2를 다시 실행해야 합니다.
* 재실행 중에 트랜잭션 2는 사용자 A의 업데이트된 상태를 90 USDC로 읽습니다. 그러면 사용자 A에서 사용자 C로 10 USDC가 성공적으로 이체되고, 사용자 A에게는 80 USDC가 남고, 사용자 C의 잔액 310 USDC로 증가합니다.
* 이 경우, 사용자 A는 두 번의 이체를 모두 수행할 수 있는 충분한 자금을 보유하고 있으므로 두 거래가 모두 성공적으로 완료됩니다.
최종 상태에서는 병렬 실행(Monad)의 경우:
결과는 동일합니다.
*사용자 A는 80USDC를 남겼습니다.(B와 C에게 각각 10USDC를 보냄).
* 사용자 B는 10 USDC를 보유하고 있습니다.
* 사용자 C는 310 USDC를 보유하고 있습니다.
* 사용자 D는 NFT 비용과 민트 NFT를 제외한 100 USDC를 보유하고 있습니다.
5. 지연된 실행
블록체인이 거래를 검증하고 합의에 도달하려면 전 세계의 노드가 서로 통신해야 합니다. 이러한 글로벌 커뮤니케이션은 도쿄에서 뉴욕까지 먼 거리 사이에서 데이터를 전송하는 데 시간이 걸리기 때문에 물리적인 한계에 부딪힙니다.
대부분의 블록체인은 실행이 합의와 밀접하게 결합된 순차적 접근 방식을 사용합니다. 이러한 시스템에서 실행은 합의의 전제 조건입니다. 즉, 블록을 확정하기 전에 노드가 거래를 실행해야 합니다.
자세한 내용은 다음과 같습니다.
실행은 합의에 앞서 이루어지므로 다음 블록을 시작하기 전에 블록이 확정됩니다. 노드는 먼저 거래 순서에 대한 합의에 도달하고, 거래를 실행한 후 상태 요약의 머클 루트에 대한 합의에 도달합니다. 리더는 블록을 공유하기 전에 제안된 블록의 모든 거래를 실행해야 하며, 검증 노드는 합의에 도달하기 전에 모든 거래를 실행해야 합니다. 이 프로세스는 여러 라운드의 글로벌 커뮤니케이션을 통해 합의에 도달하는 동안 두 번 발생하므로 실행 시간이 제한됩니다. 예를 들어, 이더 의 블록 시간은 12초인 반면, 실제 실행에는 100밀리초만 걸릴 수 있습니다(실제 실행 시간은 블록 복잡성과 가스 사용량에 따라 크게 다릅니다).
일부 시스템에서는 실행을 교차하여 최적화하려고 합니다. 즉, 작업을 여러 프로세스 간에 번갈아가며 수행하는 작은 세그먼트로 나눕니다. 처리는 여전히 순차적이며 주어진 순간에는 하나의 작업만 실행되지만, 빠른 전환으로 인해 상당한 동시성이 생성됩니다. 그러나 이러한 접근 방식은 실행과 합의가 여전히 상호 의존적이기 때문에 처리량을 근본적으로 제한합니다.
모나드는 실행을 합의에서 분리함으로써 순차적이고 교차적인 실행의 한계를 해결합니다. 노드는 거래를 실행하지 않고도 거래 순서에 대한 합의에 도달합니다. 두 가지 병렬 프로세스가 발생합니다.
*노드는 합의에 도달한 거래를 실행합니다.
*합의는 실행이 완료될 때까지 기다리지 않고 다음 블록으로 계속 진행되며, 실행은 합의에 따라 진행됩니다.
이러한 구조는 실행이 시작되기 전에 시스템이 합의를 통해 대량 의 작업을 처리할 수 있게 하며, 이를 통해 모나드는 추가 시간을 할당하여 더 큰 블록과 더 많은 거래를 처리할 수 있습니다. 더욱이 이를 통해 각 프로세스가 전체 블록 시간을 독립적으로 사용할 수 있습니다. 즉, 합의에서는 전체 블록 시간을 글로벌 통신에 사용할 수 있고 실행에서는 전체 블록 시간을 계산에 사용할 수 있으며 서로를 차단하지 않습니다.
실행을 합의에서 분리하는 동시에 안전성과 상태 일관성을 유지하기 위해 Monad는 지연된 머클 루트를 사용합니다. 여기서 각 블록은 N 블록 전의 상태의 머클 루트를 포함합니다. (N은 출시 시 10이 될 것으로 예상되며, 현재 테스트넷에서는 3으로 설정되어 있습니다.) 이를 통해 노드는 실행 후 동일한 상태에 도달했는지 확인할 수 있습니다. 지연된 머클 루트는 체인이 상태 일관성을 검증할 수 있도록 합니다. 지연된 머클 루트는 체크포인트 역할을 합니다. N개 블록 후에 노드는 같은 상태 루트에 도달했다는 것을 증명해야 하며, 그렇지 않으면 잘못된 것을 실행한 것입니다. 더욱이 노드의 실행으로 인해 다른 상태 루트가 생성되는 경우 N개 블록 이후에 이를 감지하고 롤백하여 재실행하여 합의에 도달할 수 있습니다. 이는 노드가 악의적인 행동을 할 리스크 제거하는 데 도움이 됩니다. 결과적으로 지연된 Merkle 루트는 라이트 클라이언트가 상태를 검증하는 데 사용할 수 있습니다. 다만 N블록의 지연이 있을 뿐입니다.
실행이 지연되고 합의 이후에 이루어지기 때문에 발생할 수 있는 문제 중 하나는 악의적인 행위자(또는 일반 사용자 실수로)가 자금이 부족하여 결국 실패할 거래를 계속 제출한다는 것입니다. 예를 들어, 총 잔액 10 MON인 사용자가 5건의 거래를 제출할 때 각 거래에서 개별적으로 10 MON을 보내려고 하면 문제가 발생할 수 있습니다. 그러나 확인 절차가 없다면 이러한 거래는 합의에 통과하더라도 실행 과정에서 실패할 수 있습니다. 이 문제를 해결하고 잠재적인 스팸을 줄이기 위해 노드는 합의 과정에서 진행 중인 거래를 추적하여 보호조치 구현합니다.
각 계정에 대해 노드는 N 블록 전의 계정 잔액 확인합니다(이것이 가장 최근에 검증된 정확한 상태이기 때문입니다). 그런 다음 해당 계정에서 "전송 중"(합의를 통과했지만 아직 실행되지 않음)인 보류 중인 각 거래에 대해 전송되는 값(예: 1 MON 전송)과 gas_limit에 maxFeePerGas를 곱하여 계산된 최대 가스 비용을 뺍니다.
이 프로세스는 합의 중에 새로운 거래를 검증하는 데 사용되는 실행 중인 "사용 가능한 잔액"을 생성합니다. 새 거래의 가치와 최대 가스 비용을 합친 금액이 사용 가능한 잔액 초과하면, 실행 중에 거래를 통과시키고 실패하는 대신 합의 과정에서 해당 거래가 거부됩니다.
모나드의 합의는 상태에 대한 약간 지연된 견해(실행 분리로 인해)로 진행되므로, 송신자가 궁극적으로 지불할 수 없는 거래를 포함하지 않도록 보호조치 구현합니다. Monad에서는 합의 과정에서 각 계정마다 사용 가능한 잔액 또는 "예비"잔액 있습니다. 제안된 블록에 거래가 추가되면 프로토콜은 이 사용 가능한 잔액 에서 거래의 최대 가능 비용(가스 * 최대 수수료 + 전송된 가치)을 차감합니다. 계좌의 사용 가능한 잔액 0보다 낮아지면 해당 계좌의 추가 거래는 블록에 포함되지 않습니다.
이 메커니즘(때로는 예비 잔액 에 운송비를 청구하는 것으로 설명됨)은 지불이 가능한 거래만 제안되도록 보장하여, 공격자가 자금이 0인 쓸모없는 거래로 네트워크를 범람시키려는 DoS 공격을 방지합니다. 블록이 확정되고 실행되면 잔액 그에 따라 조정되지만, 합의 단계에서 모나드 노드는 항상 보류 중인 거래의 지출 가능한 잔액 최신 상태로 확인합니다.
6. 모나드BFT
(1) 합의
핫스터프
MonadBFT는 HotStuff 합의에서 파생된 저지연, 고처리량 비잔틴 장애 허용(BFT) 합의 메커니즘입니다.
Hotstuff는 VMresearch에서 개발되었으며, 이전 Meta 블록체인 팀의 LibraBFT에 의해 더욱 개선되었습니다. 이 기술은 선형적인 뷰 변경과 반응성을 실현하여 사전 결정된 시간 초과가 아닌 실제 네트워크 속도로 리더를 효율적으로 회전할 수 있습니다. HotStuff는 또한 효율성을 높이기 위해 임계값 시그니처를 사용하고 파이프라인을 구현하여 이전 블록이 커밋되기 전에 새로운 블록이 제안될 수 있도록 합니다.
그러나 이러한 이점에는 특정한 상쇄 효과가 있습니다. 기존의 2라운드 BFT 프로토콜과 비교했을 때 라운드가 추가되어 지연 시간이 길어지고 파이프라인 중에 포크 발생할 가능성이 있습니다. 이러한 상쇄에도 불구하고 HotStuff의 디자인은 대규모 블록체인 구현에 더 적합하지만 2라운드 BFT 프로토콜보다 최종성이 느립니다.
HotStuff의 설명은 다음과 같습니다.
*거래가 발생하면, 거래는 리더라고 불리는 네트워크의 검증자에게 전송됩니다.
*리더는 이러한 거래를 블록으로 컴파일하여 네트워크의 다른 검증자에게 브로드캐스트합니다.
*그런 다음 검증자는 투표를 통해 블록을 검증하고, 투표는 다음 블록의 리더에게 전송됩니다.
* 악의적인 행위자나 통신 장애로부터 보호하기 위해, 블록은 상태가 확정되기 전에 여러 라운드의 투표를 거쳐야 합니다.
*특정한 구현 방식에 따라 블록은 2~3라운드를 성공적으로 통과한 후에만 커밋될 수 있으며, 이를 통해 합의의 견고성과 보안성이 보장됩니다.
MonadBFT는 HotStuff에서 파생되었지만, 더욱 탐구해 볼 만한 고유한 수정 사항과 새로운 개념을 도입했습니다.
거래 계약
MonadBFT는 부분적으로 동기적 조건에서 거래 프로토콜을 구현하도록 특별히 설계되었습니다. 즉, 메시지 지연이 예측할 수 없는 비동기 기간 중에도 체인이 합의에 도달할 수 있습니다.
결국 네트워크는 안정화되고 (알려진 시간 범위 내에서) 메시지를 전달합니다. 이러한 비동기 단계는 모나드의 아키텍처에서 비롯됩니다. 체인은 속도, 처리량 및 병렬 실행을 높이기 위한 특정 메커니즘을 구현해야 합니다.
듀얼 휠 시스템
원래 3륜 시스템을 구현했던 HotStuff와 달리 MonadBFT는 Jolteon, DiemBFT, Fast HotStuff와 유사한 2륜 시스템을 사용합니다.
라운드는 다음과 같은 기본 단계로 구성됩니다.
* 각 라운드에서 리더는 새로운 블록과 이전 라운드의 인증서(QC 또는 TC)를 브로드캐스트합니다.
*각 검증자는 블록을 검토하고 서명 투표를 다음 라운드 리더에게 보냅니다.
* 충분한 투표(2/3)가 수집되면 QC가 형성됩니다. QC는 네트워크의 검증자가 블록을 추가하기로 합의에 도달했음을 의미하고, TC는 합의 라운드가 실패하여 다시 시작해야 함을 의미합니다.
"듀얼 라운드"는 구체적으로 제출 규칙을 의미합니다. 2라운드 시스템에서 블록을 제출하려면:
* 라운드 1: 초기 블록이 제안되고 QC를 받습니다.
*라운드 2: 다음 블록이 제안되고 QC를 받습니다. 이 두 라운드가 연속적으로 완료되면 첫 번째 블록이 커밋될 수 있습니다.
DiemBFT는 3라운드 시스템을 사용했으나 2라운드 시스템으로 업그레이드되었습니다. 2라운드 시스템은 의사소통 라운드 수를 줄임으로써 더 빠른 제출이 가능합니다. 추가 확인을 기다릴 필요가 없으므로 거래를 더 빠르게 제출할 수 있으므로 대기 시간이 줄어듭니다.
구체적인 프로세스
MonadBFT의 합의 프로세스는 다음과 같습니다.
*리더 운영 및 블록 제안: 현재 라운드의 지정된 리더가 합의를 시작하면 프로세스가 시작됩니다. 리더는 사용자 거래와 QC 또는 TC 형태의 이전 라운드 합의 증명을 포함하는 새로운 블록을 생성하고 방송합니다. 이는 각 블록 제안이 이전 블록의 인증을 수행하는 파이프라인 구조를 생성합니다.
*검증자 작업: 검증자가 리더로부터 블록 제안을 받으면 검증 프로세스를 시작합니다. 각 검증자는 프로토콜 규칙에 따라 블록의 유효성을 신중하게 검토합니다. 유효한 블록은 서명된 YES 투표를 받고, 이 투표는 다음 라운드의 리더에게 전송됩니다. 그러나 검증자가 예상 시간 내에 유효한 블록을 받지 못하면, 검증자는 알고 있는 가장 높은 QC를 포함하는 서명된 Timeout 메시지를 브로드캐스트하여 시간 초과 절차를 시작합니다. 이러한 이중 경로 접근 방식은 블록 제안이 실패하더라도 프로토콜이 진행될 수 있도록 보장합니다.
* 인증서 생성: 프로토콜은 두 가지 유형의 인증서를 사용하여 합의 진행 상황을 추적합니다. 리더가 검증자 3분의 2로부터 YES 투표를 모으면 QC가 생성되어 블록에 대한 광범위한 합의가 이루어집니다. 또는 검증자 3분의 2가 유효한 제안을 받지 못하고 시간 초과가 발생하면 TC를 생성하여 프로토콜이 안전하게 다음 라운드로 진행할 수 있습니다. 두 가지 유형의 인증서 모두 검증자의 참여를 증명하는 주요 증거 역할을 합니다.
*블록 마무리(두 체인 커밋 규칙): MonadBFT는 블록 마무리를 위해 두 체인 커밋 규칙을 사용합니다. 검증자가 연속 라운드에서 인접한 두 인증 블록이 체인 B ← QC ← B' ← QC'를 형성하는 것을 관찰하면 블록 B와 그 모든 조상을 안전하게 커밋할 수 있습니다. 이러한 2개 체인 접근 방식은 성능을 유지하는 동시에 보안과 활성성을 제공합니다.
로컬 메모리 풀 아키텍처
모나드는 기존의 글로벌 메모리 풀 대신 로컬 메모리 풀 아키텍처를 사용합니다. 대부분의 블록체인에서 보류 중인 거래는 모든 노드에 브로드캐스트되는데, 이는 중복 전송으로 인해 속도가 느리고(네트워크 홉이 많음) 대역폭을 많이 소모할 수 있습니다. 이와 대조적으로 Monad에서는 각 검증자가 자체 메모리 풀을 유지 관리하고, 트랜잭션은 RPC 노드에서 다음 미리 정해진 몇몇 리더(현재 다음 N=3 리더)에게 직접 전달되어 포함됩니다.
이는 알려진 리더 일정을 활용하여(리더가 아닌 사람에게 불필요한 브로드캐스트를 방지) 새로운 거래가 블록 제안자에게 신속하게 전달되도록 보장합니다. 들어오는 리더는 유효성 검사를 수행하고 거래를 로컬 메모리 풀에 추가합니다. 따라서 유효성 검사자가 리더를 맡을 차례가 되면 관련 거래가 이미 대기열에 추가됩니다. 이 설계는 전파 지연을 줄이고 대역폭을 절약하여 더 높은 처리량을 달성합니다.
(2) 랩터캐스트
Monad는 RaptorCast라는 특수 멀티캐스트 프로토콜을 사용하여 리더에서 모든 검증자에게 블록을 빠르게 전파합니다. 리더는 전체 블록을 각 피어에 순차적으로 전송하거나 간단한 브로드캐스트에 의존하는 대신, 삭제 코딩 방식(RFC 5053에 따름)을 사용하여 블록 제안 데이터를 인코딩된 청크로 나누고 이러한 청크를 2단계 릴레이 트리를 통해 효율적으로 분배합니다. 실제로 리더는 여러 블록을 1차 검증자 노드에 전송하고, 1차 검증자 노드는 해당 블록을 다른 검증자에게 전달하여 각 검증자가 완전한 블록을 재구성할 수 있을 만큼 충분한 블록을 결국 수신하게 됩니다. 블록의 분배는 부하 분산을 보장하기 위해 지분 가중치에 따라 이루어집니다(각 검증자는 블록의 일부를 전달해야 함). 이런 방식으로 전체 네트워크의 업로드 용량을 사용하여 블록을 빠르게 전파하고 지연 시간을 최소화하는 동시에 메시지를 삭제할 수 있는 비잔틴(악의적이거나 결함이 있는) 노드를 허용합니다. RaptorCast를 사용하면 Monad가 대용량 블록도 빠르고 안정적인 블록 브로드캐스팅을 구현할 수 있으며, 이는 높은 처리량에 필수적입니다.
BLS 및 ECDSA 서명
QC와 TC는 암호화에 사용되는 두 가지 다른 유형의 디지털 서명 체계인 BLS와 ECDSA 서명을 사용하여 구현됩니다.
Monad는 BLS 서명과 ECDSA 서명을 조합하여 보안과 확장성을 개선합니다. BLS 서명은 서명 집계를 지원하는 반면, ECDSA 서명은 일반적으로 검증 속도가 더 빠릅니다.
ECDSA 서명
서명을 집계할 수는 없지만 ECDSA 서명이 더 빠릅니다. 모나드는 이를 QC와 TC에 사용합니다.
QC 생성:
* 리더가 블록을 제안합니다.
* 검증자는 투표에 서명하여 동의합니다.
* 필요한 투표 부분이 수집되면 이를 QC로 결합할 수 있습니다.
*QC는 검증자가 블록에 동의한다는 것을 증명합니다.
TC 생성:
* 검증자가 예정된 시간 내에 유효한 블록을 수신하지 못하는 경우
* 피어에게 서명된 시간 초과 메시지를 브로드캐스트합니다.
* 충분한 시간 초과 메시지가 수집되면 TC를 형성합니다.
*TC는 현재 라운드에서 탈락하더라도 다음 라운드에 진입할 수 있도록 허용합니다.
BLS Signature Monad는 다중 서명에 BLS 서명을 사용하여 여러 서명을 점진적으로 단일 서명으로 집계할 수 있습니다. 이는 주로 투표나 시간 초과와 같은 집계 가능한 메시지 유형에 사용됩니다.
투표는 검증자가 제안된 블록에 동의할 때 보내는 메시지입니다. 여기에는 블록 승인을 나타내는 서명이 포함되어 있으며 QC를 구성하는 데 사용됩니다.
타임아웃은 예상 시간 내에 유효한 블록을 받지 못할 때 검증자가 보내는 메시지입니다. 여기에는 현재 라운드 번호, 검증기의 가장 높은 QC 및 이러한 값의 서명이 포함된 서명된 메시지가 포함됩니다. TC를 구축하는 데 사용됩니다.
투표와 타임아웃 모두 BLS 서명 조합/집계를 사용하여 공간을 절약하고 효율성을 높일 수 있습니다. 앞서 언급했듯이 BLS는 ECDSA 서명보다 상대적으로 느립니다.
Monad는 ECDSA와 BLS를 함께 사용하여 두 가지의 효율성을 모두 활용합니다. BLS 방식은 느리지만 서명 집계가 가능하므로 투표와 타임아웃에 특히 유용합니다. 반면 ECDSA는 빠르지만 집계가 불가능합니다.
7. 모나드 MEV
간단히 말해서, MEV는 당사자가 블록에서 거래를 순서 포함하거나 제외함으로써 클레임 할 수 있는 가치를 나타냅니다. MEV는 종종 "좋은" MEV, 즉 시장을 건강하고 효율적으로 유지하는 MEV(예: 청산, 차익거래) 또는 "나쁜" MEV(예: 샌드위치 공격)로 분류됩니다.
Monad의 지연된 실행은 온체인 MEV의 작동 방식에 영향을 미칩니다. 이더 에서는 실행이 합의의 전제 조건입니다. 즉, 노드가 블록에 동의하면 거래 목록과 순서, 그리고 결과 상태에도 동의한다는 의미입니다. 새로운 블록을 제안하기 전에 리더는 모든 거래를 실행하고 최종 상태를 계산해야 하며, 이를 통해 검색자와 블록 빌더는 가장 최근에 확인된 상태에 대해 거래를 안정적으로 시뮬레이션할 수 있습니다.
이와 대조적으로 모나드에서는 합의와 실행이 분리됩니다. 노드는 가장 최근 블록의 거래 순서에만 동의하면 되며, 상태에 대한 합의는 나중에 이루어질 수 있습니다. 즉, 검증자는 이전 블록의 상태 데이터를 기반으로 작업할 수 있으며, 이로 인해 최신 블록에 대한 시뮬레이션이 불가능해질 수 있습니다. 확인된 상태 정보의 부족으로 인해 발생하는 복잡성 외에도 Monad의 1초 블록 시간은 빌더가 블록을 시뮬레이션하여 빌드하는 블록을 최적화하는 데 어려움을 줄 수 있습니다.
투자자에게는 최신 상태 데이터에 대한 접근이 필요합니다. 이를 통해 확인된 자산 가격, 유동성 풀 잔액, DEX의 스마트 계약 상태 등을 확인할 수 있으며, 이를 통해 잠재적인 차익거래 기회를 파악하고 청산 이벤트를 파악할 수 있습니다. 최신 상태 데이터가 확인되지 않으면 검색자는 다음 블록이 생성되기 전에 블록을 시뮬레이션할 수 없으며 상태가 확인되기 전에 트랜잭션 롤백의 리스크 에 직면하게 됩니다.
모나드 블록의 지연을 고려하면 MEV 환경은 솔라나와 유사할 수 있습니다.
문맥상 Solana에서 블록은 ~400ms마다 슬롯에 생성되지만 블록이 생성되고 "루팅"(완료)되는 사이의 시간은 훨씬 더 깁니다. 일반적으로 2000-4000ms입니다. 이러한 지연은 블록 생산 자체에서 발생하는 것이 아니라 블록을 최종적으로 확정할 만큼 충분한 지분 가중 투표를 수집하는 데 걸리는 시간에서 발생합니다.
이 투표 기간 동안 네트워크는 새로운 블록을 병렬로 계속 처리합니다. 거래 수수료가 매우 낮고 새로운 블록을 병렬로 처리할 수 있었기 때문에 검색자가 포함되기를 바라며 대량 의 거래를 보내는 "경쟁 조건"이 발생했고, 이로 인해 많은 거래가 롤백되었습니다. 예를 들어, 12월 동안 솔라나의 비투표 거래 31억 6천만 건 중 13억 건(약 41%)이 롤백되었습니다. Jito의 Buffalu는 2023년 초에 "Solana의 중재 거래의 98%가 실패한다"고 강조했습니다.
최신 블록에 대한 확인 상태 정보가 없고 새로운 블록이 병렬로 처리되는 모나드에서의 유사한 블록 지연 효과로 인해, 검색자는 대량 의 거래를 보내려는 인센티브를 받을 수 있습니다. 하지만 거래가 롤백되고 확인된 상태가 시뮬레이션에 사용한 상태와 다르기 때문에 실패할 수 있습니다.
8. 모나드DB
Monad는 블록체인 데이터를 저장하고 액세스하기 위해 MonadDB라는 맞춤형 데이터베이스를 구축하기로 결정했습니다. 체인 확장성과 관련된 일반적인 문제는 상태 증가, 즉 데이터 크기가 노드의 용량을 초과할 때 발생하는 문제입니다. Paradigm은 4월에 상태 성장에 관한 짧은 연구 논문을 발표했는데, 이 논문에서 상태 성장, 기록 성장, 상태 접근의 차이점을 강조했습니다. 이들은 이 두 개념이 노드 하드웨어 성능에 영향을 미치는 별개의 개념임에도 불구하고 종종 혼동된다고 주장합니다.
그들은 다음과 같이 지적합니다.
*상태 증가는 새로운 계정(계정 잔액 및 nonce)과 계약(계약 바이트코드 및 스토리지)의 축적을 의미합니다. 노드에는 상태 증가를 수용할 만큼 충분한 저장 공간과 메모리 용량이 있어야 합니다.
*역사적 성장은 새로운 블록과 거래의 축적을 의미합니다. 노드는 블록 데이터를 공유하기 위한 충분한 대역폭과 블록 데이터를 저장하기 위한 충분한 저장 공간을 가져야 합니다.
*상태 액세스는 블록을 구축하고 검증하는 데 사용되는 읽기 및 쓰기 작업을 말합니다.
앞서 언급했듯이 상태 성장과 기록 성장은 모두 체인의 확장성에 영향을 미칩니다. 왜냐하면 데이터 크기가 노드의 용량을 초과할 수 있기 때문입니다. 노드는 블록을 구축, 검증, 배포하기 위해 영구 저장소에 데이터를 저장해야 합니다. 또한, 노드는 체인과 동기화하기 위해 메모리 내 캐시를 가져야 합니다. 상태 성장, 이력 성장, 최적화된 상태 접근은 체인이 적응해야 하며, 그렇지 않으면 블록 크기와 블록당 작업이 제한됩니다. 블록에 더 많은 데이터가 포함될수록 블록당 읽기 및 쓰기 작업이 많아지고, 히스토리 증가와 상태 증가도 커지며, 효율적인 상태 액세스에 대한 필요성도 커집니다.
상태 및 기록 증가는 확장성에 중요한 요소이기는 하지만, 특히 디스크 성능 관점에서 볼 때 큰 문제는 아닙니다. MonadDB는 로그 데이터베이스 확장을 통해 상태 증가를 관리하는 데 중점을 둡니다. 따라서 상태를 16배 늘리면 상태를 읽을 때마다 추가 디스크 액세스가 한 번만 필요합니다. 역사적 성장과 관련하여, 체인의 성능이 높을 경우 결국 로컬에 저장할 데이터가 너무 많아질 것입니다. 솔라나(Solana)와 같이 처리량이 높은 다른 체인은 Google BigTable과 같은 클라우드 호스팅에 의존하여 과거 데이터를 저장하는데, 이는 효과적이지만 중앙 집중화된 기관에 의존하기 때문에 탈중앙화 희생됩니다. Monad는 처음에는 비슷한 솔루션을 구현한 후 결국 탈중앙화 솔루션을 개발할 예정입니다.
(1) 상태 접근
MonadDB의 주요 구현 중 하나는 상태 증가 및 기록 증가 외에도 각 블록의 읽기 및 쓰기 작업을 최적화하는 것입니다(즉, 상태 액세스를 개선하는 것입니다).
이더 Merkle Patricia Trie("MPT")를 사용하여 상태를 저장합니다. MPT는 PATRICIA(데이터 검색 알고리즘)의 특성을 활용해 더욱 효율적인 데이터 검색을 달성합니다.
머클 트리 머클 트리("MT")는 해시 값의 집합으로, 궁극적으로 머클 루트라고 하는 단일 루트 해시 값으로 축소됩니다. 데이터 해시는 원본 데이터를 고정된 크기로 암호화하여 표현한 것입니다. 머클 루트는 단일 해시 값(머클 루트)이 남을 때까지 데이터 쌍을 반복적으로 해싱하여 생성됩니다. 머클 루트의 유용성은 각 리프 노드를 개별적으로 검증하지 않고도 리프 노드(즉, 루트를 생성하기 위해 반복적으로 해시되는 단일 해시 값)를 검증할 수 있다는 것입니다.
이 방법은 각 거래를 개별적으로 검증하는 것보다 훨씬 효율적이며, 특히 각 블록에 많은 거래가 있는 대규모 시스템에서는 더욱 그렇습니다. 이는 개별 데이터 간에 검증 가능한 관계를 생성하고 거래와 루트를 재구성하는 데 필요한 중간 해시(n개 거래 대신 log(n)개 해시)를 제공하여 거래가 블록에 포함되었음을 증명할 수 있는 "Merkle 증명"을 허용합니다.
머클 파트리샤 트리
머클 트리는 거래가 정적이고 주요 요구 사항이 거래가 블록에 존재한다는 것을 증명하는 것인 비트코인의 요구 사항에 매우 적합합니다. 그러나 이는 단순히 존재 여부를 확인하는 것이 아니라 저장된 데이터(예: 계정 잔액 및 논스, 신규 계정 추가, 저장소의 키 업데이트)를 검색하고 업데이트해야 이더 이더 의 사용 사례에는 적합하지 않습니다. 이것이 이더 상태를 저장하기 위해 Merkle Patricia Trie를 사용하는 이유입니다.
머클 패트리샤 트라이("MPT")는 상태 데이터베이스에서 키-값 쌍을 저장하고 검증하는 데 사용되는 수정된 머클 트리입니다. MT는 일련의 데이터(예: 거래)를 가져와 쌍으로만 해시하는 반면, MPT는 데이터를 사전처럼 구성합니다. 즉, 각 데이터(값)에는 저장되는 특정 주소(키)가 있습니다. 이 키-값 저장소는 Patricia Trie를 사용하여 구현됩니다.
이더 검색해야 하는 데이터에 따라 다양한 유형의 Tries에 액세스하기 위해 여러 유형의 키를 사용합니다. 이더 4가지 유형의 Trie를 사용합니다.
*World State Trie: 주소와 계정 상태 간의 매핑을 포함합니다.
*계정 저장 트리: 스마트 계약과 관련된 데이터를 저장합니다.
*거래 트라이: 블록에 포함된 모든 거래를 담고 있습니다.
* 영수증 트리: 거래 실행 정보가 포함된 거래 영수증을 저장합니다.
*Trie는 다양한 유형의 키를 통해 값에 액세스하며, 이를 통해 체인은 잔액 확인, 계약 코드 존재 확인, 특정 계정 데이터 조회 등 다양한 기능을 수행할 수 있습니다.
참고: 이더 "블록 검증 기능을 잃지 않으면 대량 의 상태 데이터를 저장하는 것을 중단할 수 있도록 이더 노드를 업그레이드"하기 위해 MPT에서 Verkle 트리로 이동할 계획입니다.
모나드 DB: 패트리샤 트라이
이더 과 달리 MonadDb는 Patricia Trie 데이터 구조를 디스크와 메모리에 기본적으로 구현합니다.
앞서 언급했듯이 MPT는 키-값 검색을 위한 Merkle 트리 데이터 구조와 Patricia Trie를 결합한 것입니다. 두 개의 서로 다른 데이터 구조가 통합/결합됩니다. Patricia Trie는 키-값 쌍을 저장, 검색, 업데이트하는 데 사용되고 Merkle 트리는 검증에 사용됩니다. 이로 인해 해시 기반 노드 참조에 복잡성이 추가되고, Merkle은 각 노드의 해시에 대한 추가 저장소가 필요하므로 추가적인 오버헤드가 발생합니다.
Patricia Trie 기반 데이터 구조를 통해 MonadDB는 다음을 수행할 수 있습니다.
* 더 간단한 구조를 갖습니다. 각 노드에는 머클 해시가 없고, 노드 관계에는 해시 참조가 없으며, 키와 값을 직접 저장합니다. * 직접 경로 압축: 데이터에 도달하는 데 필요한 탐색 횟수를 줄여줍니다. * 로컬 키-값 저장소: MPT가 Patricia Trie를 별도의 키-값 저장소 시스템에 통합하더라도 Patricia Trie의 로컬 기능은 키-값 저장소로서 더 나은 최적화를 가능하게 합니다. * 데이터 구조 변환 필요 없음: Trie 형식과 데이터베이스 형식 간에 변환할 필요가 없습니다. 이러한 기능을 통해 MonadDB는 상대적으로 낮은 계산 오버헤드를 갖고, 적은 저장 공간을 필요로 하며, 더 빠른 작업(검색 또는 업데이트)을 가능하게 하고, 더 간단한 구현을 유지할 수 있습니다.
비동기 I/O
거래는 모나드에서 병렬로 실행됩니다. 즉, 저장소는 상태에 병렬로 접근하는 여러 트랜잭션을 수용해야 합니다. 즉, 데이터베이스는 비동기 I/O를 제공해야 합니다.
MonadDB는 최신 비동기 I/O 구현을 지원하므로 대량 스레드를 생성하지 않고도 여러 작업을 처리할 수 있습니다. LMDB와 같이 여러 디스크 작업을 처리하기 위해 여러 스레드를 생성해야 하는 다른 기존 키-값 데이터베이스와 달리 관리할 스레드가 적기 때문에 오버헤드가 적습니다.
암호화 세계에서 입출력 처리의 간단한 예는 다음과 같습니다.
* 입력: 거래 전 계좌 잔액 확인하기 위해 상태를 읽습니다. * 출력: 이체 후 계좌 잔액 쓰거나 업데이트합니다. 비동기 I/O를 사용하면 이전 I/O 작업이 아직 완료되지 않았더라도 입출력 처리(즉, 저장소 읽기 및 쓰기)가 가능합니다. 여러 거래가 병렬로 실행되기 때문에 모나드에 이것이 필요합니다. 따라서 한 트랜잭션이 저장소에 액세스하여 데이터를 읽거나 써야 하는 동안, 다른 트랜잭션은 저장소에서 데이터를 읽거나 쓰고 있는 중입니다. 동기식 I/O에서는 프로그램이 순차적으로 한 번에 하나씩 I/O 작업을 수행합니다. 동기식 I/O 처리에서 I/O 작업이 요청되면 트랜잭션은 이전 작업이 완료될 때까지 기다립니다. 예를 들어:
* 동기화 I/O: 체인은 tx/블록 #1
