Monad 입문 가이드: 병렬 EVM과 성능 향상을 빠르게 이해하기
작성: Decentralised.Co
번역: TechFlow
거래 확장성은 항상 뜨거운 주제였다. 지난 몇 주 동안 우리는 Monad가 TPS를 확장하는 데 어떻게 기여할 수 있는지에 대해 탐구해왔다.
다음은 Saurabh Deshpande가 작성한 Monad의 작동 원리에 대한 자세한 설명이다.
TPS는 우리가 매우 주목하는 지표다. 더 많은 사용자와 애플리케이션을 지원할 수 있기 때문에 우리의 체인이 더 높은 TPS를 지원하기를 원한다. 아래 차트는 이더리움과 L2들의 TPS 수치를 보여준다. 어떤 체인도 100 TPS라는 마크를 돌파한 적이 없다. 참고로 TPS는 규모를 측정하기 위한 일반적인 용어일 뿐이며 정확하지 않다. 모든 거래가 동일하지 않고 복잡성 면에서 다르기 때문이다. 하지만 간단함을 위해 우리는 TPS를 규모 측정 지표로 사용한다.
우리가 TPS를 늘리고 싶다면 어떻게 해야 할까?
-
첫 번째 방법은 솔라나(Solana)가 한 것처럼 완전히 새로운 시스템을 구축하는 것이다. 속도에 비해 EVM 호환성을 희생하며, 단일 스레드 실행 대신 다중 스레드 실행(멀티코어 CPU 대 단일 코어 CPU 생각)을 사용하고, 거래를 병렬화하며 다른 합의 메커니즘을 사용한다.
-
두 번째 방법은 오프체인에서 실행하고 중심화된 정렬기를 사용하여 이더리움을 확장하는 것이다.
-
세 번째 방법은 EVM을 개별 구성 요소로 분해하고 확장성을 높이기 위해 최적화하는 것이다.
Monad는 최근 2억 2,500만 달러를 조달한 새로운 EVM 호환 L1으로, 기존 것을 직접 사용하는 대신 처음부터 EVM을 재구축하고 있다. Monad는 확장성을 높이기 위해 이러한 세 번째 방법을 선택했다.
우리는 Monad가 가져온 여러 가지 중요한 변화에 대해 논의했다.
병렬 실행
이더리움 가상 머신(EVM)은 거래를 순차적으로 실행한다. 하나의 거래를 실행하기 전에 다음 거래는 반드시 기다려야 한다. 이렇게 생각해보자. 오토바이 조립 공장에 플랫폼 하나가 있다고 하자. 여러 트럭들이 오토바이 부품들을 운반해 온다(각 트럭은 50대의 오토바이를 조립하는 데 필요한 모든 부품을 가지고 있음). 조립 공장에서는 하역, 분류, 조립, 적재의 네 가지 서로 다른 기능을 수행한다.
현재의 EVM 설정에서는 하나의 플랫폼만 있고 하역 및 적재가 같은 위치에서 이루어진다. 따라서 트럭이 주차하면 오토바이 부품들이 하역되고, 분류되며, 조립되고, 다시 같은 트럭에 적재된다. 분류 팀이 작업 중일 때 다른 팀들은 모두 대기한다. 즉, 각 팀의 작업을 서로 다른 슬롯으로 본다면, 각 팀은 네 슬롯 중 한 번만 작업하게 된다. 이는 상당한 비효율성을 초래하며, 더욱 원활한 접근 방식의 필요성을 강조한다.
이제 하역 및 적재 지역이 각각 따로 있는 네 개의 플랫폼이 있다고 상상해보자. 하역팀은 한 번에 한 대의 트럭만 처리할 수 있지만, 다음 세 슬롯을 기다릴 필요가 없다. 바로 다음 트럭으로 이동할 수 있다.
분류, 조립, 적재 팀들도 마찬가지다. 하역이 끝나면 트럭은 조립된 오토바이를 적재할 적재 구역으로 이동한다. 따라서 하나의 플랫폼과 하역/적재 구역만 있는 창고는 모든 작업을 순차적으로 수행하지만, 네 개의 플랫폼과 별도의 하역/적재 구역을 갖춘 창고는 작업을 병렬화한다.
Monad를 여러 대의 트럭 플랫폼을 갖춘 창고와 같은 인프라로 생각하자. 그러나 이는 단순하지 않다. 트럭들 사이에 의존성이 있을 경우 복잡성이 증가한다. 예를 들어, 어떤 트럭이 50대의 오토바이를 조립하는 데 필요한 모든 부품을 갖고 있지 않다면 어떻게 될까? 거래들이 항상 독립적인 것은 아니다. 따라서 Monad가 이를 병렬 실행할 때 서로 의존하는 거래들을 처리해야 한다.
어떻게 처리할까? 이 프로토콜은 낙관적 병렬 실행(optimistic parallel execution)이라는 방식을 사용한다. 프로토콜은 독립적인 거래들만 병렬로 실행할 수 있다. 예를 들어 Joel의 잔액이 1ETH인 상태에서 다음 4건의 거래를 고려해보자.
-
Joel이 Saurabh에게 0.2 ETH를 송금함
-
Sid이 NFT를 민팅함
-
Joel이 Sid에게 0.1 ETH를 송금함
-
Shlok이 PEPE를 구매함
이 모든 거래는 병렬로 실행되며, 미결 결과들이 차례로 제출된다. 미결 결과의 출력이 어떤 거래의 원래 입력과 충돌하면 해당 거래를 다시 실행한다. 거래 2와 4는 다른 거래들과 입력이 충돌하지 않는 미결 결과를 가지므로 서로 독립적이다. 그러나 거래 1과 3은 독립적이지 않다.
모든 4개의 거래가 동일한 상태(즉, Joel의 잔액이 1ETH)에서 시작된다는 점에 유의하자. Joel이 0.2 ETH를 송금한 후 잔액은 0.8 ETH가 된다. Joel이 Sid에게 0.1 ETH를 송금한 후에는 그의 잔액이 0.9 ETH가 된다. 결과는 충돌이 없도록 차례로 제출된다. 1번 거래의 미결 결과를 제출한 후 Joel의 새 잔액은 0.8 ETH가 된다.
이 출력은 3번 거래의 입력과 충돌한다. 따라서 이제 3번 거래는 입력값이 0.8 ETH인 상태에서 다시 실행된다. 3번 거래를 실행한 후 Joel의 잔액은 0.7 ETH가 된다.
MonadDb
여기서 자연스럽게 떠오르는 질문은 대부분의 거래를 다시 실행하지 않아도 되는 이유를 어떻게 알 수 있느냐는 것이다. 답은 다시 실행하는 것이 병목이 아니라는 데 있다. 병목은 바로 이더리움의 메모리를 접근하는 데 있다. 사실 이더리움이 데이터베이스에 상태를 저장하는 방식은 상태 접근을 어렵게 만들며(시간이 오래 걸리고 따라서 비용이 많이 든다). 이것이 바로 Monad의 또 다른 개선점인 MonadDb가 등장하는 지점이다. Monad는 읽기 작업과 관련된 오버헤드를 줄이는 방식으로 데이터베이스를 구축한다.
거래가 다시 실행되어야 할 때, 모든 입력은 전체 상태보다 접근이 훨씬 쉬운 캐시 메모리에 이미 존재한다.
솔라나는 테스트넷에서 5만 TPS를 기록했지만 현재 메인넷에서는 약 1천 TPS 정도다. Monad는 내부 테스트넷에서 이미 1만 실제 TPS를 달성했다고 주장한다. 비록 이것이 항상 실제 성능을 의미하진 않지만, 우리는 Monad가 실제 환경에서 어떻게 작동하는지 보기 위해 기대감을 감추지 못하고 있다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@Decentralisedco
