Monad 시작 가이드: 병렬 EVM 및 성능 개선을 빠르게 이해하기

트랜잭션 확장성은 항상 뜨거운 주제였습니다. 지난 몇 주 동안 우리는 모나드가 TPS 확장에 어떻게 도움이 될 수 있는지 탐구해 왔습니다.

다음은 Saurabh Deshpande가 작성한 Monad의 작동 방식에 대한 자세한 설명입니다.

모나드의 작동 원리에 대한 자세한 설명

TPS는 우리가 주목하는 지표입니다. 우리는 체인이 더 많은 사용자와 애플리케이션을 지원할 수 있기 때문에 더 높은 TPS를 지원할 수 있기를 바랍니다. 아래 차트는 Ethereum과 L2의 TPS 수치를 보여줍니다. 어떤 체인도 100TPS를 돌파한 적이 없습니다. TPS는 규모를 측정하는 데 사용되는 일반적인 용어입니다. TPS는 모든 트랜잭션이 동일하지 않고 복잡도가 다르기 때문에 부정확합니다. 그러나 단순화를 위해 TPS를 규모의 척도로 사용합니다.

TPS를 높이려면 어떻게 해야 할까요?

• 첫 번째 방법은 솔라나처럼 완전히 새로운 시스템을 구축하는 것입니다. 속도에 비해 EVM 호환성이 희생됩니다. 단일 스레드 실행(멀티 코어 CPU와 단일 코어 CPU 비교) 대신 멀티 스레드 실행을 사용하고 트랜잭션을 병렬화하며 다른 합의 메커니즘을 사용합니다.

• 두 번째 접근 방식은 오프체인 실행을 사용하고 중앙 집중식 시퀀서로 이더리움을 확장하는 것입니다.

• 세 번째 접근 방식은 EVM을 별도의 구성 요소로 분해하고 최적화하여 확장성을 향상시키는 것입니다.

Monad는 최근 EVM을 직접 사용하는 대신 처음부터 EVM을 구축하는 2억 2,500만 달러를 모금한 새로운 EVM 호환 L1입니다. 확장성을 높이기 위해 이 세 번째 접근 방식을 선택했습니다.

우리는 Monads가 가져온 몇 가지 주요 변경 사항에 대해 논의했습니다.

병렬 실행

이더리움 가상 머신(EVM)은 트랜잭션을 순차적으로 실행합니다. 하나의 트랜잭션이 실행되기 전에 다음 트랜잭션이 기다려야 합니다. 이렇게 생각해보세요. 오토바이 조립 공장의 플랫폼을 생각해 보세요. 여러 대의 트럭이 오토바이 부품을 배송합니다(각 트럭에는 오토바이 50대를 조립하는 데 필요한 모든 부품이 포함되어 있습니다). 조립 공장에서는 하역, 분류, 조립, 적재라는 네 가지 기능을 수행합니다.

현재 EVM 설정에는 플랫폼이 하나만 있으며 로드 및 언로드에 동일한 위치가 사용됩니다. 따라서 트럭이 주차되어 있는 동안 오토바이 부품은 동일한 트럭에 하역, 분류, 조립 및 적재됩니다. 분류팀이 작업하는 동안 다른 팀이 기다리고 있습니다. 따라서 작업을 별도의 슬롯으로 생각하면 각 팀은 4개의 슬롯에 한 번만 작업합니다. 이로 인해 상당한 비효율성이 발생하므로 보다 효율적인 접근 방식이 필요합니다.

이제 4가지 서로 다른 적재 및 하역 영역이 있는 플랫폼을 상상해 보세요. 하역 팀이 한 번에 한 대의 트럭만 작업할 수 있더라도 다음 세 개의 트럭을 기다릴 필요는 없습니다. 다음 트럭으로 직접 이동할 수 있습니다.

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

모나드를 여러 트럭 플랫폼이 있는 창고와 같은 인프라로 생각하세요. 그러나 그것은 간단하지 않습니다. 트럭에 의존하면 복잡성이 증가합니다. 예를 들어, 트럭 한 대에 오토바이 50대를 조립할 부품이 모두 없으면 어떻게 됩니까? 거래가 항상 독립적인 것은 아닙니다. 따라서 모나드는 병렬로 실행할 때 서로 의존하는 트랜잭션을 처리해야 합니다.

어떻게 처리하나요? 낙관적 병렬 실행이라는 방법을 구현합니다. 프로토콜은 독립적인 트랜잭션만 병렬로 실행할 수 있습니다. 예를 들어, Joel의 잔액이 1 ETH인 4개의 거래를 생각해 보세요.

• Joel은 Saurabh에게 0.2 이더를 보냅니다

• Sid는 NFT를 발행합니다

• Joel은 Sid

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

4개의 거래가 모두 동일한 상태에서 시작되므로 초점은 Joel의 잔액인 1ETH에 맞춰져 있습니다. Joel이 0.2 ETH를 보낸 후 잔액은 0.8 ETH였습니다. Joel이 Sid에게 0.1 ETH를 보낸 후 그의 잔액은 0.9 ETH입니다. 결과는 하나씩 제출되므로 출력이 입력과 충돌하지 않는지 확인됩니다. 보류 결과 1을 제출한 후 Joel의 새 잔액은 0.8 ETH입니다.

이 출력은 세 번째 트랜잭션의 입력과 충돌합니다. 이제 0.8 ETH를 입력하여 3이 다시 실행됩니다. 3번을 실행한 후 Joel의 잔액은 0.7ETH입니다.

MonadDb

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

트랜잭션을 다시 실행해야 할 때 모든 입력은 이미 캐시 메모리에 있으므로 전체 상태에 비해 액세스하기 쉽습니다.

Solana의 테스트넷에는 50,000 TPS가 있었지만 현재 메인넷에는 약 1,000 TPS만 있습니다. Monad는 내부 테스트넷에서 10,000개의 실제 TPS를 달성했다고 주장합니다. 이것이 항상 실제 성능을 나타내는 것은 아니지만 Monad가 실제 응용 프로그램에서 어떻게 작동하는지 보고 싶습니다.

위 내용은 Monad 시작 가이드: 병렬 EVM 및 성능 개선을 빠르게 이해하기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!