메인넷 업그레이드는 제안서 공개만으로 완료되지 않는다. 포함 제안 확정, 테스트넷 적용, 호환 클라이언트 배포, 정해진 epoch·블록 활성화, 체인 상태 확인을 차례로 거쳐야 하며 각 단계의 날짜를 분리해 보도해야 한다.
제안서에서 메인넷 적용까지의 다섯 단계
아이디어가 EIP로 문서화되고 검토·수정된 뒤 업그레이드 범위에 포함된다. 테스트넷 활성화에서 클라이언트 간 호환과 버그를 확인하고, 메인넷 릴리스와 활성화 epoch를 공지한다. 마지막으로 실제 체인이 해당 지점을 통과해 새 규칙으로 블록을 이어 갔는지 확인해야 적용 완료라고 쓸 수 있다.
업그레이드가 합의층과 실행층을 함께 바꾸면 한쪽 클라이언트만 갱신해서는 노드가 정상 동작하지 않을 수 있다. 릴리스 노트의 최소 조합과 알려진 문제, 데이터베이스 마이그레이션 시간을 확인한다. 서드파티 패키지 관리자가 아직 새 버전을 제공하지 않았다면 공식 바이너리 검증 절차를 따른다.
업그레이드 이름은 묶음의 표지이고, 실제 변화는 포함 EIP와 활성화 블록에 있다.
JOBCOIN 해설
Pectra 발표에서 예정과 기능을 나누기
Ethereum Foundation은 2025년 4월 23일 Pectra 메인넷 공지에서 5월 7일 epoch 364032 활성화를 예정하고 호환 클라이언트 릴리스를 제시했다. 공지는 EIP-7702 계정 기능, 검증자 경험 개선, L2 확장을 주요 범주로 설명했다. 발표일에 기능이 이미 메인넷에서 동작했다고 쓰면 시점을 앞당기는 오류다.
테스트넷 성공도 메인넷 무결점 증거는 아니다. 테스트넷의 검증자 분포·부하·애플리케이션 가치가 다르고, 최종 리허설 뒤 사양이 바뀔 수 있다. 어떤 테스트넷이 어느 사양과 클라이언트 버전을 사용했는지 기록하고 메인넷 최종 릴리스와 커밋을 맞춘다.
Fusaka는 별도의 업그레이드 묶음이다
Ethereum Foundation의 2025년 11월 Fusaka 메인넷 발표도 활성화 시점과 클라이언트 버전, 포함 기능을 별도로 안내한다. Pectra 이후 로드맵이라는 이유로 두 업그레이드의 EIP를 섞지 않는다. 지갑 기능 변화, 노드 저장·대역폭 변화, L2 데이터 처리 변화는 영향을 받는 사용자와 운영자가 서로 다르다.
| 상태 | 증거 | 쓸 수 있는 표현 |
|---|---|---|
| 제안 | EIP 문서와 상태 | 검토·제안됐다 |
| 예정 | 재단 공지와 클라이언트 릴리스 | 활성화가 예정됐다 |
| 적용 | 활성화 블록·노드 상태 | 메인넷에서 적용됐다 |
날짜보다 epoch와 블록을 확인하는 이유
네트워크 활성화는 현지 달력 날짜가 아니라 합의 규칙에 설정된 epoch·블록·타임스탬프를 기준으로 한다. 시간대 변환과 블록 진행에 따라 사람에게 보이는 날짜가 다를 수 있다. 보도에는 UTC와 체인 식별자를 함께 적고, 탐색기나 노드에서 최초 새 규칙 블록과 최종성을 확인한다.
EIP 번호가 기사에 나열돼도 이용자 효과가 즉시 보이는 것은 아니다. EIP-7702 같은 기능은 지갑이 새로운 권한 위임 UX와 보안 경고를 구현해야 실제 사용자가 접한다. 프로토콜 허용과 제품 지원을 분리하고, 새 서명 형식이 피싱 면을 어떻게 바꾸는지도 설명한다.
이용자와 노드 운영자의 행동이 다르다
일반 지갑 사용자는 보통 자산을 다른 곳으로 보내거나 새 토큰을 받을 필요가 없다. 노드 운영자는 공식 목록의 실행·합의 클라이언트 버전과 체크섬, 업그레이드 전 동기화 상태를 확인해야 한다. ''업그레이드 지원''을 사칭해 시드 입력이나 토큰 교환을 요구하는 링크는 프로토콜 공지와 무관하다.
블롭 용량처럼 운영 중 점진적으로 조정되는 매개변수가 있다면 최초 하드포크 시점과 후속 BPO 변경을 나눠 쓴다. 한 번의 업그레이드가 목표 용량을 즉시 최대치로 만드는지, 여러 단계 예약 변경인지 공식 사양을 확인한다. 수수료 변화도 같은 기간 수요와 함께 본다.
적용 뒤에도 확인할 지표
체인이 멈추지 않았는지, 최종성 참여율과 클라이언트 오류가 정상인지, 특정 EIP 기능을 실제 지갑과 서비스가 지원하는지 나눠 본다. 프로토콜 기능이 활성화돼도 애플리케이션이 바로 노출하지 않을 수 있다. 버그 수정 릴리스가 나오면 최초 활성화 성공과 후속 운영 안정성을 별도 업데이트한다.
활성화 직후 체인이 정상이라도 소수 클라이언트가 잘못된 블록을 만들거나 RPC가 새 필드를 오해할 수 있다. 재단 상태 공지, 클라이언트 이슈 트래커, 주요 인프라의 장애를 관찰한다. 기술적 최종화와 사용자 서비스의 정상 입출금은 서로 다른 복구 지표다.
- 공식 공지의 epoch·UTC·네트워크를 기록한다
- 포함 EIP와 제외·연기된 제안을 구분한다
- 호환 클라이언트 버전과 체크섬을 확인한다
- 활성화 뒤 체인 최종성과 서비스 지원을 따로 본다
자주 묻는 질문
EIP가 Final이면 메인넷에 이미 적용됐나요?
문서 상태와 특정 네트워크 업그레이드 포함은 별개다. 해당 하드포크 사양과 실제 활성화 블록을 확인해야 한다.
업그레이드 때 보유 ETH를 교환해야 하나요?
프로토콜 업그레이드는 일반적으로 기존 ETH 잔액을 새 토큰으로 바꾸는 절차가 아니다. 공식 재단 공지가 아닌 교환·시드 입력 요구는 피한다.
예정 시각이 지나면 바로 성공인가요?
활성화 지점을 통과했는지와 체인이 정상적으로 최종화되는지 확인해야 한다. 클라이언트별 오류와 후속 패치도 운영 안정성에 영향을 준다.
