Hegota에서의 확장성: 이더리움(ETH) 전송을 활용하여 실행 및 대역폭 안정화

이 보고서 작성에 도움을 주신 토니 바르슈타터, 마리우스 반더바이덴, 파리토시 자얀티 님께 감사의 말씀을 전합니다.

이 글에서는 글램스터담 업데이트 이후 가스 한도를 지속적으로 확장하기 위해 헤고타가 무엇을 변경해야 하는지 분석합니다. 출발점은 단 하나의 관찰입니다. 21,000 ETH 가스 전송량이 슬롯의 두 가지 차원을 모두 제한한다는 점입니다.

• 실행 측면에서 글램스터담 가격 재조정으로 비용이 이체 한도 내에서 허용되는 최대치까지 상승했으며, 최악의 경우 실행 비용은 100Mgas/s로 확정되었습니다.
• 대역폭 측면에서 보면, 전송으로 가득 찬 블록 자체는 데이터 페이로드(봉투, 서명 및 BAL 항목)이며, 어떤 가격 책정 도구도 21,000달러 이상의 요금을 부과하지 않고는 접근할 수 없습니다.

따라서 우리는 전송 완료 블록을 기준 블록 으로 사용합니다. 해당 블록의 대역폭 성능을 도출하고, 가스 한도를 최대화하는 PTC 마감 시간을 찾고, 이를 공격자의 호출 데이터 + SLOAD 블록과 비교한 다음, 이것이 상태 증가, 기록 및 메모리에 어떤 의미를 갖는지 살펴봅니다.

주요 결과

• 21,000 ETH 전송은 슬롯의 양쪽 끝을 고정합니다. 최악의 경우 실행 속도를 100 Mgas/s로 고정하고 , 어떤 가격 책정 도구도 이보다 낮출 수 없는 최소 바이트 밀도인 약 0.0105 B/gas(최악의 경우 전송당 221 B)를 설정합니다. 앵커 블록은 약 214 Mgas/s로 전파되므로 실행 속도에 제약이 있으며, 대칭적인 25% 버퍼를 사용하여 양쪽 상한선을 모두 해결하면 PTC 마감 시간 약 6.4초에서 약 422M이 됩니다. 25% 버퍼는 엄격한 하한값이 아닌 가이드라인으로 간주하고, 정수에 가깝게 조정합니다. 권장 값 은 $D = 6$s이며 , 이는 앵커 블록을 최악의 경우 실행 버퍼 약 25%와 전파 버퍼 약 11%로 실행하는 값입니다.

• 헤고타의 가격 재조정 작업은 모든 가격 책정된 구성 요소를 전송 라인 수준으로 낮추는 것입니다. 21k 상한선을 건드리지 않고는 전송 가격을 재조정할 수 없으므로, 구조적으로 최악의 경우를 만드는 것이 목표입니다. 글램스터담 가격 책정 방식은 이 목표를 달성하지 못합니다. 혼합 통화 데이터 + SLOAD 블록은 라인 가격의 약 2.2배에 달하며, 시스템을 약 302M에 고정시켜 최적 기준선보다 약 120M 낮춥니다. 해결책은 통화 데이터 하한선을 다시 높이거나(64 → 96) BAL 바이트를 포함하거나, 단일 균일 통화 데이터 속도(약 94)를 도입하는 것입니다. 즉, 메커니즘의 복잡성과 발생 빈도 사이의 균형을 맞춰야 합니다.

• 전송선 아래에서는 추가 최적화를 통해서만 최적값이 이동합니다. 가격 책정을 통해 전송선에서의 구성은 균등화될 수 있지만, 그 아래로는 내려갈 수 없습니다. 킬로바이트당 전파 시간이 10% 개선될 때마다 가스 한도가 대략 +14~18M씩 증가하며, 최대 618M까지 늘어날 수 있습니다. 이와 동시에 ETH 전송 실행 시간이 개선되면 더 높은 실행 앵커를 설정할 수 있으므로 PTC 마감 시간을 변경하지 않고도 더 높은 한도를 설정할 수 있습니다.

배경

Glamsterdam은 ePBS( EIP-7732 ), BAL( EIP-7928 ) 및 데이터 가격 책정 EIP 7976 (calldata floor 64/64, standard 4/16)과 7981 (access-list bytes at floor rate)을 포함한 가격 재조정 번들을 제공합니다. 이러한 가격 재조정은 최악의 경우 실행 성능을 100Mgas/s로 목표로 설정했습니다. 이 목표치는 더 이상 높일 수 없습니다. 그렇게 하면 ETH 전송에 대한 가스 비용을 21,000 이상으로 재조정해야 하는데, 이는 일부 하드웨어 지갑의 기능을 손상시킬 수 있기 때문입니다. 따라서 Hegota의 경우 100Mgas/s의 실행 기준점이 고정되어 있으며, 추가적인 확장은 최적화(실행 및 전파 모두), PTC 마감 시간 변경, 그리고 (별도로) 과도하게 비싼 컴퓨팅 작업의 비용 절감을 통해 이루어져야 합니다. 마지막 옵션은 병렬적으로 분석되며, 이 보고서에서는 나중에 언급될 한 번의 상호 작용을 통해서만 다뤄집니다.

본문 전체에서 사용된 가정은 다음과 같습니다.

자원 지도

이는 자원을 제한하는 제약 조건의 종류별 로 정리하는 데 도움이 됩니다. 왜냐하면 각 자원이 더 높은 가스 제한에 어떻게 반응하는지가 그 제약 조건에 따라 결정되기 때문입니다.

다음 섹션에서는 슬롯별 트레이드오프(가스 제한 설정)에 대해 다루고, 마지막에 누적 리소스에 대해 다시 살펴보겠습니다.

전달 블록을 앵커 블록으로 사용

데이터 전송 시 몇 바이트가 전송되나요?

전송은 저장 공간을 쓰지 않고 연산 코드를 실행하지 않지만, 여전히 바이트를 전송합니다. 여기에는 전송 봉투와 서명, 그리고 EIP-7928이 BAL에 보관하는 기록이 포함됩니다.

타입 2 전송의 실제 봉투 크기는 약 110B입니다. 서명( r , s 각각 32B, y_parity 포함)이 약 65B이고, RLP 프레임 처리된 20바이트 수신자 주소가 약 21B이므로, 논스, 두 개의 수수료 필드, 가스 한도, 값, 체인 ID 및 빈 액세스 목록에 약 25B가 남습니다. 표에서는 현재 거래 유형 전체에서 최악의 경우 봉투 크기를 130B로 반올림했습니다.

BAL의 경우, 이체는 두 개의 계정(송신자: 잔액 + 논스; 수신자: 잔액)을 거칩니다. RLP는 잔액을 최소 길이(≤ 11B, 총 ETH 공급량으로 제한되며 32B가 아님)로, 논스를 1~2B로 인코딩하기 때문에 최악의 경우 한계 기여도는 약 91B입니다.

전파 모델은 Snappy 처리 후 바이트를 기준으로 보정되므로, 전송 블록을 비압축성 (Snappy 처리 후 ≈ 원시)으로 처리하여 이 221B의 원시 데이터를 네트워크에 매핑합니다. 이는 최악의 경우에도 안전한 방식입니다. 서명은 Snappy가 접근할 수 없는 임의의 바이트이기 때문입니다. 이는 보고서에서 가장 중요한 가정입니다. 실제 압축은 단지 한계를 완화하고 달성 가능한 가스 한도를 높일 뿐입니다. 실제 인코딩된 블록에서 압축된 바이트의 한계 기울기를 측정하는 것이 이 보고서에서 가장 중요한 데이터 작업으로 지적됩니다.

PTC 마감일은 어디로 옮겨야 할까요?

마감 시간 D D는 슬롯을 전파 기간(T_1 = 3초부터 D D 까지)과 실행 기간 (D D 부터 12초까지)으로 나눕니다. 두 기간 모두에 25% 버퍼 가이드라인을 적용하면, 앵커 블록이 제시간에 전파되고 실행될 수 있을 때 가스 한도 L L이 실현 가능합니다.

첫 번째 천장은 D D가 나중에 이동함에 따라 낮아지고, 두 번째 천장은 높아집니다. 최적점은 교차점입니다.

전송을 기준으로 최적화된 값은 두 윈도우 모두에서 25% 가이드라인을 유지하며, $D ≈ 6.4초에서 약 4억 2200만 건 입니다. 25% 버퍼는 엄격한 하한값이 아니라 가이드라인이므로, 이를 약간 완화하여 대략적인 운영 수치인 $D = 6초에서 4억 5000만 건을 권장합니다. 이는 마감 시간을 약간 앞당겨 전파 여유 공간을 확보하는 대신 더 높은 한도를 설정하는 것입니다. 실행 버퍼는 약 25%를 유지하고, 전파 버퍼는 이러한 변화를 흡수하여 25%에서 약 11%로 감소합니다. 따라서 앵커 블록은 전파 윈도우의 75% 대신 약 89%를 사용하게 됩니다.

잔여 불확실성은 전파 적합(p90 백분위수 및 Toni의 꼬리 강조 가중치와 보수적인 \sqrt{n\cdot\text{size}} √ n ⋅ size 가중치)과 스냅 압축 후 가정에 있습니다. 전파 개선(아래 참조)을 통해 450M에서 대칭적인 25% 버퍼를 복원하거나 한계를 더 높일 수 있습니다.

적대적 블록

전송 차단은 최악의 경우는 아닙니다.

전송 블록은 슬롯의 기준점이 되지만, 우리가 만들 수 있는 가장 밀도가 높은 블록은 아닙니다. 전송 블록의 \beta_t \approx 0.0105 β t ≈ 0.0105 B/gas는 하한값이지 상한값이 아닙니다. 21k 상한선을 건드리지 않고 전송 블록의 가격을 책정할 수 없으므로, 우리의 목표는 설계상 최악의 경우를 만드는 것입니다. 즉, 프로토콜이 가격을 매기는 모든 구성은 가스당 최대 \beta_t β t 바이트를 포함해야 합니다 . \beta_t β t 보다 높은 가격으로 책정된 블록은 전송 블록보다 먼저 슬롯을 차지하게 되어 L^* L ∗ 값을 422M 아래로 떨어뜨리므로, 우리는 각 블록을 검사합니다.

단일 리소스 블록의 바이트 밀도는 연산당 바이트 사용량을 가스 비용으로 나눈 값입니다. β = b/c β = b / c :

• 1층 1 / F 층별 통화 데이터
• 콜드 SLOAD (32바이트 BAL 키)의 경우 32/c 32 / c
• BALANCE (20바이트 주소)와 같은 콜드 계정 액세스의 경우 20/c 20 / c를 사용합니다.
• 콜드 SSTORE 의 경우 64/c 64 / c (BAL에 32바이트 키 + 32바이트 값)

혼합 블록은 가능한 한 가장 밀도가 높고 저렴한 통화 데이터(16가스/바이트 표준 요금, 7976 하한선 미만을 유지하는 비율까지)를 추가하고 나머지는 콜드 SLOAD 로 채웁니다.

글램스터담의 예상 가격(콜드 SLOAD 3,000, 콜드 계정 액세스 3,000, 콜드 SSTORE 13,000, 통화 데이터 바닥 F = 64 ) 을 기준으로 메뉴를 평가하면 다음과 같습니다.

주요 관찰 사항:

• 콜드 SLOAD 만이 전송 라인과 견줄 만한 성능을 보입니다. 콜드 BALANCE 는 3,000 가스(0.63배)로 20바이트 주소만 BAL에 기록하고, 콜드 SSTORE 13,000 가스(0.47배)로 64바이트 키+값을 기록하는데, 둘 다 전송 라인보다 훨씬 저렴합니다. 콜드 SLOAD 의 3,000 가스로 지불되는 32바이트 스토리지 키는 상태 접근이 가스당 추가할 수 있는 가장 바이트 밀도가 높은 정보이며, 이것이 바로 공격자 블록이 콜드 SLOAD 로 구성되는 이유입니다.

• Cold SLOAD 본질적으로 선 위에 있습니다. 3,000 가스에서 32바이트 키는 0.01067 B/gas를 제공하며, 이는 \beta_t β t 보다 1% 높습니다. 선은 정확히 c = 3{,}041 c = 3,041 에서 도달합니다.

• 가격이 책정된 두 블록, 즉 순수 통화 데이터(1.49배)와 혼합 블록(2.25배)이 기준선을 초과했습니다. 두 경우 모두 통화 데이터 가격이 전송 기준선보다 낮게 책정된 동일한 원인으로 인해 기준선을 초과했지만, 다음에서 살펴보듯이 해결 방법은 서로 다릅니다.

가장 작은 해결책: 통화 데이터 최저치를 다시 높이는 것

순수 호출 데이터 블록이 기준을 초과하는 이유는 단 한 줄 때문입니다. EIP-7976의 최저값인 64 gas/byte는 1/64 = 0.0156 B / gas 를 의미하며, 이는 \beta_t β t 보다 49% 높습니다. 해결책은 단 하나의 상수를 추가하는 것입니다. 최저값을 64로 올리면 됩니다.

이는 헤고타의 가장 간단한 데이터 가격 조정 방식입니다. 하지만 이 방식도 혼합 블록 문제를 해결하지는 못합니다. F 값 을 높이면 저렴한 콜데이터 점유율( 16/64 = 25% 에서 16/96 = 16.7 % 로 ) 은 줄어들지만, 콜드 SLOAD 잔여 데이터가 BAL에 계속 추가되어 전체 바이트 밀도가 β ( 96 , 3000 ) = 0.0193 B / gas 가 됩니다 . 이는 여전히 기준선보다 1.84배 높은 수치입니다.

실제로 F → ∞ 일 때 바이트 밀도는 32/c 32 / c 에 가까워지는데, 이는 SLOAD 블록 밀도 자체와 같습니다. 즉, 유한한 호출 데이터 플로어가 혼합 블록의 밀도를 충분히 낮추지 못한다는 의미입니다.

혼합 블록을 길들이는 세 가지 방법

남은 병목 현상은 회선의 1.84배에 달하는 혼합 블록입니다. 세 가지 옵션이 있습니다. 첫 번째와 두 번째 옵션은 방금 도출한 64 → 96 플로어 증가분 위에 콜데이터 플로어에서 볼 수 없는 BAL 바이트의 가격을 책정하는 것입니다. 세 번째 옵션 은 BAL 가격을 책정하지 않고 대신 혼합 블록이 악용하는 이중 속도 콜데이터 구조를 제거하는 것입니다.

옵션 1: BAL 바이트를 최저 요금 계산에 포함. 가장 확실한 해결책은 BAL 바이트를 최저 요금 계산에 포함하는 것입니다. 토니의 제안은 7623 방식의 최저 요금 계산을 BAL 바이트를 포함한 모든 페이로드 바이트로 확장합니다. 이렇게 하면 가격이 책정된 모든 바이트는 가스당 최대 1/96 바이트를 사용하게 되며, SLOAD 전혀 변경되지 않습니다. 이 방식에는 모든 콜드 액세스 경로 에 런타임 최저 요금 누적기를 적용하는 새로운 가스 회계 메커니즘이 필요합니다. 이 메커니즘은 최저 요금 계산에만 적용되므로 일반 사용자와 21k 전송에는 영향을 미치지 않습니다.

옵션 2: 내재적 데이터 추가 요금. 대안으로, 모든 BAL 생성 작업(콜드 액세스, 콜드 스토리지 등)에 명시적인 데이터 구성 요소를 추가할 수 있습니다. 이는 상수만 사용하는 가장 간단한 메커니즘으로, 최저 요금 위에 추가되는 방식입니다. 그러나 이러한 방식으로 BAL 바이트에 가격을 책정하는 것은 사실상 상태 액세스 가격을 재조정하는 것과 같습니다. 혼합 블록을 최저 요금선에 맞추려면 콜드 상태 액세스 비용을 상당히 높여야 하는데, 이는 실행 안전성은 확보되더라도 고정 앵커 원칙과 상충됩니다. 또한, 이는 이미 최저 요금선 아래에 있는 순수 연산 코드 블록의 가격을 더욱 왜곡시킵니다.

옵션 3: 균일한 콜데이터 가격, BAL 가격 책정 없음. 콜데이터는 두 가지 요금, 즉 저렴한 16가스/바이트 표준 요금(최저 점유율까지 적용됨)과 그보다 높은 최저 점유율 요금을 사용하기 때문에 혼합 블록이 작동합니다. 콜데이터에 단일 요금 p p 를 부여하면 이 병목 현상이 사라집니다. 모든 콜데이터 바이트는 p p 의 비용이 들기 때문에 콜데이터 블록은 1/p 1 / p 로 제한되며, 이를 상태 블록에 혼합하면 밀도만 희석됩니다. 최악의 경우 가장 밀도가 높은 가격 책정되지 않은 상태 연산인 32/c 32 / c 의 콜드 SLOAD 로 돌아갑니다. 따라서 p p는 순수 콜데이터가 SLOAD 보다 높은 비용을 지불하지 않도록 하는 데만 필요합니다.

이는 최저 요율인 96에 거의 근접하는 수준입니다. 최저 요율을 낮추는 것은 요율 자체가 아니라 누가 비용을 부담하는지를 바꾸는 것입니다. 최저 요율 96은 데이터 사용량이 많은 거래에만 적용되는 반면, 균일한 94 요율은 모든 호출 데이터 바이트에 최저 요율을 적용합니다. 이는 표준 요율 16 대비 약 6배 상승한 수치입니다. 하지만 그 대신 가장 간단한 메커니즘(단일 요율, 잔액 관리 불필요, max() 사용 불필요)을 제공합니다.

선택은 메커니즘 복잡성과 영향 범위 사이에서 이루어집니다. 옵션 1은 사용자에게 미치는 영향이 가장 적습니다. 호출 데이터 최소값을 초과하는 블록에만 영향을 주기 때문입니다. 하지만 새로운 가스 계산 메커니즘이 도입됩니다. 옵션 2와 3은 모두 상수만 변경하는 방식이지만, BAL에 영향을 미치는 연산을 사용하는 모든 사용자(옵션 2) 또는 호출 데이터를 사용하는 모든 사용자(옵션 3)에게 영향을 미칩니다. 옵션 3은 옵션 2보다 깔끔하고 논리적으로 타당합니다. BAL 바이트를 생성하는 연산은 이미 실행 비용과 대역폭 비용에 대한 정확한 가격을 가지고 있기 때문입니다. 혼합 블록은 호출 데이터의 이중 속도 구조만 악용하므로, 이를 제거하면 BAL 바이트를 전혀 건드리지 않고도 문제를 직접 해결할 수 있습니다.

전파 속도가 빨라지면 어떻게 될까요?

가격 책정은 전송 라인에서 구성을 균등화할 수 있지만 그 이하로 내려갈 수는 없습니다. 그 지점을 넘어서면 멤풀 기반 페이로드 재구성(대부분의 페이로드 바이트는 이미 피어의 멤풀에 저장됨), 가십 및 토폴로지 개선, 또는 소거 부호화 전파를 통해 전파 모델 자체만 움직일 수 있습니다. x% x % 더 나은 기울기로 중앙 교차점을 다시 실행하면 다음과 같습니다.

패턴은 대략 기울기 개선 10%당 가스 제한이 +14~18M 정도 증가 하며, 마감 시간은 단계적으로 앞당겨집니다. 기울기가 -20%일 경우 라운드 450M에 도달하는 데 $D = 6.0초가 소요되어 권장 제한에서 대칭적인 25% 버퍼를 복원하고, -50%일 경우 약 501M에 도달하는 데 $D \approx 5.3초가 소요됩니다. 고정 오버헤드를 절반으로 줄이는 것(569ms → 285ms)만으로도 기울기 10분위수(약 +19M)만큼의 이득이 있습니다. 전송량이 많은 페이로드는 압축률이 가장 낮은 형태(서명은 임의의 바이트)이므로 압축 기반 개선은 앵커 블록 자체보다 공격자 꼬리 부분에 더 큰 도움이 됩니다.

이 전체 프레임워크의 한계는 실행 시간입니다. D 가 T_1 에 고정 오버헤드를 더한 값에 가까워질수록 실행 창은 약 8.2초, 즉 100Mgas/s의 75%에서 6억 1800만 건으로 포화됩니다. 이를 넘어서려면 실제 실행 처리량을 높여야 하는데, 이는 과도하게 비싼 컴퓨팅 작업의 가격 재조정에 대한 병렬 분석에서 다루는 내용입니다. 이 분석은 이 보고서와 한 가지 점에서 연결됩니다. 실행 비용이 저렴해지면 더 많은 트랜잭션이 calldata 플로어로 몰리므로, F = 96 에서 의 플로어 발생률은 가격 재조정 후 실행 비용과 비교하여 평가해야 합니다.

다른 자원에 대한 영향

주 성장: CPSB 재추출

최신 EIP-8037 사양에서는 CPSB = 1530 고정했는데, 이는 120GiB/년 목표에 대해 1억 5천만 기준 한계에서 도출된 값이며, 재도출은 추후 포크에서 진행하도록 명시적으로 연기했습니다. CPSB 값을 1530으로 유지하면 4억 5천만 기준 한계에서의 목표 증가율은 약 360GiB/년이 됩니다. 새로운 한계에서 사양 자체의 도출 방식을 사용하면 다음과 같습니다.

계정 생성 시에만 상태 가스 비용이 발생하므로, 이체 과정은 어느 방향으로든 영향을 받지 않습니다. 이는 저장소 모델을 사용하는 별도의 차원에서 이루어집니다.

또한 블록 제한 상향 및 CPSB 증가에 대한 실제 수요가 어떻게 반응할지에 대한 의문도 있습니다. 최종 수치는 사용자들이 글램스터담 포크에 어떻게 적응하는지 관찰한 후에 달라질 가능성이 높습니다.

이력: 가격 재조정은 필요 없지만, 만료일이 더욱 중요해집니다.

측정된 geth 히스토리(헤더, 본문 및 영수증)는 2024년 5월부터 2025년 5월까지 3,600만 건의 제한 기간 동안 하루 약 525MiB, 즉 연간 약 180GiB 씩 증가했습니다( 자세한 내용은 여기 참조 ). 이를 4억 5천만 건으로 선형적으로 확장하면 연간 약 2.2TiB가 됩니다. 이 수치에는 영수증에 저장되는 로그가 이미 포함되어 있지만, 측정 기간이 BAL(EIP-7928) 도입 이전이므로 BAL은 제외되었습니다. BAL은 전송 블록 바이트의 약 41%를 차지하는 두 번째 히스토리 채널로, 상태 접근이 많이 필요한 구성에서 주로 사용됩니다. 하지만 EIP-7928은 저장된 BAL을 해시 루트까지 삭제할 수 있도록 허용하므로, BAL의 영구적인 기여도는 보존 기간에 따라 달라집니다.

이러한 이력 증가율에서는 롤링 이력 만료(EIP-4444 계열)가 검증자에게 더욱 중요해집니다. 하지만 이 증가율은 여전히 관리 가능한 수준이므로 가격 재조정은 필요하지 않습니다.

메모리: 할 일 없음

최악의 경우 EVM 메모리 사용량은 트랜잭션당 할당량입니다. EIP-7825 제한에 대한 제곱에 비례하는 확장 비용으로 인해 단일 프레임당 약 3~4MB가 사용되며, 순차적으로 실행되는 트랜잭션 사이에 메모리가 해제됩니다. 블록 제한이 높아지면 블록당 트랜잭션 수가 늘어나지만 동시 메모리 사용량은 증가하지 않습니다. 이는 7825 제한이 상향 조정되거나 선형 메모리 가격 책정 방식(EIP-7923/7686)이 보상 제한 없이 출시될 경우에만 변경됩니다.

계산: 가격 인하

100Mgas/s 기준치를 고정하면 대부분의 연산 비용이 현재 기준치에 비해 과도하게 높아진다는 단점이 있습니다. 즉, 최악의 경우 클라이언트 실행 시간이 현재 가스 비용보다 낮기 때문에 실제로 소요되는 시간보다 블록의 가스 예산을 더 많이 소모하게 됩니다. 현재 클라이언트 성능 결과를 기준으로 하면 약 62개의 EVM 연산 및 사전 컴파일 연산의 가격을 재조정할 수 있으며, 그중 36개는 기준치에서 1가스 미만으로 낮아질 수 있습니다. 이러한 연산은 비용이 저렴하고 실행 빈도가 높은 산술, 비트 연산, 스택 및 메모리 연산입니다.

이러한 과도한 가격 책정은 처리량 손실을 초래합니다. 메인넷 트래픽 에서 현재 블록 가스의 약 12.4%가 실제 실행 비용보다 높은 비용이 청구되는 작업에 낭비되고 있습니다 . 정수 반올림( max(⌈exact⌉, 1) )을 사용하여 가격을 낮추면 이 비율이 약 2.6% 로 줄어듭니다.

10% 수익 증가는 좋지만, 62개 작업의 가격을 재조정하는 데 드는 비용을 상쇄하기에는 부족할 가능성이 높습니다. 따라서 여기서는 Hegota의 계산 비용을 변경하지 않는 것이 좋습니다.

헤고타가 실제로 배송하는 것

제한 사항

• 모든 전파 번호는 Toni의 p90 MEV-부스트 적합( 569 + 0.443 ⋅ KB , 빠른 압축 크기, 방출 후 p90 - min 으로 측정 )과 T1 = 3초 가정을 상속합니다. 이 두 가지는 선택 사항이며, 확정된 값은 아닙니다. Toni의 보수적 인 √n ⋅ size 가중치는 더 가파른 기울기를 제공하며( 로컬 /상위 백분위수 적합은 더욱 가파름), 각각 최적값을 낮춥니다. 교차점은 T1 T1 의 초당 약 51M씩 이동하며 기울기에 비례합니다.

• 전송당 바이트 수치는 확인된 RLP 최소 길이 인코딩에서 파생되었으므로 프레임 오버헤드는 해결되었습니다. 그러나 Toni의 전파 모델은 스냅 처리 후 바이트를 기준으로 보정되었으며 전송 블록은 압축 불가능 하다고 가정합니다(스냅 처리 후 ≈ 원시 221B). 실제 와이어 압축과 트랜잭션 수에 따른 block_access_index 너비의 증가는 모델링되지 않았으며 모든 주요 수치를 변경합니다. 특히 압축은 경계를 완화하고 L^* L ∗를 증가시킬 뿐입니다.

• 크로스오버 모델은 전파와 실행을 엄격하게 직렬로 처리하며 25%의 버퍼를 사용합니다. 파이프라인 처리 또는 중복 검증을 사용하면 최적점이 바깥쪽으로 이동합니다.

• 8037 수치는 현재 사양( CPSB = 1530 )을 따릅니다. 로컬 EIP 저장소에는 여전히 이전 자동 스케일링 초안이 포함되어 있으며, 해당 수치는 적용되지 않습니다.

• 과거 예측은 현재 측정된 과거 증가량(헤더, 본문, 수신량)을 가스 제한에 비례하여 선형적으로 조정합니다. 관찰된 30M→36M 스케일링은 선형에 가깝지만, 구성 변화(블롭 채택, 실제 BAL 크기)에 따라 달라질 수 있습니다.