Ethereum Reth는 어떻게 초당 1GB 가스를 달성하나요? 우리는 L2의 실행 계층 확장 문제를 해결하는 동시에 Ethereum L1에 탄력성을 제공하기 위해 2022년에 Reth 구축을 시작했습니다. 오늘 우리는 Reth가 2024년에 초당 1GB의 가스 L2 처리량을 달성할 계획과 그 목표를 초과하는 방법에 대한 장기 로드맵을 공유하게 되어 기쁘게 생각합니다. 우리는 전체 생태계가 암호화폐의 성능 한계를 뛰어넘고 엄격한 벤치마킹에 참여하도록 초대합니다. 오늘 이 웹사이트의 편집자는 Reth가 어떻게 초당 1GB 가스를 달성하는지 자세히 소개할 것입니다. Ethereum Reth를 좋아하는 친구들은 놓치지 마세요!
초당 가스를 강조하고 이를 사용하여 컴퓨팅 및 스토리지 비용을 파악하는 동시에 EVM 네트워크 성능을 종합적으로 평가합니다. Solana, Sui 또는 Aptos와 같은 네트워크는 고유한 비용 모델로 인해 포함되지 않습니다. 포괄적이고 공정한 비교가 가능하도록 모든 블록체인 네트워크에서 비용 모델을 조화시키려는 노력을 권장합니다.
우리는 실제 워크로드를 복제하기 위해 Reth용 논스톱 벤치마킹 도구 모음을 개발하고 있습니다. 노드에 대한 요구 사항은 TPC 벤치마크를 준수하는 것입니다.
2022년에 Reth를 만들게 된 동기 중 하나는 웹 롤업을 위해 특별히 제작된 클라이언트가 절실히 필요하다는 것이었습니다. 우리는 앞으로 나아갈 길이 유망하다고 믿습니다.
Reth는 실시간 동기화(발신자 복구, 트랜잭션 실행 및 각 블록에 대한 시도 계산 포함) 중에 이미 초당 100-200MB 가스에 도달했습니다. 따라서 초당 1GB 가스라는 단기 목표를 달성하려면 확장이 필요합니다. 또 10번.
Reth가 성장함에 따라 우리의 확장 계획은 확장성과 효율성 사이의 균형을 찾아야 합니다.
수직적 확장: 우리의 목표는 각 "박스"의 잠재력을 최대한 활용하는 것입니다. 각 개별 시스템이 트랜잭션과 데이터를 처리하는 방식을 최적화함으로써 전반적인 성능을 크게 향상시키는 동시에 개별 노드 운영자의 효율성을 높일 수 있습니다.
수평 확장: 최적화에도 불구하고 웹 규모의 엄청난 트랜잭션 볼륨은 단일 서버의 처리 용량을 초과합니다. 이러한 상황을 해결하기 위해 우리는 블록체인 노드의 Kubernetes 모델과 유사한 수평 확장 아키텍처 배포를 고려했습니다. 이는 어떤 노드도 병목 현상이 발생하지 않도록 여러 시스템에 작업 부하를 분산시키는 것을 의미합니다.
여기에서 논의하는 최적화에는 상태 성장 솔루션이 포함되지 않습니다. 이 부분은 다른 기사에서 별도로 논의할 내용입니다. 이를 달성하기 위한 계획의 개요는 다음과 같습니다.
기술 스택 전반에 걸쳐 액터 모델을 사용하여 IO 및 CPU를 최적화하여 스택의 각 부분을 서비스로 배포하고 세분화할 수 있도록 했습니다. 그 사용을 통제합니다. 마지막으로, 우리는 대체 데이터베이스를 적극적으로 평가하고 있지만 아직 완성되지 않았습니다.
수직 확장의 목표는 Reth를 실행하는 서버 또는 노트북의 성능과 효율성을 최대화하는 것입니다.
(1) Even(Just-In-Time) EVM 및 Ahead-of-Time(Ahead-of-Time) EVM
EVM(Ethereum Virtual Machine)과 같은 블록체인 환경에서 바이트코드의 실행은 다음과 같이 해석됩니다. 통역사(interpreter), 통역사는 명령을 순서대로 처리합니다. 이 방법을 사용하면 기본 어셈블리 명령이 직접 실행되지 않고 VM 계층을 통해 작업이 수행되므로 약간의 오버헤드가 발생합니다.
JIT(Just-in-time) 컴파일은 실행 전에 바이트코드를 기본 기계어 코드로 변환하여 이 문제를 해결하므로 VM의 해석 프로세스를 우회하여 성능이 향상됩니다. 이 기술은 계약을 최적화된 기계어 코드로 미리 컴파일할 수 있으며 Java, WebAssembly 등 다른 가상 머신에서도 잘 사용되었습니다.
그러나 JIT는 JIT 프로세스 취약점을 악용하도록 설계된 악성 코드에 취약하거나 실행 중에 실시간으로 실행하기에는 너무 느릴 수 있습니다. Reth는 가장 까다로운 계약을 미리(AOT) 컴파일하고 디스크에 저장하여 라이브 실행 중에 신뢰할 수 없는 바이트코드가 네이티브 코드 컴파일 프로세스를 남용하는 것을 방지합니다.
우리는 Revm용 JIT/AOT 컴파일러를 개발해 왔으며 현재 이를 Reth와 통합하고 있습니다. 앞으로 몇 주 안에 벤치마크가 완료되는 대로 오픈소스로 공개하겠습니다. 평균적으로 실행 시간의 약 50%가 EVM 인터프리터에서 소비되므로 EVM 실행에서 약 2배의 개선이 필요하지만 계산 요구가 더 큰 경우에는 영향이 더 클 수 있습니다. 앞으로 몇 주 동안 우리는 벤치마크를 공유하고 Reth에 자체 JIT EVM을 통합할 것입니다.
(2) 병렬 EVM
병렬 이더리움 가상 머신(병렬 EVM)의 개념은 동시에 여러 트랜잭션 처리를 지원하며 이는 기존 EVM 직렬 실행 모델과 다릅니다. 다음 두 가지 경로가 있습니다:
기록 동기화: 기록 동기화를 사용하면 기록 트랜잭션을 분석하고 모든 기록 상태 충돌을 식별하여 가능한 최상의 병렬 일정을 계산할 수 있습니다.
실시간 동기화: 실시간 동기화를 위해 Block STM과 같은 기술을 사용하여 추가 정보(예: 액세스 목록) 없이 추측 실행을 수행할 수 있습니다. 심각한 상태 경합 기간 동안 알고리즘 성능이 저하되므로 작업 부하 조건에 따라 직렬 실행과 병렬 실행 간 전환을 탐색하고 병렬 처리 품질을 향상시키기 위해 액세스할 스토리지 슬롯을 정적으로 예측하려고 합니다.
역사적 분석에 따르면 이더리움 스토리지 슬롯의 약 80%는 독립적으로 액세스할 수 있습니다. 이는 병렬성이 EVM 실행 효율성을 5배 증가시킬 수 있음을 의미합니다.
(3) 상태 약속 최적화
Reth 모델에서 상태 루트 계산은 트랜잭션 실행과 독립적인 프로세스이므로 trie 정보를 얻지 않고도 표준 KV 스토리지를 사용할 수 있습니다. 현재 블록을 봉인하는 데 전체 시간의 75% 이상이 소요되며 이는 매우 흥미로운 최적화 영역입니다.
우리는 프로토콜 변경 없이 상태 루트 성능을 2~3배 향상시킬 수 있는 다음 두 가지 "쉬운 승리"를 확인했습니다.
상태 루트 완전 병렬화: 이제 다시 병렬화하기만 하면 됩니다. 변경된 계정에 대한 스토리지 트리를 계산하지만, 한 단계 더 나아가 스토리지 루트 작업이 백그라운드에서 완료되는 동안 병렬로 계정 트리를 계산할 수 있습니다.
파이프라인 상태 루트: 실행 중에 관련 스토리지 슬롯 및 계정의 상태 루트 서비스에 알림을 통해 중간 트라이 노드가 디스크에서 프리페치됩니다.
이 외에도 Ethereum L1 상태 루트 활동에서 벗어나 앞으로 몇 가지 경로를 탐색할 수도 있습니다.
더 빈번한 상태 루트 계산: 모든 블록의 상태 루트를 계산하지 않지만 모든 T 블록은 한번 계산해 보세요. 이렇게 하면 전체 시스템의 상태 루트에 투자하는 데 소요되는 총 시간이 줄어듭니다. 이는 아마도 가장 간단하고 효과적인 솔루션일 것입니다.
상태 루트 추적: 동일한 블록의 상태 루트를 계산하는 대신 몇 블록 뒤에 두십시오. 이를 통해 상태 루트 계산을 차단하지 않고 실행을 진행할 수 있습니다.
RLP 인코더 및 Keccak256 교체: RLP 인코딩을 사용하는 것보다 바이트를 직접 병합하고 Blake3와 같은 더 빠른 해시 함수를 사용하는 것이 더 저렴할 수 있습니다.
Wider Trie: 트리의 logN 깊이로 인한 IO 증가를 줄이기 위해 트리의 하위 노드의 N-arity를 늘립니다.
여기에 몇 가지 질문이 있습니다.
라이트 클라이언트, L2, 브리지, 코프로세서 및 빈번한 계정과 저장 증명에 의존하는 기타 프로토콜에 대한 위의 변경 사항이 이차적으로 미치는 영향은 무엇입니까?
SNARK 증명과 기본 실행 속도에 대한 상태 약속을 동시에 최적화할 수 있나요?
기존 도구를 사용하여 얻을 수 있는 가장 광범위한 주정부 약속은 무엇입니까? 증인 규모에 대한 이차적 영향은 무엇입니까?
우리는 초당 1GB 가스 목표를 달성하기 위해 2024년 내내 위의 여러 가지 작업을 실행할 것입니다.
그러나 수직적 확장은 결국 물리적, 실무적 한계에 직면하게 됩니다. 어떤 단일 기계도 전 세계의 컴퓨팅 요구를 처리할 수 없습니다. 로드가 증가한 후 더 많은 상자를 도입하여 확장을 지원할 수 있는 두 가지 경로가 있다고 믿습니다.
(1) 다중 롤업 Reth
오늘날의 L2 스택은 체인을 추적하기 위해 여러 서비스를 실행해야 합니다: L1 CL, L1 EL, L1 -> L2 파생 함수(L2 EL과 번들로 제공될 수 있음) 및 L2 EL. 이는 모듈화에는 좋지만 여러 노드 스택을 실행하면 상황이 더 복잡해집니다. 100개의 롤업을 실행해야 한다고 상상해보세요!
Reth가 발전함에 따라 롤업이 동시에 출시될 수 있도록 하고 수천 개의 롤업을 실행하는 데 드는 운영 비용을 거의 0으로 줄이고 싶습니다.
우리는 이미 Execution Scaling 프로젝트에서 이 작업을 진행하고 있으며 앞으로 몇 주 안에 더 많은 작업이 진행될 예정입니다.
(2) 클라우드 기반 Reth
고성능 분류기는 단일 체인에 대해 많은 요구 사항을 가질 수 있으며 확장이 필요하며 하나의 기계가 요구 사항을 충족할 수 없습니다. 이는 현재의 단일 노드 배포에서는 불가능합니다.
저희는 클라우드 기반 Reth 노드 실행을 지원하고, 컴퓨팅 요구 사항에 따라 자동으로 확장할 수 있는 서비스 스택으로 배포하고, 영구 스토리지에 겉으로는 무제한인 클라우드 객체 스토리지를 사용하기를 희망합니다. 이는 NeonDB, CockroachDB 또는 Amazon Aurora와 같은 서버리스 데이터베이스 프로젝트의 일반적인 아키텍처입니다.
우리는 이 로드맵을 모든 Reth 사용자에게 점진적으로 출시할 수 있기를 바랍니다. 우리의 임무는 모든 사람이 초당 1GB 이상의 가스에 액세스할 수 있도록 하는 것입니다. 우리는 Reth AlphaNet에서 최적화를 테스트할 예정이며 사람들이 Reth를 SDK로 사용하여 최적화된 고성능 노드를 구축하기를 바랍니다.
아직 답변을 찾지 못한 질문이 있습니다.
Reth는 전체 L2 생태계의 성능을 향상시키는 데 어떻게 도움이 되나요?
일반적으로 일부 최적화에서 발생할 수 있는 최악의 시나리오를 올바르게 측정하려면 어떻게 해야 합니까?
L1과 L2 사이의 잠재적 불일치를 어떻게 처리합니까?
아직 많은 질문에 대한 답을 얻지는 못했지만 한동안 우리를 바쁘게 할 유망한 초기 아이디어가 많이 있으며 이러한 노력이 앞으로 몇 달 안에 결실을 맺기를 바랍니다.
위 내용은 Ethereum Reth가 초당 1GB 가스를 달성하는 방법을 설명하는 기사의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
