EIP-6916 자동 리셋 테스트넷 (Automatically Reset Testnet)

최종 확정 · 네트워크·노드 · 원문 상태 Final · 2023-04-10 작성

정해진 기간이 지나면 자동으로 최초 상태(제네시스)로 되돌아가는 테스트넷의 표준입니다. 클라이언트가 스스로 새 제네시스를 계산해 네트워크를 다시 시작할 수 있게 합니다.

왜 필요한가

테스트넷을 오래 운영하면 문제가 쌓입니다. 거래 기록과 상태 데이터가 계속 불어나 노드를 새로 띄우기 무거워지고 테스트용 코인을 나눠 주는 수도꼭지(faucet)는 자금이 말라 갑니다. 검증자 집합이 비대해지거나 합의 문제가 생겨도 되돌릴 방법이 없습니다. 이 EIP는 네트워크를 주기적으로 제네시스로 되돌리는 방식을 표준으로 정합니다. 리셋 때마다 검증자 집합이 비워지고 자금이 수도꼭지로 돌아오며 데이터베이스가 작게 유지됩니다. 각 네트워크의 제네시스가 정해진 규칙으로 계산되기 때문에, 하나의 테스트 인프라 위에서 짧게 살다 사라지는 네트워크를 반복해서 돌릴 수 있습니다. 애플리케이션과 검증자의 단기 테스트는 물론, 클라이언트의 파괴적인 변경을 시험하는 환경으로도 쓸 수 있습니다.

무엇이 바뀌나

지금

EIP-6916 이후

누구에게 영향이 있나

심층 설명

실행 클라이언트의 제네시스 반복 공식

최초 제네시스인 genesis 0만 클라이언트에 하드코딩하고, 이후의 모든 제네시스는 거기서 결정적으로 계산합니다. 반복 횟수는 i = int((current_slot_timestamp - genesis_0.genesis_time) / period)입니다. 현재 제네시스 시각은 current_genesis.genesis_time = period * i + genesis_0.genesis_time, 현재 체인ID는 chainId = genesis_0.chainId + i입니다. i가 0인 첫 반복에서만 genesis 0을 그대로 쓰고 i>0부터는 이를 전구체(preimage)로 삼아 최신 제네시스를 만듭니다. 클라이언트는 시작할 때 저장된 제네시스가 없거나 현재 슬롯 타임스탬프가 current_genesis.genesis_time + period보다 뒤이면 새 제네시스 생성을 트리거합니다.

합의 클라이언트: ForkDigest를 바꾸는 방법

합의(CL) 쪽도 체인ID처럼 반복 값이 들어간 설정에 더해 갱신된 제네시스 상태(SSZ)가 필요합니다. MIN_GENESIS_TIME은 최신 제네시스 시각으로 설정하고 인프라 재시작 중의 문제를 피하기 위해 15분 정도의 작은 GENESIS_DELAY를 두기를 권합니다. 리셋이 성공하려면 반복마다 ForkDigest가 달라야 하는데, 도구 호환성을 위해 ForkVersions는 고정해 둡니다. 대신 첫 번째 검증자의 출금 자격 증명을 genesis.validators[0].withdrawal_credentials = 0x0100000000000000000000000000000000000000000000000000000000000000 + i로 덮어쓰고 genesis.genesis_validators_root = hash_tree_root(genesis.validators)로 다시 계산합니다. 이렇게 상태가 바뀌므로 매 반복의 ForkDigest가 자연히 달라집니다.

제네시스 상태를 얻는 세 가지 경로

클라이언트가 제네시스 SSZ를 직접 생성하면 신뢰 없이 최신 상태를 만들 수 있지만 구현이 복잡합니다. 체크포인트 동기화를 재활용하는 방식을 권합니다. 테스트넷 플래그가 켜져 있으면 하드코딩된 체크포인트 엔드포인트에서 최신 제네시스 상태를 자동으로 내려받습니다. 사용자가 별도 체크포인트 플래그를 주면 그 엔드포인트를 우선합니다. 체크포인트 동기화가 실패하거나 지원되지 않으면 공개 배포된 SSZ 파일 URL에서 내려받는 예비 경로를 둡니다. 생성 기능이 있다면 내려받은 상태의 값과 체크섬을 검증해 불일치 시 오류를 냅니다. 이 방식은 Holešky 테스트넷에서 이미 쓰인 관행이며 새 클라이언트 릴리스 없이도 유지관리자가 제네시스 검증자 집합을 갱신할 수 있게 합니다.

리셋 절차

terminal_timestamp = current_genesis.genesis_time + period로 네트워크 만료 시점을 정합니다. 그 시점의 슬롯에 도달하면 클라이언트는 블록 생성과 수락을 멈추고 p2p, 비컨 서비스, 실행 환경을 내립니다. 이 중단 기능은 리셋의 나머지 부분 없이도 구현할 가치가 있는데, 이것만으로 포크 사고를 막을 수 있기 때문입니다. 이어서 현재 제네시스와 모든 체인·비컨 데이터를 삭제하고(기존 DB 정리 도구를 재사용할 수 있고 --retain-ephemeral-data 같은 플래그로 삭제 전 내보내기를 지원할 수도 있습니다), 제네시스 함수를 다시 호출해 새 제네시스를 DB에 쓰고 서비스를 재시작합니다. 전체 구현은 수동 재시작 없이 최소한의 중단 시간으로 이 과정을 스스로 수행해야 합니다. 우아한 종료를 지원하지 않는 클라이언트는 내부 리셋 대신 외부 스크립트와 시스템 도구로 같은 동작을 만들 수 있습니다.

기본 지원과 전체 지원

이 EIP는 클라이언트 지원을 두 단계로 나눕니다. 기본 지원은 제네시스 함수만 구현해 현재 네트워크 사양을 계산하고 접속하는 수준입니다. 단기 테스트 참여에는 충분하지만 다음 반복을 따라가려면 사용자가 직접 클라이언트를 끄고 데이터베이스를 지워야 합니다. 전체 지원은 리셋 기능까지 구현해 항상 최신 체인 반복을 자동으로 따라가는 수준으로, 상시 인프라와 제네시스 검증자, 부트노드 운영에 필요합니다. 설계는 외부 도구로 관리되는 노드와도 호환되므로, 커스텀 네트워크를 지원하는 어떤 클라이언트든 스크립트로 리셋하며 같은 네트워크에 참여할 수 있습니다.

리셋 주기와 검증자 수의 관계

period는 클라이언트에 하드코딩되는 상수로, 사용자 필요에 맞춰 정할 수 있지만 보안상 제네시스 검증자 수와 맞물립니다. 검증자 활성화에 걸리는 시간 때문에, 악의적 행위자가 네트워크의 66% 미만 다수를 장악하기 전에 리셋이 오도록 신뢰 검증자 수를 충분히 잡아야 합니다. 원문 기준으로 제네시스 검증자 1만 명이면 1289 에포크(5.7일), 5만 명이면 6441 에포크(28.6일), 10만 명이면 12877 에포크(57.2일), 20만 명이면 25764 에포크(114.5일)까지 안전합니다. 체인ID는 리플레이 공격을 피하려고 반복마다 1씩 증가하므로, 여러 번 반복돼도 다른 공개 EVM 체인과 충돌하지 않도록 낮은 체인ID 값은 피해야 합니다.

한계와 주의점

리셋 때 상태 전체가 지워지므로 장기·고급 애플리케이션 테스트에는 맞지 않습니다. 다만 리셋 후 표준 컨트랙트를 자동 배포하는 오프체인 메커니즘을 누구나 둘 수 있습니다. genesis_validators_root가 미리 알려져 있지 않다는 점도 일부 아키텍처를 깨뜨릴 수 있는데, 이 값을 하드코딩에 의존하는 라이트 클라이언트가 대표적입니다. 보안 측면에서는 취약점이 악용돼도 다음 리셋에서 사라지므로 주기를 몇 주에서 몇 달 수준으로 짧게 유지하는 것이 권장됩니다. 리셋을 트리거하는 메커니즘은 임시 네트워크로 설정되지 않은 다른 네트워크와 반드시 분리해야 합니다. 이 EIP는 상태가 Final로 확정된 표준입니다.

EIP 원문 · ← EIPs