EIP-7840 실행 클라이언트 설정에 블롭 일정 추가 (Add blob schedule to EL config files)

최종 확정 · 확장성·데이터 · 원문 상태 Final · 2024-12-12 작성

실행 클라이언트 설정 파일에 blobSchedule 항목을 추가해, 포크별로 블록당 블롭 목표 개수(target), 최대 개수(max), 수수료 갱신 계수(baseFeeUpdateFraction)를 적도록 합니다.

왜 필요한가

블롭(blob)은 블록에 첨부되는 대용량 데이터 공간이고 블록 하나에 몇 개까지 담을지(최대)와 평균적으로 몇 개를 유지할지(목표)는 포크가 바뀔 때마다 달라질 수 있습니다. 이 값은 원래 합의 클라이언트가 관리하는 것이 바람직하지만, 실제로는 실행 클라이언트도 여러 작업에 이 값이 필요합니다. 예를 들어 수수료 내역을 알려 주는 eth_feeHistory RPC는 블롭 가스 사용 비율(blobGasUsedRatio)을 돌려주는데, 이 값을 계산하려면 최대 블롭 수를 알아야 합니다. 그렇다고 두 클라이언트를 잇는 엔진 API(engine API)로 매 블록 이 값을 주고받는 것은 지나칩니다. 복잡한 핸드셰이크도 피하고 싶습니다. 이 EIP는 그 중간 지점으로 클라이언트 설정 파일에 포크별 블롭 값을 적는 표준 자리를 만듭니다. 블롭 가스 가격이 얼마나 빨리 움직일지 정하는 계수도 포크마다 조정할 수 있도록 함께 넣었습니다.

무엇이 바뀌나

지금

• 블롭 목표·최대 개수를 실행 클라이언트에 알려 주는 표준 방법이 없습니다
• 값을 공유하려면 엔진 API 위에서 복잡한 핸드셰이크가 필요합니다
• 포크마다 달라지는 블롭 수수료 갱신 계수를 적을 정해진 자리가 없습니다

EIP-7840 이후

• 설정 파일의 blobSchedule 객체에 포크별 값을 적습니다
• 각 포크마다 target, max, baseFeeUpdateFraction을 반드시 설정합니다
• 엔진 API를 거치지 않고 설정 파일만으로 포크별 블롭 값을 조정합니다

누구에게 영향이 있나

• 클라이언트 팀: 설정 파일에서 blobSchedule을 읽어 포크별 target, max, baseFeeUpdateFraction을 적용해야 합니다
• 노드 운영자: 커스텀 네트워크의 설정 파일에 포크별 블롭 값을 직접 적을 수 있습니다
• 지갑·앱 개발자: eth_feeHistory의 blobGasUsedRatio처럼 블롭 값에 기대는 RPC 응답이 포크별 설정을 따르게 됩니다
• 일반 사용자: 직접 체감하는 변화는 없습니다. 클라이언트 내부의 설정 방식을 정리하는 제안입니다

심층 설명

blobSchedule 객체의 모양

클라이언트 설정 파일에 blobSchedule이라는 객체를 추가합니다. 포크 이름이 키가 되고 각 포크 아래에 target, max, baseFeeUpdateFraction 세 값을 적습니다. 원문 예시는 cancun에 target 3, max 6, baseFeeUpdateFraction 3338477을, prague에 target 6, max 9, baseFeeUpdateFraction 5007716을 적습니다. 클라이언트는 이 세 값을 포크별로 반드시 설정해야 하며 새 포크가 생기면 같은 모양의 항목을 추가하는 식으로 확장합니다.

세 파라미터가 하는 일

target은 블록당 목표 블롭 수, max는 블록당 최대 블롭 수입니다. baseFeeUpdateFraction은 블롭 가스 가격이 수요 변화에 얼마나 민감하게 반응할지를 정하는 계수로, 포크마다 가격 반응 속도를 조정할 수 있도록 추가됐습니다. 세 값을 포크 이름 아래에 함께 적기 때문에, 포크가 바뀌면서 블롭 개수나 가격 공식의 민감도가 달라져도 설정 파일만 고치면 됩니다.

설정이 없거나 불완전하면

어느 포크의 설정이 빠져 있거나 불완전할 때의 동작은 정의되지 않습니다(undefined). 원문은 이 상황을 어떻게 처리할지 각 클라이언트가 자유롭게 정하도록 맡깁니다. 오류를 내고 멈출 수도, 자체 기본값으로 채울 수도 있으며 어느 쪽이 맞는지는 이 EIP가 정하지 않습니다.

왜 엔진 API가 아니라 설정 파일인가

블롭 목표·최대값은 합의 클라이언트만 관리하는 것이 바람직하지만 실행 클라이언트도 여러 작업에 이 값이 필요하다는 현실을 원문은 인정합니다. 대표 사례가 eth_feeHistory RPC입니다. 이 메서드가 돌려주는 blobGasUsedRatio 필드는 핵심 프로토콜에는 필요 없는 값인데도 max를 알아야 계산할 수 있습니다. 그렇다고 이 값을 매 블록 엔진 API로 넘기는 것은 과하다고 보고 설정 파일이 좋은 중간 지점이라고 판단했습니다. Motivation에서도 목표·최대 개수와 수수료 갱신 계수를 동적으로 조정할 길을 열면서 엔진 API 위의 복잡한 핸드셰이크를 피하는 것을 목적으로 듭니다.

Informational 타입, Final 상태

이 EIP의 타입은 Informational, 상태는 Final입니다. 블록 유효성 같은 합의 규칙을 바꾸는 제안이 아니라 클라이언트 설정 파일의 관례를 정하는 문서이고 내용이 확정되어 더 바뀌지 않습니다. 하위 호환성 문제와 보안 고려 사항은 모두 발견된 것이 없다고 기재되어 있습니다.

EIP 원문 · ← EIPs