3일 후, 이더리움은 이러한 중대한 변화를 맞이할 것입니다

원문 출처 Sahil Sojitra

편집｜Odaily 별자리 일보 Golem

2025년 12월 3일에 활성화될 예정인 Fusaka 하드포크는 이더리움이 Pectra 이후 또 한 번의 주요 네트워크 업그레이드를 의미하며, 이 암호화 거대 기업이 확장성에 중요한 발걸음을 내딛는 것을 나타냅니다.

Pectra 업그레이드의 EIP는 성능, 보안 및 개발자 도구 향상에 중점을 두었습니다. Fusaka 업그레이드의 EIP는 확장성, 연산 코드 업데이트 및 실행 보안 등에 중점을 두고 있습니다.

PeerDAS (EIP-7594)는 노드가 모든 데이터를 다운로드하지 않고도 Blob을 검증할 수 있도록 하여 데이터 가용성을 향상시킵니다. 여러 업그레이드는 실행 보안을 강화했으며, 여기에는 ModExp 제한 (EIP-7823), 거래 Gas 한도 제한 (EIP-7825) 및 ModExp Gas 비용 업데이트 (EIP-7883)가 포함됩니다. 이번 Fusaka 업그레이드는 결정론적 제안자 전방 메커니즘 (EIP-7917)을 통해 블록 생성을 개선하고, 실행 비용에 연계된 "유지 가격"을 설정하여 Blob 비용의 안정성을 유지합니다 (EIP-7918).

기타 향상 기능으로는 RLP 형식의 블록 크기 제한 (EIP-7934), 비트 연산 속도를 높이기 위한 새로운 CLZ 연산 코드 추가 (EIP-7939), 현대 암호학 및 하드웨어 보안 키와의 호환성을 높이기 위한 secp256r1 프리컴파일 도입 (EIP-7951) 등이 있습니다.

Fusaka는 Fulu(실행 계층)와 Osaka(합의 계층)의 조합 이름입니다. 이는 이더리움이 고도로 확장 가능하고 데이터가 풍부한 미래로 나아가는 또 한 걸음을 의미하며, 이 미래에서는 Layer 2 Rollup이 더 낮은 비용과 더 빠른 속도로 운영될 수 있습니다.

본 기사는 Fusaka 하드포크의 9대 핵심 EIP 제안에 대해 깊이 분석할 것입니다.

EIP-7594：PeerDAS ------노드 데이터 가용성 샘플링

이더리움은 이 제안이 필요합니다. 왜냐하면 네트워크는 사용자(특히 Rollup 사용자)에게 더 높은 데이터 가용성을 제공하고자 하기 때문입니다.

그러나 현재 EIP-4844 설계 하에서는 각 노드가 발행된 Blob을 검증하기 위해 여전히 많은 Blob 데이터를 다운로드해야 합니다. 이는 모든 노드가 모든 데이터를 다운로드해야 한다면 네트워크의 대역폭과 하드웨어 요구 사항이 증가하고 탈중앙화 수준에도 영향을 미치기 때문에 확장성 문제를 초래합니다. 이 문제를 해결하기 위해 이더리움은 노드가 모든 데이터를 다운로드하지 않고도 데이터의 가용성을 확인할 수 있는 방법이 필요합니다.

데이터 가용성 샘플링(DAS)은 노드가 소량의 무작위 데이터를 확인하도록 허용함으로써 이 문제를 해결합니다.

하지만 이더리움은 기존 Gossip 네트워크와 호환되는 DAS 방법이 필요하며, 블록 생산자에게 과도한 계산 부담을 주지 않아야 합니다. PeerDAS의 생성은 이러한 요구를 충족시키기 위해 이루어졌으며, 노드 요구 사항을 낮게 유지하면서 Blob 처리량을 안전하게 증가시킵니다.

PeerDAS는 노드가 전체 데이터가 발행되었는지 검증하기 위해 소량의 데이터 조각만 다운로드하도록 허용하는 네트워크 시스템입니다. 노드는 모든 데이터를 다운로드할 필요 없이 일반적인 gossip 네트워크를 통해 데이터를 공유하고, 특정 데이터 조각을 보유한 노드를 찾아 필요한 소량의 샘플만 요청합니다. 핵심 아이디어는 노드가 데이터 조각의 무작위 소량만 다운로드함으로써 전체 데이터 조각의 존재를 확신할 수 있다는 것입니다. 예를 들어, 노드는 약 1/8의 데이터만 다운로드할 수 있으며, 전체 256 KB 데이터 조각을 다운로드할 필요는 없습니다. 그러나 많은 노드가 서로 다른 부분을 샘플링하기 때문에 누락된 데이터는 빠르게 발견됩니다.

샘플링을 구현하기 위해 PeerDAS는 EIP-4844의 각 데이터 조각에 대해 기본적인 오류 정정 코드를 사용합니다. 오류 정정 코드는 추가적인 중복 데이터를 추가하는 기술로, 일부 데이터 조각이 누락되더라도 원본 데이터를 복원할 수 있습니다.

Blob은 원본 데이터와 추가적인 인코딩 데이터를 포함하는 "행"으로 변환되어, 이후 데이터 재구성이 가능하도록 합니다. 이 행은 KZG 약속과 관련된 최소 검증 단위인 "셀"이라고 불리는 여러 개의 작은 조각으로 나뉩니다. 모든 "행"은 이후 "열"로 재조직되며, 각 열은 모든 행의 동일한 위치에서 셀을 포함합니다. 각 열은 특정 gossip 서브넷에 할당됩니다.

노드는 자신의 노드 ID에 따라 특정 열을 저장하고, 각 시간 슬롯에서 피어 노드로부터 몇 개의 열을 샘플링합니다. 만약 노드가 50% 이상의 열을 수집하면, 데이터를 완전히 재구성할 수 있습니다. 수집된 열이 50% 미만일 경우, 누락된 열을 피어 노드에 요청해야 합니다. 이는 데이터가 실제로 발행되었다면 항상 재구성이 가능하다는 것을 보장합니다. 간단히 말해, 총 64개의 열이 있을 경우, 노드는 약 32개의 열만으로도 전체 Blob을 재구성할 수 있습니다. 노드는 일부 열을 보유하고, 피어 노드로부터 일부 열을 다운로드합니다. 네트워크에 절반의 열이 존재하기만 하면, 노드는 모든 것을 재구성할 수 있으며, 일부 열이 누락되더라도 가능합니다.

또한, EIP-7594는 중요한 규칙을 도입했습니다: 어떤 거래도 6개 이상의 Blob을 포함할 수 없습니다. 이 제한은 거래 검증, gossip 전파, 블록 생성 및 블록 처리 중에 강제로 시행되어야 합니다. 이는 단일 거래가 Blob 시스템을 과부하시키는 극단적인 상황을 줄이는 데 도움이 됩니다.

PeerDAS는 "셀 KZG 증명"이라고 불리는 기능을 추가했습니다. 셀 KZG 증명은 KZG 약속이 Blob 내의 특정 셀(소단위)과 실제로 일치함을 나타냅니다. 이를 통해 노드는 샘플링하고자 하는 셀만 다운로드할 수 있습니다. 데이터 무결성을 보장하면서 전체 Blob을 획득하는 것은 데이터 가용성 샘플링에 매우 중요합니다.

하지만 이러한 모든 셀 증명을 생성하는 비용은 매우 높습니다. 블록 생산자는 많은 Blob에 대해 이러한 증명을 반복적으로 계산해야 하므로 속도가 너무 느려집니다. 그러나 증명 검증의 비용은 매우 낮기 때문에, EIP-7594는 Blob 거래 발신자가 모든 셀 증명을 미리 생성하고 이를 거래 포장기에 포함하도록 요구합니다.

이로 인해 거래 gossip(PooledTransactions)는 이제 수정된 포장기를 사용합니다:

rlp([txpayloadbody, wrapperversion, blobs, commitments, cellproofs])

새 포장기에서 cellproofs는 각 Blob의 각 셀에 대한 모든 증명을 포함하는 목록일 뿐입니다(예: [cellproof0, cellproof1, …]). 다른 필드인 txpayloadbody, blobs 및 commitments는 EIP-4844와 완전히 동일합니다. 차이점은 기존의 단일 "proofs" 필드가 제거되고 새로운 cellproofs 목록으로 대체되었으며, 현재 사용 중인 포장기 형식을 나타내는 wrapper_version이라는 필드가 추가되었습니다.

PeerDAS는 이더리움이 노드 작업량을 증가시키지 않고 데이터 가용성을 향상시킬 수 있도록 합니다. 현재 노드는 총 데이터의 약 1/8만 샘플링하면 됩니다. 미래에는 이 비율이 1/16 또는 1/32로 줄어들 수 있어 이더리움의 확장성을 높일 수 있습니다. 이 시스템은 각 노드가 많은 피어 노드를 보유하고 있기 때문에 잘 작동합니다. 따라서 특정 피어 노드가 필요한 데이터를 제공할 수 없는 경우, 해당 노드는 다른 피어 노드에 요청할 수 있습니다. 이는 자연스럽게 중복 메커니즘을 구축하고 보안을 강화하며, 노드는 실제 필요 이상의 데이터를 저장할 수 있는 선택권이 있어 네트워크의 보안을 더욱 강화합니다.

검증 노드는 일반 전체 노드보다 더 많은 책임을 집니다. 검증 노드는 성능이 더 강력한 하드웨어를 운영하고 있기 때문에, PeerDAS는 검증 노드의 총 수에 따라 해당 데이터 호스팅 부하를 할당합니다. 이는 항상 더 많은 데이터를 저장하고 공유할 수 있는 안정적인 노드 그룹이 존재하도록 보장하여 네트워크의 신뢰성을 높입니다. 간단히 말해, 90만 개의 검증 노드가 있다면 각 검증 노드는 총 데이터의 일부를 저장하고 서비스하도록 할당될 수 있습니다. 검증 노드는 더 강력한 기계를 보유하고 있기 때문에, 네트워크는 이들이 데이터 가용성을 보장할 수 있다고 신뢰할 수 있습니다.

PeerDAS는 행 샘플링이 아닌 열 샘플링을 사용합니다. 이는 데이터 재구성을 크게 단순화할 수 있기 때문입니다. 노드가 전체 행(전체 Blob)을 샘플링하면, 존재하지 않는 추가 "확장 Blob"을 생성해야 하므로 블록 생산자의 속도가 느려집니다.

열 샘플링을 통해 노드는 추가 행 데이터를 미리 준비할 수 있으며, 거래 발신자가(블록 생산자가 아닌) 필요한 증명을 계산합니다. 이는 블록 생성 속도와 효율성을 유지할 수 있습니다. 예를 들어, 하나의 Blob이 4×4 셀 그리드라고 가정해 보겠습니다. 행 샘플링은 한 행에서 모든 4개의 셀을 가져오는 것을 의미하지만, 일부 확장 행이 아직 준비되지 않았기 때문에 블록 생산자는 현장에서 이를 생성해야 합니다. 반면 열 샘플링은 각 행(각 열)에서 하나의 셀을 추출하여 필요한 추가 셀을 미리 준비할 수 있습니다. 이렇게 하면 노드는 블록 생성 속도를 늦추지 않고 데이터를 검증할 수 있습니다.

EIP-7594는 EIP-4844와 완전히 호환되므로 이더리움의 기존 기능을 손상시키지 않습니다. 모든 테스트와 세부 규칙은 합의 및 실행 규격에 포함되어 있습니다.

모든 DAS 시스템의 주요 보안 위험은 "데이터 은폐 공격"입니다. 즉, 블록 생산자가 데이터가 가용하다고 가장하지만 실제로는 일부 데이터를 숨기는 것입니다. PeerDAS는 무작위 샘플링을 사용하여 이러한 상황을 방지합니다: 노드는 데이터의 무작위 부분을 확인합니다. 샘플링된 노드가 많을수록 공격자가 속이는 것이 더 어려워집니다. EIP-7594는 노드 총 수(n), 샘플 총 수(m) 및 각 노드의 샘플 수(k)에 따라 이러한 공격이 성공할 가능성을 계산할 수 있는 공식을 제공합니다. 약 10,000개의 노드가 있는 이더리움 메인넷에서 공격 성공 확률은 극히 낮으므로 PeerDAS는 안전한 것으로 간주됩니다.

EIP-7823：MODEXP에 1024 바이트 상한 설정

이 제안의 필요성은 이더리움의 현재 MODEXP 프리컴파일 메커니즘이 수년간 여러 합의 취약점을 초래했기 때문입니다. 이러한 취약점은 대부분 MODEXP가 입력 데이터 양을 매우 방대하고 비현실적으로 허용하여 클라이언트가 수많은 예외 상황을 처리해야 했기 때문입니다.

모든 노드가 거래에서 제공된 모든 입력을 처리해야 하므로 상한이 없으면 MODEXP를 테스트하기가 더 어려워지고, 오류가 발생하기 쉬우며, 서로 다른 클라이언트에서 다르게 작동하기도 합니다. 과도한 입력 데이터는 gas 비용 공식을 예측하기 어렵게 만들며, 데이터 양이 무한히 증가할 수 있을 때 가격을 책정하기가 어렵습니다. 이러한 문제는 EVMMAX와 같은 도구를 사용하여 MODEXP를 EVM 수준의 코드로 교체하는 것을 어렵게 만듭니다. 고정된 제한이 없으면 개발자는 안전하고 최적화된 실행 경로를 만들 수 없습니다.

이러한 문제를 줄이고 이더리움의 안정성을 높이기 위해 EIP-7823은 MODEXP 입력 데이터 양에 엄격한 상한을 추가하여 프리컴파일 프로세스를 보다 안전하고 테스트하기 쉬우며 예측 가능하게 만듭니다.

EIP-7823은 MODEXP에서 사용되는 모든 세 개의 길이 필드(기수, 지수 및 모듈러스)가 8192 비트, 즉 1024 바이트 이하이어야 한다는 간단한 규칙을 도입합니다. MODEXP 입력은 EIP-198에서 정의된 형식을 따릅니다: \<len(BASE)> \<len(EXPONENT)> \<len(MODULUS)> \<BASE> \<EXPONENT> \<MODULUS> 따라서 이 EIP는 길이 값만 제한합니다. 만약 어떤 길이가 1024 바이트를 초과하면, 프리컴파일은 즉시 중단되고 오류를 반환하며 모든 gas를 소모합니다.

예를 들어, 누군가 2000 바이트 길이의 기수를 제공하려고 하면, 호출은 작업이 시작되기 전에 실패합니다. 이러한 제한은 모든 실제 응용 시나리오를 충족할 수 있습니다. RSA 검증은 일반적으로 1024 비트, 2048 비트 또는 4096 비트와 같은 키 길이를 사용하며, 이러한 길이는 새로운 제한 범위 내에 있습니다. 타원 곡선 연산은 더 작은 입력 크기를 사용하며, 일반적으로 384 비트 미만이므로 영향을 받지 않습니다.

이러한 새로운 제한은 미래의 업그레이드에도 도움이 됩니다. 미래에 EVMMAX를 사용하여 MODEXP를 EVM 코드로 다시 작성할 경우, 개발자는 일반적인 입력 크기(예: 256 비트, 381 비트 또는 2048 비트)에 대한 최적화 경로를 추가하고 드문 경우에는 느린 폴백 방안을 사용할 수 있습니다. 고정된 최대 입력 크기를 통해 개발자는 매우 일반적인 모듈러스에 대한 특별 처리를 추가할 수 있습니다. 이전에는 입력 크기가 제한되지 않아 설계 공간이 너무 방대하여 안전하게 관리하기 어려웠기 때문에 이러한 것도 실현할 수 없었습니다.

이 변경이 과거 거래를 손상시키지 않도록 확인하기 위해 저자는 블록 5,472,266(2018년 4월 20일)부터 블록 21,550,926(2025년 1월 4일)까지의 모든 MODEXP 사용 사례를 분석했습니다. 결과는 역사적으로 모든 성공적인 MODEXP 호출이 513 바이트를 초과하는 입력을 사용하지 않았으며, 이는 새로운 1024 바이트 제한보다 훨씬 낮다는 것을 보여주었습니다. 대부분의 실제 호출은 32 바이트, 128 바이트 또는 256 바이트와 같은 더 작은 길이를 사용했습니다.

무효하거나 손상된 호출도 존재합니다. 예를 들어 빈 입력, 반복 바이트로 채워진 입력 및 매우 크지만 무효한 입력 등이 있습니다. 이러한 호출은 새로운 제한 하에서도 무효로 간주됩니다. 따라서 EIP-7823은 기술적으로 중대한 변경이지만, 실제로는 과거 거래의 결과를 변경하지 않습니다.

보안 측면에서 허용된 입력 크기를 줄이는 것은 새로운 위험을 초래하지 않습니다. 반대로, 이는 클라이언트 간의 오류와 불일치를 초래했던 이전의 불필요한 극단적인 상황을 제거합니다. MODEXP 입력을 합리적인 크기 범위로 제한함으로써 EIP-7823은 시스템을 보다 예측 가능하게 만들고, 이상한 극단적인 상황을 줄이며, 서로 다른 구현 간의 오류 가능성을 낮춥니다. 이러한 제한은 미래의 업그레이드(예: EVMMAX)가 최적화된 실행 경로를 도입할 경우 시스템이 보다 원활하게 전환될 수 있도록 준비하는 데에도 도움이 됩니다.

EIP-7825：거래 1670만 Gas 상한

이더리움은 이 제안이 필요합니다. 현재 단일 거래가 거의 전체 블록의 Gas 상한을 소모할 수 있기 때문입니다.

이는 여러 가지 문제를 초래합니다. 하나의 거래가 블록의 대부분 자원을 소모하여 DoS 공격과 유사한 느린 지연을 초래할 수 있습니다. 많은 Gas를 소모하는 작업이 이더리움의 상태 업데이트를 너무 빠르게 증가시킵니다. 블록 검증 속도가 느려지고, 노드가 이를 따라잡기 어려워집니다.

사용자가 거의 모든 Gas를 소모하는 대규모 거래(예: 4000만 Gas 블록에서 3800만 Gas를 소모하는 거래)를 제출하면, 다른 일반 거래는 해당 블록에 포함될 수 없으며, 각 노드는 해당 블록을 검증하는 데 추가적인 시간을 소모해야 합니다. 이는 네트워크의 안정성과 탈중앙화에 위협이 됩니다. 검증 속도가 느려지면 성능이 낮은 노드가 뒤처지게 됩니다. 이 문제를 해결하기 위해 이더리움은 단일 거래가 사용할 수 있는 Gas 수량을 제한하는 안전한 Gas 상한이 필요합니다. 이를 통해 블록 부하를 보다 예측 가능하게 하고, DoS 공격의 위험을 줄이며, 노드의 부하를 보다 균형 있게 유지할 수 있습니다.

EIP-7825는 모든 거래가 소모하는 Gas가 16,777,216(2²⁴)를 초과해서는 안 된다는 강력한 규칙을 도입합니다. 이는 프로토콜 수준의 상한이 되어, 사용자 거래 전송, 거래 풀에서 거래 확인 및 검증자가 거래를 블록에 패키징하는 모든 단계에 적용됩니다. 누군가가 전송하는 Gas 상한이 이 값을 초과하면, 클라이언트는 즉시 해당 거래를 거부하고 MAXGASLIMIT_EXCEEDED와 유사한 오류를 반환해야 합니다.

이 상한은 블록 Gas 상한과 완전히 독립적입니다. 예를 들어, 블록 Gas 상한이 4000만일지라도, 어떤 단일 거래의 Gas 소모는 1670만을 초과할 수 없습니다. 이는 각 블록이 여러 거래를 수용할 수 있도록 보장하기 위한 것입니다. 단일 거래가 전체 블록을 차지하는 것을 방지합니다.

이를 더 잘 이해하기 위해, 블록이 4000만 Gas를 수용할 수 있다고 가정해 보겠습니다. 이 상한이 없다면, 누군가가 3500만에서 4000만 Gas를 소모하는 거래를 보낼 수 있습니다. 이 거래는 블록을 독점하게 되어 다른 거래에 공간을 남기지 않게 됩니다. 이는 마치 한 사람이 버스를 독점하여 다른 사람들이 탑승할 수 없는 것과 같습니다. 새로운 1670만 Gas 상한은 블록이 자연스럽게 여러 거래를 수용하도록 하여 이러한 남용을 방지합니다.

이 제안은 클라이언트가 거래를 검증하는 방법에 대한 구체적인 요구 사항도 제시합니다. 거래의 Gas가 16,777,216을 초과할 경우, 거래 풀은 해당 거래를 거부해야 하며, 이는 이러한 거래가 대기열에 들어가지 않도록 보장합니다. 블록 검증 과정에서 블록에 상한을 초과하는 거래가 포함되어 있으면, 해당 블록 자체도 거부되어야 합니다.

16,777,216(2²⁴)이라는 숫자를 선택한 이유는 명확한 2의 거듭제곱 경계로 구현이 용이하며, 여전히 대부분의 실제 거래를 처리할 수 있을 만큼 충분히 큰 수치이기 때문입니다. 예를 들어 스마트 계약 배포, 복잡한 DeFi 상호작용 또는 다단계 계약 호출 등이 이에 해당합니다. 이 값은 전형적인 블록 크기의 절반 정도로, 가장 복잡한 거래조차도 이 제한 범위 내에서 쉽게 제어할 수 있습니다.

이 EIP는 기존 Gas 메커니즘과의 호환성을 유지합니다. 대부분의 사용자는 이 변화를 인식하지 못할 것입니다. 왜냐하면 현재 존재하는 거래에서 소모하는 Gas는 거의 모두 1600만보다 훨씬 낮기 때문입니다. 검증자와 블록 생성자는 여전히 총 Gas가 1670만을 초과하는 블록을 생성할 수 있지만, 각 거래가 새로운 상한을 준수하기만 하면 됩니다.

유일하게 영향을 받는 거래는 이전에 새로운 제한을 초과하려고 했던 초대형 거래입니다. 이러한 거래는 이제 여러 개의 작은 작업으로 분할해야 하며, 이는 매우 큰 파일을 업로드할 때 두 개의 작은 파일로 나누는 것과 유사합니다. 기술적으로 이 변경은 이러한 드문 극단 거래에 대해 하위 호환성이 없지만, 영향을 받는 사용자 수는 매우 적을 것으로 예상됩니다.

보안 측면에서 Gas 상한은 이더리움이 Gas 기반 DoS 공격에 더 잘 저항할 수 있도록 합니다. 공격자는 더 이상 검증자가 초대형 거래를 처리하도록 강요할 수 없습니다. 이는 블록 검증 시간의 예측 가능성을 유지하는 데에도 도움이 되어, 노드가 동기화를 유지하기 쉽게 만듭니다. 주요 극단적인 상황은 소수의 대규모 계약 배포가 상한 요구 사항을 충족하지 못할 수 있으며, 이 경우 재설계하거나 여러 배포 단계로 나누어야 할 수 있습니다.

전반적으로 EIP-7825는 네트워크가 남용을 방지하고, 노드 요구 사항을 합리적으로 유지하며, 블록 공간 사용의 공정성을 높이고, Gas 상한이 증가함에 따라 블록체인이 여전히 빠르고 안정적으로 운영될 수 있도록 보장하는 것을 목표로 합니다.

EIP-7883：ModExp Gas 비용 상승

이더리움이 이 제안이 필요한 이유는 ModExp 프리컴파일(모듈로 거듭제곱 연산)의 가격이 실제 소모되는 자원에 비해 항상 낮았기 때문입니다.

일부 경우 ModExp 작업에 필요한 계산량은 사용자가 현재 지불하는 비용을 훨씬 초과합니다. 이러한 불일치는 위험을 초래합니다. 복잡한 ModExp 호출의 가격이 너무 낮으면, 이는 병목 현상이 되어 네트워크가 안전하게 Gas 상한을 높이기 어렵게 만듭니다. 블록 생산자는 매우 낮은 비용으로 매우 무거운 작업을 처리해야 할 수 있습니다.

이 문제를 해결하기 위해 이더리움은 ModExp의 가격 책정 공식을 조정하여 Gas 소모가 클라이언트가 실제로 수행한 작업량을 정확하게 반영하도록 해야 합니다. 따라서 EIP-7883은 새로운 규칙을 도입하여 최소 Gas 비용을 높이고, 총 Gas 비용을 증가시키며, 입력 데이터 양이 큰 작업(특히 32 바이트를 초과하는 지수, 기수 또는 모듈러스 연산)을 더 비싸게 만들어 Gas 가격 책정이 실제 필요한 계산량과 일치하도록 합니다.

이 제안은 여러 중요한 측면에서 비용을 증가시켜 EIP-2565에서 정의된 ModExp 가격 책정 알고리즘을 수정합니다.

첫째, 최소 Gas 소모량이 200에서 500으로 증가하며, 총 Gas 소모량은 더 이상 3으로 나누지 않으므로 총 Gas 소모량이 실제로 세 배 증가합니다. 예를 들어, 이전에 ModExp 호출이 1200 gas를 소모했다면, 새로운 공식 하에서는 약 3600 gas를 소모해야 합니다.

둘째, 지수가 32 바이트를 초과하는 연산 비용이 두 배로 증가합니다. 이는 곱셈 수가 8에서 16으로 증가했기 때문입니다. 예를 들어, 지수 길이가 40 바이트인 경우 EIP-2565는 반복 횟수를 8 × (40 − 32) = 64로 증가시키지만, EIP-7883는 이제 16 × (40 − 32) = 128로 사용하여 비용이 두 배로 증가합니다.

셋째, 가격 책정은 최소 기수/모듈러스 크기가 32 바이트라고 가정하며, 이러한 값이 32 바이트를 초과할 경우 계산 비용이 급격히 증가합니다. 예를 들어, 모듈러스가 64 바이트인 경우 새로운 규칙은 복잡도를 두 배로 적용합니다(2 × words²)하며, 이전의 더 간단한 공식 대신 대수 연산의 실제 비용을 반영합니다. 이러한 변경은 소형 ModExp 연산이 합리적인 최소 비용을 지불하도록 보장하며, 대형 복잡한 연산의 비용은 그 크기에 따라 적절하게 조정됩니다.

이 제안은 새로운 Gas 계산 함수를 정의하고 복잡도 및 반복 횟수 규칙을 업데이트합니다. 곱셈 복잡도는 이제 기수/모듈러스 길이가 32 바이트를 초과하지 않는 경우 기본값 16을 사용하며, 더 큰 입력의 경우 더 복잡한 공식 2 × words²로 전환됩니다. "words"는 8 바이트 블록의 수를 나타냅니다. 반복 횟수도 업데이트되어 32 바이트 이하의 지수는 비트 길이를 사용하여 복잡도를 결정하며, 32 바이트를 초과하는 지수는 더 큰 Gas 패널티를 부과합니다.

이로 인해 실제 계산 비용이 높은 초대형 지수는 이제 더 높은 Gas 비용을 가지게 됩니다. 중요한 것은 반환되는 최소 Gas 비용이 500으로 강제 설정되며, 이전의 200보다 높아져 가장 간단한 ModExp 호출조차도 보다 합리적으로 만듭니다.

이러한 가격 상승의 동기는 벤치마크 테스트에서 ModExp 프리컴파일의 가격 책정이 명백히 낮다는 것을 보여주었습니다. 수정된 공식은 소형 작업의 Gas 비용을 150% 증가시키고, 전형적인 작업은 약 200% 증가시키며, 대형 또는 불균형 작업의 Gas 비용은 더 많이 증가하여 때로는 80배 이상 증가합니다. 이는 지수, 기수 또는 모듈러스의 크기에 따라 다릅니다.

이 조치는 ModExp의 작동 방식을 변경하기 위한 것이 아니라, 자원 소모가 가장 큰 극단적인 상황에서도 네트워크의 안정성을 위협하거나 미래의 블록 Gas 상한을 높이는 것을 방해하지 않도록 하기 위한 것입니다. EIP-7883는 ModExp에 필요한 Gas 양을 변경하였으므로 하위 호환성이 없지만, Gas 재가격 책정은 이더리움에서 여러 번 발생하였으며 충분히 이해되고 있습니다.

테스트 결과, 이번 Gas 비용 상승 폭이 매우 크다는 것이 확인되었습니다. 약 99.69%의 역사적인 ModExp 호출은 이제 500 Gas(이전에는 200 Gas) 또는 이전 가격의 세 배가 필요합니다. 그러나 일부 고부하 테스트 사례의 Gas 비용 상승 폭은 더 큽니다. 예를 들어, "지수 연산 집약적" 테스트에서 Gas 소모량이 215에서 16,624로 증가하여 약 76배 증가하였으며, 이는 이제 매우 큰 지수의 가격 책정이 더욱 합리적이기 때문입니다.

보안 측면에서 이 제안은 새로운 공격 경로를 도입하지 않으며, 어떤 연산의 비용도 낮추지 않습니다. 반대로, 가격이 너무 낮은 ModExp 연산이 공격자가 매우 낮은 비용으로 블록을 채울 수 있는 중요한 위험을 방지하는 데 중점을 두고 있습니다. 유일한 단점은 일부 ModExp 연산의 가격이 너무 높을 수 있지만, 이는 현재 가격이 너무 낮은 문제보다 훨씬 나은 상황입니다. 이 제안은 어떤 인터페이스 변경이나 새로운 기능을 도입하지 않으므로 기존의 산술 동작 및 테스트 벡터는 여전히 유효합니다.

EIP-7917：다음 제안자를 정확히 예측하기

이더리움은 이 제안이 필요합니다. 왜냐하면 네트워크의 다음 epoch 제안자 스케줄이 완전히 예측할 수 없기 때문입니다. N번째 epoch에서 N+1번째 epoch의 RANDAO 시드가 알려져 있더라도, 실제 제안자 목록은 N번째 epoch 내의 유효 잔액(EB) 업데이트로 인해 변경될 수 있습니다.

이러한 EB 변화는 벌금, 처벌, 1 ETH를 초과하는 보상, 검증자 통합 또는 새로운 예치금에서 발생할 수 있으며, 특히 EIP-7251이 최대 유효 잔액을 32 ETH 이상으로 높인 이후에는 더욱 그러합니다. 이러한 불확실성은 다음 제안자를 미리 알아야 하는 시스템(예: 사전 확인 기반 프로토콜)에 문제를 일으킵니다. 이러한 시스템은 원활한 운영을 위해 안정적이고 예측 가능한 일정이 필요합니다. 검증자는 심지어 다음 epoch의 제안자에게 영향을 미치기 위해 자신의 유효 잔액을 "조작"하려고 할 수도 있습니다.

이러한 문제로 인해 이더리움은 제안자 일정이 향후 몇 개의 epoch 동안 완전히 확정되도록 하는 방법이 필요합니다. 이를 통해 마지막 순간의 EB 업데이트로 인해 변경되지 않으며, 애플리케이션 계층에서 쉽게 접근할 수 있습니다.

이를 실현하기 위해 EIP-7917은 각 epoch 시작 시 다음 MINSEEDLOOKAHEAD + 1 epoch의 제안자 스케줄을 미리 계산하고 저장하는 결정론적 제안자 전방 메커니즘을 도입합니다. 간단히 말해, 신호 상태는 이제 `prosoperer_lookahead`라는 목록을 포함하며, 이 목록은 항상 두 개의 전체 주기의 제안자(총 64개 슬롯)를 포함합니다.

예를 들어, epoch N이 시작될 때 이 목록은 이미 epoch N과 epoch N+1의 각 슬롯의 제안자를 포함하고 있습니다. 그런 다음 네트워크가 주기 N+1로 이동할 때 이 목록은 앞으로 이동합니다: 주기 N의 제안자 항목을 제거하고, 주기 N+1의 항목을 목록 앞에 이동시키며, 목록 끝에 주기 N+2의 새로운 제안자 항목을 추가합니다. 이를 통해 스케줄이 고정되고 예측 가능해지며, 클라이언트는 매 슬롯마다 제안자를 다시 계산할 필요 없이 직접 읽을 수 있습니다.

업데이트를 유지하기 위해 목록은 각 epoch 경계에서 앞으로 이동합니다: 이전 epoch의 데이터를 제거하고, 다음 미래 epoch의 새로운 제안자 인덱스 집합을 계산하여 목록에 추가합니다. 이 과정은 이전과 동일한 시드 및 유효 잔액 규칙을 사용하지만, 이제 스케줄 계산이 더 일찍 이루어져 시드 결정 후 유효 잔액 변화가 영향을 미치지 않도록 합니다. 분기 후 첫 번째 블록도 전체 전방 범위를 채워 모든 미래의 epoch가 올바르게 초기화된 스케줄을 갖도록 합니다.

각 epoch에 8개의 슬롯이 있다고 가정해 보겠습니다(단순화를 위해). 이 EIP가 없다면, 5번째 epoch 동안 6번째 epoch의 시드를 알고 있더라도, 검증자가 벌금에 처해지거나 충분한 보상을 받아 5번째 epoch 동안의 유효 잔액을 변경하면 6번째 epoch의 슬롯 2의 실제 제안자가 여전히 변경될 수 있습니다. EIP-7917을 통해 이더리움은 5번째 epoch 시작 시 5, 6 및 7번째 epoch의 모든 제안자를 미리 계산하고 순서대로 `prosopers_lookahead`에 저장합니다. 따라서 5번째 epoch 후반에 잔액이 변경되더라도 6번째 epoch의 제안자 목록은 고정되고 예측 가능하게 유지됩니다.

EIP-7917은 신호 체인 설계에서 오랫동안 존재해온 결함을 수정합니다. 이는 이전 epoch의 RANDAO가 사용 가능해지면 미래 epoch의 검증자 선택이 변경될 수 없음을 보장합니다. 이는 또한 "유효 잔액 조작"을 방지합니다. 즉, 검증자가 RANDAO를 보고 다음 epoch의 제안자 목록에 영향을 미치기 위해 잔액을 조정하려고 시도하는 것을 방지합니다. 결정론적 전방 메커니즘은 전체 공격 벡터를 제거하고 보안 분석을 크게 단순화합니다. 또한 합의 클라이언트가 다가오는 블록을 제안할 제안자가 누구인지 미리 알 수 있도록 하여 구현을 지원하고, 애플리케이션 계층이 신호 루트의 머클 증명을 통해 제안자 일정을 쉽게 검증할 수 있도록 합니다.

이 제안 이전에는 클라이언트가 현재 슬롯의 제안자만 계산했습니다. EIP-7917을 통해 이제 클라이언트는 각 epoch 전환 동안 다음 epoch의 모든 슬