📈 이더리움 하드포크 20개를 스펙 원문으로 세니 블록 번호 14개와 시각 6개로 갈렸어요

「이더리움 하드포크가 지금까지 몇 번 있었나」를 찾아보면 자료마다 숫자가 달라요. 세는 기준을 안 적어 두기 때문이에요. 그래서 정리 글을 다시 정리하는 대신, 이더리움 실행 계층 스펙 저장소를 열어 포크 폴더를 직접 셌어요.

먼저 답부터 적을게요. 커밋 하나로 고정한 mainnet 브랜치 기준으로 포크 폴더는 20개였어요. 그리고 각 폴더가 스스로 선언한 활성화 조건을 분류하니 블록 번호 14개와 타임스탬프 6개로 갈렸어요. 두 종류가 섞인 자리는 한 곳도 없었고, 갈리는 경계는 정확히 병합 지점이었어요.

이 글이 재는 자리를 못박을게요. 스펙 저장소의 파일 텍스트만 읽고 셌어요. 클라이언트를 빌드하지도, 노드를 돌리지도, 체인에서 수치를 받아 오지도 않았어요. 그래서 이 글의 문장은 전부 「이더리움 네트워크가 그렇다」가 아니라 「스펙 저장소가 그렇게 적어 두었다」까지예요. 조회 시각은 2026년 9월 14일 오전 11시 54분부터 낮 12시 15분까지(한국 시각)예요. 매매 권유가 아니에요.

이더리움 하드포크를 세기 전에 분모부터 못박았어요

숫자보다 먼저 정해야 하는 건 「어느 저장소의 어느 브랜치를 열었나」예요.

여기서 먼저 넘어진 자리를 적어 둘게요. 실행 계층 스펙 저장소에는 master 브랜치가 아예 없어요. 「어느 저장소든 master 가 있겠지」 하고 요청하면 404가 돌아와요. 브랜치 목록 84개를 받아 확인한 결과이고, 기본 브랜치 이름은 지금 개발 중인 포크 이름을 그대로 쓰고 있었어요. 반대로 합의 계층 저장소는 master 가 맞았고요. 이런 자리를 대충 넘기면 「없는 것」을 「0건」으로 오인해서 적게 돼요.

폴더를 셀 때는 엔드포인트를 바꿔 두 번 셌어요. 디렉터리 목록을 주는 쪽으로 한 번 세고, 전혀 다른 방식인 전체 경로 목록을 주는 쪽으로 다시 세었는데 둘 다 같은 값이 나왔어요. 두 번째 응답에는 「잘라서 줬다」는 표시가 꺼져 있어서, 응답이 잘려 덜 세인 게 아니라는 것도 확인했어요.

20 더하기 4가 24예요. 그러니까 「이더리움 하드포크는 20번이다」라고 단정하면 곤란해요. 정확히는 실행 계층 스펙 저장소의 mainnet 브랜치가 폴더로 나눠 놓은 기준으로 20개예요. 기준을 바꾸면 수가 바뀌고, 그 이야기는 아래에서 다시 할게요.

활성화 조건은 세 종류인데 메인넷 브랜치엔 두 종류만 있었어요

각 포크 폴더에는 그 포크가 언제 켜지는지를 적은 선언이 한 줄씩 들어 있어요. 조건 종류를 정의한 파일을 먼저 열었어요.

BLOCK_NUMBER: Final[int] = 0
"""
Value representing a fork criteria based on the block's number.

Used for pre-merge blocks.
"""

TIMESTAMP: Final[int] = 1
"""
Value representing a fork criteria based on the block's timestamp.

Used for post-merge blocks.
"""

UNSCHEDULED: Final[int] = 2
"""
Value representing a fork criteria that will never be satisfied.

Used for in-development forks.
"""

정리하면 이래요. 블록 번호 기준은 「병합 이전 블록에 쓴다」고 적혀 있고, 타임스탬프 기준은 「병합 이후 블록에 쓴다」고 적혀 있어요. 미정은 「절대 충족되지 않는 조건」이라고 적혀 있고 개발 중인 포크에 쓴다고 되어 있어요.

이 대목이 중요해요. 「경계가 병합이다」는 제 해석이 아니라 스펙 주석이 직접 적어 둔 문장이에요. 합의 방식이 왜 바뀌었는지는 작업증명과 지분증명의 차이 쪽에 따로 정리해 뒀고, 이 글에서는 병합이 조건 종류를 갈랐다는 한 문장까지만 쓸게요.

정렬 규칙도 같은 파일에 원문으로 있어요.

All [`BLOCK_NUMBER`] forks come before [`TIMESTAMP`] forks, and all
scheduled forks come before [`UNSCHEDULED`] forks.

판정 방식도 짚고 갈게요. 두 조건 모두 값이 같을 때가 아니라 그 값 이상이면 켜지는 방식이에요. 블록 번호 기준은 블록 번호가 적힌 값 이상이면, 타임스탬프 기준은 블록의 타임스탬프가 적힌 값 이상이면 켜져요. 미정 조건의 판정 함수는 아예 「절대 일어나지 않는다」는 설명과 함께 항상 거짓을 돌려주도록 적혀 있어요.

20개를 전부 펼친 표예요

mainnet 브랜치 폴더 20개의 선언을 하나씩 읽어 옮긴 표예요. 값은 스펙에 적힌 그대로예요.

14 더하기 6이 20이에요. 그리고 표를 위에서 아래로 읽으면 열네 번째까지 줄줄이 블록 번호, 열다섯 번째부터 줄줄이 타임스탬프예요. 중간에 한 번 되돌아가는 자리가 없어요.

세는 범위를 다시 적어 둘게요. 이 표는 폴더가 스스로 적어 둔 선언 한 줄씩을 옮긴 것이고, 그 포크가 실제로 언제 네트워크에서 켜졌는지를 체인에서 확인한 값은 아니에요.

경계에 선 파리 포크는 원래 다른 조건이 적혀 있던 자리예요

여기가 이 글에서 가장 조심해야 하는 자리예요. 열네 번째인 paris 폴더에는 블록 번호가 적혀 있지만, 주석이 그 사정을 직접 밝히고 있어요.

# The actual trigger for the Paris hardfork was The Merge occurring when
# total difficulty (the sum of the all block difficulties) reached the
# Terminal Total Difficulty value (58750000000000000000000 on Mainnet). The
# Merge is now a historical event.

읽어 보면 이래요. 병합의 진짜 발동 조건은 블록 번호가 아니라 누적 난이도가 58,750,000,000,000,000,000,000에 닿는 것이었고, 이제는 지나간 일이 되었기 때문에 그때 넘어간 블록 번호로 바꿔 적었다는 거예요. 그러니까 블록 번호 14개 중 한 개는 원래 다른 조건이 적혀 있던 자리예요. 같은 값이 합의 계층 설정 파일에도 그대로 들어 있었어요.

표 모양이 바뀌는 자리도 정확히 여기예요. 파리 폴더의 안내 표에는 누적 난이도 칸이 있는데, 샹하이 폴더부터는 그 칸이 사라지고 타임스탬프 칸과 비컨 체인 에포크 칸이 생겨요. 같은 저장소 안에서 표의 열 구성이 바뀌는 지점이 딱 한 번인데, 그게 병합 자리예요.

시각 6개를 에포크로 되돌리니 합의 계층과 6개 중 6개가 맞았어요

실행 계층이 적어 둔 건 유닉스 타임스탬프인데, 합의 계층은 같은 포크를 에포크라는 단위로 적어요. 두 값이 정말 같은 순간을 가리키는지 직접 확인해 봤어요.

에포크 하나는 슬롯 32개이고 슬롯 하나는 12초라서, 에포크 하나는 384초예요. 두 값 모두 합의 계층 설정 파일에 상수로 적혀 있어요. 여기서 쓰는 384초는 스펙에 적힌 상수값이고, 블록이 실제로 몇 초마다 나오는지를 잰 실측값이 아니에요. 실측 쪽 이야기는 슬롯 12초와 실제 블록 간격 글에 따로 있어요.

먼저 구간별로 검산했어요. 기준 시각을 몰라도 되는 방식이에요.

다섯 구간 전부 나머지 0으로 떨어졌어요. 그다음에는 각 포크의 타임스탬프에서 에포크 곱하기 384를 빼 봤어요.

shanghai  1681338455 - 194048*384 = 1606824023
cancun    1710338135 - 269568*384 = 1606824023
prague    1746612311 - 364032*384 = 1606824023
osaka     1764798551 - 411392*384 = 1606824023
bpo1      1765290071 - 412672*384 = 1606824023
bpo2      1767747671 - 419072*384 = 1606824023

여섯 식이 전부 같은 값을 냈어요. 1,606,824,023 은 2020년 12월 1일 오후 9시 0분 23초(한국 시각)예요. 이건 스펙 어딘가에 적힌 값을 옮겨 적은 게 아니라 여섯 식이 각자 계산해서 같은 답을 낸 것이라 의미가 달라요. 기준 시각이 틀렸다면 여섯 값이 정수로 떨어지지도, 서로 같지도 않았을 거예요.

마지막으로 실행 계층 타임스탬프와 합의 계층 설정값을 한 줄씩 맞대 봤어요.

6개 중 6개 일치예요. 관리 주체가 다른 두 저장소인데 값이 한 개도 안 어긋났어요. 덤으로 각 폴더 안내 표에도 비컨 체인 에포크 칸이 따로 있는데, 그 칸의 값까지 위 환산값과 같았어요. 세 방향이 맞은 셈이에요.

두 이름이 서로 다른 것도 눈에 띄죠. 실행 계층은 shanghai, 합의 계층은 CAPELLA 로 부르는데 같은 순간이에요. 실행 계층과 합의 계층이 각자 이름을 붙이기 때문에 한 번의 업그레이드에 이름이 둘씩 붙어요. 이름이 다르다고 다른 포크로 세면 수가 부풀어요.

설정 한 줄만 바꾸는 하드포크가 따로 생겼어요

표 아래쪽의 bpo1 과 bpo2 는 이름부터 다르게 생겼죠. 이건 블롭 관련 설정값만 바꾸는 전용 포크예요. 관련 제안 문서를 열어 보니 상태가 확정(Final)이고 종류는 정보 제공형으로 적혀 있었어요. 본문 두 문장이 성격을 정확히 말해 줘요.

BPO hardforks are defined as protocol upgrades that modify only blob-related
parameters through configuration, without requiring any client-side code changes.
The new parameters take effect immediately at the specified activation time.

클라이언트 코드를 고치지 않고 설정만 바꾸는 업그레이드이고, 새 설정값은 지정된 활성화 시각에 곧바로 적용된다는 뜻이에요. 바꾸는 값도 세 개로 못박혀 있어요. 목표치, 상한, 그리고 기본 수수료 갱신에 쓰는 나눗수예요.

이름 짓는 규칙도 문서에 적혀 있어요. bpo 뒤에 번호를 붙이는 방식이고 번호는 1부터 시작해요. 그리고 활성화 시각을 반드시 적어야 하는 건 프라하 이후에 오는 포크뿐이라고 적어 두었어요. 실제로 폴더 이름이 bpo1, bpo2 순서로 붙어 있었고, 앞에서 본 것처럼 둘 다 타임스탬프 조건이었어요.

이 글에서 블롭 이야기는 「한 줄만 바꾸는 포크가 왜 따로 필요했나」까지만 쓸게요. 그 설정값이 실제 수수료를 어떻게 움직이는지는 이 글이 잰 자리가 아니에요.

아직 시각이 안 적힌 포크는 기본 브랜치에만 있었어요

mainnet 브랜치 20개 중 미정 상태인 폴더는 0개였어요. 그리고 조회 시각 기준으로 아직 안 온 타임스탬프 포크도 0개였어요. 여섯 개 전부 이미 지난 시각이었거든요. 분모는 mainnet 브랜치 20개 폴더 중 타임스탬프 조건 6개이고, 비교 기준은 2026년 9월 14일 낮 12시 15분(한국 시각)이에요.

미정 폴더 4개는 기본 브랜치에만 있었어요. 그중 한 폴더를 열어 보면 이렇게 생겼어요.

| Network | Timestamp    | Date & Time (UTC)       | Fork Hash    | Beacon Chain Epoch |
| Mainnet | `          ` |                         | `          ` | `      `           |

칸이 통째로 비어 있어요. 표 자리는 미리 만들어 두었는데 채울 값이 아직 없는 상태예요. 선언 쪽에도 시각 대신 순서 번호만 붙어 있고요.

그래서 「다음 하드포크는 언제」라는 질문에 이 글이 답할 수 있는 범위는 여기까지예요. 스펙 저장소에 개발 중인 폴더가 4개 있고, 그 폴더들은 활성화 시각이 비어 있다. 그 이상을 일정처럼 말하면 스펙이 적지 않은 것을 적는 셈이 돼요.

포크 폴더가 링크한 제안 문서 번호도 세어 봤어요

각 포크 폴더의 설명문에는 그 포크와 관련된 제안 문서가 링크로 달려 있어요. 그 번호를 세면 이렇게 나와요.

세는 법을 반드시 같이 읽어 주세요. 이건 「그 포크에 들어간 제안 전부」가 아니라 「그 폴더 설명문이 링크 형태로 적어 둔 번호」의 개수예요. 변경 사항 항목뿐 아니라 참고 안내 항목에 적힌 번호도 함께 잡혀요. 그래서 다른 집계와 숫자가 다를 수 있어요. 제안 문서 저장소 전체를 분모로 삼아 번호를 센 이야기는 제안 문서 저장소 분리 실측 쪽에 따로 있는데, 그쪽은 저장소 전체가 분모이고 이 글은 포크 폴더 설명문이 분모라 두 숫자를 나란히 놓고 비교하면 안 돼요.

폴더별로 보면 osaka 가 13개로 가장 많고 prague 11개, byzantium 10개 순이에요. 여기서도 같은 주의가 붙어요. 「프라하는 제안 11개」가 아니라 「프라하 폴더 설명문이 링크한 번호가 11개」라고 읽어야 해요. 폴더별 값을 전부 더하면 85가 되어 위 표와 맞아요. 여러 폴더에 걸쳐 나온 유일한 번호는 앞에서 본 블롭 전용 포크를 정의한 문서였고, 여섯 폴더에 걸쳐 있었어요.

기준을 바꾸면 이더리움 하드포크 수가 달라져요

마지막으로 「그래서 몇 개냐」를 다시 한번 흔들어 둘게요. 같은 질문에 대해 저장소가 내놓는 답이 여러 개예요.

합의 계층 설정 파일의 포크 에포크 항목 9개 중 실제 에포크가 박힌 건 6개이고, 나머지 3개에는 18,446,744,073,709,551,615 라는 값이 들어 있어요. 이건 부호 없는 64비트 정수가 담을 수 있는 최댓값, 그러니까 2의 64제곱 빼기 1이에요. 파일 주석이 그 이유를 직접 적어 두었어요.

# Some forks are disabled for now:
#  - These may be re-assigned to another fork-version later
#  - Temporarily set to max Uint64 value: 2**64 - 1

「지금은 끈 상태이고 나중에 다른 포크 버전으로 재배정될 수 있다」는 뜻이에요. 절대 오지 않을 만큼 큰 수를 넣어 두는 방식으로 「아직 아님」을 표현한 거죠. 실행 계층이 미정이라는 별도 상태를 만들어 처리한 자리를, 합의 계층은 최댓값을 넣는 방식으로 처리한 셈이에요. 같은 사정을 두 저장소가 다르게 적고 있다는 게 흥미로운 대목이에요.

정리하면, 하드포크를 몇 번으로 셀지는 어느 계층의 무엇을 분모로 삼았는지에 달려 있어요. 그래서 이 글은 처음부터 끝까지 분모를 붙여 적었어요. 분모가 다른 두 숫자를 나란히 놓고 「자료마다 다르다」고 말하는 게 가장 흔한 오해예요.

확인하지 못한 것

범위를 분명히 해 둘게요.

• 노드를 돌리거나 클라이언트를 빌드하지 않았어요. 스펙 저장소의 텍스트를 읽고 센 것까지가 전부예요. 각 포크가 실제로 그 블록·그 시각에 켜졌는지를 체인에서 확인한 게 아니에요.
• 커밋 두 개에 고정한 스냅샷이에요. 폴더가 하나 더 생기거나 비어 있던 칸이 채워지면 20도 24도 0도 바뀌어요.
• 제안 문서 번호 83개는 링크를 센 값이에요. 각 문서가 실제로 그 포크에 포함되었는지를 문서 본문으로 재확인하지는 않았어요.
• 테스트넷 값은 세지 않았어요. 각 폴더 안내 표에는 테스트넷 행도 함께 있지만, 이 글은 메인넷 행만 읽었어요.
• 미정 포크가 언제 활성화될지는 확인할 방법이 없어요. 스펙이 시각 칸을 비워 둔 상태라는 것까지가 확인되는 사실이에요.

자주 묻는 질문 (FAQ)

Q. 이더리움 하드포크 목록을 어디서 직접 볼 수 있나요?

실행 계층 실행가능 스펙 저장소의 포크 폴더를 열어 보면 돼요. 다만 브랜치를 먼저 고르셔야 해요. 메인넷에 이미 적용된 것만 보려면 mainnet 브랜치를, 개발 중인 것까지 보려면 기본 브랜치를 열면 돼요. 2026년 9월 14일 기준으로 앞쪽은 20개, 뒤쪽은 24개였어요.

Q. 블록 번호 기준과 타임스탬프 기준은 왜 다른가요?

병합 이전에는 블록이 몇 초마다 나올지가 고정되어 있지 않았어요. 그래서 시각으로 약속하면 언제 켜질지 알기 어려웠고, 블록 번호로 약속하는 편이 확실했어요. 병합 이후에는 슬롯 단위가 생겨 시각이 예측 가능해졌고요. 다만 이 설명 중 스펙이 직접 적어 둔 부분은 블록 번호 기준은 병합 이전 블록에, 타임스탬프 기준은 병합 이후 블록에 쓴다는 문장까지예요.

Q. 하나의 업그레이드에 이름이 두 개인 이유는 뭔가요?

실행 계층과 합의 계층이 각자 이름을 붙이기 때문이에요. 2026년 9월 14일 기준으로 실행 계층 폴더 이름이 샹하이일 때 합의 계층 설정에서는 카펠라로 적혀 있고, 두 값을 에포크로 환산해 맞춰 보면 같은 순간을 가리켜요. 이 글에서는 시각 조건 여섯 개를 전부 그렇게 맞춰 봤고 여섯 개가 모두 일치했어요.

Q. 블롭 전용 포크는 왜 따로 세나요?

폴더가 따로 있기 때문이에요. 설정값만 바꾸는 업그레이드라도 활성화 시각이 따로 필요하고, 그 시각을 적어 둘 자리가 있어야 하니까 폴더가 하나씩 생겨요. 그래서 폴더를 세는 방식으로는 일반 하드포크와 같은 한 칸을 차지해요. 반대로 굵직한 업그레이드만 세는 목록에서는 빠질 수 있어서, 두 집계가 어긋나는 흔한 자리예요.

Q. 20개 중에 되돌려진 포크도 들어 있나요?

목록에는 체인이 갈라졌던 사건과 관련된 폴더도 들어 있고, 수수료 구조를 바꾼 폴더도, 시한을 뒤로 미루기만 한 폴더도 함께 들어 있어요. 폴더 기준으로 세면 성격을 가리지 않고 한 칸씩 차지해요. 그러니 20이라는 값은 사건의 크기를 잰 값이 아니라 스펙이 파일을 나눈 횟수라고 읽으시는 편이 정확해요.

Q. 이 숫자를 다시 세어 보려면 어떻게 하나요?

저장소 이름과 브랜치, 그리고 커밋을 먼저 고정하세요. 브랜치만 적고 커밋을 안 적으면 나중에 다시 셌을 때 값이 달라져도 원인을 찾을 수 없어요. 그리고 폴더 개수는 서로 다른 두 방식으로 세어 보시길 권해요. 이 글도 그렇게 두 번 세었고 두 값이 같았기 때문에 20이라고 적을 수 있었어요.

정리

• 실행 계층 스펙 저장소의 mainnet 브랜치 기준으로 포크 폴더는 20개이고, 활성화 조건은 블록 번호 14개와 타임스탬프 6개로 갈렸어요. 두 종류가 섞인 자리는 0곳이었어요.
• 경계는 정확히 병합 지점 한 곳이에요. 이건 해석이 아니라 스펙 주석이 블록 번호는 병합 이전, 타임스탬프는 병합 이후라고 직접 적어 둔 내용이에요.
• 열네 번째인 paris 는 원래 누적 난이도 조건이었던 자리이고, 지난 일이 되어 블록 번호로 바꿔 적었다고 주석이 밝히고 있어요.
• 타임스탬프 6개를 에포크로 환산해 합의 계층 설정과 맞대니 6개 중 6개가 일치했고, 기준 시각 역산에서도 여섯 식이 전부 같은 값을 냈어요.
• mainnet 브랜치에 미정 폴더는 0개이고, 미정 폴더 4개는 기본 브랜치에만 있으며 활성화 시각 칸이 비어 있어요. 그 이상을 일정처럼 말할 수 없어요.
• 모든 값은 실행 계층 커밋 7b8124a77280, 합의 계층 커밋 f21dac06e997, 조회 2026년 9월 14일 낮 12시 15분(한국 시각) 기준이고, 노드를 돌려 확인한 값은 아니에요.

이 글은 매매 권유가 아닌 정보 제공 글입니다. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 투자 판단과 그 결과에 대한 책임은 본인에게 있습니다.