블록 크기: 가스 캡과 확장성

토니 와르슈테터

최근 이더블록의 가스 캡을 올리는 것에 대해 많은 논의가 있었습니다. 많은 논의가 있었습니다. 일부는 무어의 법칙에 근거하여 더 큰 블록 크기를 주장하고, 일부는 개인적인 직관에 근거하여, 일부는 그냥 소문을 퍼뜨리고, 일부는 솔라나와 같은 다른 체인이 광범위한 사용자 채택 측면에서 이더를 추월할 것이라고 우려하고 있습니다.

다음으로 이더의 탈중앙화를 훼손하지 않으면서 가스 상한을 최대화하는 데 도움이 될 수 있는 차트와 데이터를 보여드리겠습니다.

처음부터

비트코인과 달리 이더리움은 블록 크기 제한이 고정되어 있지 않고, 대신 일종의 단위인 "가스 "라는 단위로 측정합니다. 이더에서 가스란 트랜잭션이나 스마트 컨트랙트와 같은 작업을 수행하는 데 필요한 연산량을 측정하는 단위입니다. 이더에서 각 작업을 완료하려면 일정량의 가스가 필요하며, 각 블록에는 블록에 포함할 수 있는 작업 수를 결정하는 가스 제한이 있습니다.

초기인 2015년에 이더는 블록당 5,000개의 가스 상한을 가졌습니다. 이 상한은 빠르게 약 300만 개로 증가했고, 2016년 후반에는 약 470만 개로 증가했습니다. 2016년에 DoS 공격에 대응하기 위해 탠저린 휘슬 하드포크(EIP-150)가 시행되면서 다양한 IO 집약적 연산 코드의 가격을 재조정하여 가스 상한선을 550만 개로 올렸습니다. 이러한 공격 이후 채굴자들은 2017년 7월에 670만 개, 2017년 12월에 800만 개, 2019년 9월에 1000만 개, 2020년 8월에 1250만 개, 2021년 4월 3일에 1500만 개로 가스 캡을 계속 올렸습니다.

그 이후, 비잔티움은 스퓨리어스 드래곤과 함께합니다, 콘스탄티노플, 이스탄불, 베를린 하드포크가 활성화되면서 특정 옵코드의 가격 책정이 더욱 세분화되었습니다. 이러한 세분화의 예로는 EIP-145, EIP-160, EIP-1052, EIP-1108, EIP-1884, EIP-2028, EIP-2200, EIP-2565, EIP-2929 등이 있습니다.

가장 중요한 이더넷 수수료 시장 2021년 8월 런던 하드포크(EIP-1559)가 도입되면서 변화가 일어났습니다.EIP-1559는 블록 공간 수요에 따라 시간/블록 높이에 따라 동적으로 조정되는 기본 수수료를 도입했습니다. 블록당 1,500만 가스라는 '목표 크기'도 도입되었으며, 이 목표는 기본 수수료의 동적 조정을 안내하는 데 사용됩니다. 한 블록에서 사용된 총 가스가 이 목표를 초과하면 다음 블록의 기본 수수료가 인상됩니다. 반대로 총 가스 사용량이 목표보다 적으면 기본 수수료는 감소합니다. 이 메커니즘은 트랜잭션 오버헤드를 안정화하여 보다 예측 가능한 수수료 시장을 만들고 사용자 경험을 개선하기 위한 것입니다. 또한, EIP-1559는 기본 수수료 소멸 메커니즘을 도입하여 이더의 해당 부분을 유통에서 영구적으로 제거함으로써 프로토콜의 지속 가능성을 높이고 초 건전 화폐 밈으로 알려진 것을 생성합니다.

EIP-1559에서는 최대(또는 "하드 캡") 가스 한도가 목표치의 두 배인 3천만 개로 설정되어 있으며, 이는 단일 블록이 총 3천만 개까지 사용하는 트랜잭션을 포함할 수 있다는 의미입니다. 즉, 한 블록은 총 3,000만 가스까지 사용하는 트랜잭션을 포함할 수 있습니다. ">런던 포크 이후의 가스 사용량

이후 이더의 블록 가스 상한은 변함없이 유지되고 있습니다. 2024년 현재 블록당 3,000만 가스로 유지될 예정입니다.

블록 크기를 늘릴 준비가 되셨나요?

최근 일부 사람들은 이더의 가스 상한에 대해 우려를 표하며 이를 늘려야 한다고 주장하고 있습니다. 비탈릭은 최근 Reddit의 이더리움 재단 AMA에서 가스 캡을 33% 늘려 4천만 개로 늘리는 방안을 고려하고 있다고 말했습니다. 그의 추론은 마이크로칩의 트랜지스터 수가 약 2년마다 두 배로 증가하여 그에 상응하는 컴퓨팅 성능이 증가한다는 무어의 법칙에 근거하고 있습니다. 이 원리는 트랜잭션 처리 및 실행 능력을 포함한 네트워크 성능도 시간이 지남에 따라 향상될 수 있음을 시사합니다.

이더넷 재단의 Dankrad와 Ansgar 연구원도 덴쿤 업그레이드 이후 어떤 일이 일어날지 평가한 후 가스 상한을 늘리는 아이디어를 지지합니다. 또한 이더넷 재단의 Pari는 가스 상한을 늘릴 수 있는 잠재적인 방법을 모색하는 게시물을 발표했습니다. Geth의 피터와 마리우스와 같은 다른 사람들은 특히 적절한 도구/모니터링이 마련되지 않은 상태에서 가스 상한을 늘리는 것에 대해 우려를 표명했습니다. 이러한 우려는 주로 스테이트 성장 가속화, 동기화 시간, 재편성 블록률과 같은 문제와 관련이 있습니다.

블록 크기는 어떻게 되나요?

블록 크기는 두 가지 방법으로 측정할 수 있습니다.

가스 사용량

바이트 단위의 블록 크기

이 두 측정값은 서로 연관되어 있지만 독립적으로 고려해야 합니다.

예를 들어, 0이 아닌 콜데이터 바이트가 많이 포함된 블록의 바이트 크기는 크지만 실제 가스 사용량(0이 아닌 바이트당 16가스)은 상대적으로 작을 수 있습니다.

압축을 잠시 무시하고 현재 달성할 수 있는 최대 블록 크기는 Geth의 트랜잭션당 128KB 제한을 준수하면서 약 6.88MB입니다. 이렇게 하면 해당 블록에 포함될 수 있는 128KB 트랜잭션의 수가 최대화됩니다. 실제 결과는 약 130,900바이트의 0바이트 콜데이터(바이트당 4가스)를 포함하는 55개의 트랜잭션과 나머지 공간을 채우기 위한 1개의 트랜잭션으로 구성됩니다. 그러나 빠른 압축을 거친 후 이러한 블록의 크기는 약 0.32MB로 무시할 수 있을 정도로 작아집니다.

또 다른 시나리오에서는 가능한 최대 블록 크기를 고려할 때 0바이트가 아닌 콜 데이터를 전달하는 15개의 트랜잭션이 포함되며, 압축 크기는 약 1.77MB가 됩니다.

그렇습니다.

따라서 현재로서는 1.77MB가 실행 레이어 블록의 실제 블록 크기의 상한선을 나타냅니다.

번역자 주:

위 단락에서 작성자들은 30M의 고정된 가스 제한으로 블록 크기를 최대화하려고 시도하면서 블록을 최대로 얼마나 많이 넣을 수 있는지 계산하려고 노력했습니다. 채울 수 있습니다.

가스 제한을 고정하면 블록 크기를 더 크게 만들 수 있는 유일한 방법은 호출 데이터로 채우는 것입니다(compute/STORE와 같은 바이트코드는 실제로 블록 저장 공간을 소비하지 않으므로).

따라서 블록을 더 크게 만드는 유일한 방법은 트랜잭션에 최대한 많은 콜데이터를 채우는 것이며, 이를 위해서는 "0 콜데이터 채우기"와 "0이 아닌 콜데이터 채우기" 두 가지 방법이 있는데, 이는 블록 크기를 늘리기 위해 계산을 필요로 합니다. 그런 다음, 어떤 것이 블록 크기를 더 크게 만드는지 알기 위해 계산해야 하는 "stuff 0 calldata"와 "stuff non-0 calldata" 메서드가 있습니다. 최종 결과는 "채워진 0이 아닌 콜데이터" 블록 크기가 더 크다는 것입니다.

Geth 클라이언트가 트랜잭션당 최대 128KB로 제한된다는 전제하에, 다음은 계산하는 방법에 대한 두 가지 예시입니다.

사례 1:규모 130,900B(< 128KB) 트랜잭션 56개(모두 콜데이터 0, 가스/B 4): with gas = 56* (130,900 * 4 +21000) = 30497600 > (30M)이므로 위 트랜잭션 중 최대 55개 + 위보다 작은 트랜잭션 1개가 들어갑니다. 해당 블록 크기는 약 55*128 = 7040kB = 6.875MB입니다. 그러나 콜데이터가 모두 0이므로 압축된 블록 크기는 약 0.32MB입니다."

case 2: 15 130,900B(< 128KB) 크기의 트랜잭션(모두 0이 아닌 콜데이터, 16가스/B): 사용된 가스 = 15 *(130900 *16+21000) = 31731000 > 30M. 해당 블록 크기는 약 14 *128 = 1792kB = 1.75MB ~ 15 * 128 =. 1.875 M. 단, 콜데이터가 0이 아니고 잘 압축되지 않으므로 압축된 블록 크기는 약 1.77 MB입니다.)

이 최대 블록 크기와 관련하여 영향을 미치는 몇 가지 요인을 확인할 수 있습니다.

가스 캡: 가스 캡이 최대 블록 크기에 영향을 미친다는 것은 의심의 여지가 없습니다. 캡이 높을수록 더 많은 데이터를 블록에 담을 수 있습니다.

연산 및 데이터 가격: 연산에 사용되는 가스가 저렴할수록 블록에서 더 많은 연산을 수행할 수 있습니다. CALLDATALOAD 또는 CALLDATACOPY와 같은 연산은 3가스의 오버헤드가 상대적으로 저렴하지만, CREATE 및 CREATE와 같은 다른 연산 코드는 상대적으로 저렴합니다. 코드>  는 더 비쌉니다. 블록에 사용되는 연산 코드가 비쌀수록 해당 블록에서 calldata(또는 다른 연산)를 위한 공간이 줄어듭니다.

클라이언트 측 제한: 클라이언트 측 제한의 영향은 덜 분명하지만, 예를 들어 Geth 클라이언트에서처럼 트랜잭션당 128KB 제한은 최종 블록 크기에도 영향을 미칠 수 있습니다. 트랜잭션당 고정 수수료가 21k 가스이므로 클라이언트의 트랜잭션당 크기 제한이 낮을수록 클라이언트는 고정 수수료를 더 자주 지불해야 하므로 통화 데이터에 사용할 수 있는 가스를 "낭비"하게 됩니다. 따라서 결국 제한은 다음과 같습니다. 따라서 결국 이 제한으로 인해 최대 블록 크기가 약 0.07MB 감소할 수 있습니다. 클라이언트 측 제한은 이미 확정된 블록이 아닌 트랜잭션 브로드캐스트에만 영향을 미칩니다.

먼저 블록당 가스 한도에 대해 살펴보겠습니다.

오늘 기준, snappy를 사용하여 압축된 비콘 체인 블록의 평균 블록 크기입니다. 현재 스내피 압축을 사용한 비콘 체인 블록의 평균 블록 크기는 약 125KB입니다. 4844를 사용하면 블록당 375KB가 추가되어 현재 평균 블록 크기가 4배 증가합니다. 최대 블롭 수에 도달하면 기본적으로 현재 블록 크기가 7배 증가하게 됩니다.

최악의 경우 블록 크기는 ~1.77MB에서 ~2.5MB로 증가하며, 이 추정치는 블록의 CL(합의 계층) 부분을 고려하지 않은 수치입니다. 하지만 어떤 경우든 DoS 공격이 발생할 경우 이 최대 블록 크기에 대비해야 합니다.

요약

결론적으로 현재 블록 가스 캡을 늘리려면 구현 전에 철저한 연구와 분석이 필요합니다. 코인베이스, 바이낸스, 크라켄, 리도 노드 운영자 같은 기존 업체는 4천만 개 이상의 블록 가스 상한을 처리할 수 있지만, 독립 노드 운영자는 더 힘들어질 수 있습니다.

따라서 탈중앙화를 희생하지 않기 위해서는 이와 같은 결정을 신중하게 내려야 합니다.

결국, Facebook만큼의 용량과 성능을 갖춘 무언가를 구축하는 것은 비교적 쉽지만, 우리 대부분이 추구하는 탈중앙화라는 가치를 잃지 않는 것이 중요합니다.