패러다임 CTO의 설명: Reth가 초당 1GB 가스를 달성한 방법

저자: 조지오스 콘스탄토풀로스, 리서치 파트너 겸 패러다임 CTO, 번역: 골든 파이낸스 샤오저우

우리는 2022년에 이더리움 L1에 탄력성을 제공하는 동시에 L2의 실행 레이어 확장 문제를 해결하기 위해 Reth를 구축하기 시작했습니다.

오늘, 2024년에 L2에서 초당 1GB 가스 처리량을 달성할 계획과 그 목표를 어떻게 초과 달성할 것인지에 대한 장기 로드맵을 공유하게 되어 기쁘게 생각합니다.

암호화폐의 성능 한계를 뛰어넘고 엄격한 벤치마킹을 위해 전체 생태계가 저희와 함께 해주시길 바랍니다.

1. 스케일아웃을 달성했나요?

암호화폐가 글로벌 규모에 도달하고 (주요 사용 사례가 되는) 투기를 피할 수 있는 아주 간단한 방법이 있습니다: 트랜잭션이 낮고 빨라야 한다는 것입니다.

1.1 성능은 어떻게 측정하나요? 초당 가스 양은 무엇을 의미하나요?

성능은 흔히 "초당 트랜잭션 수"(TPS)로 측정됩니다. 특히 이더 및 기타 EVM 블록체인의 경우 더 미묘하고 더 정확한 측정은 "초당 가스"입니다. 이 지표는 네트워크가 초당 처리할 수 있는 연산 작업의 양을 반영하며, 여기서 "가스"는 트랜잭션이나 스마트 콘트랙트와 같은 작업을 수행하는 데 필요한 연산 작업의 양을 측정하는 단위입니다.

초당 가스를 성능 지표로 정규화하면 블록체인의 용량과 효율성을 보다 명확하게 파악할 수 있습니다. 또한 덜 세분화된 측정값을 활용하여 잠재적인 서비스 거부(DOS) 공격에 대한 시스템의 비용 영향을 평가하는 데 도움이 됩니다. 이 메트릭은 다양한 이더리움 가상머신(EVM) 호환 체인의 성능을 비교하는 데 도움이 됩니다.

초당 가스 양을 표준 메트릭으로 채택하고 다른 가스 가격 책정 차원과 결합하여 포괄적인 성능 표준을 만들 것을 EVM 커뮤니티에 권장합니다.

1.2 현재 상황

초당 가스 양은 각 블록의 목표 가스 사용량을 블록 시간으로 나누어 결정합니다. 다음 표에는 다양한 EVM 체인 L1과 L2의 현재 가스 처리량과 초당 지연 시간이 표시되어 있습니다(전체가 아님):

컴퓨팅 및 스토리지 비용을 파악하면서 EVM 네트워크 성능을 완전히 평가하는 데 초당 가스 양을 강조하며, Solana, Sui 또는 Aptos 같은 네트워크는 고유 비용 모델로 인해 제외됩니다. 저희는 포괄적이고 공정한 비교를 위해 모든 블록체인 네트워크의 비용 모델을 조화시키기 위한 노력을 권장합니다.

레스는 실제 워크로드를 복제하기 위한 논스톱 벤치마킹 도구 세트를 개발 중입니다. 노드에 대한 우리의 요구 사항은 TPC 벤치마크를 준수하는 것입니다.

2. Reth는 어떻게 초당 1GB 가스 또는 그 이상에 도달하나요?

2022년에 Reth를 만든 동기 중 하나는 웹 롤업을 위해 구축된 클라이언트가 절실히 필요했기 때문입니다. 저희는 앞으로 나아갈 길이 유망하다고 생각합니다.

Reth는 이미 실시간 동기화(발신자 복구, 트랜잭션 실행, 각 블록에 대한 시도 계산 포함) 중에 초당 100-200MB 가스를 사용하고 있으므로 단기 목표인 초당 1GB 가스를 달성하려면 10배 더 확장해야 할 것입니다.

Reth가 성장함에 따라 확장 계획은 확장성과 효율성 사이에서 균형을 찾아야 합니다.

• 수직적 확장: 우리의 목표는 각 '박스'의 잠재력을 최대한 활용하는 것입니다. 각 개별 시스템이 트랜잭션과 데이터를 처리하는 방식을 최적화함으로써 전반적인 성능을 획기적으로 개선하는 동시에 각 노드 운영자의 효율성을 높일 수 있습니다.

• 수평적 확장: 최적화에도 불구하고 웹 스케일 트랜잭션의 절대적인 양은 단일 서버의 처리 용량을 초과합니다. 이에 대응하기 위해 블록체인 노드를 위한 Kubernetes 모델과 유사한 수평적 확장 아키텍처를 배포하는 것을 고려합니다. 이는 단일 노드가 병목현상이 발생하지 않도록 여러 시스템에 워크로드를 분산하는 것을 의미합니다.

여기에서 살펴보는 최적화에는 스테이트풀 성장 솔루션이 포함되지 않으며, 이는 다른 포스팅에서 별도로 살펴보도록 하겠습니다. 이를 달성하기 위한 계획의 개요는 다음과 같습니다.

전체 기술 스택 내에서도 스택의 각 부분을 서비스로 배포하여 사용량을 세밀하게 제어할 수 있다는 아이디어를 지원하는 액터 모델을 사용하여 IO 및 CPU를 최적화하고 있습니다. 마지막으로, 아직 확인되지 않은 대체 데이터베이스를 적극적으로 평가하고 있습니다.

2.1 레스의 수직 확장 로드맵

수직 확장의 목표는 레스를 실행하는 서버나 노트북의 성능과 효율성을 극대화하는 것입니다.

(1) 정시(Just-In-Time) EVM과 사전(Ahead-of-Time) EVM

이더 가상 머신(EVM)과 같은 블록체인 환경에서는 인터프리터를 통해 바이트코드 실행이 이루어지며, 이 인터프리터는 순차적으로 인터프리터를 통해 이루어집니다. 이 접근 방식은 네이티브 어셈블리 명령어가 직접 실행되지 않고 VM 계층을 통해 작업이 수행되기 때문에 약간의 오버헤드가 발생합니다.

JIT(Just-in-time) 컴파일은 실행 전에 바이트코드를 네이티브 머신 코드로 변환하여 VM의 해석 프로세스를 우회함으로써 성능을 개선함으로써 이 문제를 해결합니다. 컨트랙트를 최적화된 머신 코드로 미리 컴파일하는 이 기술은 이미 Java 및 WebAssembly와 같은 다른 VM에서 잘 확립되어 있습니다.

그러나 JIT 프로세스의 취약점을 악용하도록 설계되거나 실행 중에 실시간으로 실행하기에는 너무 느린 악성 코드에 취약할 수 있으며, Reth는 가장 수요가 많은 컨트랙트를 미리 컴파일(AOT)하여 디스크에 저장함으로써 실시간 실행 중에 네이티브 코드 컴파일 프로세스를 악용하려는 신뢰할 수 없는 바이트코드 시도를 방지합니다.

우리는 Revm을 위한 JIT/AOT 컴파일러를 개발해왔으며 현재 이를 Reth와 통합하고 있습니다. 벤치마킹을 마치는 대로 몇 주 내에 오픈소스로 공개할 예정입니다. 평균적으로 실행 시간의 약 50%가 EVM 인터프리터에 소요되므로 약 2배의 EVM 실행 개선이 필요하지만, 연산 요구가 더 큰 경우에는 그 영향이 더 클 수 있습니다. 향후 몇 주에 걸쳐 벤치마크를 공유하고 자체 JIT EVM을 Reth에 통합할 예정입니다.

(2) 병렬 EVM

병렬 이더넷 가상 머신(Parallel EVM)의 개념은 기존 EVM의 직렬 처리 모델과는 달리 여러 트랜잭션의 동시 처리를 지원합니다. 실행 모델과 달리 여러 트랜잭션의 동시 처리를 지원합니다. 다음과 같은 두 가지 경로가 있습니다.

• 기록 동기화: 기록 동기화를 사용하면 기록 트랜잭션을 분석하고 모든 기록 상태 충돌을 식별하여 가능한 최상의 병렬 스케줄링을 계산할 수 있습니다.

• 실시간 동기화: 실시간 동기화의 경우, 추가 정보(예: 액세스 목록) 없이도 실행을 추측하기 위해 블록 STM과 유사한 기법을 사용할 수 있습니다. 이 알고리즘은 상태 경합이 심한 기간에는 성능이 저하되므로 워크로드 조건에 따라 직렬 실행과 병렬 실행을 전환하고 병렬 품질을 개선하기 위해 어떤 스토리지 슬롯에 액세스할지 정적으로 예측하는 방법을 모색하고자 합니다.

기록 분석에 따르면 이더넷 스토리지 슬롯의 약 80%가 독립적으로 액세스되므로 병렬 처리를 통해 EVM 실행을 최대 5배 더 효율적으로 만들 수 있습니다.

(3) 상태 커미트먼트 최적화

Reth 모델에서 상태 루트를 계산하는 것은 트랜잭션 실행과 무관한 프로세스이므로, 시도 정보를 얻을 필요가 없는 표준 KV 스토어를 사용할 수 있습니다. 이는 현재 블록을 봉인(SEAL)하는 데 엔드투엔드 시간의 75%가 소요되며, 이는 최적화를 위한 매우 흥미로운 영역입니다.

우리는 프로토콜 변경 없이 스테이트 루트 성능을 2~3배 향상시킬 수 있는 다음 두 가지 "쉬운 승리" 경로를 확인했습니다.

• 상태 루트를 완전히 병렬화: 지금은 변경된 계정에 대해서만 스토리지 트리를 다시 병렬화하지만, 한 단계 더 나아가 스토리지 루트 작업이 백그라운드에서 완료되면 계정 트리를 병렬화할 수 있습니다.

• 파이프라인 상태 루트: 스토리지 슬롯과 관련된 계정을 상태 루트 서비스에 알림으로써 실행 중에 디스크에서 중간 시도 노드를 미리 가져옵니다.

이 외에도 이더넷 L1 상태 루트 활동에서 벗어나 몇 가지 경로를 탐색할 수 있습니다.

• 저주파 상태 루트 계산: 상태 루트 계산을 하지 않고 각 블록마다 상태 루트를 계산하지 않고 T 블록마다 한 번씩 계산합니다. 이는 시스템 전체에서 상태 루트에 할당되는 총 시간 비율을 줄여주며, 가장 간단하고 효율적인 솔루션입니다.

• 상태 루트 추적: 같은 블록에서 상태 루트를 계산하는 대신 몇 블록 뒤에 계산하는 것이 더 좋습니다. 이렇게 하면 상태 루트 계산을 차단하지 않고도 실행을 진행할 수 있습니다.

• RLP 인코더 & Keccak256 교체: RLP 인코딩을 사용하는 것보다 바이트만 병합하고 더 빠른 해시 함수(예: Blake3)를 사용하는 것이 비용이 더 적게 들 수 있습니다.

• 더 넓은 트라이: 트리의 N-아리티 하위 노드를 늘려 트라이의 로그N 깊이로 인한 IO 증가를 줄입니다.

질문 몇 가지 :

• 위의 변경 사항은 라이트 클라이언트, L2, 브리지, 코프로세서 및 빈번한 계정에 의존하는 기타 프로토콜에 영향을 미칩니다. 저장 증명, 라이트 클라이언트, L2, 브리지, 코프로세서 및 빈번한 계정과 저장 증명에 의존하는 기타 프로토콜에 위의 변경 사항이 미치는 부차적인 영향은 무엇인가요?

• 네이티브 실행 속도를 위해 SNARK 증명과 스테이트풀 프라미스를 모두 최적화할 수 있나요?

• 우리가 가진 도구로 얻을 수 있는 가장 광범위한 상태 약속은 무엇인가요? 증인 크기에 대한 부차적인 효과는 무엇인가요?

2.2 Reth의 수평적 확장 로드맵

초당 1GB 가스라는 목표를 달성하기 위해 2024년까지 위의 많은 부분을 실행할 것입니다.

그러나 수직적 확장은 결국 물리적, 실무적 한계에 부딪히게 될 것입니다. 단 하나의 컴퓨터로 전 세계의 컴퓨팅 수요를 처리할 수는 없습니다. 다음은 부하가 증가함에 따라 더 많은 박스를 도입하여 확장을 지원할 수 있는 두 가지 경로입니다.

(1) 다중 롤업 레스

오늘날의 L2 스택은 체인 추적을 위해 여러 서비스를 실행해야 합니다: L1 CL, L1 EL, L1 -> L2 파생 함수(L1 EL 바인딩에 연결될 수 있는 L2 EL 바인딩) 및 L2 EL. 모듈화에는 좋지만, 여러 노드 스택을 실행하면 상황이 더 복잡해집니다. 100개의 롤업을 실행해야 한다고 상상해 보세요!

레스가 발전함에 따라 롤업을 동시에 릴리스하고 수천 개의 롤업을 실행하는 데 드는 운영 비용을 거의 0으로 줄이고자 합니다.

이미 구현 확장 프로젝트에서 이를 위한 작업을 진행 중이며, 앞으로 몇 주 안에 더 많은 기능이 추가될 예정입니다.

(2) 클라우드 네이티브 Reth

고성능 시퀀서는 단일 체인에 많은 수요가 있을 수 있으며, 확장해야 하는데 단일 머신으로는 이를 감당할 수 없습니다. 이는 오늘날의 단일 노드 배포로는 불가능합니다.

우리는 클라우드 네이티브 Reth 노드를 실행하고, 컴퓨팅 수요에 따라 자동으로 확장할 수 있는 서비스 스택으로 배포하며, 영구적인 스토리지를 위해 무한한 클라우드 오브젝트 스토리지를 사용할 수 있도록 지원하고자 합니다. 이는 네온DB, 콕로치DB 또는 아마존 오로라와 같은 서버리스 데이터베이스 프로젝트에서 흔히 볼 수 있는 아키텍처입니다.

3. 향후 전망

우리는 이 로드맵을 모든 Reth 사용자들에게 점진적으로 적용하고자 합니다. 저희의 목표는 모든 사용자가 초당 1GB 이상의 가스를 이용할 수 있도록 하는 것입니다. 저희는 레스 알파넷에서 최적화를 테스트할 것이며, 사람들이 레스를 SDK로 사용하여 최적화된 고성능 노드를 구축할 수 있기를 바랍니다.

아직 답을 찾지 못한 몇 가지 질문이 있습니다.

• Reth가 L2 생태계 전반의 성능 향상에 어떻게 도움이 될 수 있나요?

• 일반적으로 일부 최적화에서 발생할 수 있는 최악의 시나리오를 어떻게 적절하게 측정할 수 있나요?

• L1과 L2 간의 잠재적 차이를 어떻게 처리할 수 있나요?

아직 이러한 질문에 대한 해답을 찾지는 못했지만, 당분간은 충분히 바쁠 수 있는 유망한 초기 아이디어가 많이 있으며, 앞으로 몇 달 안에 이러한 노력이 결실을 맺기를 기대합니다.