Monad는 이더리움-호환 Layer-1 블록체인으로 초당 10,000 건의 처리량, 1초의 블록 시간 및 싱글-슬롯의 최종성을 제공합니다.
Monad의 이더리움 버츄얼 머신 구현은 상하이 포크와 일치하며, Monad 실행 환경에서 역사적인 이더리움 트랜잭션의 시뮬레이션은 동일한 결과를 생성합니다. Monad는 또한 사용자가 MetaMask 및 Etherscan과 같은 익숙한 도구를 사용하여 Monad와 상호 작용할 수 있도록 완전한 이더리움 RPC 호환성을 제공합니다.
Monad는 다음과 같은 몇 가지 주요 혁신을 통해 이러한 성능 향상을 달성합니다:
비록 Monad에는 병렬 실행과 파이프라이닝이 포함되어 있지만, Monad의 블록은 선형이며 각 블록 내에서 트랜잭션은 선형적으로 오더된다는 점에 주목하는 것이 중요합니다.
| 주소 공간 | 이더리움과 일치 ****ECDSA를 사용한 20-바이트 주소 | | --- | --- | | 트랜잭션 형식 | 이더리움과 일치 EIP-2718을 준수하며 RLP로 인코딩됩니다. 액세스 목록 (EIP-2930)은 지원되지만 필수는 아닙니다. | | 지갑 호환성 | Monad는 Metamask와 같은 표준 이더리움 지갑과 호환됩니다. 필요한 유일한 변경 사항은 RPC URL 및 ChainId를 수정하는 것입니다. |
Monad는 EVM 바이트코드를 지원하며 이더리움과 바이트코드 측면에서 동등합니다. 모든 옵코드(상하이 포크 기준)가 지원됩니다.
| Sybil 저항 메커니즘 | 지분증명 (PoS) |
|---|---|
| 위임 | 허용됨 (프로토콜 내) |
| 컨센서스 메커니즘 및 파이프라이닝 | MonadBFT는 부분 동기화 조건 하에서 트랜잭션 오더와 인클루젼에 대한 합의를 도출하기 위한 리더-기반 알고리즘입니다. 대체로 말하자면, 이것은 추가적인 연구 개선이 된 HotStuff의 파생물입니다. |
MonadBFT는 일반적인 경우에 선형 통신 오버헤드를 갖는 파이프라인 2단계 BFT 알고리즘입니다. 대부분의 BFT 알고리즘과 마찬가지로 통신은 단계별로 진행됩니다. 각 단계에서 리더는 투표자에게 서명된 메시지를 보내고, 투표자들은 서명된 응답을 반환합니다. 파이프라이닝을 통해 블록k에 대한 쿼럼 인증서(QC) 또는 타임아웃 인증서(TC)가 블록k+1.의 제안에 동반될 수 있습니다. 타임아웃은 이차 메시징을 초래합니다. |
| 블록 시간 | 1초 |
| 최종성 | 싱글 슬롯. 지분 가중치의 2/3이 블록 제안에 YES를 투표하면 최종화됩니다. |
| 멤풀 | 멤풀이 존재합니다. 효율성을 위해 트랜잭션은 이레이저 코드화되고 브로드캐스트 트리를 사용하여 통신됩니다. |
| 스팸 저항 | 사용자는 블록에 포함되기 위해 ("운송 비용") 지불하고 트랜잭션 실행 ("실행 비용")에 대한 비용을 지불합니다. |
| 컨센서스 참가자 | 직접적인 컨센서스 참가자는 블록 제안에 투표하고 리더로서 역할을 합니다. 직접 참가자가 되려면 노드는 최소한의 MinStake를 스테이크하고 가중치에 따라 상위 MaxConsensusNodes 참가자 중 하나여야 합니다. 이러한 매개변수는 코드에서 설정됩니다. |
| 트랜잭션 해싱 | 효율성을 위해 블록 제안은 트랜잭션을 오직 해시로만 참조합니다. 노드가 트랜잭션을 보유하지 않은 경우 이를 이웃에게서 해시를 통해 요청합니다. |
| 지연 실행 및 운송 비용 | Monad에서 컨센서스와 실행은 파이프라인 형식으로 발생합니다. 노드들은 해당 오더링을 실행하기 전에 공식적인 트랜잭션 오더에 대한 컨센서스에 도달합니다 (지연 실행); 실행의 결과는 컨센서스의 선행 조건이 아닙니다.
실행이 컨센서스의 전제 조건인 블록체인에서는 실행에 대한 시간 예산이 블록 시간의 작은 부분입니다. 컨센서스와 실행을 파이프라인화함으로써 Monad는 컨센서스와 실행 양쪽 모두의 풀 블록 시간을 확장할 수 있습니다.
블록 제안은 트랜잭션 해시의 오더된 목록과 D블록 전의 스테이트 머클 루트로 구성됩니다. 지연 매개변수 D는 코드에서 설정되며, 초기에는 D = 10으로 예상됩니다.
사용자는 트랜잭션을 블록에 포함시키기 위해 ("운송 비용") 지불해야 합니다. 각 주소에 대해 노드는 두 가지 잔고를 유지합니다:
• 준비금 잔고: 이 운송 비용을 지불하기 위해 사용됨 • 실행 잔고: 트랜잭션 실행 비용을 지불하기 위해 사용됨
운송 비용은 트랜잭션이 블록에 포함될 때 (컨센서스) 준비금 잔고에 청구됩니다; 이것은 실행 시 실행 잔고에서 차감됩니다 (이중 청구), 그리고 D블록의 지연 기간이 지난 후 준비금 잔고에 상환됩니다.
계정의 준비금 잔고는 사실상 "in-flight (인플라이트)" 오더에 대한 예산이며, 지불된 트랜잭션만이 블록에 포함되도록 보장합니다.
각 계정에는 미리 정의된 스마트 컨트랙트와 상호 작용하여 변경할 수 있는 타겟 준비금 잔고가 있습니다, 예시로 대량의 인플라이트 주문을 보낼 것으로 예상되는 EOAs의 경우 |
| 스테이트 디터미니즘 | 최종성은 컨센서스 시점에 발생합니다; 공식적인 트랜잭션 오더링은 이 시점에서 정립되며, 결과는 1초 미만에 새로운 블록에 대한 트랜잭션을 실행하는 모든 풀 노드에 대해 완전히 디터미니스틱입니다.
스테이트 머클루트에 대한 D-블록 지연은 주로 스테이트 루트 검증을 위한 것이며, 예를 들어 노드가 계산 오류를 발생시키지 않았는지 확인하는 데 사용됩니다. |
각 블록에 대한 실행 단계는 해당 블록에 대한 컨센서스에 도달한 후에 시작되며, 이를 통해 노드는 후속 블록에 대한 컨센서스를 진행할 수 있습니다.
트랜잭션은 선형으로 오더됩니다; 실행 작업은 해당 트랜잭션 목록을 연속적으로 실행한 결과 스테이트에 도달하는 것입니다. 단순한 방법은 트랜잭션을 하나씩 실행하는 것뿐입니다. 더 나은 방법은 가능할까요? 네, 가능합니다!