사슬이 둘로 갈라진 날: 2013년 3월, 아무도 정한 적 없는 규칙

2026-10-06 · 읽는 데 약 4분 · 블록체인 암호학 컴퓨터

앞 글에서 네트워크의 컴퓨터 하나하나(노드)는 전해 받은 블록을 저마다 검사한다고 했습니다. 그러면 같은 블록을 놓고 노드들의 답이 갈리면 어떻게 될까요? 2013년 3월 11일 비트코인에서 실제로 그런 일이 있었습니다 [S1] [S3].

한 블록, 두 가지 답

그날 225,430번 블록이 만들어져 네트워크에 퍼졌습니다 [S3]. 블록에 든 거래의 입력을 모두 합친 수가 그때까지 나온 어느 블록보다 많았습니다 [S1]. 보고서를 따라 이 블록을 «큰 블록» 이라고 부르겠습니다.

비트코인 프로그램 0.8 버전을 돌리던 노드는 큰 블록을 검사해 유효하다고 받아들였습니다. 0.8 이전 버전을 돌리던 노드 가운데 일부는 받아들이지 않았습니다 [S1]. 답이 둘 나왔습니다(그림 1).

노드는 저마다 검증합니다

노드의 사슬에는 그 노드가 검증한 블록만 들어갑니다. 노드들이 같은 블록들을 갖게 하려고 함께 따르는 검증 규칙을 합의 규칙이라고 합니다 [S2].

큰 블록을 받아들이지 않은 노드의 사슬에는 그 블록이 없습니다. 그 블록 위에 이어진 블록도 붙일 자리가 없습니다. 그래서 사슬이 둘로 갈라졌습니다(그림 2) [S1]. 사슬이 이렇게 갈라지는 것을 포크라고 합니다 [S2].

이중 지불 글에서 본 포크는 다음 블록이 나오면 긴 쪽으로 모였습니다. 이번에는 큰 블록이 든 사슬 쪽에 계산력의 약 60% 가 있었습니다. 보고서는 그래서 포크가 저절로 풀리지 않았다고 적습니다 [S1]. 노드는 유효한 블록만 든 사슬 가운데서 고르는데 [S2], 그 사슬은 아무리 길어져도 옛 프로그램 노드에게는 받아들일 수 없는 사슬이기 때문입니다.

하나가 되는 길은 반대쪽에 있었습니다. 큰 블록이 없는 사슬은 새 프로그램 노드도 받아들일 수 있습니다. 그쪽이 더 길어지면(쌓인 작업이 더 많아지면) 새 프로그램 노드가 그 사슬로 옮겨 옵니다 [S1]. 그런데 계산력이 40% 인 쪽은 블록을 더 느리게 쌓습니다.

계산력을 옮겨 보기

계산력을 어느 쪽에 얼마나 두어야 할까요? 먼저 60% 로 진행해 보고, 그날처럼 과반을 반대쪽으로 옮겨 이어서 해 보세요.

사람이 나서서 다시 하나로

실제로도 그렇게 풀렸습니다. 포크는 금방 알려졌고, 필요한 사람들과 바로 연락이 닿았습니다 [S1]. 블록을 만드는 쪽 가운데 큰 두 곳(BTCGuild 와 Slush)이 자기 노드를 0.8 에서 0.7 로 내렸습니다. 자기들도 큰 블록을 받아들이지 않게 한 것입니다 [S1]. 계산력의 과반이 큰 블록이 없는 사슬로 넘어갔고, 결국 0.8 노드들도 그 사슬로 옮겨 왔습니다1 [S1]. 보고서는 두 곳이 이 일로 적지 않은 돈을 포기했다고 적습니다 [S1].

그동안 큰 거래소들은 입금을 잠시 멈췄습니다 [S1]. 그사이 큰 이중 지불이 적어도 한 번 있었습니다2. 보고서에 따르면 되는지 실험해 본 사람이 한 일이고, 악의는 없었습니다 [S1].

아무도 정한 적 없는 규칙

옛 프로그램은 왜 큰 블록을 받아들이지 못했을까요? 0.8 이전 버전은 Berkeley DB 라는 데이터베이스를 썼습니다. 이 데이터베이스는 쓸 수 있는 잠금(lock)의 수를 미리 설정해 두어야 하는데, 그 수가 «크지만 그 밖에는 유효한» 블록을 처리하기에 모자랐습니다 [S1]. 0.8 은 데이터베이스를 LevelDB 로 바꿨고, 여기에는 같은 한도가 없었습니다 [S1]. 걸린 것은 블록의 크기가 아니라 블록을 처리하는 데 드는 잠금 수였습니다(표 1). 입력이 많은 블록이 왜 잠금을 더 쓰는지는 보고서가 풀어 적지 않습니다. 잠금이 디스크의 쪽(page)마다 잡힌다는 것만 적습니다 [S1].

«잠금이 모자라면 그 블록은 받아들이지 않는다» 는 누가 정한 규칙이 아닙니다. 그런데 보고서는 이 설정이 «암묵적으로 네트워크의 합의 규칙이 되어 있었다» 고 적습니다 [S1]. 일관된 규칙도 아니었습니다. 필요한 잠금 수는 노드마다 디스크에 놓인 데이터의 배치에 따라 달랐습니다. 그래서 모든 노드가 같은 0.7.2 버전이었어도, 이론으로는 한 노드가 만든 블록을 다른 노드가 검증하지 못할 수 있었습니다3 [S1].

숨은 규칙을 드러내 고치기

개발자들은 숨어 있던 규칙을 드러내 적었습니다. 곧 나온 0.8.1 은 두 달 동안, 잠금을 1만 개 넘게 쓸 것 같은 블록을 받아들이지 않고 50만 바이트가 넘는 블록을 만들지 않았습니다4 [S1]. 2013년 8월 16일에는 252,451번 블록이 네트워크에 받아들여졌고, 고치지 않은 노드들은 네트워크에서 떨어져 나갔습니다 [S1].

개발자 안내서는 이 일을 두 번의 하드 포크로 적습니다5. 하나는 뜻하지 않은 하드 포크로, 업그레이드한 노드의 능력을 잠시 낮춰서 풀었습니다. 다른 하나는 그 임시 조치를 걷어 낼 때의, 의도한 하드 포크입니다 [S2].

같은 장부는 같은 규칙에서

«잠금이 모자라면 받아들이지 않는다» 는 누가 정한 적이 없지만, 옛 프로그램의 그 동작이 규칙 노릇을 했습니다 [S1]. 합의를 지키려면 모든 전체 노드가 같은 합의 규칙으로 블록을 검증해야 합니다 [S2]. 시뮬레이터 ① 의 «옛 프로그램도 큰 블록을 받아들인다면» 을 누르면, 두 프로그램의 답이 같을 때는 사슬이 처음부터 갈라지지 않습니다. «모두가 같은 장부를 갖는다» 는 «모두가 같은 규칙으로 검증한다» 에 기대고 있습니다.