비탈릭이 제안하는 이더리움 가스 한도 상향 조정: 어떤 위험이 있을까요?

저자: 존 오탄더, 코어 이더 개발자; 번역: 골든 파이낸스 샤오조우

이 게시물은 이더리움 우대 고객 비탈릭이 최근 Reddit AMA에서 답변한 내용에서 영감을 받았습니다.

비탈릭은 가스 한도를 소폭 인상하는 것이 정당하며, 가스 한도가 거의 3년 동안 인상되지 않았다고 지적했습니다. 프로토콜 역사상 가장 긴 기간이며, 비탈릭은 간단한 계산을 통해 이더 가스 한도를 4천만 개로 늘릴 수 있음을 보여주었습니다.

이 글은 이더 가스 한도를 올리는 것이 더 어렵다고 하는 이유에 대한 글입니다. 이더 가스 한도 상향과 관련된 위험과 관련 해결책에 대해 설명합니다.

1, 가스 한도

가스 한도는 주어진 자산에 사용할 수 있는 금액의 한도를 결정합니다. ">가스 한도는 블록 내에서 수행되는 작업의 양과 블록당 실행할 수 있는 트랜잭션 수를 결정합니다. 가스 한도를 높이면 이더는 더 많은 트랜잭션 처리량이나 더 복잡한 트랜잭션을 처리할 수 있습니다. 정확한 가스 한도 설정은 항상 채굴자/서약자의 영향을 받았으며, 가스 한도는 수년에 걸쳐 증가해 왔습니다. 아래 차트는 이더스캔.io의 과거 가스 사용량을 보여줍니다(가스 한도에 매우 근접하며, 한도 증가는 모두 시장에 흡수되었습니다).

2, 위험

지금 가스 한도를 올리는 데에는 몇 가지 위험이 따릅니다.

(1) 삼촌 비율

이전 게시물에서 언급했듯이 삼촌 비율은 가스 한도 인상을 평가할 때 가장 많이 논의되는 지표 중 하나입니다. 가스 한도 증가를 평가할 때 가장 많이 논의되는 지표 중 하나입니다. 이제 이더리움 합병 이후 더 이상 엉클 블록은 존재하지 않습니다. 노드가 현재 가스 한도를 잘 처리하고 있는지 알 수 있는 유일한 방법은 엉클 비율을 살펴보는 것입니다. 그러나 이 메트릭은 현재 프로비저닝이 부족한 노드만 보여주기 때문에 결함이 있습니다. 이 지표는 가스 한도 증가에 대한 좋은 지표를 제공하지 않으며, 공격으로 발생할 수 있는 최악의 시나리오가 아닌 평균 시나리오만 보여줍니다.

(2) 상태 크기

블록 18418786(2023년 10월 24일)의 계정 스냅샷은 10.33GB이고 스토리지 스냅샷은 다음과 같습니다. 76.59GB이므로 전체 상태는 약 87GB입니다. 블록 17419840(2023년 6월 6일)의 상태는 80GB에 약간 못 미칩니다. 이는 4개월 동안 약 7GB, 즉 매월 약 2GB씩 증가했음을 의미합니다.

87 + (2**#년) 값을 사용하면 12*#년) 값을 사용하여 추정하면 1년 후 111GB, 5년 후 207GB가 될 것입니다. 여기서 문제는 크기가 아닙니다. 누구나 그 정도의 데이터를 저장할 수 있지만, 그 데이터에 액세스하고 수정하는 속도는 점점 느려집니다.

이것은 여전히 일반적인 상태인 스냅샷일 뿐이며, Geth는 상태 루트를 확인하기 위해 이 상태를 다른 형태로 저장해야 합니다. 18418786 블록(트라이 노드)을 위한 또 다른 형태의 상태 저장소에는 약 180GB가 필요합니다.

따라서 현재 상태 저장소로만 사용할 수 있는 공간의 총 크기는 약 267GB이며, 가스 한도를 늘리면 상태 크기가 더 빠르게 증가합니다.

스테이트 증가의 문제점은 과거와 달리 스테이트 제거에 대한 명확한 경로가 없다는 것입니다. 성장 상태에서 벗어나기 위해 빠르게 구현할 수 있는 특정 상태 지속 시간 권장 사항이 없습니다.

(3) 과거 크기

2021년 게시물 중 하나에서 언급했듯이, 전체 geth 노드는 약 350GB(새로 가지치기한 경우)입니다. 약 3년이 지난 지금, 전체 geth 노드(pbs에서)는 900GB가 넘습니다. 아래 그래프는 총 누적 트랜잭션 양을 보여줍니다. 이를 통해 거래량이 약 9억 8천만 건에서 22억 건 이상으로 3년 만에 두 배 이상 증가했음을 쉽게 알 수 있습니다.

L2의 등장으로, 현재(4844가 활성화되기 전) 데이터를 다음과 같이 저장하기 때문에 과거 크기는 더욱 큰 문제가 되었습니다. calldata. 블록 18418786 의 블록 크기는 427GB가 넘고, 블록 17419840 (역시 4개월 전)의 블록 크기는 339GB로 4개월 동안 28GB, 즉 매달 약 9GB가 증가했습니다. 이 증가를 427 + (9*12*#년)으로 추정하면 1년 후에는 535GB가 되고, 5년 후에는 967GB가 됩니다(다시 선형적으로 증가한다고 가정).

이러한 증가세는 EIP-4844가 가동된 후, L2가 데이터 가용성을 위해 CALLDATA 사용을 중단하고 몇 주 후에 만료되는 블롭 사용으로 전환하면 둔화될 것으로 예상됩니다.

EIP. -44444는 풀 노드가 더 이상 모든 히스토리를 저장할 필요가 없으므로 히스토리 증가 문제를 해결합니다. EIP-4444를 구현하려면 풀 노드가 히스토리 데이터 제공을 중단하기 전에 히스토리를 검색할 수 있는 안정적인 네트워크가 필요합니다.

(4) 동기화 시간

가스 제한은 여러 가지 방식으로 동기화 시간에 영향을 줄 수 있습니다. 정렬: 왼쪽;">- 전체 동기화가 느려지고, geth 노드가 체인을 완전히 동기화하는 데 일주일 이상 걸리며, 다른 클라이언트가 더 나은 전체 동기화 모드를 위해 최적화되었습니다.

- 기록 데이터 동기화가 느립니다. 더 많은 데이터를 다운로드해야 하므로 기록 데이터 동기화 부분이 더 느립니다.

- 더 많은 상태를 다운로드해야 하므로 스냅샷 상태 동기화 속도가 느립니다.

- 스냅샷 복구 속도가 느립니다. 스냅샷 동기화 중에 피벗 포인트가 이동하기 때문에 디스크에 수정해야 할 불완전한 상태가 많이 있습니다. 피벗이 더 자주 이동하고 블록당 변경 사항이 더 많으면 복구 단계가 더 느려집니다.

-블록 헤더를 형성하기 위해 노드가 더 많은 변경을 거쳐야 하므로 체인과의 동기화 속도가 느려집니다.

(5) 클라이언트 다양성

새로운 EL 클라이언트를 구축하는 것은 그 자체로 어려운 작업입니다. 가스 한도를 추가하면 클라이언트를 구축하고 메인 네트워크에서 사용하도록 최적화하는 것이 더 어려워진다는 단점이 있습니다. Geth는 10년 넘게 수많은 최적화를 거치며 개발되어 왔습니다. 새로운 클라이언트가 기존 클라이언트로부터 학습하여 동일한 실수를 반복하지 않을 수 있다는 반대의 견해가 있을 수 있습니다.

그러나 우리는 이미 두 클라이언트(파이썬으로 작성된 실행 스펙과 자바스크립트로 작성된 이더리움J)의 메인넷 문제를 경험한 바 있습니다. 이는 또한 특정 언어로 작성된 클라이언트가 현재 작동하지 않는다는 것을 의미합니다. 가스 한도를 늘리면 언어 오버헤드와 코드베이스의 성숙도로 인해 일부 클라이언트가 중단될 수 있습니다.

KZG에서도 이러한 현상을 볼 수 있는데, 대부분의 클라이언트는 필요한 성능을 얻기 위해 선택한 언어로 작성된 라이브러리를 사용하는 대신 C로 작성된 코드베이스인 C-KZG를 호출하는 데 의존하고 있습니다.

(6) 최악의 경우

가스 한도를 고려할 때 일반적인 경우만 볼 수는 없습니다. 항상 최악의 경우를 고려해야 합니다. 물론 체인의 평균 부하가 낮을 때는 노드가 정상적으로 작동할 수 있지만, 갑자기 디스크 I/O가 5블록 연속으로 두 배로 증가하면 어떻게 될까요?

런타임만이 고려해야 할 유일한 지표는 아니며, 공격자가 디스크 I/O, CPU 시간, 메모리 등 다른 리소스를 차지할 수 있다면 구성이 낮은 시스템을 강제로 오프라인으로 전환할 수 있습니다. 특히 이더넷 병합 이후에는 동일한 시스템에서 두 개의 클라이언트를 실행하면서 그 중 하나를 공격하면 다른 클라이언트도 불안정한 상태에 놓일 수 있습니다. 이더넷 병합 테스트 초기에는 한 클라이언트의 메모리 누수로 인해 전체 시스템이 다운되는 경우를 여러 번 목격했습니다.

고려해야 할 또 다른 최악의 시나리오는 증명 크기입니다. 가스 한도가 증가하면 두 블록 사이에서 발생할 수 있는 잠재적인 상태 변화도 증가합니다. 이는 앞서 설명한 스냅샷 동기화에도 영향을 미치지만, 실행 수준에서 라이트 클라이언트의 증명 크기에도 영향을 미칩니다. 머클-패트리샤 트리의 증명은 네트워크를 통해 전송하기에는 너무 크기 때문에 큰 문제가 되지 않습니다. 그러나 동일한 컴퓨터에서 실행되는 여러 라이트 클라이언트로 교차 검증이라는 아이디어를 구현하려면 증명 크기가 중요해집니다.

3, 해결책

끝났나요? 30MGas로 제한이 계속 유지될까요? 아니요!

2021년 게시물 중 하나에서 당시 직면했던 딜레마에 대한 해결책을 제안한 적이 있습니다. 2021년에 직면했던 전체 동기화 문제의 경우, geth는 스냅샷 동기화 및 스냅샷을 구현했습니다. 가지치기 및 데이터베이스 레이아웃 문제를 해결하기 위해 geth는 PBSS를 구현했습니다. txpool은 높은 트랜잭션 로드를 처리하는 데 훨씬 더 안정적이 되었고 대부분의 MEV 로보콜 트랜잭션은 빌더로 전환되었습니다. 또한 많은 트랜잭션이 L2로 이동하여 메인넷의 평균 트랜잭션 크기가 증가했습니다.

실현되지 않은 유일한 해결책은 재생성이었습니다. 수년 동안 의견에 약간의 변화가 있었으며, 대부분의 사람들은 기록 데이터 증가에 대한 단기적인 해결책으로 EIP-4444 기록 기간을 선호하는 것으로 보입니다. EIP-4444의 출시를 위해서는 모든 풀 노드에서 더 이상 히스토리를 저장하지 않더라도 히스토리가 손실되지 않도록 강력한 히스토리 데이터 서비스 노드 네트워크가 필요합니다(참고로 대부분의 비트코인 노드는 히스토리 데이터를 전혀 저장하지 않습니다).

우리는 아직 상태 마감일을 처리할 수 있는 적절하고 현실적인 방법을 찾지 못했습니다.

상하이 업그레이드 이전 공격에서 보셨듯이 가스 리밋을 올리지 못하게 하는 몇 가지 알려진 공격이 있었습니다. (제가 알기로는) 모든 취약점이 해결되었습니다.

이 글을 쓰는 시점에서 EIP-4844가 테스트 네트워크에 배포되고 있습니다. 이 EIP는 노드의 스토리지 및 I/O 요구 사항을 증가시킬 것입니다. 제 생각에는 이 변경 사항이 메인 네트워크에 어떤 영향을 미치는지 지켜보는 것이 가스 한도 증가를 시도하기 전에 가장 안전한 조치입니다. L2가 블롭 트랜잭션으로 전환되면 콜데이터 비용을 늘려야 합니다(제 생각에 콜데이터는 데이터를 저장해야 하는 다른 것들에 비해 저평가되어 있기 때문입니다). 이는 L2가 블롭 스페이스를 사용하도록 강제하는 기능이 될 수도 있습니다.

요약하자면, 가스 한도 상향은 노드의 여러 측면에 영향을 미치며, 그 중 일부는 비교적 분명하게 드러날 것이므로 신중하게 진행해야 한다는 점을 말씀드리고 싶습니다. 관련 논의에서 가스 한도 변경의 장단기적 영향을 모두 고려하는 것이 중요합니다.