모나드 자세히 알아보기: 트랜잭션 속도를 재정의한 EVM 혁신

저자: Decentralised.Co 출처: X, @Decentralisedco 번역: 굿오바, 골든파이낸스

트레이딩 확장성은 업계에서 뜨거운 논의 주제였습니다. 지난 몇 주 동안 모나드가 트랜잭션 처리 속도(TPS)를 높이는 데 어떻게 도움이 될 수 있는지 살펴봤습니다. 이 글에서는 모나드의 작동 원리를 자세히 설명합니다.

TPS는 우리가 오랫동안 주시해 온 지표입니다. 저희는 블록체인이 더 많은 사용자와 애플리케이션을 수용할 수 있도록 더 높은 TPS를 지원할 수 있기를 바랍니다. 아래 차트는 이더와 L2의 TPS 수치를 보여줍니다. 지금까지 100 TPS를 돌파한 체인은 없습니다. TPS는 확장성을 측정하는 데 사용되는 일반적인 용어라는 점에 유의하는 것이 중요합니다. 모든 트랜잭션이 똑같이 복잡한 것은 아니기 때문에 단순한 TPS 수치는 정확하지 않습니다. 하지만 편의상 TPS를 확장성의 척도로 간주하겠습니다.

TPS를 개선하는 방법에는 어떤 것이 있나요?

한 가지 방법은 속도를 위해 EVM과의 호환성을 희생하는 Solana처럼 완전히 새로운 시스템을 처음부터 다시 구축하는 것입니다. 솔라나는 싱글 스레드 실행 대신 멀티 스레드 실행을 사용하고(멀티 코어 CPU와 싱글 코어 CPU에 비유), 트랜잭션을 병렬로 처리하며, 다른 합의 메커니즘을 사용합니다.

두 번째 접근 방식은 오프체인 실행과 중앙화된 시퀀서를 사용해 이더를 확장하는 것입니다.

세 번째 접근 방식은 EVM을 개별 구성 요소로 분해하고 확장성을 최적화하는 것입니다.

2억 2,500만 달러의 투자를 유치한 EVM 호환 L1 블록체인의 신생 기업 모나드(Monad)는 기존 버전을 사용하는 대신 EVM을 처음부터 다시 구축하기로 결정하고 확장성을 개선하기 위해 세 번째 접근 방식을 택했습니다.

아래에서 모나드가 도입한 몇 가지 큰 변화에 대해 설명합니다.

병렬 실행

이더넷 가상 머신(EVM)은 트랜잭션을 순차적으로 실행합니다. 이전 트랜잭션이 실행될 때까지 다음 트랜잭션은 대기해야 합니다. 예를 들어 오토바이 조립 창고를 위한 플랫폼을 상상해 보겠습니다. 여러 대의 트럭이 오토바이 부품을 가져옵니다(각 트럭에는 오토바이 50대를 만드는 데 필요한 모든 부품이 들어 있습니다). 조립 창고에는 하역, 분류, 조립, 적재 등 네 가지 기능이 있으며 각 기능은 전담 팀에서 처리합니다.

현재 조립 창고에는 현재 EVM 설정에서는 플랫폼이 하나만 있고 적재와 하역에 동일한 위치가 사용됩니다. 따라서 트럭이 멈추면 오토바이 부품을 내리고 분류하고 조립하여 같은 트럭에 적재합니다. 분류 팀이 작업하는 동안 다른 팀은 기다리고 있습니다. 따라서 각 팀의 작업을 다른 슬롯으로 간주하면 각 팀은 네 개의 슬롯에 한 번씩만 작업하게 됩니다. 이는 심각한 비효율로 이어지며 보다 능률적인 접근 방식의 필요성을 강조합니다.

이제 로딩과 언로딩 영역이 분리된 4개의 플랫폼을 상상해 보겠습니다. 하역팀이 한 번에 한 대의 트럭만 처리할 수 있어도 다음 세 대의 트럭이 작업할 때까지 기다릴 필요가 없습니다. 바로 다음 트럭으로 이동하여 작업을 시작할 수 있습니다.

분류, 조립, 적재 팀도 마찬가지입니다. 트럭은 하역이 끝나면 적재 구역으로 이동하여 적재 팀이 조립된 오토바이를 적재할 때까지 기다립니다. 따라서 플랫폼과 적재 구역이 하나인 창고에서는 모든 작업을 순차적으로 수행하지만, 플랫폼이 4개이고 적재 구역이 다른 창고에서는 작업을 병렬로 처리할 수 있습니다.

Monad를 여러 트럭 플랫폼이 있는 창고 인프라로 생각할 수도 있지만, 이 예시보다 훨씬 더 복잡합니다. 트럭 간에 종속성이 있을 때 복잡성은 더욱 증가합니다. 예를 들어 트럭에 오토바이 50대를 제작하는 데 필요한 모든 부품이 없다면 어떻게 될까요? 트랜잭션이 항상 독립적인 것은 아닙니다. 따라서 모나드는 트랜잭션을 병렬로 실행할 때 상호 의존적인 트랜잭션을 처리해야 합니다.

이것은 어떻게 할까요? 이는 낙관적 병렬 실행이라는 연산을 수행합니다. 이 프로토콜은 독립적인 트랜잭션만 병렬로 실행할 수 있습니다. 예를 들어, 조엘의 잔액이 1 이더인 4개의 트랜잭션을 생각해봅시다:

• 조엘은 0.2 이더를 사우라브에게 보냅니다.

• 조엘은 0.2 이더를 사우라브에게 보냅니다. li>

  Sid가 NFT를 캐스팅합니다.

• Jor가 Sid에게 0.1 ETH를 보냅니다.

• Jor가 Saurabh에게 0.2 ETH를 보냅니다. align: left;">슬로크가 PEPE를 구매합니다.

이 모든 트랜잭션은 하나씩 제출되는 대기 중인 결과와 병행하여 실행됩니다. 보류 중인 결과 출력이 트랜잭션의 원래 입력과 충돌하는 경우 트랜잭션이 다시 실행됩니다. 트랜잭션 2와 4는 서로 독립적이므로 보류 중인 결과가 다른 트랜잭션의 입력과 충돌하지 않습니다. 그러나 트랜잭션 1과 4는 독립적이지 않습니다.

4개의 트랜잭션 모두 동일한 초기 상태(조엘의 잔고 1ETH)로 시작하므로 여기서는 조엘의 잔고에 초점을 맞추고 있습니다. 0.2 이더를 전송한 후 조엘의 잔액은 0.8 이더가 되고, 0.1 이더를 시드에게 전송한 후 잔액은 0.9 이더가 됩니다. 결과가 입력과 충돌하지 않는지 확인하기 위해 결과가 하나씩 제출됩니다. 1에 대한 보류 중인 결과가 제출된 후 조엘의 새 잔액은 0.8 ETH가 됩니다.

이 출력은 3에 대한 입력과 충돌합니다. 이제 입력값 0.8 ETH로 3을 다시 실행합니다. 3을 실행하면 조엘의 잔액이 0.7 ETH로 변경됩니다.

MonadDb

이 시점에서 분명한 질문은 대부분의 트랜잭션을 다시 실행할 필요가 없다는 것을 어떻게 알 수 있는가 하는 것입니다. 답은 재실행이 병목 현상이 아니라는 사실에 있습니다. 병목 현상은 이더의 메모리에 액세스하는 것입니다. 이더가 데이터베이스에 상태를 저장하는 방식 때문에 액세스가 어렵고(시간과 비용이 많이 들기 때문입니다). 여기서 또 다른 모나드의 개선 사항인 MonadDb가 등장합니다. 모나드는 읽기 작업과 관련된 오버헤드를 줄이는 방식으로 데이터베이스를 구축했습니다.

트랜잭션을 다시 실행해야 할 때 모든 입력은 이미 캐시 메모리에 캐시되어 있으므로 전체 상태에 액세스하는 것보다 훨씬 더 빠르게 액세스할 수 있습니다.

솔라나는 테스트 네트워크에서 50만 TPS를 달성했지만 메인 네트워크에서는 약 1천 TPS에 불과하며, 모나드는 내부 테스트 네트워크에서 실제 1만 TPS를 달성했다고 주장합니다. 이것이 항상 실제 성능을 나타내는 것은 아니지만, 모나드가 실제 환경에서 어떤 성능을 발휘하는지 기대가 됩니다!