업그레이드의 날짜는 사람이 이해하기 쉽게 환산한 예상치일 수 있다. 실제 조건은 특정 블록 높이, 합의 계층의 에폭, 실행 계층의 Unix 타임스탬프, 누적 난이도 또는 참여자 신호 임계값처럼 명세에 고정된다. 공지에서 네트워크 이름과 활성화 상수를 찾고, 해당 경계를 지난 뒤 호환 클라이언트가 새 규칙으로 블록을 처리했는지 확인해야 ‘시행됐다’고 말할 수 있다.
예정일은 활성화 규칙 그 자체가 아니다
업그레이드 공지에는 대개 날짜와 시각이 가장 크게 보인다. 그러나 노드가 달력을 읽고 규칙을 바꾸는 것은 아니다. 명세에 적힌 블록 번호, 에폭 또는 타임스탬프가 경계에 도달하면 클라이언트가 새 상태 전이 규칙을 적용한다. 블록 생성 간격이 일정하지 않거나 슬롯을 놓칠 수 있는 체인에서는 사람이 보는 시각이 다소 달라질 수 있으므로, 기사 제목의 날짜만으로 성공 여부를 판정하면 안 된다.
Ethereum의 EIP-6953은 역사적으로 블록 번호, 비콘체인 출범 조건, 에폭, 총난이도, 타임스탬프가 서로 다른 활성화 장치로 사용됐음을 정리한다. 특히 병합 이후 업그레이드는 합의 계층에서 에폭을 사용하고, 이에 대응하는 시각을 실행 계층 타임스탬프로 사용한다. 같은 사건에 서로 다른 숫자가 등장해도 모순이 아닐 수 있다는 뜻이다.
업그레이드 뉴스의 핵심 질문은 ‘언제쯤인가’보다 ‘어떤 상태가 되면 새 규칙이 켜지는가’다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 예정일은 활성화 규칙 그 자체가 아니다
업그레이드 공지에는 대개 날짜와 시각이 가장 크게 보인다.
- 활성화 방식마다 확인할 증거가 다르다
블록 높이 방식은 지정 블록의 부모까지 옛 규칙, 해당 블록부터 새 규칙을 적용하는지 본다.
- 포함 결정과 네트워크 시행 사이에는 여러 관문이 있다
개선안이 논의되거나 ‘포함 예정’ 상태가 됐다는 사실은 메인넷 시행과 다르다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
활성화 방식마다 확인할 증거가 다르다
블록 높이 방식은 지정 블록의 부모까지 옛 규칙, 해당 블록부터 새 규칙을 적용하는지 본다. 에폭 방식은 슬롯 여러 개를 묶은 합의 단위의 시작점이 경계다. 타임스탬프 방식은 블록 헤더 시간이 상수를 넘었는지가 중요하다. 참여 임계값 방식은 일정 기간 동안 필요한 신호 수나 예치량이 충족돼야 하므로 예정 창이 끝나도 실패할 수 있다.
비콘체인 출범 사례는 최소 524,288 ETH, 16,384 검증자, 최소 시작시각 경과, 추가 지연이라는 복수 조건을 사용했다. 반면 Paris 업그레이드는 사전에 정한 총난이도로 작동했다. 서로 다른 체인의 공지를 읽을 때 한 사례의 체크리스트를 그대로 복사하지 말고, 해당 네트워크의 명세에서 활성화 변수를 찾아야 한다.
| 조건 | 공식 문서에서 찾을 값 | 활성화 뒤 확인 |
|---|---|---|
| 블록 높이 | 정확한 네트워크와 블록 번호 | 경계 블록의 규칙·클라이언트 로그 |
| 에폭 | 합의 계층 에폭 번호 | 해당 에폭 이후 정당화·최종화 상태 |
| 타임스탬프 | UTC Unix 초와 실행 계층 사양 | 경계 이후 블록의 새 실행 규칙 |
| 참여 임계값 | 측정 창·분모·필요 찬성 수 | 창 종료 시 충족 여부와 후속 경계 |
포함 결정과 네트워크 시행 사이에는 여러 관문이 있다
개선안이 논의되거나 ‘포함 예정’ 상태가 됐다는 사실은 메인넷 시행과 다르다. EIP-7723은 Proposed, Considered, Scheduled, Included 같은 포함 단계를 구분한다. Scheduled for Inclusion도 예기치 않은 문제가 있으면 제외될 수 있고, Included는 네트워크 업그레이드 활성화 뒤의 상태다. 기사에서 ‘채택’이라는 한 단어만 쓰면 기술 사양 합의, 릴리스 포함, 테스트넷 적용, 메인넷 적용을 혼동하게 된다.
실무에서는 제안 문서의 상태, 하드포크 메타 문서, 각 클라이언트 릴리스 노트, 메인넷 활성화 공지를 차례로 연결한다. 그중 하나만 확인해서는 부족하다. 사양이 확정돼도 사용자가 구버전 노드를 실행하면 경계 이후 합의에서 이탈할 수 있고, 클라이언트가 출시돼도 메인넷 경계를 아직 지나지 않았다면 새 규칙은 작동하지 않는다.
네트워크 이름과 계층을 섞으면 잘못된 결론이 나온다
테스트넷에서 먼저 성공한 업그레이드는 메인넷에서도 같은 코드 경로를 시험했다는 근거가 되지만 메인넷 시행 증거는 아니다. 공지 표에서 Sepolia·Hoodi·mainnet 행을 분리하고 각 활성화 상수를 적어야 한다. Ethereum처럼 실행 계층과 합의 계층 클라이언트를 함께 쓰는 구조에서는 두 소프트웨어가 모두 호환 버전인지도 확인한다.
업그레이드 이름도 단서일 뿐이다. 실행 계층과 합의 계층에 서로 다른 이름이 붙고 합쳐 부르는 경우가 있다. 운영자는 명칭보다 버전 조합과 fork 설정값을 기준으로 준비한다. 독자는 기사에 적힌 현지시각을 UTC로 환산할 때 날짜가 하루 달라질 수 있음을 감안하고, 원문의 Unix 타임스탬프나 에폭을 함께 보존하는 편이 안전하다.
- 공식 메타 사양에서 대상 네트워크와 활성화 상수를 기록한다
- 사람용 날짜가 UTC인지 현지시각인지 확인하고 원래 숫자를 남긴다
- 실행·합의 클라이언트의 최소 호환 버전과 알려진 문제를 읽는다
- 테스트넷 성공과 메인넷 경계 통과를 별도의 사건으로 기록한다
- 활성화 뒤 블록 생성뿐 아니라 정당화·최종화와 애플리케이션 동작을 본다
임계값 방식은 분모와 관측 창이 핵심이다
참여자 신호로 업그레이드를 켜는 설계라면 ‘80% 찬성’ 같은 비율만으로는 재현할 수 없다. 지분, 블록, 검증자 수 중 무엇을 세는지, 오프라인 참여자를 분모에 넣는지, 어느 블록부터 어느 블록까지 측정하는지를 알아야 한다. EIP-7848은 온체인 신호 제안의 예로 투표 창 시작·종료, 참조 구현 해시, 필요 승인 수를 명시하고 창 종료 시 임계값을 넘지 못하면 실패하도록 기술한다. 이 문서는 제안 상태이므로 현재 Ethereum 메인넷 규칙으로 오인해서는 안 된다.
제안 문서를 기사 근거로 사용할 때는 ‘이런 방식이 논의됐다’고 표현해야 한다. 실제 시행 체계라고 단정하려면 최종 사양과 활성화 기록이 별도로 필요하다. 특히 거버넌스 투표의 찬성률과 프로토콜 합의 신호는 다른 시스템일 수 있으므로 화면 숫자를 서로 대체하지 않는다.
기사 한 줄을 검증 가능한 상태표로 바꾸기
‘업그레이드가 10월 1일 시행된다’는 문장은 계획인지 확정인지 드러내지 않는다. 대신 ‘메인넷의 합의 계층 에폭 A, 실행 계층 타임스탬프 B에서 활성화되도록 사양이 확정됐고 호환 클라이언트가 공개됐다’처럼 근거를 나눈다. 아직 경계 전이라면 예정, 경계는 지났지만 장애 조사 중이면 활성화·안정화 확인 중, 새 규칙의 블록과 최종성이 확인되면 활성화 확인으로 표시한다.
가격 반응이나 사용자 체감은 별도 질문이다. 프로토콜 규칙이 적용됐다는 기술적 사실만으로 수수료가 즉시 낮아지거나 모든 서비스가 지원을 끝냈다고 말할 수 없다. 지갑·RPC·인덱서·거래 서비스는 각자 호환성 확인과 재개 공지를 낼 수 있으므로 후속 운영 상태를 따로 추적한다.
자주 묻는 질문
업그레이드 예정 시각이 지났으면 자동으로 성공한 건가요?
아니다. 경계 조건 통과 뒤 호환 노드가 새 규칙으로 블록을 처리하고 네트워크가 정상적으로 합의·최종화하는지 확인해야 한다.
테스트넷 활성화가 성공하면 메인넷 일정도 확정인가요?
반드시 그렇지 않다. 테스트 결과에 따라 사양·클라이언트·일정이 바뀔 수 있다. 메인넷 전용 공식 공지와 메타 사양을 다시 확인한다.
에폭 번호와 Unix 타임스탬프가 함께 나오면 무엇을 써야 하나요?
각 계층의 실제 트리거를 모두 기록한다. 사람용 날짜는 보조 표기이며, 원문에 적힌 에폭과 타임스탬프를 검증 기준으로 남긴다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
