메가이더스는 정말 실시간 블록체인인가요?

저자: knower, Crypto KOL; 번역: Golden Finance xiaozou

1, MegaETH

strong>소개

이 글의 대부분은 메가ETH 백서에 대한 제 개인적인 생각의 일부이며, 제가 할 수 있는 범위 내에서 여기에서 더 확장할 수 있습니다. 이 기사가 어떻게 마무리되든, 새로운 것을 배우시길 바랍니다.

MegaETH의 웹사이트는 눈에 띄는 색감의 기계 토끼가 그려져 있어 멋집니다. 그 전에는 깃허브가 하나밖에 없었는데, 웹사이트가 생기면서 모든 것이 훨씬 쉬워졌습니다.

메가이더리움 깃허브를 둘러보고 일종의 실행 레이어를 개발하고 있다는 사실을 알게 되었지만, 솔직히 말해서 제가 틀렸을 수도 있다고 말씀드리고 싶습니다. 사실 저는 메가ETH에 대해 충분히 알지 못하는데, 이제 그들은 이더리움의 화두가 되고 있습니다.

멋진 사람들이 보고 있는 것과 같은 기술을 제가 보고 있는지 확인하려면 모든 것을 알아야 합니다.

메가ETH 백서에 따르면 이들은 암호화폐 세계에 웹2.0과 같은 성능을 제공하는 것을 목표로 하는 EVM 호환 실시간 블록체인입니다. 초당 10만 건 이상의 트랜잭션, 1밀리초 미만의 블록 시간, 1센트 거래 수수료와 같은 속성을 제공하여 이더리움 L2 경험을 향상시키는 것을 목표로 합니다.

이 백서는 암호화폐 업계에서 L2의 증가(이전 게시물에서 논의했지만, 현재 50개 이상으로 늘어났으며 "개발 중인" L2가 더 많습니다)와 PMF의 부족을 강조하고 있습니다. 이더와 솔라나는 가장 인기 있는 블록체인이며, 사용자들은 둘 중 하나에 매력을 느끼고 채굴할 토큰이 있는 경우에만 다른 L2를 선택할 것입니다.

저는 L2가 너무 많다고 해서 반드시 좋은 것이라고 생각하지 않는 것처럼 나쁜 것이라고 생각하지 않지만, 한 발짝 물러서야 할 필요가 있다는 것을 인식하고 있습니다. 한 발 물러서서 업계가 왜 그렇게 많은 L2를 만드는지 검토해야합니다.

Occam의 Razor는 VC가 다음 L2 (또는 L1) 왕을 만들 수있는 진정한 기회가 있다는 느낌을 즐기고 있으며 이러한 프로젝트에 투자함으로써 만족을 얻고 있다고 말하고 싶습니다. 만족감을 얻고 있지만, 많은 암호화폐 개발자들은 실제로 더 많은 L2를 원할 수도 있다고 생각합니다. 양쪽 모두 옳을 수 있지만 어느 쪽이 더 옳다는 결론은 무의미하며 현재 인프라 생태계를 객관적으로 바라보고 우리가 가진 것을 활용하는 것이 가장 좋습니다.

현재 사용 가능한 L2의 성능은 높지만 충분하지 않습니다. MegaETH의 백서에 따르면 opBNB의 (상대적으로) 높은 100 MGas/s를 사용하더라도 이는 초당 650개의 유니스왑 트랜잭션에 불과하다고 합니다. -최신 또는 웹2.0 인프라는 초당 1백만 건의 트랜잭션을 처리할 수 있습니다.

암호화폐의 탈중앙화 특성과 무허가 결제를 가능하게 하는 장점에도 불구하고 여전히 속도가 상당히 느립니다. 블리자드와 같은 게임 개발사가 오버워치를 체인에 도입하려면 실시간 PvP와 웹2.0 게임이 자연스럽게 제공하는 기타 기능을 제공하려면 훨씬 더 높은 클릭률이 필요합니다.

L2 수렁에 대한 메가이더스의 해결책 중 하나는 보안과 검열 저항을 각각 이더리움과 아이젠다에 위임하여 메가이더스를 아무런 트레이드오프 없이 세계 최고 성능의 L2로 전환하는 것이었습니다.

L1은 일반적으로 전문화할 여지가 없이 동일한 작업을 수행하는 동형 노드를 필요로 합니다. 이 경우 전문화란 정렬이나 증명과 같은 작업을 의미하며, L2는 이기종 노드의 사용을 허용하고 작업을 분리하여 확장성을 개선하거나 이러한 부담을 일부 완화함으로써 이 문제를 우회합니다. 이는 아스트리아나 에스프레소 같은 공유 시퀀서의 인기 증가와 Succinct나 Axiom 같은 전문화된 zk 증명 서비스의 부상에서 확인할 수 있습니다.

"실시간 블록체인을 생성하려면 기성 이더리움 실행 클라이언트를 사용하고 시퀀서 하드웨어를 추가하는 것 이상의 작업이 필요합니다. 예를 들어, 저희의 성능 실험에 따르면 512GB RAM이 장착된 강력한 서버를 사용하더라도 최근 이더 블록의 실시간 동기화 설정에서 Reth는 약 1000 TPS만 달성할 수 있으며, 이는 약 100 MGas/s에 해당합니다. "

MegaETH는 "활성" 시퀀서만 사용하여 일반적인 트랜잭션 실행의 합의 오버헤드를 제거함으로써 전체 노드에서 트랜잭션 실행을 추상화하여 이 부분을 확장합니다. "활성" 시퀀서만 사용하여 일반적인 트랜잭션 실행의 합의 오버헤드를 제거하여 트랜잭션 실행을 추상화합니다. "대부분의 풀 노드는 이 시퀀서로부터 p2p 네트워크를 통해 상태 차이를 수신하고, 그 차이를 직접 적용하여 로컬 상태를 업데이트합니다. 특히 트랜잭션을 재실행하지 않고, 대신 증명자(prover)가 제공한 증명을 사용해 블록을 간접적으로 검증합니다. "

"빠르다" 또는 "저렴하다"는 의견 외에는 메가테크에 대해 많이 읽지 못했습니다. MegaETH가 얼마나 좋은지에 대한 분석을 많이 읽지 못했기 때문에 아키텍처를 자세히 분석하고 다른 L2와 비교해보려고 합니다.

MegaETH는 오늘날 상당히 표준적인 관행인 데이터 가용성을 처리하기 위해 EigenDA를 사용합니다. Conduit과 같은 서비스형 롤업(RaaS: 롤업 서비스) 플랫폼에서는 롤업을 위한 데이터 가용성 공급자로 Celestia, EigenDA, 심지어 이더리움(원하는 경우)을 선택할 수 있습니다. 이 둘의 차이는 상당히 기술적이고 완전히 관련이 없으며, 어느 쪽을 선택하느냐는 다른 무엇보다도 공감을 바탕으로 결정되는 것 같습니다.

시퀀서는 트랜잭션을 주문하고 궁극적으로 실행하지만 블록, 증인, 상태 차이를 게시하는 역할도 담당합니다. L2 컨텍스트에서 증인은 증명자가 시퀀서 블록의 유효성을 검사하기 위해 사용하는 추가 데이터입니다.

상태 차이는 블록체인의 상태에 대한 변경으로, 기본적으로 체인에서 일어나는 모든 일이 될 수 있습니다. 블록체인은 상태에 추가되는 새로운 정보를 지속적으로 추가하고 검증하는 기능을 하며, 이러한 상태 차이의 기능은 전체 노드가 거래를 확인할 수 있도록 허용하는 것입니다. 트랜잭션을 재실행하지 않고도 트랜잭션을 확인할 수 있습니다.

프로버는 블록 내용을 검증하기 위해 암호학적 증명을 계산하는 특수 하드웨어로 구성됩니다. 또한 노드가 중복 실행을 피할 수 있도록 합니다. 영지식 증명과 부정 증명(또는 낙관적 증명)이 있습니다. 가 있지만, 현재로서는 그 차이는 중요하지 않습니다.

이 모든 것을 종합하는 것은 증명자, 시퀀서, 아이겐다 사이의 일종의 집계자 역할을 하는 완전 노드 네트워크의 임무이며, (희망적으로) 메가 이더의 마법을 현실화할 수 있게 해줄 것입니다.

MegaETH의 설계는 EVM에 대한 근본적인 오해에 기반하고 있습니다. L2는 종종 성능(처리량) 저하를 EVM 탓으로 돌리지만, 레브엠이 14000 TPS에 도달할 수 있다는 사실이 밝혀졌습니다. EVM이 아니라면 무엇 때문일까요?

2, 현재 확장성 문제

성능 병목현상을 유발하는 3가지 주요 EVM 비효율성은 병렬 실행 부족, 인터프리터 오버헤드, 높은 상태 액세스 지연시간입니다. .

메가이더는 풍부한 RAM으로 인해 전체 블록체인의 상태를 저장할 수 있으며, 이더의 정확한 RAM이 100GB인 것에 비해 이 설정은 SSD 읽기 지연 시간을 제거하여 상태 액세스를 크게 가속화합니다.

SSD 읽기 지연 시간에 대해서는 잘 모르겠지만, 아마도 일부 연산코드는 다른 연산코드보다 밀도가 높기 때문에 RAM을 더 투자하면 문제를 해결할 수 있을 것입니다. 이것이 여전히 대규모로 작동하나요? 잘 모르겠지만 이 글의 목적상 사실로 받아들이겠습니다. 저는 여전히 체인이 처리량, 트랜잭션 비용, 지연 시간을 동시에 결정할 수 있다는 것에 회의적이지만, 적극적으로 배우려고 노력하고 있습니다.

또 한 가지 말씀드리고 싶은 것은 너무 비판적이 되고 싶지 않다는 것입니다. 한 프로토콜을 다른 프로토콜보다 더 많이 지지하거나 처음부터 동일한 비중을 두지 않겠다는 생각입니다. 단지 이해를 돕고 이 글을 읽는 모든 사람이 동시에 동일한 이해를 얻을 수 있도록 하기 위해 이렇게 하는 것입니다.

병렬 EVM에 대한 추세에 익숙하실 수도 있지만 문제가 있는 것으로 알려졌습니다. 블록-STM 알고리즘을 EVM으로 포팅하는 데 진전이 있었지만 "실제 프로덕션에서 달성할 수 있는 속도 향상은 본질적으로 워크로드에서 사용할 수 있는 병렬성에 의해 제한된다"고 합니다. 즉, 병렬 EVM이 출시되어 최종적으로 메인 네트워크의 EVM 체인에 배포되더라도 대부분의 트랜잭션이 병렬로 실행될 필요가 없다는 근본적인 현실에 의해 기술이 제한된다는 것입니다.

거래 B가 거래 A의 결과에 의존하는 경우 두 개의 거래를 동시에 실행할 수 없습니다. 이 경우처럼 블록 트랜잭션의 50%가 상호 의존적이라면 병렬 실행은 주장한 것만큼 큰 개선이 되지 않습니다. 이는 다소 지나치게 단순화되어 있지만(어쩌면 약간 부정확할 수도 있습니다), 핵심을 짚어낸 것이라고 생각합니다.

revm과 네이티브 실행 간의 차이는 매우 분명하며, 특히 revm은 독립형 VM 환경으로서 가치가 있기에는 여전히 1~2 OOM이 너무 느립니다. 또한 revm의 사용을 보증할 만큼 컴퓨팅 집약적인 계약이 충분하지 않다는 사실도 밝혀졌습니다. "예를 들어, 과거 동기화 중 옵코드당 소요 시간을 분석한 결과, revm에서 약 50%의 시간이 "호스트 "에 소요되는 것으로 나타났습니다.". strong> 및 "시스템 " 옵코드에 사용됩니다."

상태 동기화와 관련하여 MegaETH는 더 많은 문제를 발견했습니다. 상태 동기화는 간단히 말해 전체 노드를 시퀀서 활동과 동기화하는 과정으로 설명할 수 있으며, 이는 MegaETH와 같은 프로젝트의 대역폭을 빠르게 소모할 수 있는 작업입니다. 예를 들어 초당 100,000개의 ERC20 전송을 동기화하는 것이 목표라면, 약 152.6Mbps의 대역폭을 소비하게 됩니다. 이 152.6Mbps는 메가이더스의 예측(또는 성능)을 초과하는 것으로, 사실상 불가능한 작업이라고 할 수 있습니다.

이것은 단순한 토큰 전송만을 고려한 것이며, 트랜잭션이 더 복잡할 경우 더 높은 소비가 발생할 가능성을 무시한 것입니다. 이는 실제 온체인 활동의 다양성을 고려할 때 가능한 시나리오이며, 메가이더스는 유니스왑 트랜잭션이 8개의 스토리지 슬롯을 수정(ERC20 전송은 3개의 스토리지 슬롯만 수정)하여 총 대역폭 소비량이 476.1Mbps로 훨씬 덜 실현 가능한 목표라고 기록했습니다.

100k TPS 고성능 블록체인을 달성하는 데 있어 또 다른 문제는 라이트 클라이언트에 저장 증명 전송을 관리하는 작업인 체인 상태 루트 업데이트의 해결에 있습니다. 전문화된 노드가 있더라도 풀 노드는 여전히 네트워크의 시퀀서 노드를 사용하여 상태 루트를 유지해야 합니다. 초당 100,000개의 ERC20 전송을 동기화하는 위의 문제를 예로 들면, 초당 300,000개의 키를 업데이트하는 비용이 발생합니다.

이더는 MPT(머클 패트리샤 트리: 머클 접두사 트리) 데이터 구조를 사용해 각 블록 이후의 상태를 계산합니다. 초당 300,000개의 키를 업데이트하기 위해 이더는 "캐시되지 않은 데이터베이스 읽기 6백만 건을 변환"해야 하는데, 이는 현재 소비자 등급의 SSD가 처리할 수 있는 것보다 훨씬 많은 양이며, 메가ETH는 쓰기(또는 유니스왑 거래와 같은 온체인 거래의 추정치)도 포함되지 않은 수치이므로 이 도전은 시지프스의 도전에 가깝다고 할 수 있습니다. 우리 대부분이 선호하는 언덕을 오르는 전투보다는 시지프스의 끝없는 노력에 더 가까운 도전입니다.

블록체인의 한계에 도달했다는 또 다른 문제도 있습니다. 블록체인의 속도는 실제로 블록체인의 보안과 신뢰성을 높이기 위해 자체적으로 부과된 장벽인 블록가스 한계에 의해 제한됩니다. "블록 가스 한도를 설정하는 경험 법칙은 이 한도 내에서 모든 블록이 블록 시간 내에 안전하게 처리될 수 있도록 하는 것이 중요합니다." 백서에서는 블록 가스 한도를 최소 하드웨어 요구 사항을 충족한다는 가정 하에 노드가 안정적으로 속도를 유지할 수 있도록 보장하는 "스로틀링 메커니즘"으로 설명합니다.

블록가스 제한이 최악의 시나리오에 대비하기 위한 보수적인 선택이라고 말하는 사람들도 있는데, 이는 최신 블록체인 아키텍처가 확장성보다 보안을 중요시한다는 또 다른 예입니다. 확장성이 보안보다 더 중요하다는 생각은 매일 블록체인 간에 얼마나 많은 돈이 전송되는지, 그리고 확장성을 조금 높이기 위해 그 돈이 손실되어 핵 겨울로 이어질 경우 어떤 일이 벌어질지 생각해 보면 무너지게 됩니다.

블록체인은 고품질 소비자 앱을 유치하는 데는 탁월하지 않을 수 있지만, 라이선스가 필요 없는 P2P 결제에는 매우 뛰어납니다. 누구도 이를 망치고 싶지 않을 것입니다.

그런 다음 병렬 EVM 속도는 워크로드에 따라 달라지며, 블록체인 기능을 최소화하여 지나치게 '가속'된 "긴 의존성 체인"으로 인해 성능에 병목 현상이 발생한다는 점이 있습니다. 병목 현상. 이 문제를 해결할 수 있는 유일한 방법은 다차원 가스 가격 책정(MegaETH는 솔라나의 로컬 수수료 시장을 의미함)을 도입하는 것인데, 이는 아직 구현하기 어렵습니다. 전용 EIP가 있는지 또는 그러한 EIP가 EVM에서 어떻게 작동할지는 잘 모르겠지만 기술적으로는 이것이 해결책이라고 생각합니다.

마지막으로, 사용자는 시퀀서 노드와 직접 상호 작용하지 않으며 대부분의 사용자는 집에서 전체 노드를 실행하지 않습니다. 따라서 블록체인의 실제 사용자 경험은 RPC 노드 및 인덱서와 같은 기본 인프라에 크게 좌우됩니다. 실시간 블록체인이 아무리 빠르게 실행되더라도, 피크 시간에 많은 읽기 요청을 효율적으로 처리하지 못하거나, 시퀀서 노드로 트랜잭션을 빠르게 전파하지 못하거나, 인덱서가 체인을 따라잡을 만큼 빠르게 애플리케이션 뷰를 업데이트하지 못하면 실시간 블록체인이 아무리 빠르게 실행되더라도 아무런 의미가 없습니다. "

중복성이 너무 많을 수도 있지만, 매우 중요합니다. 우리 모두는 인퓨라, 알케미, 퀵노드 등에 의존하고 있으며, 이들은 우리의 모든 트랜잭션을 지원하는 인프라를 운영합니다. 이러한 의존성에 대한 가장 간단한 설명은 경험에서 비롯됩니다. 특정 L2 에어드랍 후 처음 2~3시간 내에 에어드랍을 받으려고 시도해 본 적이 있다면 RPC가 이러한 혼잡을 관리하는 것이 얼마나 어려운지 이해하실 것입니다.

3, 결론

이 모든 것은 MegaETH와 같은 프로젝트가 도달하고자 하는 높이에 도달하기 위해 뛰어넘어야 할 장애물이 많다는 것을 전달하기 위해 말한 것일 뿐입니다. 한 게시물에 따르면 이기종 블록체인 아키텍처와 고도로 최적화된 EVM 실행 환경을 사용하여 고성능 개발을 달성할 수 있었다고 합니다. "현재 MegaETH는 고성능 실시간 개발 네트워크를 보유하고 있으며, 하드웨어에 국한되지 않고 가장 빠른 블록체인이 되기 위해 꾸준히 발전하고 있습니다."

MegaETH의 깃허브에는 다음과 같은 주요 개선 사항들이 나열되어 있습니다: EVM 바이트코드 → 네이티브 코드 컴파일러, 대용량 메모리 시퀀서 노드 전용 실행 엔진, 그리고 다음을 포함하되 이에 국한되지 않습니다. 병렬 EVM을 위한 효율적인 동시성 제어 프로토콜. EVM 바이트코드/네이티브 코드 컴파일러는 이제 evmone으로 제공되며, 저는 그 핵심 작동 방식을 알 만큼 코딩에 능숙하지는 않지만 최선을 다해 알아냈습니다.

evmone은 EVMC API를 잡고 이를 이더넷 클라이언트를 위한 실행 모듈로 변환하는 EVM의 C++ 배포판입니다. 이중 인터프리터 접근 방식(기본 및 고급), intx 및 ethash 라이브러리 등 제가 이해하지 못하는 몇 가지 다른 기능도 언급되어 있습니다. 요컨대, evmone은 더 빠른 트랜잭션 처리(더 빠른 스마트 컨트랙트 실행을 통해), 더 큰 개발 유연성, 더 큰 확장성(다양한 EVM 배포가 블록당 더 많은 트랜잭션을 처리할 수 있다고 가정할 때)을 제공합니다.

다른 코드베이스도 몇 가지 있지만, 대부분은 상당히 표준적이며 메가이더리움(reth, geth)과 특별히 관련이 없습니다. 백서 작업은 거의 끝났다고 생각하므로 이제 이 글을 읽는 모든 분들께 메가이더리움의 다음 단계는 무엇인가요? 유효한 확장 코드를 구현하는 것이 정말 가능한가요? 이를 구현하는 데 얼마나 걸릴까요?

블록체인 사용자로서 저는 이 모든 것이 가능한지 목격하게 되어 기쁩니다. 메인넷 거래 수수료에 너무 많은 돈을 지출해왔고 이제 변화가 필요한 시점이지만, 그 변화는 점점 더 실현되기 어렵고 조만간 이루어질 것 같지 않습니다.

이 글의 내용은 주로 아키텍처 개선과 확장성에 중점을 두고 있지만, 롤업 A의 경험을 롤업 B와 일치시키기 위해 이동성과 크로스체인 도구를 공유하기 위한 내부 롤업이 여전히 필요하지만 아직은 그 단계에 이르지 못했습니다. 아직은 아니지만 2037년이 되면 모두가 확장성 문제를 '해결'하는 데 얼마나 집착했는지 기억하고 있을 것입니다.