EIP-7910 eth_config JSON-RPC 메서드 (eth_config JSON-RPC Method)
최종 확정 · 네트워크·노드 · 원문 상태 Final · 2025-03-18 작성
노드가 현재 적용 중인 포크, 다음 포크, 마지막으로 설정된 포크의 설정값을 JSON으로 보고하는 eth_config RPC 메서드를 추가합니다. 하드포크 전에 클라이언트 설정이 올바른지 미리 점검할 수 있게 합니다.
왜 필요한가
이더리움 역사에서 클라이언트가 다가오는 하드포크(네트워크 규칙을 한꺼번에 바꾸는 업그레이드)에 맞게 설정되지 않아 포크 시점에 합의에서 이탈한 사고가 여러 번 있었습니다. 대부분은 한 클라이언트의 블록이 버려지는 정도의 작은 사고였지만 홀레슈키(Holešky) 테스트넷의 펙트라(Pectra) 활성화 때는 달랐습니다. 네트워크의 6개 클라이언트 중 4개가 예치 컨트랙트 주소를 잘못 설정했고 잘못된 체인이 버려지는 대신 정당화(justified)되어 최종화 이후에도 부작용이 남았습니다. 그런데 포크가 실제로 일어나기 전에는 각 노드가 올바른 설정을 들고 있는지 밖에서 확인할 표준 방법이 없었습니다. 이 EIP는 노드가 핵심 설정값을 포크 전에 스스로 보고하게 해서 운영팀이 여러 노드의 응답을 비교해 설정 오류를 미리 잡을 수 있게 합니다.
무엇이 바뀌나
지금
- 포크 설정이 올바른지 포크가 실제로 넘어가기 전에는 표준 방법으로 확인할 수 없습니다
- 클라이언트마다 설정 파일 형식이 달라 노드 간 비교가 어렵습니다
- 설정 오류가 포크 경계를 넘는 순간 합의 이탈로 드러납니다
EIP-7910 이후
- eth_config 호출 한 번으로 현재·다음·마지막 포크 설정을 표준 JSON으로 받습니다
- 여러 노드의 응답을 비교해 포크 전에 불일치를 찾아냅니다
- 체인 ID, 프리컴파일, 시스템 컨트랙트 주소, 블롭 일정까지 항목별로 점검합니다
누구에게 영향이 있나
- 노드 운영자·검증자 팀: 포크 전에 자동 점검 스크립트로 노드들의 eth_config 출력을 비교해 준비 상태를 확인할 수 있습니다.
- 클라이언트 개발팀: 메서드를 구현해야 하며 설정 불일치를 디버깅하는 데에도 쓸 수 있습니다.
- 네트워크 모니터링 도구: 노드들의 응답을 알려진 포크 명세나 다른 노드와 교차 검증해 이상을 탐지할 수 있습니다.
- 합의 레이어(CL) 측 상대 노드: 짝을 이루는 실행 클라이언트의 포크 준비 상태를 자동으로 확인할 수 있습니다.
심층 설명
메서드 정의와 응답 구조
eth_config는 파라미터 없이 호출하며 응답은 current, next, last 세 멤버를 가집니다. 각각 현재 적용 중인 설정, 다음 설정, 마지막으로 알려진 설정이고 미래 포크가 설정되어 있지 않으면 next와 last는 null입니다. 다음 포크가 곧 마지막 포크이면 두 멤버는 같은 설정을 담습니다. 클라이언트는 표준 JSON-RPC 포트로 이 메서드를 반드시(MUST) 노출해야 하고 Engine API로도 노출할 수 있습니다(MAY). 응답은 이 EIP가 정한 모든 설정 파라미터를 포함해야 하며 가장 최근에 제공한 블록 헤더 기준의 최신 값을 반영해야 합니다. 설정을 캐시한다면 포크 경계를 넘을 때 캐시를 반드시 비워야 합니다. 설정 객체를 내부 포크별 설정 관리에 써도 되지만 가공하지 않은 설정 데이터를 그대로 돌려줘서는 안 됩니다(SHOULD NOT).
설정 객체의 필드
각 설정 객체는 알파벳 순으로 다음 멤버를 반드시 포함합니다. activationTime은 포크 활성화 시각을 Unix epoch 초(UTC)의 JSON 숫자로 적습니다. current는 실제 활성화 시각, next와 last는 예정 시각이며 제네시스에서 활성화된 포크는 0을 씁니다. blobSchedule은 baseFeeUpdateFraction, max, target 세 숫자를 담은 객체입니다. chainId는 0x 접두사가 붙은 소문자 16진수 문자열로, 앞자리 0을 제거하며 체인 ID가 없거나 0인 체인은 지원하지 않습니다. forkId는 EIP-6122의 FORK_HASH 값으로, 4바이트 길이로 0을 왼쪽에 채운 소문자 16진수입니다. 이 명세는 머지 이후 네트워크를 전제로 하며 작업증명 관련 사항은 다루지 않습니다. 미래 포크가 멤버를 추가·변경·제거하려면 해당 EIP나 메타 EIP에 정의해야 합니다.
프리컴파일과 시스템 컨트랙트의 전수 나열
precompiles는 포크에서 활성화된 프리컴파일 컨트랙트를 이름과 20바이트 주소(앞자리 0 보존, 소문자)로 나열하는 객체입니다. 프리컴파일이 온체인 컨트랙트로 대체되거나 제거되면 목록에서 빠지므로, 향후 프리컴파일 제거 논의도 반영할 수 있습니다. 캔쿤(Cancun)의 이름은 ECREC, SHA256, RIPEMD160, ID, MODEXP, BN254_ADD, BN254_MUL, BN254_PAIRING, BLAKE2F, KZG_POINT_EVALUATION이고, 프라하(Prague)에서 BLS12_G1ADD, BLS12_G1MSM, BLS12_G2ADD, BLS12_G2MSM, BLS12_PAIRING_CHECK, BLS12_MAP_FP_TO_G1, BLS12_MAP_FP2_TO_G2가, 오사카(Osaka)에서 P256VERIFY가 추가됩니다. systemContracts는 시스템 컨트랙트 이름과 주소의 객체로, 캔쿤 이전 포크에서는 생략합니다. 캔쿤은 BEACON_ROOTS_ADDRESS 하나이고 프라하는 BEACON_ROOTS_ADDRESS, CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, DEPOSIT_CONTRACT_ADDRESS, HISTORY_STORAGE_ADDRESS, WITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS입니다. 미래 포크는 시스템 컨트랙트 목록을 메타 EIP에 정의해야 합니다.
블롭 파라미터 전용(BPO) 포크 처리
블롭 파라미터만 바꾸는 BPO(Blob Parameter Only) 포크도 새 포크로 취급합니다. 부모 포크의 설정을 기반으로 삼되(부모도 BPO라면 재귀적으로 거슬러 올라가서), blobSchedule 객체의 해당 값만 갱신해 새 포크 설정을 만듭니다. 따라서 BPO 포크도 current와 next에 완전한 설정 객체로 나타나며 운영자는 블롭 일정 변경이 제대로 설정됐는지 같은 방식으로 점검할 수 있습니다.
왜 전체 설정을 돌려주고 해시는 없는가
초기 설계에서는 next에 바뀐 부분만 담는 방안을 검토했지만 과거 사고를 분석해 보니 합의 분기를 일으킨 파라미터(예: 예치 컨트랙트)가 이전 포크에서 도입된 뒤 나중 포크에서 다른 EIP가 그 설정에 의존하면서 문제가 터진 경우가 있었습니다. 부분 설정으로는 이런 오류를 잡을 수 없어 전체 설정을 택했습니다. 초기 초안에 있던 설정 해시도 제거됐는데, 해시 생성에 쓸 데이터 형식(일반 JSON, RLP, SSZ)에 대한 이견이 있었고 객체 키를 알파벳 순으로 정렬하면 도구로 JSON을 직접 비교할 수 있어 해시가 불필요했기 때문입니다. 형식으로 JSON을 고른 이유는 보편성, 사람과 기계 모두 읽기 쉬움, RFC-8785라는 표준 정규형의 존재입니다. YAML은 표준 정규형이 없고 XML은 쓰는 이더리움 소프트웨어가 없습니다.
하위 호환성과 보안 고려사항
이 EIP는 기존 동작을 바꾸지 않습니다. 캔쿤 이전 포크의 설정은 비표준이어서 해당 포크를 지원하는 클라이언트는 부분적이거나 비표준인 설정을 돌려줄 수 있으며(MAY) 완전한 준수는 캔쿤 이후 포크에만 요구됩니다(REQUIRED). 보안 측면에서는 잘못된 설정이 운영 정보를 노출할 수 있으므로 운영자는 eth_config를 로컬 접근이나 인증된 엔드포인트 같은 신뢰된 인터페이스로 제한하는 것이 좋습니다. 노드가 거짓 설정을 보고할 수 있으므로 모니터링 도구는 알려진 포크 명세나 다른 노드의 응답과 교차 검증할 수 있습니다. 자원 고갈을 막기 위해 설정 객체를 내부에 캐시하고 요청 빈도를 제한할 수 있으며 최소 응답 간격(예: 1초)을 둘 수 있습니다. 이 EIP는 Final 상태로 명세가 확정됐습니다.