모나드와 모나드의 에코 프로젝트에 대해 한눈에 알아보기

기사 출처: ASXN, Golden Finance xiaozou 편집

1. 서문

Monad는 10,000 TPS(초당 10억 가스), 500ms 블록아웃 주파수, 1초 완결성을 갖춘 고성능 최적화 EVM 호환 L1입니다. 이 체인은 처음부터 EVM이 직면한 몇 가지 문제, 특히 다음과 같은 문제를 해결하기 위해 구축되었습니다.

*EVM은 트랜잭션을 순차적으로 처리하므로 네트워크 활동이 많은 기간에는 병목 현상이 발생하여 특히 네트워크 혼잡 시 트랜잭션 시간이 길어집니다.

* 12~15TPS의 낮은 처리량과 12초의 긴 블록 아웃 시간.

*EVM에는 트랜잭션당 가스 요금이 필요하며, 특히 네트워크 수요가 많을 때 변동이 심하고 비용이 매우 높아질 수 있습니다.

2. EVM을 확장해야 하는 이유

Monad는 완전한 EVM 바이트코드 및 이더넷 RPC API 호환성을 제공하므로 개발자와 사용자가 기존 워크플로를 변경하지 않고 통합할 수 있습니다. 통합을 위해 기존 워크플로를 변경할 필요가 없습니다.

일반적인 질문은 대부분의 EVM 구현보다 빠른 차단 시간, 낮은 수수료, 높은 처리량을 제공하는 SVM과 같은 더 나은 성능의 대안이 있는데 왜 EVM을 확장해야 하는지에 대한 것입니다. 그러나 EVM에는 두 가지 주요 요인, 즉 EVM 생태계의 막대한 자본과 광범위한 개발자 리소스에서 비롯된 몇 가지 주요 이점이 있습니다.

(1) 자본 기반

EVM은 이더의 TVL이 520억 달러에 육박하고 솔라나는 70억 달러로 상당한 자본을 보유하고 있습니다.L2 다음과 같은 업체들이 있습니다. Arbitrum과 Base는 각각 약 25억~30억 달러의 TVL을 보유하고 있으며, 모나드 및 기타 EVM 호환 체인은 마찰을 최소화하면서 통합된 표준 브리지와 타사 브리지를 통해 EVM 체인의 대규모 자본 기반으로부터 혜택을 받을 수 있습니다. 이러한 대규모 EVM 자본 기반은 상대적으로 활성화되어 있으며 다음과 같은 이유로 사용자와 개발자를 끌어들일 수 있습니다.

*사용자는 유동성과 높은 거래량을 선호합니다.

*개발자는 높은 거래량, 수수료, 앱 가시성을 추구합니다.

 (2) 개발자 리소스

이더넷의 도구와 응용 암호화 연구가 모나드에 직접 통합되어 처리량과 확장성을 높였습니다.

*애플리케이션

*개발자 도구

*개발자 도구 (하드햇, Apeworx, 파운드리)

*지갑(래비, 메타마스크, 팬텀)

*분석/인덱싱(이더스캔, 듄)

*분석/인덱싱(Etherscan , Dune)

Electric Capital의 개발자 보고서에 따르면 2024년 7월 현재 이더리움의 풀타임 개발자는 2,788명, 베이스는 889명, 폴리곤은 834명이며 솔라나는 664명으로 7위에 랭크되어 있습니다. 솔라나는 폴카닷, 아비트럼, 코스모스에 이어 664명의 개발자를 보유한 7위이며, 일부에서는 암호화폐 개발자의 총 수가 여전히 적기 때문에 이를 무시하고 외부 인재 영입에 집중해야 한다고 주장하지만, "작은" 암호화폐 개발자 풀에 많은 EVM 인재가 있다는 것은 분명합니다. 또한, 대부분의 인재가 EVM에서 일하고 대부분의 도구가 EVM에 있다는 점을 고려할 때, 새로운 개발자는 EVM에서 배우고 개발해야 하거나 선택해야 할 가능성이 높습니다. Keone이 인터뷰에서 언급했듯이 개발자는 다음을 선택할 수 있습니다.

*멀티체인 배포가 가능하지만 처리량이 제한적이고 비용이 많이 드는 EVM용 휴대용 앱을 빌드

*휴대성이 있고 멀티체인 배포가 가능하지만 처리량이 제한적이고 비용이 많이 드는 EVM용 앱을 빌드

*휴대성이 있고 다음과 같은 특정 에코시스템에서 멀티체인 배포가 가능한 EVM용 앱을 빌드할 수 있습니다. 솔라나, 앱토스, 수이)를 사용하여 고성능의 저비용 애플리케이션을 구축할 수 있습니다.

 Monad는 이 두 가지 접근 방식을 결합하는 것을 목표로 삼고 있습니다. 대부분의 도구와 리소스가 EVM에 맞게 맞춤화되어 있기 때문에 에코시스템 내에서 개발된 애플리케이션을 원활하게 포팅할 수 있습니다. 모나드의 최적화를 통한 상대적인 성능과 효율성이 결합된 EVM은 분명 강력한 경쟁 장벽입니다.

개발자뿐 아니라 사용자도 익숙한 워크플로를 선호합니다. 래비, 메타마스크, 이더스캔과 같은 툴을 통해 EVM 워크플로가 표준으로 자리 잡았습니다. 이러한 성숙한 플랫폼은 브릿지와 프로토콜의 통합을 용이하게 합니다. 또한 기본 애플리케이션(AMM, 머니 마켓, 브릿지)을 즉시 시작할 수 있습니다. 이러한 기본 요소는 새로운 애플리케이션뿐만 아니라 체인의 지속 가능성을 위해 매우 중요합니다.

3. EVM 확장

EVM을 확장하는 방법에는 크게 두 가지가 있습니다:

*실행을 체인 아래로 이동: 모듈식 아키텍처를 사용하여 롤업을 통해 실행을 다른 VM으로 오프로드합니다.

*성능 개선: 합의 최적화와 블록 크기 및 가스 한도를 늘려 베이스체인 EVM의 성능을 개선합니다.

(1) 롤업 및 모듈식 아키텍처

비탈릭은 2020년 10월 이더리움의 주요 확장으로 롤업을 도입했습니다. 솔루션의 주요 확장으로 롤업을 도입했습니다. 그 결과 이더의 확장 로드맵은 이더의 보안을 활용하는 오프체인 가상 머신인 롤업에 실행을 위임했으며, 롤업은 더 높은 처리량, 더 낮은 지연 시간, 더 낮은 거래 비용으로 뛰어난 실행력을 자랑합니다. 롤업은 이더보다 반복 개발 주기가 짧습니다. 이더에서는 몇 년이 걸리는 업데이트가 롤업에서는 잠재적인 비용과 손실이 적기 때문에 몇 달이 걸릴 수 있습니다.

롤업은 중앙화된 시퀀서를 사용해 실행하면서 특정 탈중앙화 요건을 우회할 수 있도록 안전한 이스케이프 해치를 유지할 수 있습니다. 아비트럼, 베이스, OP 메인넷을 포함한 많은 롤업이 아직 초기 단계(0단계 또는 1단계)에 있다는 점에 유의해야 합니다. 1단계 롤업에서 사기 증명 제출은 화이트리스트 참여자로 제한되며, 온체인 증명 가능 오류와 관련이 없는 업그레이드는 사용자에게 최소 30일의 옵트아웃 기간을 제공해야 합니다. 0단계 롤업은 라이선스 운영자의 다운타임 또는 검토가 필요한 경우 사용자에게 7일 미만의 옵트아웃 기간을 제공합니다.

 이더리움에서 일반적인 트랜잭션 크기는 156바이트이며 서명에 가장 많은 데이터가 포함되어 있습니다.롤업을 사용하면 여러 트랜잭션을 함께 묶어서 함께 묶어 전체 트랜잭션 크기를 줄이고 가스 비용을 최적화합니다. 간단히 말해 롤업은 여러 트랜잭션을 일괄적으로 패키징하여 메인 이더넷 네트워크에 전송함으로써 효율성을 달성합니다. 이는 온체인 데이터 처리를 줄이지만, 롤업 연결에 새로운 인프라 요구사항이 필요하기 때문에 생태계의 복잡성을 증가시킵니다. 또한 롤업 자체는 특히 게임 애플리케이션의 기본 롤업 처리량 제한을 해결하기 위해 실행을 L3로 이동하는 모듈식 아키텍처를 사용합니다.

롤업은 이론적으로 이더 위에 완전한 체인이 됨으로써 브리징과 유동성 파편화를 제거하지만, 현재 구현은 아직 완전한 "완전한" 체인이 아닙니다. TVL의 세 가지 주요 롤업인 Arbitrum, OP 메인넷, Base는 각각 특정 영역에서 우수하지만 포괄적인 솔루션을 제공하지 못하는 별개의 생태계와 사용자 기반을 유지하고 있습니다.

요컨대, 사용자는 솔라나와 같은 단일 체인을 사용하는 것과 동일한 경험을 얻기 위해 여러 개의 서로 다른 체인에 액세스해야 합니다. 블록체인의 핵심 명제 중 하나인 이더리움 생태계에서 통합된 공유 상태가 없다는 것은 온체인 사용 사례를 크게 제한하며, 특히 경쟁 롤업은 이동성과 상태 파편화로 인해 서로의 상태를 쉽게 이해할 수 없기 때문입니다. 또한 상태 조각화는 롤업과 상태를 함께 연결할 수 있는 브리지와 크로스체인 메시징 프로토콜에 대한 추가적인 필요성을 야기하지만, 이에 수반되는 몇 가지 트레이드오프가 있습니다. 단일 블록체인은 상태를 기록하는 단일 원장이 있기 때문에 이러한 파편화 문제에 직면하지 않습니다.

각 롤업은 최적화와 특정 영역에 집중하는 측면에서 다른 접근 방식을 취합니다. 옵티미즘은 슈퍼체인을 통해 추가적인 모듈성을 도입하므로 다른 L2에 의존하여 스택을 구축하고 경쟁을 위해 비용을 청구하며, 아비트럼은 주로 다음에 초점을 맞추고 있습니다. DeFi, 특히 영구 및 옵션 거래소에 초점을 맞추고 있으며 Xai와 Sanko를 통해 L3로 확장하고 있습니다.MegaETH 및 Base와 같은 새로운 고성능 롤업은 단일 대규모 체인을 제공하도록 설계된 높은 처리량 기능으로 등장했습니다.MegaETH는 아직 사용할 수 없으며 Base는 구현 측면에서 인상적이지만 다음과 같은 특정 영역에서 여전히 부족합니다. 파생상품 거래(옵션 및 무기한) 및 디핀 공간.

(2) 초기 L2 확장

옵티미즘과 Arbitrum

1세대 L2는 이더리움에 비해 향상된 실행 속도를 제공했지만, 초최적화된 최신 솔루션에는 뒤처졌습니다. 예를 들어, Arbitrum은 초당 37.5개의 트랜잭션(이하 "TPS")을 처리하고 옵티미즘 메인넷은 11 TPS입니다. 이는 약 80 TPS의 Base, 100,000 TPS를 목표로 하는 MegaETH, 65.1 TPS의 BNB Chain. 그리고 모나드는 10,000 TPS를 목표로 하고 있습니다.

 Arbitrum과 Optimism 메인넷은 완전한 온체인 주문장과 같은 매우 높은 처리량을 지원할 수는 없지만 애플리케이션과 같은 매우 높은 처리량을 지원할 수는 없지만, 추가 체인 레이어(Arbitrum의 L3 및 Optimism의 하이퍼체인)와 중앙화된 시퀀서를 통해 확장할 수 있습니다.

아비트럼의 게임 중심 L3, Xai, Proof of Play는 이러한 접근 방식을 보여줍니다. 이들 L3는 Arbitrum Orbit 스택을 기반으로 구축되며 AnyTrust 데이터 가용성을 사용하여 Arbitrum에 정착합니다.Xai는 67.5 TPS에 도달하고, Proof of Play Apex는 12.2 TPS, Proof of Play Boss는 10 TPS에 도달합니다.Arbitrum을 통해 이러한 L3를 정착하면 다음과 같은 이점이 도입됩니다. 메인 이더 네트워크에 대한 추가 신뢰 가정을 도입하는 동시에 더 적은 수의 분산 데이터 가용성 계층이라는 잠재적 과제에 직면하게 됩니다.옵티미즘의 L2인 베이스, 블래스트 및 곧 출시될 유니체인은 이더를 통해 정산됩니다. 더 강력한 보안을 유지하기 위해 결제 및 블롭 데이터 가용성을 배치합니다.

두 네트워크 모두 수평적 확장을 우선시합니다. 옵티미즘은 L2 인프라, 체인 배포 지원, OP 스택을 통한 상호운용성 기능을 갖춘 공유 브리지를 제공합니다. 아비트럼은 특정 사용 사례, 특히 신뢰를 추가로 가정하면 금융 애플리케이션보다 자본 위험이 낮은 게임 애플리케이션을 L3로 오프로드합니다. 애플리케이션은 더 낮은 자본 리스크를 가져옵니다.

(3) 체인 및 EVM 성능 최적화

대안적 확장 접근법은 수평적 확장이 아닌 수직적 확장으로 처리량과 TPS를 높이기 위해 최적화 또는 객관적 절충을 실행하는 데 중점을 둡니다. 베이스, 메가ETH, 아발란체, BNB 체인이 이 전략을 구현합니다.

BaseBase는 가스 목표를 점진적으로 늘려 1Ggas/s의 목표를 달성하겠다는 계획을 발표했습니다. 9월에는 목표를 11Mgas/s로 늘리고 가스 한도를 33Mgas로 늘렸으며, 초기 블록에서 258건의 거래를 처리했습니다. 트랜잭션을 처리하여 5시간 동안 약 70 TPS를 유지했습니다. 12월 18일까지 가스 목표는 20Mgas/s로, 블록 아웃 시간은 2초, 블록당 지원 가스는 4천만 개였습니다. 이는 Arbitrum의 7Mgas/s, OP 메인넷의 2.5Gas/s와 비교됩니다.

 Base는 Solana와 다른 높은 처리량 체인의 경쟁자로 떠올랐습니다. 현재 Base는 다음과 같이 활동 측면에서 다른 L2를 앞지르고 있습니다.

* 2025년 1월 기준 월 수수료 1,560만 달러 - Arbitrum의 7.5배, OP. 메인넷의 23배.

* 2025년 1월 기준 누적 거래량은 3억 2,970만 건으로, Arbitrum(5,790만 건)의 6배, OP 메인넷(2,450만 건)의 14배에 달합니다. 참고: 거래량은 조작될 수 있으며 오해의 소지가 있을 수 있습니다.

The Base 팀은 속도, 처리량, 낮은 수수료에 최적화하여 보다 통합된 경험을 제공하는 데 초점을 맞추고 있으며, Arbitrum과 Optimism의 모듈식 접근 방식이 아닌 보다 통합된 경험을 제공하는 데 집중하고 있습니다. Base의 활동 및 수익 수치에서 알 수 있듯이 사용자들은 보다 통합된 경험을 선호하는 것으로 나타났습니다. 또한 코인베이스의 지원과 배포도 도움이 되었습니다.

MegaETH

MegaETH는 EVM과 호환되는 L2입니다. 핵심은 전용 시퀀서 노드를 사용하는 하이브리드 아키텍처를 통해 트랜잭션을 처리하는 것입니다. MegaETH는 아키텍처에서 성능과 보안 작업을 고유하게 분리하고, 기존의 머클 패트리샤 트리를 대체하는 새로운 상태 관리 시스템을 통합하여 디스크 I/O 작업을 최소화합니다.

이 시스템은 완벽한 EVM 호환성과 테라바이트의 상태 데이터를 처리할 수 있는 기능을 유지하면서 밀리초 미만의 지연 시간으로 초당 100,000건의 트랜잭션을 처리하며, 데이터 가용성을 위해 EigenDA를 사용하여 3가지 전용 노드 유형에 기능을 분산합니다.

*Sequencer: 고성능 단일 노드(100코어, 1~4테라바이트의 RAM)가 트랜잭션 시퀀싱과 실행을 관리하며 빠른 액세스를 위해 RAM에 상태를 유지합니다. 약 10ms 간격으로 블록을 생성하고, 블록 유효성 검사를 감시하며, 블록체인 상태 변경에 대한 상태 차이를 추적합니다. 시퀀서는 병렬 EVM 실행과 우선순위 지원으로 고성능을 달성하며, 정상 작동 시 합의 오버헤드가 필요하지 않습니다.

*증명자: 이 경량 노드(1코어, 0.5GB RAM)는 블록 콘텐츠를 검증하는 암호학적 증명을 계산합니다. 이들은 블록을 비동기식 및 무질서적으로 검증하고, 상태 비저장 검증을 사용하며, 수평적으로 확장하고, 전체 노드 검증을 위한 증명을 생성합니다. 이 시스템은 영지식 및 사기 증명을 지원합니다.

*풀 노드: 중간 하드웨어(4-8코어, 16GB RAM)에서 실행되는 풀 노드는 프루버, 시퀀서, 아이겐다를 연결하며 P2P 네트워크를 통해 압축된 상태 차이를 처리하여 트랜잭션을 다시 실행하지 않고 차이를 적용합니다. 블록은 증명자가 생성한 증명을 사용하여 검증되고, 상태 루트는 최적화된 머클 패트리샤 트리를 사용하여 유지되며, 19배 압축 동기화가 지원됩니다.

 (4) 롤업 관련 문제

Monad는 롤업과 본질적으로 다르며 그 고유의 트레이드오프가 있습니다. 공유 및 분산형 시퀀싱 솔루션이 개발되고 있지만, 오늘날 대부분의 롤업은 중앙 집중식 단일 시퀀서에 의존하고 있습니다. 시퀀서 및 제안자의 중앙 집중화는 운영상의 취약점을 야기합니다. 단일 주체에 의한 통제는 활동 문제와 검열 저항 감소로 이어질 수 있습니다. 중앙 집중식 시퀀서는 트랜잭션의 속도나 순서를 조작하여 MEV를 추출할 수 있는 탈출구가 존재하지만, 시퀀서에 장애가 발생하면 전체 L2 네트워크가 제대로 작동하지 않는 단일 장애 지점을 생성하기도 합니다.

중앙 집중화의 위험 외에도 롤업은 특히 상호운용성과 관련하여 추가적인 신뢰 가정과 절충점을 도입합니다.

사용자는 동일한 자산의 대체 불가능한 여러 형태를 접하게 됩니다. Arbitrum, Optimism, Base의 세 가지 주요 롤업은 서로 다른 생태계, 사용 사례, 사용자 커뮤니티를 유지합니다. 사용자는 특정 애플리케이션에 액세스하기 위해 롤업 간에 브리징을 하거나 여러 롤업에서 프로토콜을 실행해야 하며, 브리징 통합과 관련된 복잡성 및 보안 위험을 관리하면서 모빌리티와 사용자를 채널링해야 합니다.

추가적인 상호운용성 문제는 기술적 제약(기본 L2 계층의 초당 트랜잭션 수 제한)으로 인해 발생하며, 특히 게임의 경우 모듈성을 강화하고 실행을 L3로 밀어붙이게 됩니다. 중앙 집중성은 또 다른 문제를 야기합니다.

우리는 최적화된 롤업(예: 베이스 및 메가ETH)이 합의 요건 없이 트랜잭션이 순서화되고 실행되기 때문에 중앙화된 시퀀서를 통해 성능을 개선하고 EVM을 최적화하는 것을 보아왔습니다. 이를 통해 단일 고용량 머신을 사용해 블록아웃 시간을 줄이고 블록 크기를 늘릴 수 있으며, 단일 장애 지점 및 잠재적 검열 벡터를 생성할 수 있습니다.

Monad는 메인 이더 네트워크에 비해 더 강력한 하드웨어를 필요로 하는 다른 접근 방식을 취합니다. 이더 L1 검증자에게는 2코어 CPU, 4~8GB RAM, 25Mbps 대역폭이 필요하지만, 모나드에는 16코어 CPU, 32GB RAM, 2TB SSD, 100Mbps 대역폭이 필요합니다. 모나드의 사양은 이더리움에 비해 방대해 보이지만, 모나드는 독립적인 검증자를 수용하기 위해 노드 요구 사항을 최소한으로 유지했으며, 현재 모나드의 권장 하드웨어에 액세스할 수 있음에도 불구하고 노드 요구 사항을 최소화했습니다.

 하드웨어 사양 외에도 Monad는 소프트웨어 스택을 재설계하여 노드 분산을 통해 L2보다 더 큰 탈중앙화를 가능하게 하고 있습니다. L2가 탈중앙화를 희생하면서 단일 시퀀서의 하드웨어 개선에 우선순위를 두었다면, 모나드는 하드웨어 요구 사항을 높이면서 노드 분산을 유지하면서 성능을 개선하기 위해 소프트웨어 스택을 수정했습니다.

(5) 모나드의 EVM 초기 이더 포크는 주로 아발란체와 같은 합의 메커니즘을 수정하는 동시에 실행을 위해 Go 이더리움 클라이언트를 유지했습니다. 여러 프로그래밍 언어용 이더리움 클라이언트가 존재하지만, 대부분 원래 설계를 복제합니다. 모나드는 합의와 실행 구성 요소를 처음부터 다시 구축한다는 점에서 다릅니다.

모나드는 하드웨어 활용 극대화를 우선시합니다. 반면, 이더리움 메인넷은 독립적인 지분 보유자를 지원하는 데 초점을 맞추기 때문에 더 약한 하드웨어와의 호환성이 필요하기 때문에 성능 최적화에 한계가 있습니다. 이러한 제한은 블록 크기, 처리량, 블록아웃 시간 개선에 영향을 미치며, 궁극적으로 네트워크의 속도는 가장 느린 검증자에 따라 달라집니다.

솔라나의 접근 방식과 유사하게, 모나드는 더 강력한 하드웨어를 사용해 대역폭을 늘리고 지연 시간을 줄입니다. 이 전략은 사용 가능한 모든 코어, 메모리, SSD를 활용하여 속도를 높입니다. 강력한 하드웨어의 가격이 하락하고 있는 상황에서 저품질 디바이스의 성능을 제한하는 것보다 고성능 디바이스를 최적화하는 것이 더 실용적입니다.

 현재 Geth 클라이언트는 단일 스레드 순차 처리를 통해 실행됩니다. 블록에는 이전 상태를 새로운 상태로 변환하는 선형적으로 정렬된 트랜잭션이 포함되어 있습니다. 이 상태에는 모든 계정, 스마트 컨트랙트, 저장된 데이터가 포함됩니다. 상태 변경은 트랜잭션이 처리되고 확인될 때 발생하며 계정 잔액, 스마트 컨트랙트, 토큰 소유권 및 기타 데이터에 영향을 미칩니다.

거래는 일반적으로 독립적으로 실행됩니다. 블록체인 상태는 서로 다른 계정으로 구성되며, 각 계정은 독립적으로 트랜잭션을 수행하며, 이러한 트랜잭션은 일반적으로 서로 상호 작용하지 않습니다. 이를 염두에 두고 모나드는 낙관적 병렬 실행을 사용합니다.

최적 병렬 실행은 처음에는 충돌이 없다고 가정하고 잠재적인 성능 이점을 위해 트랜잭션을 병렬로 실행하려고 시도합니다. 처음에는 잠재적인 충돌이나 종속성에 대한 우려 없이 여러 트랜잭션이 동시에 실행됩니다. 실행 후 시스템은 병렬 트랜잭션이 실제로 서로 충돌하는지 확인하고 충돌이 있는 경우 이를 수정합니다.

4. 프로토콜 메커니즘병렬 실행

(1) 솔라나를 위한 병렬 실행

(1) 솔라나를 위한 병렬 실행

병렬 실행이라고 하면 보통 액세스 목록을 통해 트랜잭션을 병렬로 실행할 수 있는 솔라나와 SVM을 떠올리게 되는데, 솔라나에서 트랜잭션에는 헤더, 계정 키(트랜잭션에 포함된 명령어의 주소), 블록 해시(트랜잭션 생성 시점에 포함된 해시)가 포함됩니다, 인스트럭션 및 트랜잭션 인스트럭션에 따라 필요한 모든 계정 서명의 배열입니다.

각 트랜잭션의 명령에는 호출되는 프로그램을 지정하는 프로그램 주소, 명령이 읽고 쓰는 모든 계정을 나열하는 계정, 명령 핸들러(명령을 처리하는 함수)와 명령 핸들러가 필요로 하는 추가 데이터를 지정하는 명령 데이터가 포함됩니다.

각 인스트럭션은 관련된 각 계정에 대해 세 가지 주요 세부 정보를 지정합니다.

*계정의 공개 주소

*이 계정이 다음을 수행해야 하는지 여부 트랜잭션에 서명해야 하는지 여부

*명령이 계정의 데이터를 수정하는지 여부

솔라나는 이러한 지정된 계정 목록을 사용하여 트랜잭션 충돌을 사전에 식별합니다. 쓰기 가능 여부에 대한 세부 정보를 포함하여 모든 계정이 명령에 지정되므로 동일한 상태에 쓰는 계정이 없는 경우 트랜잭션이 병렬로 처리될 수 있습니다.

프로세스는 다음과 같습니다.

*솔라나가 각 트랜잭션에 제공된 계정 목록을 검토합니다

*쓰기할 계정을 식별합니다

*쓰기할 계정 식별

*거래 간 충돌 여부(동일한 계정에 쓰는지 여부)를 확인합니다

*동일한 계정에 쓰지 않는 거래는 병렬로 처리하고, 충돌하는 쓰기 작업이 있는 거래는 순차적으로 처리합니다

유사한 메커니즘이 EVM에도 존재하지만, 이더리움에는 액세스 목록이 필요하지 않기 때문에 사용되지 않습니다. 사용자는 트랜잭션에 이 액세스 목록을 포함하기 때문에 더 많은 비용을 선불로 지불해야 합니다. 트랜잭션은 더 커지고 비용이 더 많이 들지만, 사용자는 액세스 목록을 지정하는 대신 할인을 받습니다.

(2) 모나드의 병렬 실행 모나드는 솔라나와 달리 낙관적 병렬 실행을 사용합니다. 어떤 트랜잭션이 어떤 계정에 영향을 미치는지 식별하고 이를 기반으로 병렬화하는 방식(Solana의 접근 방식)과 달리, 모나드는 트랜잭션이 서로 간섭하지 않고 병렬로 실행될 수 있다고 가정합니다.

모나드는 트랜잭션을 병렬로 실행할 때 동일한 지점에서 트랜잭션이 시작된다고 가정합니다. 여러 트랜잭션이 병렬로 실행되면 체인은 각 트랜잭션에 대해 보류 중인 결과를 생성합니다. 이 경우 보류 중인 결과는 체인이 트랜잭션의 입력과 출력을 추적하고 상태에 미치는 영향을 추적하기 위해 수행하는 장부를 의미합니다. 이러한 보류 중인 결과는 트랜잭션의 원래 순서대로 표시됩니다(즉, 우선순위 비용에 따라).

보류 중인 결과를 제출하기 위해 입력이 여전히 유효한지 확인합니다. 보류 중인 결과에 대한 입력이 변경/수정된 경우(즉, 동일한 계정에 액세스하여 거래가 병렬로 작동하지 않고 서로 영향을 줄 수 있는 경우), 거래가 순차적으로 처리됩니다. 처리됩니다(나중에 트랜잭션이 다시 실행됨). 재실행은 정확성을 유지하기 위해서만 수행됩니다. 결과적으로 트랜잭션이 더 오래 걸리는 것이 아니라 더 많은 계산이 필요합니다.

첫 번째 실행 반복에서 Monad는 이미 다른 트랜잭션과의 충돌이나 종속성을 확인했습니다. 따라서 트랜잭션이 두 번째로 실행될 때(첫 번째 낙관적 병렬 실행이 실패한 후) 블록의 모든 이전 트랜잭션이 실행되었으므로 두 번째 시도가 성공할 수 있습니다. 모나드의 모든 트랜잭션이 서로 종속되어 있더라도 순차적으로 실행되므로 병렬화되지 않은 다른 EVM과 동일한 결과를 생성합니다.

Monad는 실행 중에 각 트랜잭션의 읽기 세트와 쓰기 세트를 추적한 다음 원래의 트랜잭션 순서대로 결과를 병합합니다. 병렬로 실행 중인 트랜잭션이 오래된 데이터를 사용하는 경우(이전 트랜잭션이 읽은 내용을 업데이트했기 때문에), 병합 중에 이를 감지하고 올바른 업데이트 상태로 트랜잭션을 다시 실행합니다. 이렇게 하면 최종 결과는 블록의 순차적 실행과 동일하며 이더넷 호환성을 유지합니다. 이러한 재실행은 서명 확인이나 데이터 로딩과 같은 비용이 많이 드는 단계를 처음부터 반복할 필요가 없으며, 필요한 상태가 첫 번째 실행 시 이미 메모리에 캐시되어 있는 경우가 많으므로 오버헤드가 최소화됩니다.

예시:

초기 상태에서 사용자 A는 100 USDC를, 사용자 B는 0 USDC를, 사용자 C는 300 USDC를 가지고 있습니다.

*트랜잭션 1: 사용자 A가 사용자 B에게 10 USDC를 송금

*트랜잭션 2: 사용자 A가 10 USDC

직렬 실행 프로세스 직렬 실행을 사용하면 프로세스는 더 간단하지만 효율성은 떨어집니다. 각 트랜잭션은 순차적으로 실행됩니다.

*사용자 A가 먼저 사용자 B에게 10 USDC를 전송합니다.

*그 후 사용자 A가 사용자 C에게 10 USDC를 전송합니다.

직렬 실행 프로세스. align:center">

최종 상태, 직렬 실행(비모나드)의 경우:

*사용자 A에게 80 USDC가 남습니다(B와 C에게 각각 10 USDC를 보냄).

*사용자 B는 10 USDC를 가지고 있습니다.

*사용자 C는 310 USDC를 가지고 있습니다.

병렬 실행 프로세스

병렬 실행을 사용하면 프로세스가 더 복잡하지만 더 효율적입니다. 각 트랜잭션이 순차적으로 완료될 때까지 기다리지 않고 여러 트랜잭션이 동시에 처리됩니다. 트랜잭션이 병렬로 실행되더라도 시스템은 입력과 출력을 계속 추적합니다. 순차적 '병합' 단계에서 트랜잭션이 이전 트랜잭션에서 변경된 입력을 사용하는 것이 감지되면 트랜잭션은 업데이트된 상태로 다시 실행됩니다.

단계별 프로세스는 다음과 같습니다.

*사용자 A는 처음에 100 USDC를, 사용자 B는 처음에 0 USDC를, 사용자 C는 처음에 300 USDC를 가지고 있습니다.

*사용자 B는 처음에 0 USDC를 가지고 있습니다. align: left;">*낙관적 병렬 실행을 통해 여러 트랜잭션이 동시에 실행되며, 처음에는 모두 동일한 초기 상태에서 작동한다고 가정합니다.

*이 경우 트랜잭션 1과 트랜잭션 2가 병렬로 실행됩니다. 두 트랜잭션 모두 사용자 A의 초기 상태를 100 USDC로 읽습니다.

*거래 1은 사용자 A에서 사용자 B로 10 USDC를 전송하여 사용자 A의 잔액을 90으로 줄이고 사용자 B의 잔액을 10으로 늘리도록 예약되어 있습니다.

*동시에 트랜잭션 2도 사용자 A의 초기 잔액을 100으로 읽고 사용자 C에게 10 USDC를 전송하여 사용자 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로 증가합니다.

*트랜잭션 2는 사용자 A의 업데이트된 상태를 90 USDC로 읽습니다. align: left;">*이 경우 사용자 A가 두 트랜잭션을 모두 송금할 수 있는 충분한 자금을 보유하고 있으므로 두 트랜잭션이 모두 성공적으로 완료됩니다.

 최종 상태, 병렬 실행(Monad):

결과는 동일합니다.

*사용자 A에게는 80 USDC가 남습니다(B와 C에게 각각 10 USDC가 전송됨).

*사용자 B는 10 USDC를 보유합니다.

*사용자 C는 310 USDC를 보유합니다.

*사용자 D는 100 USDC를 보유합니다! NFT 비용과 발행된 NFT를 뺀 값입니다.

5. 지연된 실행

블록체인이 거래를 검증하고 합의에 도달하면 전 세계 노드가 서로 통신해야 합니다. 이러한 글로벌 통신은 도쿄와 뉴욕과 같은 장거리 지점 간에 데이터가 이동하는 데 시간이 걸리기 때문에 물리적 한계에 부딪힙니다.

대부분의 블록체인은 실행이 합의와 긴밀하게 결합된 순차적 접근 방식을 사용합니다. 이러한 시스템에서 실행은 합의를 위한 전제 조건이며, 노드는 블록을 확정하기 전에 트랜잭션을 실행해야 합니다.

자세한 내용은 다음과 같습니다:

다음 블록을 시작하기 전에 블록을 마무리하려면 합의에 앞서 실행이 선행되어야 합니다. 노드는 먼저 트랜잭션 순서에 대한 합의에 도달한 다음 트랜잭션을 실행한 후 상태 요약의 머클 루트에 합의하며, 리더는 제안된 블록이 공유되기 전에 모든 트랜잭션을 실행해야 하고 검증 노드는 합의에 도달하기 전에 각 트랜잭션을 실행해야 합니다. 이 과정은 합의에 도달하기 위해 여러 차례의 글로벌 커뮤니케이션을 거치므로 실행 시간이 제한됩니다. 예를 들어, 이더리움의 블록아웃 시간은 12초이지만, 실제 실행 시간은 100밀리초까지 걸릴 수 있습니다(실제 실행 시간은 블록 복잡성과 가스 사용량에 따라 크게 달라집니다).

일부 시스템은 인터리빙 실행을 통해 이를 최적화하려고 시도하는데, 이는 작업을 프로세스 간에 번갈아 가며 실행하는 작은 세그먼트로 나눕니다. 처리는 여전히 순차적이지만 특정 순간에 단일 작업이 실행되므로 빠른 전환으로 인해 상당한 동시성이 생성됩니다. 그러나 실행과 합의가 여전히 상호 의존적이기 때문에 이 접근 방식은 여전히 처리량을 근본적으로 제한합니다.

 모나드는 합의에서 실행을 분리하여 순차적 및 인터리브 실행의 한계를 해결합니다. 노드는 트랜잭션을 실행하지 않고 트랜잭션 순서에 대한 합의에 도달합니다. 즉, 두 개의 병렬 프로세스가 진행됩니다.

*노드는 합의에 도달한 트랜잭션을 실행합니다.

*합의는 실행이 완료될 때까지 기다리지 않고 다음 블록으로 진행되며, 합의에 따라 실행합니다.

이 구조는 시스템이 실행을 시작하기 전에 합의를 통해 많은 양의 작업을 커밋할 수 있게 해주며, 모나드는 추가 시간을 할당하여 더 큰 블록과 더 많은 트랜잭션을 처리할 수 있습니다. 또한 각 프로세스가 전체 블록 시간을 독립적으로 사용할 수 있어 합의는 전체 블록 시간을 글로벌 통신에 사용하고, 실행은 전체 블록 시간을 계산에 사용할 수 있으며 두 프로세스가 서로를 차단하지 않습니다.

보안과 상태 일관성을 유지하면서 합의에서 실행을 분리하기 위해 Monad는 지연된 머클 루트를 사용하는데, 각 블록에는 블록 전 상태 머클 루트 N 개(시작 시 N은 10으로 예상되며 현재 테스트 네트워크에서는 3으로 설정됨)가 포함되어 노드가 실행 후 다음을 확인할 수 있습니다. 동일한 상태에 도달했는지 확인할 수 있습니다. 지연된 머클 루트를 통해 체인은 상태 일관성을 확인할 수 있습니다. 지연된 머클 루트는 체크포인트 역할을 하며, N 블록 이후 노드는 동일한 상태 루트에 도달했거나 잘못된 콘텐츠를 실행했음을 증명해야 합니다. 또한 노드의 실행이 다른 상태 루트를 생성하는 경우, N 블록 후에 이를 감지하여 롤백하고 다시 실행하여 합의에 도달할 수 있습니다. 이는 노드의 악의적인 행동의 위험을 제거하는 데 도움이 됩니다. 생성된 지연된 머클 루트는 N 블록 지연에도 불구하고 가벼운 클라이언트 상태 확인에 사용될 수 있습니다.

실행이 지연되고 합의 후에 발생하기 때문에 악의적인 행위자(또는 우연히 일반 사용자)가 자금 부족으로 인해 결국 실패할 트랜잭션을 계속 제출하는 것이 잠재적인 문제입니다. 예를 들어, 총 잔액이 10 MON인 사용자가 5개의 트랜잭션을 제출하고 각 트랜잭션이 개별적으로 10 MON을 보내려고 시도하면 문제가 발생할 수 있습니다. 그러나 확인하지 않으면 이러한 트랜잭션은 합의를 통과하지만 실행 중에 실패할 수 있습니다. 이 문제를 해결하고 잠재적인 스팸을 줄이기 위해 노드는 합의 중에 전송 중인 트랜잭션을 추적하여 보호 조치를 구현합니다.

각 계정에 대해 노드는 N 블록 전의 계정 잔액을 확인합니다(가장 최근에 확인된 올바른 상태이므로). 그런 다음 해당 계정에 대해 '전송 중'(컨센서스는 통과했지만 아직 실행되지 않은) 보류 중인 트랜잭션마다 전송 중인 값(예: 1 MON 전송)과 gas_limit에 maxFeePerGas를 곱해 계산한 최대 가스 비용을 뺍니다.

노드는 N 블록 전 계정 잔액을 확인합니다(이는 최근에 확인된 올바른 상태이므로). "text-align: left;">이 프로세스는 합의 중에 새 트랜잭션의 유효성을 검사하는 데 사용되는 실행 중인 "사용 가능한 잔액"을 생성합니다. 새 트랜잭션의 값과 최대 가스 비용이 이 사용 가능한 잔액을 초과하면 트랜잭션은 합의 중에 통과되었다가 실행 중에 실패하는 것이 아니라 거부됩니다.

모나드의 합의는 (실행 분리로 인해) 약간 지연된 상태 보기에서 이루어지기 때문에, 발신자가 궁극적으로 지불할 수 없는 트랜잭션을 포함하지 않도록 보호하는 기능을 구현합니다. 모나드에서 각 계정에는 합의가 진행되는 동안 사용 가능한 잔액 또는 "예비" 잔액이 있습니다. 트랜잭션이 제안된 블록에 추가되면 프로토콜은 이 가용 잔액에서 트랜잭션의 최대 가능한 비용(가스 * 최대 수수료 + 전송된 가치)을 차감합니다. 계정의 사용 가능한 잔액이 0 이하로 떨어지면 해당 계정의 추가 트랜잭션은 블록에 포함되지 않습니다.

이 메커니즘(예비 잔액에 전송 비용을 부과하는 것으로 설명되기도 함)은 지불 가능한 거래만 제안되도록 하여 쓸모없는 거래를 위해 네트워크에 자금을 0원으로 넘기려는 공격자의 DoS 공격을 방어합니다. 블록이 확정되고 실행되면 그에 따라 잔액이 조정되지만, 모나드 노드는 합의 단계에서 보류 중인 트랜잭션의 사용 가능한 잔액을 항상 최신 상태로 확인합니다.

6. MonadBFT

(1) 합의

HotStuff

MonadBFT는 지연 시간이 짧고 처리량이 높은 비잔틴 장애 허용("BFT") 합의 메커니즘입니다. 핫스터프 합의에서 파생되었습니다.

Hotstuff는 VMresearch에서 만들었고 Meta의 이전 블록체인 팀에서 LibraBFT로 더욱 개선했습니다. 선형적인 뷰 변경과 응답성을 구현하여 미리 정해진 타임아웃이 아닌 실제 네트워크 속도로 리더를 효율적으로 교체할 수 있으며, 핫스터프는 또한 효율성을 위해 임계값 서명을 사용하고 파이프라인 작업을 구현하여 이전 블록이 커밋되기 전에 새 블록을 제안할 수 있습니다.

그러나 이러한 이점에는 특정 단점이 있습니다. 추가 라운드로 인해 기존 2라운드 BFT 프로토콜에 비해 지연 시간이 길어지고 파이프라인 도중 포크가 발생할 가능성이 높아집니다. 이러한 단점에도 불구하고 HotStuff의 설계는 2라운드 BFT 프로토콜보다 완결성이 느리지만 대규모 블록체인 구현에 더 적합합니다.

핫스터프를 자세히 설명하면 다음과 같습니다.

*거래가 발생하면 리더라고 하는 네트워크의 검증자에게 전송됩니다.

*리더는 이러한 트랜잭션을 블록으로 컴파일하여 네트워크의 다른 검증자에게 브로드캐스트합니다.

*검증자들은 투표를 통해 블록을 검증하고, 다음 블록의 리더에게 전송합니다.

*악의적인 행위자나 통신 장애로부터 보호하기 위해 블록은 여러 차례의 투표를 거쳐 상태를 최종 확정해야 합니다.

*특정 구현에 따라 2~3번의 투표를 성공적으로 통과해야만 블록을 제출할 수 있으며, 이를 통해 강력하고 안전한 합의를 보장할 수 있습니다.

 MonadBFT는 HotStuff에서 파생되었지만, 고유한 수정 사항과 새로운 개념을 도입하여 더 깊이 탐구할 수 있는 가능성을 제시합니다.

트랜잭션 프로토콜

MonadBFT는 부분 동기화 조건에서 트랜잭션 프로토콜을 구현하도록 특별히 설계되었습니다. -즉, 메시지 지연 시간을 예측할 수 없는 비동기 기간 중에도 체인이 합의에 도달할 수 있습니다.

결국 네트워크는 안정화되고 (알려진 시간 내에) 메시지를 전달합니다. 이러한 비동기 기간은 모나드의 아키텍처에서 비롯되는데, 체인이 속도, 처리량, 병렬 실행을 증가시키기 위해 특정 메커니즘을 구현해야 하기 때문입니다.

DiemBFT

초기에 트리플 라운드 시스템을 구현한 HotStuff와 달리, MonadBFT는 졸테온과 유사한 방식을 사용합니다, DiemBFT와 Fast HotStuff의 2륜 시스템을 사용합니다.

"라운드"는 다음과 같은 기본 단계로 구성됩니다.

*각 라운드에서 리더는 새로운 블록과 이전 라운드의 인증서(QC 또는 TC)를 브로드캐스트합니다. TC).

*각 검증자는 블록을 검토하고 다음 라운드에서 리더에게 서명 투표를 보냅니다

*충분한 투표(2/3)가 모이면 QC가 형성됩니다.QC는 네트워크의 검증자가 블록을 첨부하기 위해 합의에 도달했음을 나타내며 합의에 도달했음을 나타내며, TC는 합의 라운드가 실패하여 다시 시작해야 함을 나타냅니다.

  "이중 라운드"는 특히 제출 규칙을 의미합니다. 2라운드 시스템에서 블록을 제출하려면:

*1라운드: 초기 블록이 제안되고 QC를 받음

*2라운드: 다음 블록이 제안되고 QC를 받음 두 라운드가 연속으로 완료되면 첫 번째 블록을 제출할 수 있습니다. .

DiemBFT는 3라운드 시스템을 사용했지만 2라운드 시스템으로 업그레이드되었습니다. 2라운드 시스템은 통신 라운드 수를 줄임으로써 더 빠른 커밋을 가능하게 합니다. 추가 확인을 기다릴 필요가 없기 때문에 트랜잭션을 더 빨리 제출할 수 있어 지연 시간이 단축됩니다.

정확한 프로세스

모나드BFT의 합의 프로세스는 다음과 같습니다:

*리더 운영 및 블록 제안: 현재 라운드의 지정된 리더가 합의를 시작하면 프로세스가 시작되며, 리더는 이전 라운드 합의의 증명과 함께 사용자의 트랜잭션이 포함된 새 블록을 QC 또는 TC 형태로 생성하고 브로드캐스트하며, 각 블록 제안이 이전 블록의 증명을 전달하는 파이프라인 구조를 만듭니다.

프로세스는 다음과 같습니다.

*검증자 작업: 검증자는 리더의 블록 오퍼를 받으면 검증 프로세스를 시작합니다. 각 검증자는 프로토콜의 규칙에 따라 블록의 유효성을 면밀히 검토합니다. 유효한 블록은 서명된 찬성 투표를 받아 다음 리더에게 전송됩니다. 그러나 검증자가 예상 시간 내에 유효한 블록을 받지 못하면, 검증자는 알려진 가장 높은 QC가 포함된 서명 타임아웃 메시지를 브로드캐스트하여 타임아웃 프로세스를 시작합니다. 이 이중 경로 접근 방식은 블록 제안이 실패하더라도 프로토콜이 진행될 수 있도록 보장합니다.

*인증서 생성: 프로토콜은 두 가지 유형의 인증서를 사용해 합의 진행 상황을 추적합니다. 리더가 검증자의 3분의 2로부터 찬성 투표를 받아 블록에 대한 광범위한 합의를 증명하면 QC가 생성됩니다. 또는 검증자의 3분의 2가 유효한 제안을 받지 못한 채 시간이 초과되면 TC를 생성하여 프로토콜이 안전하게 다음 라운드로 넘어갈 수 있도록 합니다. 두 가지 인증서 유형 모두 검증자 참여의 주요 증거 역할을 합니다.

*블록 확정화(2체인 제출 규칙): MonadBFT는 블록 확정화에 2체인 제출 규칙을 사용합니다. 검증자는 연속된 라운드에서 인접한 두 개의 인증 블록이 체인 B ← QC ← B' ← QC'를 형성하는 것을 관찰하면 블록 B와 그 모든 조상 블록을 안전하게 제출할 수 있습니다. 이 2체인 접근 방식은 성능을 유지하면서 보안과 활동성을 제공합니다.

로컬 메모리 풀 아키텍처

모나드는 기존의 글로벌 메모리 풀이 아닌 로컬 메모리 풀 아키텍처를 사용합니다. 대부분의 블록체인에서 보류 중인 트랜잭션은 모든 노드에 브로드캐스트되며, 이는 중복 전송으로 인해 속도가 느리고(네트워크 홉이 많음) 대역폭을 많이 차지할 수 있습니다. 반면, 모나드에서는 각 검증자가 자체 메모리 풀을 유지하며, 트랜잭션은 RPC 노드가 다음 몇 명의 예정된 리더(현재는 다음 N = 3명의 리더)에게 직접 전달하여 포함시킵니다.

이 방식은 알려진 리더 일정을 활용하고(리더가 아닌 사람에게 불필요한 브로드캐스트 방지) 새로운 트랜잭션이 블록 제안자에게 빠르게 도달하도록 합니다. 다음 리더는 유효성 검사를 수행하고 트랜잭션을 로컬 메모리 풀에 추가하므로, 검증자가 리더로 차례가 바뀔 때쯤이면 이미 관련 트랜잭션이 대기열에 추가되어 있습니다. 이 설계는 전파 지연 시간을 줄이고 대역폭을 절약하여 더 높은 처리량을 가능하게 합니다.

(2) 랩터캐스트

모나드는 랩터캐스트라는 특수한 멀티캐스트 프로토콜을 사용하여 블록을 빠르게 전파합니다. 리더는 완전한 블록을 각 피어에게 연속적으로 보내거나 단순한 브로드캐스트에 의존하는 대신 수정 코딩 체계(RFC 5053에 따라)를 사용하여 블록 제안 데이터를 인코딩된 블록으로 나누고 2단계 릴레이 트리를 통해 이러한 블록을 효율적으로 배포합니다. 실제로 리더는 서로 다른 블록을 일련의 1차 검증자 노드에 보내고, 이 노드는 다른 노드에 블록을 전달하여 각 검증자가 결국 전체 블록을 재구성하기에 충분한 블록을 받도록 합니다. 블록 할당은 형평성(각 검증자는 블록의 일부를 전달할 책임이 있음)에 따라 가중치를 부여하여 부하를 분산합니다. 이러한 방식으로 전체 네트워크의 업로드 용량이 블록을 빠르게 전파하는 데 사용되어 지연 시간을 최소화하는 동시에 메시지를 삭제할 수 있는 비잔틴(악의적이거나 결함이 있는) 노드를 견딜 수 있으며, RaptorCast를 통해 Monad는 높은 처리량에 중요한 대용량 블록에서도 빠르고 안정적인 블록 브로드캐스팅을 달성할 수 있습니다.

BLS 및 ECDSA 서명

QC와 TC는 서로 다른 두 가지 유형의 암호화 디지털 서명 체계입니다.

Monad는 보안과 확장성을 높이기 위해 BLS 서명과 ECDSA 서명을 조합하여 사용하며, BLS 서명은 서명 통합을 지원하는 반면 ECDSA 서명은 일반적으로 검증 속도가 더 빠릅니다.

ECDSA 서명

서명을 집계할 수는 없지만, ECDSA 서명이 훨씬 빠르며 Monad는 QC와 TC에 모두 사용합니다.

스타일="text-align: 왼쪽;">QC 생성 :

*리더가 블록을 제안

*검증자가 서명을 통해 투표로 동의

*검증자가 서명

*필요한 만큼의 투표가 모이면 이를 합쳐 QC를 생성할 수 있습니다.

*QC가 검증자가 블록에 동의함을 인증합니다

TC 생성 :

*정해진 시간 내에 유효한 블록이 검증자에게 수신되지 않으면

*서명한 타임아웃 메시지를 피어에게 브로드캐스트합니다. 충분한 타임아웃 메시지를 수집하면 TC를 형성합니다.

*TC는 현재 라운드가 실패하더라도 다음 라운드로 넘어갈 수 있습니다.

BLS 서명Monad는 BLS를 사용합니다. 서명을 사용하며, 이는 서명을 점진적으로 하나의 서명으로 통합할 수 있기 때문입니다. 이는 주로 투표 및 시간 초과와 같이 집계 가능한 메시지 유형에 사용됩니다.

투표는 검증자가 제안된 블록에 동의할 때 보내는 메시지입니다. 여기에는 블록의 승인을 나타내는 서명이 포함되어 있으며 QC를 구성하는 데 사용됩니다.

타임아웃은 예상 시간 내에 유효한 블록을 수신하지 못했을 때 검증자가 보내는 메시지입니다. 여기에는 현재 라운드 번호, 검증자의 최고 QC, 해당 값에 대한 서명이 있는 서명된 메시지가 포함됩니다. 이는 TC를 구성하는 데 사용됩니다.

폴링과 타임아웃은 모두 BLS 서명을 사용하여 결합/합산하여 공간을 절약하고 효율성을 높일 수 있습니다. 앞서 언급했듯이 BLS는 ECDSA 서명보다 상대적으로 느립니다.

Monad는 ECDSA와 BLS의 조합을 사용하여 두 가지의 효율성을 모두 활용합니다. BLS 방식은 속도가 느리지만 서명 집계를 허용하므로 폴링 및 시간 초과에 특히 적합한 반면, ECDSA는 더 빠르지만 집계를 허용하지 않습니다.

7. 모나드 MEV

단순히 말해, MEV는 당사자들이 블록에서 거래를 재순서하거나 포함하거나 제외하여 추출할 수 있는 값을 말합니다. MEV는 종종 시장을 건전하고 효율적으로 유지하는 MEV(예: 청산, 차익거래) 또는 "좋은" MEV(예: 샌드위치 공격)로 분류됩니다.

모나드의 지연된 실행은 MEV가 온체인에서 작동하는 방식에 영향을 미칩니다. 이더에서 실행은 합의를 위한 전제 조건으로, 노드가 블록에 동의할 때 트랜잭션의 목록과 순서, 결과 상태에 동의한다는 의미입니다. 새로운 블록을 제안하기 전에 리더는 모든 트랜잭션을 실행하고 최종 상태를 계산해야 하며, 이를 통해 검색자와 블록 빌더는 가장 최근에 확인된 상태에 대해 트랜잭션을 안정적으로 시뮬레이션할 수 있습니다.

반면, 모나드에서는 합의와 실행이 분리되어 있습니다. 노드는 가장 최근 블록의 트랜잭션 순서만 합의하면 되고, 상태에 대한 합의는 나중에 이루어질 수 있습니다. 즉, 검증자는 이전 블록의 상태 데이터를 기반으로 작동할 수 있으므로 최신 블록에 대해 모델링할 수 없습니다. 확인된 상태 정보의 부족으로 인한 복잡성 외에도, 모나드의 1초의 블록 외 시간은 빌더가 블록을 시뮬레이션하여 구성된 블록을 최적화하는 데 어려움을 겪을 수 있습니다.

검색자에게 최신 상태 데이터에 대한 액세스는 잠재적인 차익거래 기회와 현물 청산을 식별할 수 있는 확인된 자산 가격, 유동성 풀 잔액, DEX의 스마트 컨트랙트 상태 등을 제공하기 때문에 필수적입니다. 이벤트. 최신 상태 데이터가 확인되지 않으면 검색자는 다음 블록이 생성되기 전에 블록을 시뮬레이션할 수 없으며, 상태가 확인되기 전에 거래를 롤백할 위험이 있습니다.

모나드 블록의 지연을 고려할 때, MEV 환경은 솔라나와 유사할 가능성이 높습니다.

배경으로, 솔라나에서는 블록이 약 400밀리초마다 슬롯에 생성되지만 블록 생성에서 "루팅"(확정) 사이의 시간은 일반적으로 2000~4000밀리초로 훨씬 더 길어집니다. -일반적으로 2000~4000밀리초입니다. 이러한 지연은 블록 생성 자체가 아니라 블록을 확정하기 위해 충분한 지분 가중치를 가진 투표를 모으는 데 걸리는 시간에서 비롯됩니다.

이 투표 기간 동안 네트워크는 계속해서 새로운 블록을 병렬로 처리합니다. 트랜잭션 비용이 매우 낮고 새로운 블록을 병렬로 처리할 수 있기 때문에, 검색자가 자신이 포함되기를 바라며 많은 트랜잭션을 전송하는 '바닥을 향한 경쟁'이 발생하고, 이로 인해 많은 트랜잭션이 롤백됩니다. 예를 들어, 12월 한 달 동안 솔라나의 비투표 거래 31억 6천만 건 중 13억 건(약 41%)이 롤백되었으며, 지토의 버팔루는 2023년 초에 "솔라나에서 발생하는 차익거래의 98%가 실패한다"고 강조한 바 있습니다.

최신 블록에 대한 확인 상태 정보가 제공되지 않고 새 블록이 병렬로 처리되는 모나드에서도 비슷한 블록 지연 효과가 발생하면, 검색자는 많은 수의 거래를 전송하도록 유인을 받을 수 있으며, 이는 다음과 같은 이유로 실패할 수 있습니다. 트랜잭션이 롤백되어 시뮬레이션에 사용된 상태와 다른 상태로 확인되기 때문입니다.

8. 모나드DB

모나드는 블록체인 데이터를 저장하고 액세스하기 위해 모나드DB라는 맞춤형 데이터베이스를 구축하기로 선택했습니다. 체인 확장성의 일반적인 문제는 상태 증가, 즉 데이터의 크기가 노드의 용량을 초과하는 것입니다. 패러다임은 4월에 상태 증가에 대한 짧은 연구 기사를 발표하여 상태 증가, 과거 성장, 상태 액세스의 차이점을 강조했는데, 이들은 종종 혼동되는 경우가 많다고 주장합니다. 노드 하드웨어 성능의 서로 다른 개념임에도 불구하고 종종 혼동된다고 주장합니다.

그들이 지적한 바에 따르면:

*상태 증가는 새로운 계정(계정 잔액과 난수)과 컨트랙트(컨트랙트 바이트코드와 스토리지)의 축적을 의미합니다. 노드는 스테이트 증가를 수용하기에 충분한 스토리지와 메모리 용량을 확보해야 합니다.

*이력 증가는 새로운 블록과 새로운 트랜잭션의 축적을 의미합니다. 노드는 블록 데이터를 공유할 수 있는 충분한 대역폭과 블록 데이터를 저장할 수 있는 충분한 저장 공간이 필요합니다.

*상태 액세스는 블록을 구성하고 검증하는 데 사용되는 읽기 및 쓰기 작업을 의미합니다.

앞에서도 언급했듯이, 데이터 크기가 노드의 용량을 초과할 수 있기 때문에 상태 증가와 기록 증가 모두 체인 확장성에 영향을 미칩니다. 노드는 블록을 생성, 검증, 배포하기 위해 데이터를 영구 저장소에 저장해야 합니다. 또한 노드는 체인과 동기화하기 위해 메모리에 캐시해야 합니다. 상태 증가와 기록 증가, 최적화된 상태 액세스는 체인에 의해 수용되어야 하며, 그렇지 않으면 블록 크기와 블록당 작업이 제한될 수 있습니다. 블록에 데이터가 많고 블록당 읽기 및 쓰기 작업이 많을수록 히스토리 증가와 상태 증가가 커지고 효율적인 상태 액세스의 필요성이 커집니다.

상태와 히스토리 증가는 확장성에 중요한 요소이지만, 특히 디스크 성능 관점에서 보면 큰 문제는 아니며, MonadDB는 로그 데이터베이스 확장을 통해 상태 증가를 관리하는 데 중점을 둡니다. 그 결과, 상태를 16배 증가시켜도 상태 읽기당 디스크 액세스 횟수가 한 번만 더 필요합니다. 기록 증가와 관련하여. 체인의 성능이 높으면 로컬에 저장하기에는 너무 많은 데이터가 발생하게 됩니다. 솔라나와 같이 처리량이 높은 다른 체인은 구글 빅테이블과 같은 클라우드 호스팅에 의존하여 기록 데이터를 저장하는데, 이는 효과적이지만 중앙화된 당사자에 의존하기 때문에 탈중앙화가 희생됩니다. 모나드는 처음에는 유사한 솔루션을 구현하고 궁극적으로는 탈중앙화된 솔루션을 향해 노력할 것입니다.

(1) 상태 액세스

상태 증가와 기록 증가 외에도, MonadDB의 핵심 구현 중 하나는 각 블록의 읽기 및 쓰기 작업을 최적화하는 것입니다(즉, 상태 액세스 개선). 액세스).

이더리움은 머클 패트리샤 트리("MPT")를 사용하여 상태를 저장합니다.MPT는 데이터 검색 알고리즘인 패트리샤의 기능을 차용하여 보다 효율적인 데이터 검색을 가능하게 합니다. .

머클 트리 머클 트리("MT")는 결국 머클 루트라고 하는 단일 루트 해시로 환원되는 해시 집합입니다. 데이터 해시는 원본 데이터의 고정된 크기의 암호화 표현이며, 머클 루트는 단일 해시(머클 루트)가 남을 때까지 데이터 쌍을 반복적으로 해시하여 생성되며, 머클 루트의 유용성은 각 리프 노드를 개별적으로 검증할 필요 없이 리프 노드(즉, 루트를 만들기 위해 반복적으로 해시되는 개별 해시)의 유효성을 확인할 수 있다는 것입니다.

이 방법은 특히 블록당 트랜잭션이 많은 대규모 시스템에서 각 트랜잭션의 유효성을 개별적으로 검증하는 것보다 훨씬 효율적입니다. 이는 개별 데이터 간에 검증 가능한 관계를 생성하고, 트랜잭션과 루트를 재구성하는 데 필요한 중간 해시를 제공하여 트랜잭션이 블록에 포함되어 있음을 증명할 수 있는 "머클 증명"을 가능하게 합니다(n개의 트랜잭션 대신 로그(n) 해시).

머클 패트리샤 트리

머클 트리는 거래가 정적인 비트코인에 매우 적합하며 주요 요구사항은 다음과 같습니다. 트랜잭션이 블록에 존재한다는 것을 증명하는 것입니다. 그러나 단순히 존재 여부를 확인하는 것이 아니라 저장된 데이터(예: 계정 잔액 및 난수, 새 계정 추가, 스토어 내 키 업데이트)를 검색하고 업데이트해야 하는 이더리움의 사용 사례에는 적합하지 않으므로, 이더리움은 머클 패트리샤 트리를 사용하여 상태를 저장합니다.

머클 패트리샤 트리("MPT")는 상태 데이터베이스에 키-값 쌍을 저장하고 확인하기 위한 수정된 머클 트리입니다. MT는 다양한 데이터(예: 트랜잭션)를 가져와 쌍 단위로만 해시하는 반면, MPT는 데이터를 사전처럼 구성하여 각 데이터(값)에는 이를 저장할 특정 주소(키)가 있습니다. 이 키-값 저장소는 Patricia Trie를 통해 구현됩니다.

이더넷은 검색해야 하는 데이터에 따라 서로 다른 유형의 키를 사용하여 서로 다른 유형의 Trie에 액세스합니다. 이더넷은 4가지 유형의 Trie를 사용합니다.

*전세계 상태 Trie: 주소와 계정 상태 간의 매핑을 포함합니다.

*계정 스토리지 트라이: 스마트 컨트랙트와 관련된 데이터를 저장합니다.

*트랜잭션 트라이: 블록에 포함된 모든 트랜잭션을 포함합니다.

*수신 시도: 트랜잭션 실행에 대한 정보와 함께 트랜잭션 영수증을 저장합니다.

*Trie는 다양한 유형의 키를 통해 값에 액세스하여 체인이 잔액 확인, 컨트랙트 코드 존재 여부 확인, 특정 계정 데이터 조회 등 다양한 기능을 수행할 수 있도록 합니다.

주: 이더리움은 "블록 검증 기능을 잃지 않으면서 대량의 상태 데이터를 저장하지 않도록 이더리움 노드를 업그레이드"하기 위해 MPT에서 버클 트리로 전환할 계획입니다.

모나드 DB: 패트리샤 트리

Ether와 달리 MonadDb는 디스크와 메모리에서 로컬로 구현됩니다. 패트리샤 트리 데이터 구조를 구현합니다.

앞서 언급했듯이, MPT는 키-값 검색을 위해 머클 트리 데이터 구조와 패트리샤 트리를 결합한 것으로, 두 가지 데이터 구조가 통합/결합된 경우 패트리샤 트리는 키-값 쌍의 저장, 검색 및 업데이트에 사용되고 머클 트리는 다음과 같은 용도로 사용됩니다. 유효성 검사. 이는 해시 기반 노드 참조의 복잡성을 증가시키고 머클은 각 노드에 해시를 위한 추가 저장 공간을 필요로 하기 때문에 추가적인 오버헤드를 유발합니다.

패트리샤 트리 기반 데이터 구조를 사용하면 MonadDB는 다음을 수행할 수 있습니다.

*더 간단한 구조: 노드당 Merkle 해시가 없고 노드 관계에 해시 참조가 없으며, 오직 키와 값만 키와 값만 직접 저장합니다. *직접 경로 압축: 데이터에 도달하는 데 필요한 조회 횟수를 줄입니다. *로컬 키-값 저장: MPT는 Patricia Trie를 별도의 키-값 저장 시스템에 통합하지만, Patricia Trie의 로컬 기능은 키-값 저장으로 더 나은 최적화를 가능하게 합니다. *데이터 구조 변환 필요 없음: Trie 형식과 데이터베이스 형식 간에 변환할 필요가 없습니다. 따라서 MonadDB는 상대적으로 계산 오버헤드가 적고, 저장 공간이 덜 필요하며, 검색이나 업데이트와 같은 작업을 더 빠르게 수행할 수 있고, 구현이 더 간단합니다.

비동기 I/O

트랜잭션은 Monad에서 병렬로 실행됩니다. 즉, 스토리지가 병렬로 상태에 액세스하는 여러 트랜잭션을 수용해야 하며, 즉 데이터베이스에 비동기 I/O가 있어야 합니다.

MonadDB는 최신 비동기 I/O 구현을 지원하므로 많은 수의 스레드를 생성하지 않고도 여러 작업을 처리할 수 있습니다-

MonadDB는 최신 비동기 I/O 구현을 지원합니다. -여러 디스크 작업을 처리하기 위해 여러 개의 스레드를 생성해야 하는 기존의 키-값 데이터베이스(예: LMDB)와 달리, 관리해야 할 스레드 수가 적기 때문에 오버헤드가 적습니다.

암호화 영역에서 입출력 처리의 간단한 예는 다음과 같습니다.

*입력: 거래 전 계좌 잔액 확인을 위한 상태 읽기*출력: 이체 후 계좌 잔액 쓰기/갱신 비동기 I/O를 사용하면 입출력할 수 있습니다. 처리(즉, 스토리지에 대한 읽기 및 쓰기)를 허용하며, 이전 I/O 작업이 완료되지 않은 경우에도 가능합니다. 이는 여러 트랜잭션이 병렬로 실행되기 때문에 모나드에 필요합니다. 따라서 한 트랜잭션은 데이터를 읽거나 쓰기 위해 스토리지에 액세스해야 하고, 다른 트랜잭션은 여전히 스토리지에서 읽거나 쓰는 중입니다. 동기식 I/O에서는 프로그램이 한 번에 하나의 I/O 작업을 순차적으로 수행합니다. 동기식 I/O 처리에서 I/O 작업이 요청되면 트랜잭션은 이전 작업이 완료될 때까지 대기합니다. 예를 들어:

*동기식 I/O: 체인이 tx/블록 #1을 상태/스토리지에 씁니다. 체인은 완료될 때까지 기다립니다. 그런 다음 체인은 tx/블록 #2를 쓸 수 있습니다.* 비동기식 I/O: 체인은 tx/블록 #1, tx/블록 #2, tx/블록 #3을 동시에 스테이트/스토리지에 씁니다. 이들은 독립적으로 이 작업을 수행합니다.

(2) StateSync

모나드에는 신규 또는 지연 노드가 모든 트랜잭션을 재생하지 않고도 최신 상태를 효율적으로 따라잡을 수 있는 최신 상태를 효율적으로 따라잡을 수 있도록 도와줍니다. StateSync를 사용하면 노드("클라이언트")가 피어("서버")의 대상 블록에 가장 최근 상태의 스냅샷을 요청할 수 있습니다. 상태 데이터는 블록(예: 계정 상태의 일부와 가장 최근 블록 헤더)으로 분할되어 여러 검증자 피어에 분산되어 부하를 공유합니다. 각 서버는 요청된 상태 블록에 응답하고(MonadDb의 메타데이터를 사용하여 필요한 시도 노드를 빠르게 검색), 클라이언트는 이러한 블록을 조립하여 대상 블록의 상태를 구성합니다. 체인이 성장하고 있기 때문에 동기화가 완료되면 노드는 최상단에 더 가까운 스테이트싱크를 다시 수행하거나 소수의 최근 블록을 재생하여 완전히 따라잡습니다. 이렇게 청크화된 스테이트싱크는 노드 부트스트래핑과 복구 속도를 크게 높여 모나드의 상태가 증가하더라도 새로운 검증자가 참여하거나 재시작하여 몇 시간의 지연 없이 완전히 동기화할 수 있도록 보장합니다.

9. 생태계

(1) 생태계의 노력

모나드 팀은 체인을 위한 강력하고 견고한 생태계를 개발하는 데 주력하고 있습니다. 지난 몇 년 동안 L1과 L2 간의 경쟁은 성능에 초점을 맞추던 것에서 사용자 대면 애플리케이션과 개발자 도구로 옮겨갔습니다. 이제 체인은 더 이상 높은 TPS, 짧은 지연 시간, 낮은 수수료를 내세우는 것만으로는 충분하지 않으며, 디핀에서 AI, 디파이에서 소비자에 이르기까지 다양한 애플리케이션을 아우르는 생태계를 제공해야 합니다. 이것이 점점 더 중요해지는 이유는 고성능, 저비용 개발 환경과 블록 공간을 제공하는 솔라나, 수이, 앱토스, 하이퍼리퀴드 등 고성능 L1과 저비용 L1이 확산되고 있기 때문이며, 여기서 모나드의 강점 중 하나는 EVM을 사용한다는 점입니다.

앞서 언급했듯이 Monad는 완전한 EVM 바이트코드와 이더넷 RPC API 호환성을 제공하므로 개발자와 사용자가 기존 워크플로를 변경할 필요 없이 통합할 수 있습니다. EVM을 확장하려는 사람들이 자주 비판하는 것은 SVM이나 MoveVM과 같은 더 효율적인 대안이 있다는 것입니다. 하지만 소프트웨어 및 하드웨어 개선을 통해 EVM 성능을 극대화하면서 비용을 낮출 수 있다면 기존의 네트워크 효과, 개발자 도구, 쉽게 접근할 수 있는 자본 기반이 있기 때문에 EVM을 확장하는 것이 합리적일 수 있습니다.

모나드의 완전한 EVM 바이트코드 호환성을 통해 코드 변경 없이도 이더 메인, Arbitrum, OP 스택 등 다른 표준 EVM에서 애플리케이션과 프로토콜 인스턴스를 포팅할 수 있습니다. 이러한 호환성에는 장점과 단점이 있습니다. 가장 큰 장점은 기존 팀이 애플리케이션을 모나드로 쉽게 이식할 수 있다는 것입니다. 또한 모나드용 애플리케이션을 새로 만드는 개발자는 하드햇, 에이풕스, 파운드리, 래비, 팬텀의 지갑과 이더스캔 등 EVM용으로 개발된 풍부한 자원, 인프라, 툴을 활용할 수 있습니다, 파섹, 듄 등 다양한 분석 및 인덱싱 제품을 제공합니다.

쉽게 이식할 수 있는 프로토콜과 앱의 단점 중 하나는 체인에서 느리고 비효율적인 포크와 앱 출시로 이어질 수 있다는 것입니다. 체인이 많은 제품을 제공하는 것도 중요하지만, 대부분은 다른 체인에서 접근할 수 없는 고유한 애플리케이션이어야 합니다. 예를 들어, 대부분의 체인은 유니스왑 V2 스타일이나 중앙화된 유동성 기반 AMM이 필요하지만, 사용자를 유치하려면 새로운 종류의 프로토콜과 애플리케이션도 유치해야 합니다. 기존의 EVM 도구와 개발자 리소스는 새롭고 독특한 애플리케이션을 구현하는 데 도움이 됩니다. 또한, 모나드 팀은 체인에서 새로운 프로토콜과 애플리케이션을 장려하기 위해 액셀러레이터부터 벤처 캐피탈 대회에 이르기까지 다양한 프로그램을 시행하고 있습니다.

(2) 생태계 개요

모나드는 높은 처리량과 최저 거래 수수료를 제공하므로 CLOB와 같은 특정 유형의 앱에 매우 적합합니다, 고속, 저비용 환경의 이점을 누리기에 이상적인 소비자 애플리케이션 및 DePIN과 같은 특정 유형의 앱에 적합합니다.

모나드에 적합한 특정 카테고리를 살펴보기 전에 애플리케이션이 L2가 아닌 L1에서 실행하거나 자체 L1/L2/애플리케이션 체인을 실행하는 이유를 이해하는 것이 도움이 될 수 있습니다.

 한편으로는 시끄러운 이웃을 상대할 필요가 없으므로 자신만의 L1, L2 또는 앱 체인을 시작하는 것이 유리할 수 있습니다. 블록 공간을 전적으로 소유할 수 있으므로 활동이 많은 기간 동안의 정체를 피하고 전체 네트워크 부하와 관계없이 일관된 성능을 유지할 수 있습니다. 이는 CLOB 및 소비자 애플리케이션에 특히 중요합니다. 혼잡한 기간 동안 트레이더는 거래를 실행하지 못할 수 있으며, 웹2.0 성능을 기대하는 일반 사용자는 속도 저하와 성능 저하로 인해 애플리케이션을 사용할 수 없게 될 수 있습니다.

반면, 자체 L1 또는 앱 체인을 출시하려면 일련의 검증자를 부트스트랩해야 하며, 무엇보다도 사용자가 체인을 사용하기 위해 유동성과 자본을 연결하도록 인센티브를 제공해야 합니다. 하이퍼리퀴드가 자체 L1을 성공적으로 출시하고 사용자를 유치한 반면, 실패한 팀도 많습니다. 온체인 구축을 통해 팀은 네트워크 효과의 혜택을 누릴 수 있고, 2차 및 3차 유동성 효과를 제공하며, 다른 탈중앙 금융 프로토콜 및 애플리케이션과 통합할 수 있습니다. 또한 효율적이고 효과적으로 수행하기 어려운 인프라에 집중하고 스택을 구축할 필요가 없습니다. 앱이나 프로토콜을 구축하는 것은 L1이나 앱 체인을 구축하는 것과는 매우 다르다는 점에 유의해야 합니다.

자체 L2를 시작하면 이러한 부담, 특히 클릭 투 배포 롤업 서비스 제공업체의 존재로 인해 검증자 세트 부트스트랩 및 인프라 구축과 관련된 기술적 문제를 일부 완화할 수 있습니다. 그러나 이러한 L2는 일반적으로 특별히 효율적이지 않으며(대부분 여전히 소비자 애플리케이션이나 CLOB에 대한 TPS를 지원하지 않음) 중앙 집중화와 관련된 위험이 있는 경우가 많습니다(대부분 여전히 0단계에 있음). 또한 낮은 활동 및 초당 사용자 작업 수(UOPS)와 같은 이동성 및 활동 파편화와 관련된 단점도 여전히 존재합니다.

*CLOB

완전한 온체인 오더북은 DEX 업계에서 벤치마크가 되었습니다. 이전에는 네트워크 수준의 제약과 병목현상으로 인해 불가능했지만, 최근 높은 처리량과 낮은 비용의 환경이 급증하면서 온체인 CLOB가 가능해졌습니다. 이전에는 높은 가스 수수료(체인에서 주문하는 데 비용이 많이 들기 때문에), 네트워크 혼잡(거래량 증가로 인한), 지연 시간 문제로 인해 온체인 오더북만을 기반으로 거래하는 것이 비현실적이었습니다. 또한, CLOB 매칭 엔진에 사용되는 알고리즘은 상당한 연산 리소스를 소모하기 때문에 온체인에서 구현하기 어렵고 비용이 많이 듭니다.

온체인 오더북을 기반으로 하는 모델은 기존 오더북의 장점과 거래 체결 및 매칭의 완전한 투명성을 결합한 모델입니다. 모든 주문, 거래, 매칭 엔진 자체가 블록체인에 존재하므로 거래 과정의 모든 단계에서 완벽한 가시성을 보장합니다. 이러한 접근 방식은 몇 가지 주요 이점을 제공합니다. 첫째, 거래 정산뿐만 아니라 모든 거래가 체인에 기록되므로 완전한 투명성을 제공하며, 완전한 감사가 가능합니다.

둘째, 주문 체결과 취소 단계에서 선점 거래의 기회를 줄여 MEV를 완화하여 시스템을 더 공정하고 조작에 더 강하게 만듭니다.

마지막으로, 전체 주문장과 매칭 프로세스가 온체인에 존재하므로 오프체인 운영자나 프로토콜 내부자를 신뢰할 필요가 없고 어떤 당사자도 주문 매칭이나 체결을 조작하기 어렵기 때문에 신뢰 가정을 제거하고 조작의 위험을 줄입니다. 반면, 오프체인 오더북은 이러한 측면이 타협되며 주문 배치 및 매칭 프로세스가 완전히 투명하지 않기 때문에 내부자가 거래를 선점하고 오더북 운영자를 조작할 수 있습니다.

온체인 주문장은 오프체인 주문장에 비해 장점이 있지만, AMM에 비해 상당한 장점도 있습니다.

AMM은 일반적으로 LVR과 IL로 인한 유동성 공급자의 손실로 인해 가격 하락을 겪지만, 온체인 주문장은 가격 변동에 취약합니다. 그리고 오래된 가격을 악용한 차익거래에 취약하지만, 온체인 오더북은 유동성 공급자가 IL 또는 LVR에 노출되지 않도록 합니다. 실시간 주문 매칭을 통해 오래된 호가를 방지하고 효율적인 호가 검색을 통해 차익거래 기회를 줄입니다. 그러나 AMM은 무허가 거래와 자산 상장을 가능하게 하여 신규 토큰과 비유동성 토큰의 가격 발견을 가능하게 하므로 더 위험하고 유동성이 낮은 자산에 유리합니다. 앞서 언급했듯이 모나드의 짧은 블록 시간을 고려할 때 LVR은 다른 대안보다 문제가 적다는 점에 유의해야 합니다.

관심해야 할 프로젝트로는 쿠루, 야마타, 컴포지트 랩스 등이 있습니다.

*DePIN

블록체인은 검열에 강한 글로벌 공유 상태와 빠른 거래 및 결제 시간으로 인해 본질적으로 결제를 처리하는 데 매우 적합합니다. 그러나 결제와 가치 이전을 효율적으로 지원하려면 체인은 저렴하고 예측 가능한 수수료와 빠른 완결성을 제공해야 합니다. 처리량이 높은 L1인 모나드는 높은 결제량뿐만 아니라 하드웨어를 효율적으로 검증하고 관리하기 위한 온체인 트랜잭션이 필요한 DePIN 애플리케이션과 같은 새로운 사용 사례를 지원할 수 있습니다.

역사적으로 대부분의 DePIN 앱은 여러 가지 이유로 솔라나에서 출시되었습니다. 솔라나는 현지화된 수수료 시장을 통해 나머지 체인이 혼잡할 때 저렴한 비용으로 거래를 제공할 수 있습니다. 무엇보다도 솔라나는 네트워크에 기존 DePIN 앱이 많기 때문에 많은 DePIN 앱을 유치하는 데 성공했습니다. 이전에는 느린 결제 속도와 높은 수수료로 인해 이더리움에서 DePIN 앱이 출시되지 않았습니다. 하지만 지난 몇 년 동안 DePIN의 인기가 높아지면서 솔라나는 낮은 수수료와 높은 처리량을 제공하는 경쟁자로 떠올랐고, 많은 DePIN 앱이 솔라나에서 출시하기로 선택하게 되었습니다. 점점 더 많은 DePIN 애플리케이션이 솔라나에서 출시하기로 선택함에 따라 툴킷과 프레임워크뿐만 아니라 비교적 대규모의 DePIN 개발자 및 애플리케이션 커뮤니티가 형성되었습니다. 이로 인해 더 많은 DePIN 앱이 이미 기술과 개발 리소스를 사용할 수 있는 곳에서 출시하는 것을 선택하게 되었습니다.

그러나 처리량이 많고 수수료가 저렴한 EVM 기반 경쟁사로서 모나드는 DePIN에 대한 관심과 앱을 끌어들일 수 있는 기회를 가지고 있습니다. 이를 위해 체인 및 생태계는 기존 및 신규 DePIN 애플리케이션을 유치하기 위한 프레임워크, 툴킷 및 생태계 계획을 개발하는 것이 중요합니다. 디핀 앱은 자체 네트워크(L2 또는 L1)를 구축하려고 시도할 수 있지만, 모나드는 네트워크 효과, 다른 앱과의 구성 가능성, 심층적인 이동성, 강력한 개발자 도구를 가능하게 하는 높은 처리량의 베이스레이어를 제공합니다.

주의해야 할 사항: SkyTrade

*소셜 및 소비자 앱

style="text-align: 왼쪽;">지난 몇 년 동안 금융 앱이 암호화폐 시장을 지배해 왔지만, 최근에는 소비자 및 소셜 앱이 점점 더 많은 관심을 받고 있습니다. 이러한 앱은 크리에이터와 사회적 자본을 활용하고자 하는 사람들에게 대안적인 수익 창출 수단을 제공합니다. 또한 검열에 강하고, 구성이 가능하며, 점점 더 금융화된 버전의 소셜 그래프와 경험을 제공하여 사용자가 자신의 데이터를 더 잘 제어하거나 적어도 데이터를 통해 더 많은 혜택을 얻을 수 있도록 하는 것을 목표로 합니다.

디핀 사용 사례와 마찬가지로 소셜 및 소비자 앱에는 결제와 가치 전송을 효율적으로 지원할 수 있는 체인이 필요하며, 따라서 기본 계층에서 저렴하고 예측 가능한 수수료와 빠른 완결성이 요구됩니다. 여기서 중요한 것은 지연 시간과 최종성입니다. 현재 웹 2.0 환경은 고도로 최적화되어 있기 때문에 대부분의 사용자는 이와 유사한 짧은 지연 시간을 기대합니다. 결제, 쇼핑, 소셜 상호 작용에서 느린 경험은 대부분의 사용자에게 불쾌감을 줄 수 있습니다. 탈중앙화된 소셜 미디어와 소비자 앱은 일반적으로 기존의 중앙화된 소셜 미디어와 소비자 앱에 밀리고 있다는 점을 고려할 때, 사용자와 관심을 끌기 위해서는 동등하거나 더 나은 경험을 제공해야 합니다.

Monad의 패스트 파이널리티 아키텍처는 사용자에게 짧은 지연 시간과 저렴한 비용의 경험을 제공하는 데 이상적으로 적합합니다.

관심할 프로젝트: Kizzy, Dusted

모나드에 구축된 CLOB, DePIN, 소비자/소셜 외에도 다음과 같은 프로젝트가 있습니다. 앱 외에도 애그리게이터, LSD 및 AI 제품과 같은 차세대 기반 앱에 대한 기대가 큽니다.

유니버설 체인은 사용자를 유치하고 유지하기 위해 광범위한 제품 기반을 갖춰야 하며, 이를 통해 사용자가 자신의 요구를 충족하기 위해 여러 체인으로 이동할 필요가 없도록 해야 합니다. 지금까지는 L2가 그러했습니다. 앞서 언급했듯이, 사용자는 옵션 거래나 무기한 계약에 대한 니즈를 Arbitrum에서 충족하는 동시에 소셜 및 소비자 애플리케이션에 참여하기 위해 Base로 연결해야 할 수도 있습니다.