EIP-7706에 대한 자세한 설명과 최신 이더리움의 가스 메커니즘 정리

by @Web3Mario

소개:

비탈릭은 2024년 5월 13일, 콜데이터의 가스 계산을 별도로 분리하고 블롭 가스와 유사한 기본 요금 책정 메커니즘을 사용자 정의하여 L2의 운영 비용을 더욱 절감함으로써 기존 가스 모델을 보완하는 솔루션을 제안하는 제안서 EIP-7706을 발표했습니다. 이와 관련된 제안은 2022년 2월에 제안된 EIP-4844로 거슬러 올라가야 하는데, 꽤 오랜 시간이 지났기 때문에 관련 정보를 확인했고, 빠른 이해를 돕기 위해 최신 이더리움 가스 메커니즘에 대해 간략히 소개해드리고자 합니다.

현재 지원되는 이더리움 가스 모델 - EIP-1559 및 EIP-4844

이더리움은 원래 설계에서 거래 수수료 가격을 책정하기 위해 간단한 경매 메커니즘을 사용했는데, 이는 사용자가 거래에 적극적으로 입찰, 즉 가스 가격을 설정해야 했습니다. 일반적으로 사용자가 지불한 거래 수수료는 채굴자에게 귀속되므로 채굴자는 입찰 수준에 따라 경제 최적성의 원칙에 따라 거래를 결정하게 됩니다. 포장 주문, 이는 MEV를 무시한다는 점에 유의하세요. 당시 핵심 개발자들은 이 메커니즘이 다음과 같은 네 가지 문제를 안고 있다고 생각했습니다.

• 거래 수수료 수준의 변동성 대 거래의 합의. >합의와 비용 간의 불일치: 활성화된 상태의 블록체인의 경우, 거래의 패킹 수요가 충분하여 블록이 쉽게 채워질 수 있지만, 이는 종종 전체 수수료가 매우 변동성이 크다는 것을 의미하기도 합니다. 예를 들어 평균 가스 가격이 10G웨이인 경우, 한 블록에서 다른 트랜잭션을 수락하는 네트워크의 한계 비용은 평균 가스 가격이 1G웨이인 경우보다 10배 더 높으며, 이는 허용할 수 없는 수준입니다.

• 사용자를 위한 불필요한 지연 시간: 블록당 가스 한도의 엄격한 제한과 과거 거래량의 자연스러운 변동으로 인해 거래는 일반적으로 여러 블록이 패키징될 때까지 대기하지만 이는 비효율적입니다. 즉, 블록 단위로 수요의 차이를 수용하기 위해 한 블록을 더 크게 하고 다음 블록을 더 작게 할 수 있는 "여유" 메커니즘이 없기 때문에 네트워크 전체에 비효율적입니다.

• 가격비효율성: 단순 경매 사용으로 인한 공정한 가격 발견의 비효율성은 사용자가 합리적인 가격을 제시하기 어렵다는 것을 의미합니다. 어렵다는 것은 사용자가 높은 수수료를 지불하는 경우가 매우 많다는 것을 의미합니다.

• 블록 보상이 없는 블록체인은불안정할 것이다: 채굴에서 블록 보상을 없애고 순수 수수료 기반 모델을 채택할 경우. 거래 수수료를 훔치는 '자매 블록'의 채굴을 장려하고 이기적인 채굴을 위한 더 강력한 공격 경로를 열어주는 등 많은 불안정성을 초래할 수 있습니다.

2019년 4월 13일 비탈릭과 다른 핵심 개발자들이 제안하고 2021년 8월 5일 런던 업데이트에서 채택된 EIP-1559가 제안 및 구현되기 전까지 가스 모델의 첫 번째 반복이 있었습니다. 채택된 이 메커니즘은 경매 메커니즘을 피하고 기본 수수료와 우선 순위 수수료의 이중 가격 책정 모델을 선호하며, 기본 수수료는 상위 블록에서 생성된 가스의 소비량과 유동적이고 재귀적인 가스 목표 사이의 관계를 기반으로 확립된 수학적 모델을 통해 정량적으로 계산되며, 이전 블록의 가스가 다음과 같은 직관적인 효과를 가져옵니다. 마지막 블록의 가스 소비량이 미리 정해진 가스 목표를 초과하면 기본요금이 상향 조정되고, 가스 목표보다 적으면 기본요금이 하향 조정되어 수급 관계를 더 잘 반영할 뿐만 아니라 적정 가스 예측이 더 정확해지고, 기본요금이 시스템에 의해 직접 계산되는 반면에 기본요금은 시스템에 의해 결정되므로 가스 가격의 오용으로 인한 가스 가격 폭등 현상을 방지할 수 있게 됩니다. 기본료 계산은 사용자가 지정하는 것이 아니라 시스템에서 직접 결정합니다. 구체적인 코드는 다음과 같습니다:

여기서 부모_가스사용량이 부모_가스사용량보다 크면 기본료가 계산되는 것을 볼 수 있습니다. 가스 사용량이 부모_가스_목표보다 큰 경우 현재 블록의 기본 수수료와 이전 블록의 기본 수수료에 오프셋 값을 더한 값을 비교하며, 오프셋 값은 부모_기본 수수료에 가스 목표 대비 이전 블록의 총 가스 사용량 오프셋을 곱하고 가스 목표의 오프셋에 나머지 1과 상수 값을 곱한 값을 취합니다. 남은 값이 1이고 상수 값은 최대값입니다. 반대 로직도 비슷합니다.

또한 기본 수수료는 더 이상 채굴자에게 보상으로 분배되지 않고 소멸되어 이더리움 경제 모델이 디플레이션 상태에 놓이게 되므로 가치 안정에 도움이 됩니다. 반면, 우선권 수수료는 사용자가 채굴자에게 주는 보상과 동일하며, 자유롭게 가격이 책정될 수 있어 채굴자의 정렬 알고리즘을 어느 정도 재사용할 수 있습니다.

2021년으로 시간이 흐르면서 롤업의 OP 롤업과 ZK 롤업은 모두 L2 데이터를 압축한 다음 콜데이터를 통해 특정 증명 데이터를 체인에 업로드하여 데이터 가용성을 달성하거나 검증을 위해 체인에 직접 업로드해야 한다는 것을 알고 있습니다. 따라서 이러한 롤업 솔루션은 L2의 최종성을 유지하기 위해 가스 측면에서 상당한 비용이 발생하며, 이는 궁극적으로 사용자에게 전가되어 대부분의 L2 프로토콜은 그렇지 않은 경우보다 사용 비용이 저렴합니다.

동시에 이더리움은 블록 공간 경쟁이라는 딜레마에 직면해 있는데, 각 블록마다 가스 제한이 있어 현재 블록에 있는 모든 거래의 가스 소비량이 이 값을 초과해서는 안 되며 현재 가스 제한인 30,000,000에 따르면 이론적으로 30,000,000개의 거래가 존재한다는 것을 알 수 있습니다. 현재 Gas Limit 30,000,000에 따라 계산하면 이론적으로 30,000,000 / 16 = 1,875,000 바이트이며, 여기서 16은 EVM이 각 콜데이터 바이트를 처리하는 데 16 단위의 Gas를 소비해야 한다는 것을 의미하며, 이는 단일 블록이 전송할 수 있는 데이터의 최대 크기가 약 1.79MB이며, L2 시퀀서에서 생성되는 롤업 데이터의 데이터 규모는 일반적으로 다른 블록과 다르게 더 큽니다. 가 더 크기 때문에 다른 메인체인 사용자의 트랜잭션 확인과 경쟁하게 되어 단일 블록에 담을 수 있는 트랜잭션의 양이 줄어들어 메인체인의 TPS에 영향을 미칩니다.

이 딜레마를 해결하기 위해 핵심 개발자들은 2022년 2월 5일에 EIP-4844 제안을 제안했고 2024년 2분기 초반에 2024년 초에 덴쿤 업그레이드가 시행된 후 분기입니다. 이 제안은 기존 트랜잭션 유형과 비교하여 블롭 트랜잭션이라는 새로운 트랜잭션 유형을 제안하며, 블롭 트랜잭션의 핵심 아이디어는 새로운 데이터 유형, 즉 블롭 데이터를 보완하는 것입니다.콜데이터 유형과 구별되는 블롭 데이터는 EVM에서 직접 액세스하지 않습니다. 또한 두 가지 수반되는 설계가 있는데, 하나는 블롭 트랜잭션의 GC 주기가 일반 트랜잭션보다 짧아 블록 데이터가 지나치게 부풀려지지 않도록 하고, 다른 하나는 블롭 데이터에 EIP-1559와 유사한 네이티브 가스 메커니즘이 있지만 수학적 모델은 EIP-1559와 동일하지 않다는 것입니다. 유사하지만 수학적 모델에서는 자연 지수 함수가 선택되어 트랜잭션 크기의 변동을 처리할 때 안정성이 더 좋으며, 자연 지수 함수의 기울기도 자연 지수 함수이므로 현재 네트워크 트랜잭션 크기가 어떤 상태이든 상관없이 트랜잭션 크기가 급증하면 블롭 가스의 기본 수수료가 더 적절하게 반응하여 거래 활동을 억제하고 이 함수에는 거래 크기가 급증하면 블롭 데이터가 짧은 기간을 가지므로 블록 데이터가 너무 팽창하는 것을 보장하는 중요한 특성이 있습니다. 이 함수에는 가로 좌표가 0일 때 함수 값이 1이 되는 중요한 특징도 있습니다.

base_fee_per_blb_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_. BASE_FEE_UPDATE_FRACTION)

여기서 MIN_BASE_FEE_PER_BLOB_GAS와 BLOB_BASE_FEE_UPDATE_FRACTION은 두 상수이며, excess_. blob_gas는 부모 블록의 총 블롭 가스 소비량과 TARGET_BLOB_GAS_PER_BLOCK 상수의 차이에 의해 결정되며, 총 블롭 가스 소비량이 목표 값을 초과하는 경우, 즉 그 차이가 양수인 경우 e**(EXCESS_BLOB_GAS / BLOB_BASE_FEE_UPDATE_ FRACTION)이 1보다 크면 BASE_FEE_PER_BLOB_GAS가 커지고 그 반대의 경우도 마찬가지입니다.

블록의 트랜잭션 패킹 기능에 부담을 주지 않고 가용성을 보장하기 위해 이더리움의 합의 기능을 활용하여 특정 데이터 크기에 대한 예치만 수행하려는 시나리오에 적합한 저비용 구현 방식입니다. 롤업 시퀀서를 예로 들면, L2의 핵심 정보는 블롭 트랜잭션을 통해 블롭 데이터에 캡슐화할 수 있으며, 온체인 검증 로직은 버전화된 해시를 사용한 섬세한 설계를 통해 EVM에서 구현할 수 있습니다.

현재 TARGET_BLOB_. GAS_PER_BLOCK 및 MAX_BLOB_GAS_PER_BLOCK 설정은 메인넷에 평균 처리 목표인 3블롭(0.375MB)과 블록당 최대 6블롭(0.75MB)의 제한을 부과합니다. 이러한 초기 제한은 이 EIP가 네트워크에 가하는 부담을 최소화하기 위한 것이며, 향후 업그레이드에서 네트워크가 더 큰 블록으로 안정성을 입증함에 따라 더 늘어날 것으로 예상됩니다.

실행 환경 가스 소비 모델 개선 - EIP-7706

현행 실행 환경의 가스 소비 모델을 명확히 할 때, EIP-7706

은 좋은 아이디어입니다. ">현재 이더리움 가스 모델을 명확히 한 다음, EIP-7706 제안의 목표와 구현 세부 사항을 살펴보겠습니다. 이 제안은 비탈릭이 2024년 5월 13일에 제안했습니다. 블롭 데이터와 마찬가지로, 이 제안은 가스 모델에서 또 다른 특수 데이터 필드인 콜데이터를 제거하고 코드 구현 로직을 최적화합니다.

원칙적으로 통화 데이터의 기본 수수료 계산 로직은 지수 함수를 사용하고 부모 블록의 실제 가스 소비량 값과 목표 값의 편차를 기준으로 현재 기본 수수료의 스케일을 계산하는 EIP-4844의 블롭 데이터의 기본 수수료와 동일합니다. 부모 블록의 실제 가스 소비량 값과 목표 값의 편차를 기준으로 수수료를 계산합니다.

새로운 파라미터 설계인 LIMIT_. TARGET_RATIOS=[2,2,4], 여기서 LIMIT_TARGET_RATIOS[0]은 실행 연산 클래스 Gas의 목표 비율을 나타내고, LIMIT_TARGET_RATIOS[1]은 블롭 데이터 클래스 Gas의 목표 비율을 나타내고, LIMIT_TARGET_RATIOS[2]는 LIMIT_TARGET_RATIOS[2]는 호출 데이터 클래스의 가스 목표 비율을 나타내며, 이 벡터는 부모 블록의 세 가지 가스 유형의 해당 가스 목표값을 계산하는 데 사용되며, 계산 로직은 다음과 같습니다.

가스 제한 설정의 로직은 다음과 같습니다:

gas_. limits[0]은 기존 조정 공식을 따라야 합니다

gas_limits[1]은 MAX_BLOB_GAS_PER_BLOCK과 같아야 합니다

gas_. LIMITS[2]는 GAS_LIMITS[0] // CALLDATA_GAS_LIMIT_RATIO와 같아야 합니다

현재 GAS_LIMITS[0]은 30,000,000이고, CALLDATA_GAS_LIMIT. _RATIO가 4로 미리 설정되어 있으므로 현재 콜데이터 가스 목표는 약 30000000 // 4 // 4 = 1875000이며, 현재 콜데이터 가스 계산 로직에 따르면 0이 아닌 바이트는 각각 16개의 가스를 소비하고, 0 바이트는 4개의 가스를 소비하므로 0이 아닌 대 0의 분포가 50%라고 가정하면, 0이 아닌 바이트와 0 바이트의 가스 소비량을 계산할 때, 현재 콜데이터 가스 목표가 1875000이라는 것을 의미합니다. 특정 콜데이터 세그먼트에서 비 0과 0 바이트의 분포가 50%라고 가정하면 평균적으로 1바이트의 콜데이터를 처리하는 데 10개의 Gas가 필요하므로 현재 콜데이터 가스 목표는 현재 평균 사용량의 약 2배인 187500바이트의 콜데이터 데이터에 해당해야 합니다.

이 방식의 장점은 콜데이터가 가스 한도에 도달할 확률을 크게 줄이고, 경제 모델링을 통해 콜데이터 사용량을 보다 일관된 상태로 유지하며, 콜데이터의 오용을 방지할 수 있다는 것입니다. 이 설계의 목적은 여전히 블롭 데이터를 사용하는 L2 개발의 길을 열어 시퀀서 비용을 더욱 절감하기 위한 것입니다.