EIP-7723 네트워크 업그레이드 포함 단계 (Network Upgrade Inclusion Stages)

콜 결정 없음 · 기타 · 원문 상태 Last Call · 2024-06-12 작성

코어 EIP가 네트워크 업그레이드에 들어가기까지 거치는 다섯 단계(포함 제안, 포함 고려, 포함 확정, 포함 거절, 포함 완료)를 공식 정의하는 메타 EIP입니다.

왜 필요한가

이더리움은 여러 클라이언트 팀이 함께 준비하는 네트워크 업그레이드(하드포크)로 바뀝니다. 그동안 어떤 EIP가 업그레이드에 들어갈지는 코어 개발자 콜에서 논의되어 왔지만 '고려 중'이나 '확정' 같은 단계의 정확한 의미와 단계를 옮기는 기준이 공식 문서로 정리되어 있지 않았습니다. 그래서 프로토콜을 관리하는 개발자도, 바깥에서 지켜보는 커뮤니티도 특정 제안이 어디까지 왔는지 읽기 어려웠습니다. 이 EIP는 포함 제안부터 포함 완료까지 다섯 단계를 정의하고 각 단계로 언제 어떻게 옮기는지 지침을 제공합니다. 이더리움의 거친 합의(rough consensus) 거버넌스에 맞도록 반드시 지켜야 하는 절차는 최소한으로 줄였습니다. 프로토콜 자체를 바꾸는 제안이 아니라 지금 쓰이는 업그레이드 계획 절차를 공식화하는 제안입니다.

무엇이 바뀌나

지금

EIP-7723 이후

누구에게 영향이 있나

심층 설명

다섯 단계와 적용 범위

모든 단계는 하나의 네트워크 업그레이드에만 적용됩니다. EIP는 업그레이드마다 따로 Proposed, Considered, Declined, Scheduled 판정을 받아야 하고 한 EIP가 두 업그레이드에 Included될 수는 없습니다. 이전 업그레이드에서 Declined for Inclusion이 되었더라도 이후 업그레이드에서 다시 제안·고려·확정될 수 있습니다. 단계는 기본적으로 모든 노드가 동시에 활성화해야 하는 Standards Track Core EIP를 대상으로 정의되지만 우선순위 조정과 소통을 돕기 위해 비코어 EIP에도 부여할 수 있습니다. 비코어 EIP에 적용할 때의 차이는 각 단계 정의에 따로 적혀 있습니다.

업그레이드 메타 EIP 운영 규칙

누구나 특정 업그레이드에 들어갈 EIP 목록을 담는 메타 EIP 초안을 작성할 수 있습니다. 명세 절에는 Proposed for Inclusion, Declined for Inclusion, Considered for Inclusion, Scheduled for Inclusion 네 범주를 두어야 하고 아직 내용이 없어 TBD라도 명확성을 위해 초안부터 포함하는 것이 좋습니다. 메타 EIP가 Review 상태로 가면 Proposed와 Declined 목록을 지웁니다. Last Call로 가면 Considered 목록까지 지워 Scheduled 목록만 남깁니다. Final이 되기 전에는 Scheduled for Inclusion 범주 이름을 Included로 바꾸고 실제로 그 업그레이드에서 활성화된 EIP만 남겨야 합니다.

업그레이드 데브넷과 단계의 연동

클라이언트 개발자는 EIP를 오래 유지되는 테스트넷에 올리기 전에 먼저 임시 테스트 네트워크인 업그레이드 데브넷에 구현해 클라이언트 간 상호운용성을 검증합니다. 데브넷 이름은 upgradeName-devnet-version 형식을 따릅니다. 예를 들어 Pectra 업그레이드의 첫 데브넷은 pectra-devnet-0, Dencun 업그레이드의 두 번째 데브넷은 dencun-devnet-1입니다. 업그레이드에 어떤 EIP를 넣을 수 있는지는 결국 데브넷에서 구현·테스트할 수 있는 범위에 달려 있으므로, 이 EIP는 Considered와 Scheduled 상태를 데브넷 구현 상태와 맞추자고 제안합니다.

포함 제안(PFI)과 포함 고려(CFI)의 요건

포함을 제안하려면 메타 EIP의 Proposed for Inclusion 절에 해당 EIP를 추가하는 풀 리퀘스트를 열어야 하고 합리적인 풀 리퀘스트는 메타 EIP 저자가 제때 병합해야 합니다. 제안자는 업그레이드 주기 동안 연락 창구 역할을 맡거나 다른 사람을 지정해야 하며 제안은 다음 업그레이드로 자동 이월되지 않습니다. 클라이언트 개발자가 검토를 마치고 데브넷에 넣어 보려는 의사를 밝히면 Considered for Inclusion으로 올립니다. ACDE와 ACDC 콜 진행자는 테스팅 팀과 함께 CFI EIP의 우선순위 안을 만들어 메타 EIP에 반영합니다. 이 우선순위가 다음 데브넷 구성에 참고가 됩니다. CFI EIP는 execution-specs에 파이썬 구현과 테스트를 담은 공개 PR을 두는 것이 권장됩니다. 구현 없이 CFI가 되는 것도 허용되지만 그 경우 테스트 주기가 늦어질 수 있습니다.

포함 확정(SFI)의 성숙도 기준

Scheduled for Inclusion은 코어 개발자들이 다음 업그레이드에 넣겠다는 강한 의지에 합의하고 명세와 구현이 일정 수준 성숙했다고 판단할 때 부여합니다. 성숙도 기준은 네 가지입니다. 높은 참여율에 1주 이상 치명적 버그가 없는 안정적인 데브넷에 포함되었을 것, 자리표시자 값이나 미결 설계가 없을 만큼 명세가 최종에 가까울 것, 다른 CFI EIP와의 상호작용이 적거나 같은 데브넷에서 검증되었을 것, 클라이언트들이 합의 테스트를 통과하고 알려진 분기가 없을 만큼 테스트 범위가 충분할 것입니다. SFI 적격 여부는 ACDT 콜에서 검토하고 상태 변경은 ACDE나 ACDC에서 비준합니다. 최신 데브넷은 모든 SFI 코어 EIP를 포함해야 합니다. SFI EIP는 execution-specs에 파이썬 구현과 테스트가 공개 PR 또는 devnets/upgradeName/version 브랜치 병합 형태로 있어야 하고 구현은 예외적으로 면제될 수 있어도 테스트는 반드시 있어야 합니다. 사정이 생기면 SFI에서 DFI로 내릴 수 있고 포함 의사는 있지만 바로 다음 데브넷에 넣기 어려우면 CFI로 되돌릴 수 있습니다.

포함 거절(DFI)과 포함 완료(Included)

클라이언트 팀들이 포함에 반대하면 업그레이드 계획 중 언제든, 어느 단계에서든 EIP를 Declined for Inclusion으로 옮길 수 있습니다. DFI는 이번 업그레이드에서 그 EIP를 제외하고 포함 여부나 구현 상태에 관한 논의를 중단하겠다는 신호입니다. 다만 예외적인 상황에서는 DFI에서 CFI나 SFI로 되돌릴 수 있고 다음 업그레이드에 다시 제안하는 것도 막지 않습니다. 업그레이드가 활성화된 뒤에는 포함된 모든 코어 EIP와 활성화된 비코어 EIP를 메타 EIP의 Included로 옮기고 나머지 상태 목록은 모두 지워야 합니다.

프로토콜 비변경과 현재 상태

이 EIP는 프로토콜을 직접 바꾸지 않고 현재 쓰이는 업그레이드 계획 절차의 일부를 공식화합니다. 그래서 하위 호환성 문제가 없고 보안 고려 사항도 없습니다. 이더리움의 거친 합의 거버넌스에 맞춰 반드시 따라야 하는(MUST) 절차는 최소화했습니다. 원문은 이 절차를 최소 한 번의 업그레이드 주기 동안 써 본 뒤 Last Call로, 최소 두 번 써 본 뒤 Final로 옮기자고 제안합니다. 현재 상태는 Last Call이고 마감일은 2025-04-01입니다. 콜 기록으로는 07.09 ACDC #182와 07.20 ACDT #88에서 논의되었으나 결정은 없었습니다. Final이 되기 전까지 내용이 더 다듬어질 수 있습니다.

EIP 원문 · ← EIPs