EIP-8261 가스 한도 일정 (Gas Limit Schedule)

콜 결정 없음 · 수수료·가스 · 원문 상태 Last Call · 2026-05-11 작성

합의 레이어 설정 파일에 에폭 단위 가스 한도 일정을 넣어, 검증자의 기본 가스 한도와 권장 최대치가 정해진 시점에 자동으로 바뀌도록 권고합니다. 합의 규칙은 바꾸지 않습니다.

왜 필요한가

지금은 블록 가스 한도의 기본값이 클라이언트 릴리스에 묶여 있습니다. 새 기본값은 네트워크가 정한 시점이 아니라 운영자가 노드를 업데이트하는 순간 켜집니다. 그래서 한도를 크게 올리려 하면 곤란한 상황이 생깁니다. 활성화 시점보다 먼저 새 기본값을 담은 릴리스를 내면, 일찍 업데이트한 노드가 네트워크가 안전하다고 합의하기 전에 곧바로 한도를 올리는 투표를 시작합니다. 반대로 활성화 직후에 릴리스를 내고 모든 운영자에게 빠른 업데이트를 부탁하는 방식은 번거롭고 느립니다. 인상 때마다 임시 플래그를 만들면 조율 부담이 운영자 개개인에게 넘어갑니다. 게다가 네트워크가 운영해야 할 가스 한도가 적힌 단일한 장소도 없어서 지금은 한도를 옮기려면 모든 클라이언트 팀이 새 기본값을 내보내거나 다수 운영자가 설정을 바꾸도록 몇 달에 걸쳐 사회적으로 조율해야 합니다. EIP-7935가 Fusaka에서 정해진 에폭에 기본값 권고를 조율하는 방식이 통한다는 것을 보여 줬고 이 EIP는 그것을 재사용 가능한 일정으로 일반화합니다.

무엇이 바뀌나

지금

EIP-8261 이후

누구에게 영향이 있나

심층 설명

GAS_LIMIT_SCHEDULE 필드 구조

합의 레이어 config.yaml에 GAS_LIMIT_SCHEDULE 필드를 추가할 수 있습니다(MAY). 각 항목은 EPOCH와 GAS_LIMIT 두 uint64 값으로 이루어지며 GAS_LIMIT은 합의 명세의 ExecutionPayload.gas_limit과 같은 타입입니다. 형식은 EIP-7892의 BLOB_SCHEDULE 메커니즘을 그대로 본떴습니다. 필드는 선택 사항이라 지원하지 않는 클라이언트는 알 수 없는 설정 키 관례대로 무시합니다. 지원하는 클라이언트도 GLOAS_FORK_EPOCH 이전 듀티에는 반드시 일정을 무시해야 합니다(MUST). get_scheduled_gas_limit 함수는 주어진 에폭 이하의 항목 중 EPOCH가 가장 큰 항목의 값을 돌려주고 Gloas 이전이거나 활성 항목이 없으면 None을 돌려줍니다. 항목이 프로토콜 업그레이드와 겹칠 수는 있지만 일정 자체가 포크를 만들거나 요구하지는 않습니다.

하나의 값이 기본값이자 권장 최대치

활성화된 일정 값은 두 역할을 합니다. 운영자 설정이 없으면 클라이언트가 그 값을 가스 한도 선호값으로 써야 하고(SHOULD), 일정이 덮는 에폭에는 별도의 릴리스 단위 기본값을 두지 말아야 합니다(SHOULD NOT). 운영자 설정이 일정 값을 넘으면 강제 수단이 없으므로 그대로 존중하되, configured gas limit 100000000 exceeds the recommended maximum of 90000000 at epoch 540000 같은 명확한 경고를 남겨야 합니다. 일정보다 낮은 값은 지금처럼 그대로 동작합니다. 빌더는 해당 슬롯의 일정 값을 넘지 않는 입찰을 만들고 릴레이는 그런 입찰을 선호해야 합니다(SHOULD). 기본값과 상한을 하나의 값으로 묶은 이유는 두 번째 파라미터를 따로 협상하거나 어긋나게 둘 일이 없고 기본값과 상한 사이의 검증되지 않은 운영 구간이 생기지 않기 때문입니다.

에폭 기반 전환 로직

지금은 가스 한도 기본값을 시작 시점이나 검증자 등록 생성 시점에 한 번 읽고 고정합니다. 이 EIP에서는 일정 값을 듀티마다, 즉 제안하거나 등록하는 슬롯의 에폭을 기준으로 조회해야 하며(SHOULD), 벽시계 시간이나 시작 시 캐시한 값을 쓰면 안 됩니다. 그러면 실행 중인 노드가 설정된 에폭의 첫 슬롯에서 재시작, 후속 릴리스, 운영자 조작 없이 선호값을 바꿉니다. 검증자 등록은 주기적으로 재발급되므로 듀티가 활성화 에폭을 지나면 자연스럽게 새 값으로 넘어갑니다. 일정이 에폭에 묶여 있어서 활성화 몇 달 전에 릴리스를 내보내도 그 에폭까지는 기존 값을 쓰다가 자동으로 전환되고 그 덕분에 큰 인상을 미리 안전하게 배포할 수 있습니다.

일정이 합의 레이어에만 있는 이유

Gloas(EIP-7732)부터 블록이 지향하는 가스 한도는 빌더 흐름의 검증자 쪽, 즉 검증자 등록과 페이로드 입찰 경로를 거쳐 정해지고 실행 레이어 설정은 관여하지 않습니다. 그래서 일정은 합의 레이어 config.yaml에만 두고 실행 레이어에 대응 설정을 만들지 않습니다. 실행 레이어에 병렬 일정을 두면 합의 레이어 값과 일치하거나 어긋나는 것밖에 할 일이 없는 중복 설정이 되고 어긋남은 이득 없는 새 장애 유형이 됩니다. 값을 실제로 움직이는 레이어에 일정 하나만 두는 것이 최소 설계입니다. 실행 레이어 클라이언트는 이 EIP로 아무 변경도 필요 없고, 기존 가스 한도 플래그는 Gloas 이전과 로컬 도구용 의미를 유지합니다. Gloas 이전의 가스 한도 선택 방식도 바꾸지 않습니다.

합의 규칙이 아니라 권고로 설계한 이유

초기 초안은 일정 값을 합의로 강제되는 최대치(그 전에는 정확히 일치해야 하는 값)로 만들었지만 이 버전은 의도적으로 권고에 머뭅니다. 권고는 포크도 엔진 API 변경도 필요 없어 합의 레이어 팀들이 독립적으로, 점진적으로 채택할 수 있습니다. 가스 한도 선택권은 최종적으로 제안자에게 남아 검증자 주권이 보존되고 이 EIP가 바꾸는 것은 기본값과 사회적 관례입니다. 조기 투표와 연속 릴리스 문제는 기본값 관리 문제이고 기본값은 클라이언트 동작이므로 권고로 충분히 풀립니다. 초과 설정을 일정 값으로 잘라내는 클램프 방식도 배제했는데, 합의 규칙 없이 존재하지 않는 네트워크 상한이 있는 것처럼 보이게 하고 유효한 블록을 만드는 운영자의 명시적 결정을 조용히 덮어쓰며 채택한 클라이언트만 잘라내 동작이 갈라지기 때문입니다. 나중에 공동체가 원하면 같은 일정 값을 합의로 강제되는 최대치로 올리는 별도 Standards Track Core EIP를 설정 형식 변경 없이 만들 수 있습니다.

보안 고려사항

상한은 어디까지나 권고라서 일정 값을 일부러 넘는 제안자를 막지 못합니다. 대신 역사적으로 의도치 않은 가스 한도 변동의 원인이던 우발적 경로, 즉 일찍 배포된 기본값, 오래된 설정, 조율되지 않은 인상을 막아 줍니다. ±1/1024 탄력성 규칙이 누구든 실제 한도를 움직이는 속도를 추가로 제한합니다. 대다수 검증자가 일정을 따르면 네트워크 가스 한도가 매우 예측 가능해지는데, 이는 목표이지만 일정 값의 오류도 널리 퍼진다는 뜻이므로, 일정에 넣을 값은 EIP-7935에 기술된 것과 같은 데브넷과 최악 블록 테스트를 거쳐야 합니다. 필드가 선택 사항이라 채택하지 않은 클라이언트는 기존 기본값을 유지하고 그 운영자는 지금처럼 수동으로 조율하는데, 혼재 네트워크는 오늘보다 나빠지지 않고 조율 효과는 채택률에 비례합니다.

진행 상태와 콜 결정

이 EIP는 Informational 유형이며 상태는 Last Call, 마감일은 2026-11-01입니다. 합의 규칙과 블록 유효성은 전혀 바뀌지 않고 EIP-1559의 ±1/1024 규칙과 최소 5000이 유일한 가스 한도 유효성 규칙으로 남습니다. 08.13 ACDE #243 콜에서 EIP-8261 클라이언트 내 가스 한도 일정이 합의 레이어 설정의 선택 파라미터로 진행된다고 확정했습니다. 포크 뒤 가스 한도를 단계적으로 올리는 일정을 미리 넣을 수 있다는 뜻입니다.

EIP 원문 · ← EIPs