모나드 6개월 무엇이 바뀌었는가

Key Takeaways

• 모나드는 새로운 패러다임 제시가 아니라 극한의 엔지니어링으로 블록체인 트릴레마에 도전한다. EVM 인터페이스를 유지하며 합의, 실행, 네트워크 전파, 스토리지를 전부 다시 설계해 최적화하는 것이다. MONAD_NINE, MIP-3, MIP-4, MIP-5는 모나드가 자신의 실행 환경에 맞게 리소스 가격과 실행 규칙을 조정하는 고성능 EVM 변종을 만들고 있음을 보여준다.
• 고성능의 대가는 복잡성이다. 비동기 실행, 병렬 실행, 리저브 밸런스, RPC 상태 구분처럼 모나드만의 복잡성이 생긴다. 모나드는 이를 MIP, 툴링, RPC 스펙, 프리컴파일 등을 통해 개발자와 인프라가 감당 가능한 수준으로 추상화하려 한다. 즉 모나드의 성능은 실행, 메모리, 스토리지, 네트워크 전파까지 포함한 전체 시스템 엔지니어링의 결과다.
• 모나드의 다음 과제는 “빠른 EVM”이라는 정체성을 넘어서는 것이다. 앞으로 모나드의 과제는 단순히 빠른 체인이 아니라, 확장되는 블록체인 수요 환경에서 살아남을 수 있는 고유한 정체성을 확립하고 장기적인 비전을 제시하는 것이다.

0. 들어가며

보안, 확장성, 탈중앙성을 동시에 해결하기 어렵다는 블록체인 트릴레마는 오랜 기간 블록체인 네트워크들의 숙제였다. 블록체인에서 처리량을 높이기 위해서는 필연적으로 밸리데이터 수를 줄이거나 노드 요구사양을 높혀야 하고, 이는 탈중앙성의 감소로 이어지기 때문이다.

고성능, 탈중앙성, EVM 호환성을 동시에 추구하는 레이어 1 블록체인 모나드의 퍼블릭 메인넷은 2025년 11월 24일 런칭했다. 2026년 6월 현재 메인넷 런칭 이후 6개월이 지난 지금, 블록체인 트릴레마를 풀기 위해 등장한 모나드는 실제 운영 환경에서 얼마나 이를 달성했을까?

이 글은 토큰 가격이나 생태계 관점이 아니라, 프로토콜의 기술과 인프라 관점에서 모나드가 첫 6개월간 달성한 변화들을 정리하고 앞으로 모나드가 나아가야할 방향에 대해서 이야기한다.

1. 모나드의 핵심 가설

새로운 레이어 1 블록체인을 만드는 프로젝트는 크게 두 종류로 나눌 수 있다. 앱토스(Aptos)나 수이(Sui)처럼 이더리움과는 전혀 다른 실행 환경을 새로 설계하는 팀들이 있고, EVM 호환성을 최대한 유지하려는 팀들이 있다.

모나드는 후자에 해당한다. 모나드는 개발자와 사용자가 보는 인터페이스를 이더리움과 최대한 가깝게 유지하는 것을 목표로 한다. 주소 체계, 트랜잭션 포맷, 바이트코드 호환성, RPC 인터페이스 등을 EVM 생태계와 유사하게 유지하는 것이다. 개발자는 기존 솔리디티(Solidity) 코드와 EVM 툴링을 최대한 그대로 활용할 수 있고, 사용자는 익숙한 지갑과 애플리케이션 경험을 크게 바꾸지 않아도 된다.

대신 모나드는 체인의 성능을 결정하는 내부 파이프라인을 다시 설계한다. 모나드의 성능 개선 축은 다음 다섯 가지로 요약할 수 있다.

• MonadBFT: 파이프라이닝(pipelining) 기반의 빠른 BFT 합의
• RaptorCast: 이레이저 코딩(erasure coding)을 활용한 효율적인 블록 전파
• 비동기 실행(Asynchronous Execution): 합의와 실행을 분리해, 블록 생산이 실행 완료를 기다리지 않도록 함
• 낙관적 병렬 실행(Optimistic Parallel Execution)과 JIT 컴파일: 트랜잭션을 병렬로 처리하고, 자주 호출되는 컨트랙트를 네이티브 코드로 컴파일해 실행을 최적화
• MonadDB: 이더리움 상태(state)를 NVMe SSD에 효율적으로 저장하기 위한 전용 데이터베이스

즉, 모나드가 바꾸려는 것은 EVM이라는 인터페이스를 떠받치는 구현(implementation)인 것이다. 모나드의 핵심 가설은 개발자와 사용자가 보는 표면은 이더리움 그대로 두고, 노드 내부의 합의, 실행, 상태 접근, 블록 전파를 성능을 위해 처음부터 다시 만드는 것이다.

이 가설이 성공하려면 세 가지 조건이 동시에 충족되어야 한다. 첫째, 고성능을 추구하는 과정에서 탈중앙성이 과도하게 희생되지 않아야 한다. 둘째, 새롭게 설계한 합의와 실행 구조가 실제 운영 환경에서도 목표한 처리량과 낮은 지연 시간을 달성해야 한다. 셋째, EVM 호환성이 개발자 경험과 툴링 수준에서도 충분히 유지되어야 한다.

이 핵심 가설을 기준으로 메인넷 런칭 이후 6개월 동안 모나드에서 일어난 변화를 살펴보는 것이 이 글의 목적이다.

2. 제도화된 프로토콜 변경 절차: MIP

Source: Monad Research Forum

런칭 후 모나드에서 가장 먼저 도입된 제도적 장치는 MIP(Monad Improvement Proposal)다. MIP는 프로토콜 변경을 제안하고, 논의하고, 기록할 것인가에 대한 절차로 모나드 리서치 포럼 에서 논의가 이루어진다.

MIP-1은 MIP 프로세스를 정의하기 위한 메타(Meta) 제안이다. 이는 모나드 프로토콜, 생태계 표준, 거버넌스 프로세스의 변경을 제안하고 논의하기 위한 공식 프레임워크를 세우는 제안이며, 이더리움의 EIP-1을 모델로 하되 모나드 구조에 맞게 조정한 형태다. 2026년 상반기 동안 여러 제안이 이 절차를 거쳤는데, 그 중 일부는 이미 메인넷에 반영되었고(MIP-3, MIP-4, MIP-5), 일부는 여전히 논의 및 구현 단계에 있다(MIP-8, MIP-9 , MIP-10 등).

블록체인은 결국 코드로 이루어진 프로토콜이며, 이를 유지하고 개선하려면 민감한 설계 결정을 계속 내려야 한다. 특히 모나드처럼 고성능을 목표로 하는 L1에서는 작은 변경도 여러 계층에 영향을 미친다. 이런 결정과 논의가 MIP라는 공개된 형식으로 기록된다는 것은, 프로토콜 변경이 더 이상 개발팀 내부의 닫힌 의사결정에 머물지 않고 누구나 추적하고 검증할 수 있는 대상이 된다는 뜻이다. 노드 운영자들이나 생태계 빌더 입장에서 어떤 변경이 왜 들어오는지를 사전에 문서로 확인하고 대비할 수 있다는 점에서 실질적인 가치가 있다.

모나드는 카테고리 랩스(Category Labs)가 주도해 출발한 중앙 주도 체인이다. MIP와 같은 공개 제안 절차의 도입은 네트워크의 탈중앙화를 향한 구체적이고 검증 가능한 첫걸음이 된다. 물론 MIP 자체로 탈중앙화된 거버넌스를 의미하지는 않는다. 아직 실제 도입에 대한 무게중심은 창립 팀에 있으며, MIP는 그 출발점으로 봐야 한다.

3. MONAD_NINE: 첫 메이저 업그레이드

MONAD_NINE은 MIP를 통해 논의된 제안들이 실제 메인넷 업그레이드로 반영된 첫번째 사례다. 2026년 3월 19일 메인넷에 적용된 모나드 v0.13.0는 MONAD_NINE을 활성화하는 하드포크였으며, MIP-3(선형 메모리 비용 모델), MIP-4(리저브 밸런스 프리컴파일), MIP-5(오사카 포크 및 CLZ opcode 활성화)를 포함한다.

3.1 MIP-3: 메모리 비용을 더 예측 가능하게 만들기

MIP-3(Linear Memory)는 모나드 EVM의 메모리 확장 비용 계산을 기존의 이차 함수 기반 모델에서 선형 모델로 바꾸고, 각 트랜잭션이 사용할 수 있는 메모리의 최대 한도를 정하는 제안이다. 이더리움 EVM은 메모리를 많이 쓸수록 비용이 제곱으로 늘도록 설계되어 과도한 메모리 사용을 억제한다. 모나드는 이를 선형으로 바꿔 비용을 예측 가능하게 만들고, 8MB라는 명확한 상한으로 트랜잭션 하나가 차지할 수 있는 메모리를 명확히 한다. 이는 수많은 트랜잭션을 병렬로 실행하는 모나드의 입장에서 중요하다. 각 트랜잭션의 최악 메모리 사용량이 정해져 있어야 병렬 실행을 안정적으로 관리할 수 있기 때문이다.

이는 이더리움의 가스 비용 모델에서 의도적으로 벗어나는 지점이기도 하다. 같은 컨트랙트 코드라도 메모리를 많이 쓰는 연산의 경우 이더리움과 모나드에서 가스비가 크게 달라질 수 있는 것이다. 모나드는 EVM 호환성을 유지하지만, 리소스 가격과 같은 부분들까지 이더리움과 동일하게 유지하려는 것은 아니다. 오히려 모나드의 실행 구조에 맞게 경제적 설정값들을 재조정함으로써, EVM을 더 높은 처리량 환경에 맞게 다시 프라이싱하는 것이다.

3.2 MIP-4: 비동기 실행의 부작용을 컨트랙트에서 감지

MIP-4(Reserve Balance Introspection)는 컨트랙트가 실행 도중 리저브 밸런스(reserve balance) 규칙 위반 여부를 실시간으로 조회할 수 있는 새 옵코드(opcode)를 도입하기 위한 제안이다.

MIP-4 도입에 대한 맥락을 파악하기 위해서는 모나드의 비동기 실행 구조를 먼저 이해해야 한다. 모나드의 비동기 실행은 합의와 실행을 분리하는 구조다. 그리고 이더리움처럼 노드들이 트랜잭션을 먼저 실행해보고 합의하는 것이 아니라, 트랜잭션의 순서부터 합의하고 추후 실행한다. 이를 통해 실행이 더이상 합의의 병목이 아니게 되며, 실행에 사용할 수 있는 시간이 크게 늘어난다. 모나드의 비동기 실행 구조에 대해서는 4.1에서 보다 자세히 다룬다.

하지만 이 구조에는 새로운 문제가 생긴다. 노드들이 최신 실행 상태를 완전히 보지 못한 상태에서도 블록을 만들고 합의해야 하는 것이다. 이를 보완하기 위해 도입한 것이 리저브 밸런스 규칙이다. 쉽게 설명하자면, 리저브 밸런스는 각 외부 소유 계정이 일정 수준 이하로 잔고를 떨어뜨리지 않도록 제한함으로써, 합의가 최신 상태를 완전히 알지 못해도 “이 계정이 가스 비용을 낼 수 있다”는 판단을 할 수 있게 만드는 장치다.

MIP-4는 컨트랙트가 리저브 밸런스의 상태를 스마트 컨트랙트가 실행 중에 확인할 수 있게 만드는 것이다. 0x1001 주소에 새로운 프리컴파일(precompile)을 추가하고, dippedIntoReserve() 메서드를 통해 리저브 밸런스 위반 상태 여부를 반환하도록 한다. 이를 통해 컨트랙트는 실행 중간에 상태를 감지하고 잔고를 복구하거나, 다른 코드 경로를 선택하거나, 더 의미 있는 에러를 남기며 빠르게 리버트 할 수 있게 된다.

이는 이더리움에는 없는 모나드만의 고유 옵코드다. 이처럼 모나드는 EVM을 그대로 따라가기 보다는 자신의 아키텍처에 필요한 맞춤 명령어를 EVM에 추가하기도 한다.

3.3 MIP-5: 이더리움 업그레이드 반영

MIP-5(Fusaka EIP Activation)는 이더리움 푸사카(Fusaka) 하드포크 중 다음 실행 레이어 EIP 세 개를 모나드에 적용한다.

• EIP-7823(Set upper bounds for MODEXP): MODEXP 프리컴파일의 입력 크기에 상한을 둠(base/exponent/modulus 각각 8192비트).
• EIP-7883(ModExp Gas Cost Increase): MODEXP의 가스 비용을 실제 연산량에 맞게 인상.
• EIP-7939(CLZ opcode): 256비트 워드의 선행 0 비트를 세는 CLZ(Count Leading Zeros) 옵코드를 새롭게 추가.

푸사카 하드포크에서 이더리움에 추가된 EIP는 총 13개다. 하지만 모나드는 그 중 위의 세 가지만 가져온다. 이는 모나드의 합의(MonadBFT)나 데이터 전파(RaptorCast), 데이터 가용성은 이더리움과 전혀 다른 자체 설계이기 때문이다. EVM 바이트코드 호환성을 유지하기 위해 실행 레이어인 EVM에서 직접 영향을 주는 프리컴파일과 옵코드 변경만 따라가면 되는 것이다. 어쨌거나 모나드는 이더리움 호환을 유지하기 위해 EVM이 변경되면 모나드도 이를 추적해 어떤 변경점을 받아들일지 계속 판단하고 적용해야 한다.

3.4 모나드 EVM 호환의 방향성

MONAD_NINE에 도입된 세 가지 MIP를 보면 모나드의 방향성을 명확히 알 수 있다. 모나드가 이야기하는 EVM호환성은 단순히 EVM을 복사하는 것이 아니라는 점이다. 자체 엔진에 맞게끔 가스 비용 모델을 의도적으로 바꾸고(MIP-3), 자체 아키텍처에 필요하면 고유 옵코드를 더하며(MIP-4), 호환성 유지에 필요한 이더리움의 변경은 선별적으로 따라간다(MIP-5). 모나드는 이더리움 EVM을 그대로 가져다 쓰는 것이 아니라, 그것을 자신의 실행 환경에 맞게 변형한 변종(variant)을 운영하는 셈이다.

3.5 RPC 의미론의 변화

MONAD_NINE에서 개발자와 인프라 사업자들이 가장 직접적으로 체감할 수 있는 변화는 RPC 동작이다.

latest 블록 태그가 기존 Finalized 기준에서 Proposed 기준으로 바뀌었다. 이에 따라 eth_getBalance, eth_call 같은 상태 쿼리는 더 최신 블록 기준으로 응답할 수 있게 되었고, eth_sendRawTransactionSync도 Voted 기준에서 Proposed 기준으로 앞당겨졌다. 웹소켓의 newHeads와 logs 알림 역시 Finalized에서 Voted 기준으로 변경되었다.

이 변화는 레이턴시를 줄이는 데 유리하다. 하지만 개발자 입장에서는 최신 상태와 확정된 상태를 구분해야 한다는 복잡도가 더해진다. latest 가 확정(Finalized)이 아니라 제안(Proposed) 상태로 반환한다는 것은 낮은 지연 시간을 제공하지만, 아직 합의를 거치지 않은 잠정 실행 상태에 가깝다. 대신 모나드는 다른 블록 조건들을 위한 새로운 태그를 추가했다. safe는 투표가 완료된 상태에, finalized는 최종 확정된 상태에 대응한다. 따라서 체인 간 자산 이동, 입금 반영, 결제 정산처럼 실제 가치 정산이 필요한 경우에는 finalized 기준으로 상태를 조회하는 것이 권장된다. 즉, MONAD_NINE 이후 모나드에서 latest를 읽는다는 것은 되돌릴 수 없는 확정된 상태가 아니라 가장 빠른 상태를 읽는다는 의미다.

이 변화는 모나드의 성능 철학을 잘 보여준다. 빠른 UX를 원하는 프론트엔드는 latest를 통해 더 시의성 있는 상태를 구현할 수 있다. 하지만 인덱서, 브릿지, 결제 시스템, 오프체인 회계 시스템은 latest, safe, finalized 사이의 차이를 명확히 이해해야 한다. 고성능 체인에서는 단순히 블록이 빨라지는 것만이 아니라, 블록 상태를 해석하는 방식도 더 세분화된다.

4. 비동기/병렬 실행의 현실: EVM 호환성의 숨은 비용

MIP-3와 MIP-4는 사실 모나드 실행 엔진의 두 기둥인 비동기 실행과 낙관적 병렬 실행에서 파생된 것이다. 이는 모나드가 고성능 EVM을 가능하게 만드는 핵심이지만, 동시에 EVM호환성을 위한 가장 큰 걸림돌이기도 하다. 이 장에서는 그 두 기둥이 실제로 어떻게 동작하며, "이더리움처럼 보이는 인터페이스"를 유지하기 위해 어떤 비용을 치르는지 본다.

4.1 비동기 실행: 합의가 실행을 기다리지 않는다

이더리움에서는 블록을 제안하기 전에 그 안의 모든 트랜잭션을 실행해 상태 루트(state root)를 계산해야 한다. 하지만 모나드의 경우 400~500ms짜리 짧은 블록 시간 안에서 실행에 쓸 수 있는 시간이 부족하다. 때문에 모나드는 3.2에서 언급한 것처럼 합의와 실행을 분리한다. 리더는 트랜잭션의 순서만 정해 블록을 제안하고, 그 뒤에 지연된 상태에서 실행한다. 즉, 트랜잭션의 순서만 먼저 합의를 하고 그 결과 상태가 무엇인지는 나중에 확정하는 것이다. 이는 모나드 성능의 핵심이다. 합의가 실행 완료를 기다리지 않아도 되면, 블록 타임을 더 빠르게 가져갈 수 있다. 때문에 모나드의 블록에는 현재 상태 루트가 들어가지 않는다. 대신 D블록 전(현재 D=3)의 지연된 상태 루트가 들어간다. 프로토콜 관점에서 실행은 합의보다 항상 3블록 뒤처지는 것이다.

그러나 이 구조에는 대가가 있다. 합의가 최신 실행 상태를 완전히 모르는 상태에서 블록을 만들어야 한다는 점이다. 바로 여기서 EVM 호환성의 숨은 비용이 발생한다. 겉으로는 같은 트랜잭션과 같은 컨트랙트를 실행하는 것처럼 보이지만, 내부에서는 합의와 실행 사이에 시간차가 존재한다. 이 시간차를 안전하게 다루기 위해 모나드는 가스 과금, 리저브 밸런스, RPC 상태 모델과 같은 것들을 별도로 설계해야 한다. 또한 같은 트랜잭션이 이더리움에서는 정상 처리되지만 모나드에서는 리저브 밸런스 규칙에 따라 되돌려질 수도 있으며, 라이트 클라이언트나 일부 브리지 시스템들은 모나드의 블록이 현재가 아닌 3블록 전의 루트를 가지고 있다는 점을 고려해서 설계해야 한다.

4.2 병렬 실행

모나드는 한 블록 안의 트랜잭션을 낙관적으로(optimistically) 병렬 실행한다. 서로 충돌하지 않는다고 가정하고 우선 동시에 실행한 뒤, 각 트랜잭션의 읽기 및 쓰기 집합을 추적해 두 트랜잭션이 같은 상태를 건드리는 등의 충돌이 발견되면 해당 트랜잭션만 올바른 데이터로 다시 실행하는 것이다. 최종 상태는 이더리움의 순차 실행 결과와 동일하므로, 실제 보이는 결과값 자체는 달라지지 않는다.

병렬 실행의 이점은 트랜잭션들이 서로 독립적일 때 가장 크다. 반대로 많은 트랜잭션이 같은 상태를 동시에 건드리는 경합(contention) 상황에서는 문제가 된다. 예를 들어 수요가 몰린 AMM 풀, 밈코인 민팅, NFT 드롭처럼 모두가 한 지점에 몰리는 순간에는 충돌과 재실행이 늘어나는 것이다. 문제는 크립토 온체인 수요가 그런 형태로 몰리는 경향이 크다는 것이다. 처리량이 가장 절실한 피크 시점이 오히려 병렬 실행이 가장 불리한 순간이 될 수도 있다. 때문에 모나드의 확장성에 대해 흔히 인용되는 10,000TPS라는 수치는 조건부로 봐야 한다. 이는 트랜잭션이 충분히 병렬화 가능한 이상적 조건에서의 수치이지 실측치는 아니다.

4.3 가스는 사용량이 아니라 한도 기준으로 청구된다

이더리움과 모나드의 차이가 가장 분명하게 드러나는 곳은 가스 과금에 관한 부분이다. 이더리움에 익숙한 개발자라면 보통 “실제로 사용한 가스”를 기준으로 비용이 청구된다고 생각한다. 하지만 모나드에서는 트랜잭션이 실제로 사용한 가스가 아니라, 트랜잭션에 설정된 가스 한도를 기준으로 비용이 청구된다. 이는 모나드의 비동기 실행 때문에 발생한 변경이다.

앞서 설명한 모나드의 비동기 실행의 과정을 생각하면 이유는 명확해진다. 비동기 실행에서는 리더와 검증자가 트랜잭션을 실행하기 전에 블록을 만들고 투표한다. 만약 트랜잭션에서 실제 사용한 가스만 청구한다면, 합의 단계에서는 매우 큰 가스 한도를 가진 트랜잭션을 제출해 블록 가스 한도 공간을 크게 차지하면서도, 실제 실행에서는 적은 가스만 사용해 낮은 비용만 지불할 수 있다. 이는 블록 공간을 실제보다 매우 싼 값에 점유할 수 있는 공격 벡터가 된다. 악용하면 DoS(Denial of Service)공격이 가능한 것이다. 모나드는 이를 막기 위해 실제 트랜잭션이 사용한 가스가 아니라, 제출한 가스 한도에 따른 과금을 선택한다.

이는 개발자와 사용자 경험에 직접 영향을 준다. 모나드에서는 가스 한도를 지나치게 크게 잡는 것이 비용 측면에서 불리하다. 따라서 지갑, 프론트엔드, 백엔드, 번들러는 가스 한도 설정을 더 신중하게 다뤄야 한다.

4.4 EVM 호환성은 공짜가 아니다

모나드는 EVM 호환성을 갖추기 위해 컨트랙트와 툴링의 표면적인 부분은 최대한 EVM에 가깝게 유지하기 위해 노력한다. 하지만 성능을 위해 내부 실행 구조를 바꿨고, 그 과정에서 발생하는 문제를 해결하기 위해 발생한 차이들이 존재한다. 이 차이들이 EVM 호환성의 숨은 비용이다. 애플리케이션이 더 복잡해질수록, 특히 브릿지, 결제, 파생상품, 고빈도 거래, 계정 추상화, 인덱싱 인프라처럼 상태의 프래시함과 확정성이 중요한 영역으로 갈수록 모나드의 내부 구조를 이해하고 신경쓸 것이 많아진다.

모나드는 이러한 상황에서 고성능 실행 구조가 만들어내는 어쩔 수 없는 복잡성을 개발자와 인프라가 감당 가능한 수준으로 추상화할 필요가 있다. 이 맥락에서 지난 지난 6개월간의 업데이트를 다시 보면, MIP-3는 리소스 가격을 다시 조정했고, MIP-4는 비동기 실행의 예외를 컨트랙트가 감지할 수 있게 했으며, RPC 스팩은 블록 상태와 잠정 데이터를 더 명시적으로 구분하기 시작했다는 점에서 의미가 있다.

5. MIP-8: 상태 접근을 실제 하드웨어 단위로

Source: mipland

MIP-8(Page-ified Storage State)은 아직 메인넷에 반영된 업그레이드는 아니며, 현재 MIP로 논의되고 있는 제안이다. 초기 모나드는 빠른 합의, 병렬 실행, 비동기 실행에 집중되어 있었다. 하지만 실제 운영 환경에서 고성능 체인은 합의와 실행 엔진만 최적화한다고 완성되지 않는다. 트랜잭션은 결국 컨트랙트의 상태를 읽고 쓰며, 그 상태는 노드의 스토리지 계층에 저장된다. 따라서 체인의 처리량이 높아질수록 상태를 얼마나 빠르게 읽고 쓸 수 있는가가 중요한 병목으로 떠오른다.

EVM의 추상화와 실제 하드웨어 사이의 간극에서 MIP-8은 힌트를 얻었다. 스마트 컨트랙트 입장에서 스토리지는 32바이트 슬롯(slot)의 긴 목록처럼 보인다. 하지만 실제 하드웨어와 데이터베이스 계층에서는 훨씬 큰 단위로 데이터가 읽히고 쓰인다. SSD는 4KB 페이지(page) 단위로 읽고 쓰며, 페이지 하나에는 32바이트 슬롯 128개 분량의 데이터가 들어간다. 모나드 노드가 메모리에 없는 슬롯 하나를 읽으면, 그 노드의 실제 디스크는 어차피 그 슬롯이 속한 4KB 페이지 전체를 끌어온다. 즉 슬롯 하나를 읽는 순간 인접한 127개 슬롯도 사실상 함께 읽히는 셈이다.

문제는 기존 EVM의 스토리지 모델이 이를 반영하지 못한다는 점이다. EVM은 슬롯 단위로 상태를 다루고, 이더리움의 머클 트라이(Merkle trie) 구조는 슬롯 키를 해싱해 저장한다. 이 방식은 트리를 균형 있게 유지하는 데는 도움이 되지만, 논리적으로 가까운 데이터가 실제 디스크에서는 서로 다른 위치에 흩어지는 결과를 만든다. 결국 같은 컨트랙트 안에서 연속된 슬롯을 읽더라도, 실제로는 서로 다른 페이지를 반복해서 읽는 비효율이 발생할 수 있다.

이 문제를 해결하기 위해 카테고리 랩스는 MIP-8를 제안했다. 실제 하드웨어가 사용하는 단위인 4KB 페이지를 EVM 상태 접근의 일급 개념으로 끌어올리는 것이다. 프로토콜은 연속된 128개 슬롯마다 하나의 페이지로 묶고, 이 페이지를 가스 스케줄과 스토리지 레이아웃 양쪽에서 모두 인식한다. 머클 트라이도 개별 슬롯이 아니라 페이지 단위로 커밋하도록 재편된다.

가스 측면에서는 어떤 페이지에 처음 접근할 때만 높은 콜드(cold) 접근 비용을 지불하고, 같은 트랜잭션 안에서 그 페이지의 다른 슬롯에 접근할 때는 낮은 웜(warm) 접근 비용을 적용한다. 즉 한 번 디스크에서 가져온 페이지 안의 데이터에 대해서는, 프로토콜도 “이미 메모리에 올라온 데이터”라는 사실을 반영해 더 낮은 비용을 부과하는 것이다. 결과적으로 배열, 구조체, 패킹된 상태 변수처럼 연속된 슬롯을 활용하는 패턴은 자연스럽게 더 저렴해질 수 있다.

MIP-8이 적용되더라도 EVM의 32바이트 슬롯 모델은 그대로 유지기 때문에 모나드의 개발자는 여전히 솔리디티를 쓰고, 기존 컨트랙트도 기능적으로 유지된다. EVM의 인터페이스는 유지하면서 상태 접근을 위한 대부 단위를 실제 하드웨어에 더 가깝게 맞추는 것이다. 달라지는 것은 그 아래에서 상태를 저장하고 가격을 매기는 방식이다. 즉 EVM의 인터페이스는 유지하면서, 상태 접근의 내부 단위를 실제 하드웨어에 더 가깝게 맞추는 것이다.

모나드 앱을 개발하는 개발자 입장에서 컨트랙트를 최적화 하는 것은 단순히 스토리지 접근 횟수를 줄이는 것에서, 서로 함께 읽히는 상태를 같은 페이지 안에 얼마나 잘 배치가로 확장된다. 이는 EVM 개발자에게 익숙한 스토리지 최적화 문제를, 하드웨어의 데이터 접근 단위와 연결해 다시 생각하게 만든다. 단순 호환성을 위해서 이더리움 컨트랙트 코드를 다시 짤 필요는 없지만, 성능과 비용 최적화를 위해서는 코드 수정이 필요할 수 있다.

이처럼 모나드가 "탈중앙성 희생 없는 성능"을 추구하는 방식은, ZK나 새로운 VM, 샤딩과 같은 새로운 패러다임을 들고 오는 것이 아니라 블록체인을 고성능 시스템 엔지니어링 문제로 다루는 데 가깝다. 합의/실행 파이프라이닝부터 디스크 페이지 단위의 가스 모델까지, CPU와 분산 시스템 공학의 기법을 하드웨어 현실에 맞춰 끝까지 밀어붙이는 것이다.

6. RaptorCast와 네트워크 레이어

6.1 RaptorCast

블록체인은 P2P(Peer-to-Peer)네트워크다. 합의와 실행을 아무리 최적화해도 블록이 네트워크를 타고 모든 노드에 도달하는 속도가 느리면 의미가 없다. 모나드의 블록 타임은 400ms다. 이 짧은 시간의 대부분이 전 세계에 흩어져 있는 밸리데이터들 사이의 통신에 쓰인다. 모나드처럼 짧은 블록 시간을 목표로 하는 체인에서는 블록 전파 자체가 합의의 핵심 병목이 되는 것이다. 이더리움에서는 합의 레이어의 메시징 인프라로 libp2p(GossipSub)를 사용한다. 하지만 모나드는 블록타임 뿐 아니라 합의 구조부터 이더리움과 큰 차이가 있다. 때문에 모나드는 RaptorCast라는 자체 설계한 블록 전파 프로토콜을 사용한다.

RaptorCast는 MonadBFT 안에서 리더가 블록 제안을 검증자들에게 전파하기 위해 사용하는 전용 멀티캐스트 프로토콜이다. 리더는 블록 제안을 이레이저 코딩(erasure coding)을 통해 여러 조각으로 나누고, 각 조각은 두 단계의 브로드캐스트 트리를 통해 검증자들에게 전달된다. 리더가 아닌 밸리데이터들은 특정 조각 묶음의 1단계 전달자 역할을 맡으며, 조각 배정 비율은 각 밸리데이터의 스테이킹 지분에 따라 결정된다. 모든 청크가 정확히 두 홉 만에 네트워크 전체에 도달하므로, 전파 시간은 네트워크에서 가장 멀리 떨어진 두 노드 사이의 왕복 시간(RTT) 하나로 수렴한다.

블록 전파를 위해 네트워크 전체의 업로드 대역폭을 동시에 동원하므로, 밸리데이터 한 명이 부담하는 대역폭은 전체 밸리데이터 수와 무관하게 블록 크기의 약 3배 수준으로 고정된다. 즉, 밸리데이터가 100명이든 500명이든 개별 노드에 요구되는 회선이 늘어나지 않는다. 모나드가 "일반 회선(commodity uplink) 위의 대규모 분산 밸리데이터 집합"을 고성능/고처리량과 양립시킬 수 있다고 주장하는 근거가 여기에 있다.

또한 RaptorCast는 TCP가 아니라 UDP 위에서 동작한다. TCP의 재전송과 head-of-line blocking은 곧 지연으로 이어지기 때문에, 패킷 손실을 비정상이 아니라 정상 조건으로 받아들이고 각 노드 운영자가 설정 가능한 이레저 코딩의 중복도로 흡수하는 쪽을 택했다. 대신 모든 패킷에 리더의 서명과 증명을 실어, 손실은 허용하되 위변조는 차단한다. 한 가지 덧붙이면, 1단계 릴레이는 받은 청크를 재인코딩하지 않고 그대로 포워딩만 한다.

RaptorCast가 밸리데이터 사이의 블록 전파에만 사용되는 것은 아니다. 리더가 활성 밸리데이터 집합에 블록 제안을 전달하는 것이 1차(Primary) RaptorCast고, 각 밸리데이터들이 하위 풀노드들에게 블록을 전파하는 2차(Secondary) RaptorCast도 존재한다. 2차 RaptorCast는 원리는 비슷하지만, 스테이킹 지분과 상관 없이 모든 참여 노드를 동일한 가중치로 취급한다. 권장 설정에서는 각 밸리데이터가 150개 풀노드 규모의 2차 RaptorCast 그룹을 가질 수 있고, 200개 검증자 기준으로 최대 30,000개 풀노드 수용 능력을 만들 수 있다. 중복 계수를 감안해 네트워크 전체적으로 약 15,000개 풀노드 규모를 지원할 수 있는 구조다. 고성능 블록체인에서 네트워크 코어의 성능도 중요하지만, 사용자와 맞닿아 있는 풀노드가 얼마나 안정적으로 블록을 받고 체인의 최신 상태를 따라갈 수 있는지도 중요하다. 2차 RaptorCast는 고성능 블록체인 모나드에서 풀노드 참여를 안정적으로 유지하기 위한 네트워크 설계다.

의도한 바인지는 확인할 수 없지만, RaptorCast는 구조 자체로 네트워크의 지역적 편중에 따른 문제를 완화시킨다. 이더리움의 GossipSub는 메시(mesh) 기반 다중 홉 전파다. 메시지가 피어에서 피어로 여러 홉을 거치며 퍼지기 때문에 전파 지연이 홉마다 누적되고, 그 홉 수와 메시 내 위치는 결국 노드의 지리와 연결성에 좌우된다. 게다가 피어 스코어링(peer scoring)은 이 편향을 강화해, 메시지 진원에서 먼 지역의 노드를 체계적으로 불리하게 만든다. 하지만 모나드의 RaptorCast는 홉 수를 2로 고정함으로써 이를 비껴간다. 아시아의 노드든 아프리카의 노드든, 홉이 누적되어 뒤처지는 일은 없어진다. 물론 이것이 모나드가 기술적으로 이더리움보다 우월하다는 것을 뜻하지는 않는다. 합의 알고리즘의 구조적 근거가 다르기 때문에 가능한 것이다. 이더리움의 GossipSub가 서로에 대해 전혀 알지 못하는 피어들 사이에서의 통신을 가정하는 반면, MonadBFT는 모든 밸리데이터의 지분 가중치까지 알려진 고정된 밸리데이터 집합 위에서 돌아간다. 때문에 모나드는 누가 어떤 청크를 중계할지를 프로토콜 차원에서 미리 구조화할 수 있다.

하지만 RaptorCast가 피어의 지역적 탈중앙성에 대한 문제를 완전히 해결했다고 볼 수는 없다. 모나드 네트워크의 전파 시간이 가장 먼 두 노드 사이의 RTT로 수렴한다는 말은, 지역적으로 멀리 떨어진 노드의 정도가 블록타임의 바닥을 결정한다는 뜻이다. 즉, 밸리데이터 집합이 지리적으로 넓게 퍼질수록 최악의 RTT가 커지고, 400ms 블록타임의 예산이 빡빡해진다. 모나드 밸리데이터 집합의 수를 확대하고, 진정한 의미의 비허가형(permissionless)으로 나아갈수록 이는 문제 요소가 될 수 있다.

6.2 MIP-10

메인넷 런칭 이후에 RaptorCast를 개선하기 위한 제안은 MIP-10(Deterministic RaptorCast)다. MIP-10은 RaptorCast의 인코딩 방식을 공개적으로 계산 가능한 시드에 고정하는 제안이다. 이렇게 하면 검증자가 블록 전체를 복원하기 전에도, 검증된 조각 하나를 받은 시점에 머클 루트에 대해 투표할 수 있게 된다. 목표는 전체 블록의 복원(decoding)을 합의의 핵심 경로에서 들어내는 것이다. 이렇게 되면 다음 리더는 이전 블록의 조각들이 아직 전파되는 동안 투표를 모아 QC(Quorum Certificate)를 만들고 다음 블록 생산을 시작할 수 있어, 블록 타임이 더 이상 전체 블록 전파 시간에 묶이지 않게 된다.

MIP-10을 조금 더 풀어서 설명해보자. 기존 방식에서는 리더가 이레이저 코딩의 시드를 자유롭게 고를 수 있고, 인코딩에 대한 커밋도 32패킷 배치마다 머클 루트(Merkle root) 하나씩 쪼개져 있다. 이 자유도는 성능상 유연성을 주지만, 악의적인 리더가 특정 검증자에게 복원에 불리한 조각만 보내거나, 하나의 머클 루트가 여러 다른 페이로드와 연결될 수 있는 모호성을 만들 여지를 남긴다. MIP-10은 인코딩 시드를 결정론적으로 만들고, 각 라운드에서 처음 본 유효한 머클 루트와 리더 서명 쌍을 기록하게 함으로써 이런 공격면을 줄이기 위한 보안 강화책이다.

P2P 통신을 위한 네트워크 레이어는 블록체인의 성능과 탈중앙성 모두에 큰 영향을 주는 매우 중요한 영역이다. 모나드는 RaptorCast를 통해 블록 전파를 단순한 gossip 방식에 맡기지 않고, MonadBFT의 구조에 맞춰 프로토콜 차원에서 재설계했다. 하지만 RaptorCast가 모든 문제를 해결하는 것은 아니다. 밸리데이터 집합이 더 커지고, 더 다양한 지역으로 분산될수록 400ms 블록 타임을 유지하기 위한 제약은 커진다. 모나드의 진화에 맞춰 네트워크 레이어도 꾸준히 변화해야 한다는 뜻이다.

7. 탈중앙화를 위한 방향성

지금까지는 모나드가 메인넷 런칭 이후 6개월 동안 고성능 블록체인과 EVM 호환성이라는 기술적 가정을 실제 운영 환경에서 어떻게 다듬어 왔는지를 살펴봤다. 하지만 모나드는 단순히 고성능만 추구하는 블록체인이 아니다. 모나드가 처음부터 내세운 정체성은 고성능, EVM 호환성, 그리고 탈중앙성의 동시 달성이다.

고성능 체인에서 탈중앙성은 특히 더 까다로운 문제다. 블록 타임이 짧아질수록 노드의 네트워크 품질, 하드웨어 성능, 운영 안정성에 대한 요구가 높아지고, 이는 자연스럽게 참여 가능한 밸리데이터의 범위를 좁힌다. 다시 말해 성능 최적화는 기술적으로 처리량을 높이지만, 운영 측면에서 탈중앙성에 압력을 줄 수 있는 것이다. 이번 장에서는 모나드 메인넷 런칭 이후 탈중앙성에 대한 현실과 모나드가 이 과제를 어떻게 다루고 있는지에 대해 살펴본다.

7.1 모나드 탈중앙성의 현재

모나드는 위임 지분증명(DPoS, Delegated Proof of Stake) 체인이다. 밸리데이터로 등록하는 것 자체는 비허가형이다. 하지만 실제 합의에 참여하기 위해서는 조건을 만족해 활성 밸리데이터 집합(active validator set)에 포함되어야 한다.

활성 밸리데이터가 되기 위해서는 세 가지 조건이 필요하다. 첫째, 밸리데이터의 인증 주소가 최소 100K MON을 자체 위임해야 한다. 둘째, 해당 밸리데이터가 받은 전체 위임량이 최소 10M MON 이상이어야 한다. 셋째, 지분 가중치 기준으로 상위 ACTIVE_VALSET_SIZE 안에 들어야 한다. 현재 기준 ACTIVE_VALSET_SIZE는 200이다. 조건을 충족하지 못한 밸리데이터는 다음 에포크에 활성 집합에서 제외된다. 즉 문은 누구에게나 열려 있지만, 문턱을 넘는 것은 자본이 결정한다.

Source: Monadvision

모나드 밸리데이터들에게 위임된 자본은 어디에서 왔을까? 이 출처를 보면 모나드의 탈중앙화에 대한 논의가 조금 더 복잡해진다. 모나드 재단은 VDP(Validator Delegation Program)를 통해 재단 보유 물량을 밸리데이터들에게 위임해 왔다. 1차 웨이브에서 재단은 약 93억 MON, 총공급의 약 9.3%가 170개 밸리데이터에 위임했다. 또한 선정된 밸리데이터들에게 최소 자체 스테이킹 요건은 100K MON을 일회성 그랜트로 제공했다. 이는 재단의 선택이 활성 밸리데이터 셋 결정에 큰 영향을 미치는 구조다. 2026년 말 VDP 2차 웨이브에서 재단은 재단 위임 물량을 25% 줄이며 재단 의존도를 단계적으로 낮추는 방향성을 보여줬지만, 여전히 모나드 밸리데이터의 진입 여부는 재단 위임량에 크게 달려있다.

이는 위임 지분증명 체인의 전통적인 딜레마다. 지분이 곧 합의 권한이고, 합의 권한이 곧 체인의 보안을 결정하는 구조에서는 런칭 초기부터 충분히 신뢰할 수 있는 밸리데이터 집합과 충분한 위임량이 필요하다. 때문에 대부분의 재단은 이를 위해 재단 소유의 코인을 미리 발행하고 안정적인 밸리데이터들에게 위임한다. 이는 런칭 초창기 체인의 보안과 안정성을 높히기 위한 가장 실용적인 방법이지만, 네트워크 참여자의 선정 권한을 재단에 집중시킨다.

대부분의 블록체인들이 시간이 흘러 재단의 지분이 희석되고, 기술의 발전에 따라 동일한 성능을 내기 위한 활성 밸리데이터 수를 점진적으로 늘리며 진입 장벽을 낮추는 것으로 이 문제가 자연스럽게 해결될 것을 기대한다. 하지만 이는 시스템적 약속이 아니라 희망적인 기대일 뿐이다. 무엇보다 활성 밸리데이터 수가 지금보다 크게 늘어나더라도 성능 수준을 유지해야 한다. 즉, 모나드의 런칭 초기 탈중앙화는 두 방향의 긴장 사이에 놓여있다. 초기 네트워크를 기대 성능으로 안정적으로 운영하는 것과 재단 의존도를 줄이고 더 많은 외부 위임과 밸리데이터를 받아들이는 방향이다.

7.2 MIP-9와 활성 밸리데이터 수 증가

이 긴장 위에서 6개월간의 안정적 런칭을 마치고 탈중앙성의 방향으로 힘을 당기는 첫번째 제안이 MIP-9(Active Set Increase)다. MIP-9는 기존의 활성 밸리데이터 수 ACTIVE_VALSET_SIZE 를 200에서 300으로 늘리자는 제안으로, 현재 초안(Draft) 상태다. 활성 밸리데이터 수를 늘리는 것은 실행 데몬에는 직접적인 영향을 주지 않지만, 합의 레이어인 MonadBFT에는 영향을 준다. 활성 밸리데이터 집합의 크기가 각 합의 라운드에 참여하는 노드 수를 직접 결정하기 때문이다. MIP-9 제안서에 따르면 밸리데이터 수를 100개 증가시키는 것은 현 수준의 50%에 해당하는 의미 있는 확장이지만, MonadBFT의 투표 라운드 메시지 복잡도를 극적으로 바꾸지는 않는 수준이다.

MIP-9가 메인넷에 적용되어 활성 밸리데이터가 200개에서 300개로 늘어났다고 해서 탈중앙성이 극적으로 증가되었다는 것을 의미하지는 않는다. 네트워크에 참여하기 위한 문턱은 더 낮아져야 하며, 재단 위임에 대한 영향도 더 줄어들어야 한다. 모나드가 범용 블록체인을 지향하고, 블록체인 트릴레마를 풀었다는 것을 주장한다면 이는 타협의 여지가 없다. 즉, MIP-9는 모나드의 지향점이 단순히 성능에만 있지 않다는 방향성을 보여주는 것이지, 모나드 탈중앙화의 도착점은 아니다.

7.3 자동화된 슬래싱의 부재

모나드에는 자동화된 슬래싱(slashing)이 존재하지 않는다. 슬래싱은 지분증명 블록체인에서 공격 비용을 방어 비용보다 비싸게 만드는 가장 강력한 보안 수단이다. 이중 서명이나 합의 규칙 위반 같은 행위에 대해 프로토콜이 자동으로 해당 밸리데이터의 지분을 슬래싱 해야 악의적 행동의 기대 비용이 기대 이익을 넘어서는 것이다.

모나드는 밸리데이터들의 악의적인 행위를 로깅(logging)으로 추적해 책임 소재는 남기되, 자동화된 인프로토콜 슬래싱은 현재 구현되어 있지 않다. 적발은 가능하지만 경제적 처벌의 집행은 프로토콜의 외부인 사회적 레이어에 맡겨져 있는 것이다. 슬래싱의 도입 여부와 시점은 모나드 체인의 보안이 부트스트랩 단계에서 자립적 보안으로 넘어가는지를 가늠할 수 있는 지점이다.

8. 마치며: 앞으로의 모나드

지금까지 살펴본 것처럼, 모나드가 마주한 문제를 해결하는 방식은 시스템의 병목을 하나씩 끝까지 밀어붙여 해결하는 것이다. EVM을 실행하는 물리적 기반을 다시 짜고, 합의가 실행을 기다리지 않게 만들고, 검증을 더 빠르게 만들기 위해 메모리와 스토리지, 네트워크까지 조정한다. 모나드가 탈중앙성과 고성능의 트레이드오프를 푸는 방식은 철저한 시스템 엔지니어링인 것이다.

이는 모나드 팀의 뛰어난 엔지니어링 역량을 보여주는 지점이다. 하지만 동시에 한계와 리스크이기도 하다. 모나드는 여전히 기존 블록체인의 기본 문법 위에 있다. 모나드는 근본적으로 “재실행을 통한 검증”이라는 기존 구조를 벗어나지는 않는다. 언젠가 전혀 다른 패러다임으로 같은 문제를 더 단순하게 해결하는 프로젝트가 등장할 가능성도 있다. 그 경우 모나드가 어렵게 최적화하고 해결해 낸 성능 병목이 다른 방식으로 대체될 수도 있다.

EVM 호환성 역시 양날의 검이다. EVM 호환성은 모나드의 가장 강력한 장점이다. 개발자는 기존 솔리디티 코드와 툴링을 활용할 수 있고, 사용자는 익숙한 지갑과 애플리케이션 경험을 유지할 수 있다. 생태계 입장에서는 진입 장벽이 낮고, 이더리움 및 EVM 생태계의 유동성과 개발자 경험을 흡수하기 쉽다. 하지만 같은 이유로 이탈도 쉽다. 빌더들이 모나드로 쉽게 넘어올 수 있다는 것은, 반대로 모나드가 충분한 성능, 유동성, 사용자, 수익 기회를 제공하지 못할 경우 다른 EVM 체인으로 쉽게 떠날 수 있다는 뜻이기도 하다. EVM 호환 체인은 그 위에 왜 계속 남아 있어야 하는가에 대한 이유를 만들어야 한다. 단순히 더 빠른 EVM에 머물러서는 안 된다는 뜻이다.

모나드는 지난 6개월간 어느 정도의 탈중앙성을 갖춘 고성능 EVM의 가능성을 보여주는 것에 성공했다. 하지만 빠르다는 것만으로 블록체인이 선택받는 시대는 끝났다. 블록체인의 사용자는 사이퍼펑크적 이상을 주장하던 얼리 어답터에서 더 넓은 사용자와 기관으로 확장되고 있고, 그에 따라 네트워크에 요구되는 것도 달라지고 있다. 사용자의 확장에 따라 수요도 변하고 있는 것이다.

이러한 흐름에 따라 모나드는 해결하려는 문제를 재정의해야 한다. 출발점은 이미 마련되어 있다. 2장에서 살펴본 것처럼 모나드는 런칭 이후 MIP라는 프로세스를 갖췄고, 지난 6개월간의 주요 개선은 대부분 이 프로세스 위에서 이루어졌다. 프로토콜을 바꾸는 논의가 공개적으로 절차화되고 기록된다는 것은, 모나드가 더 이상 닫힌 팀 내부에서만 설계되는 프로젝트가 아니라는 의미다. 하지만 현재의 MIP는 여전히 대부분 핵심 개발팀과 재단이 제안하고 주도한다.

앞으로 모나드는 단순히 엔지니어링적 병목 해결을 넘어 장기적으로 어떤 네트워크가 되려는지에 대한 구체적인 비전을 제시해야 한다. 그리고 이 비전에 공감하는 다양한 생태계 참여자들이 각자의 위치에서 발견한 문제를 MIP를 통해 제기할 수 있어야 한다. MIP에 참여하는 주체가 재단과 핵심 팀을 넘어 생태계 전반으로 확대되어야 하는 것이다.

이제 모나드에게 필요한 것은 시스템 엔지니어링을 통한 기술적 병목 해결을 넘어선 새로운 문제 정의와 패러다임의 전환이다. 첫 6개월이 모나드가 무엇을 할 수 있는지를 보여준 시간이었다면, 앞으로는 모나드가 장기적으로 무엇이 되려 하는지를 제시할 시간이다.