비트코인과 피어코인의 Fork 선택 규칙

비트코인과 피어코인은 왜 포크를 허용할까?

지난 글에서는 Safety와 Liveness에 대해 정리했다. Safety는 정상적인 노드들이 서로 같은 결과를 바라보는 성질이다. 반대로 Liveness는 시스템이 멈추지 않고 계속 다음 단계로 진행되는 성질이다. 블록체인에서는 새로운 블록이 계속 만들어져야 하고 사용자의 거래도 결국 처리되어야 한다.

 

문제는 비동기 네트워크 환경에서는 Safety와 Liveness를 동시에 완벽하게 만족시키기 어렵다는 점이다. 래서 어떤 합의 알고리즘은 Safety를 더 중요하게 보고, 어떤 합의 알고리즘은 Liveness를 더 중요하게 본다.

 

이번 글에서는 그중에서 Liveness를 우선시하는 방식에 가까운 비트코인의 나카모토 컨센서스와 피어코인의 체인 기반 지분증명을 정리해보려고 한다.

---

나카모토 컨센서스란?

출처: DSRV Research

나카모토 컨센서스는 비트코인에서 사용되는 합의 방식이다. 비트코인에서는 채굴자들이 새로운 블록을 만들기 위해 경쟁한다. 채굴자는 어려운 연산을 수행하고, 가장 먼저 조건에 맞는 값을 찾으면 새로운 블록을 제안할 수 있다.

 

그런데 비트코인 네트워크는 전 세계에 퍼져 있다. 그래서 어떤 채굴자가 만든 블록이 모든 노드에게 동시에 전달되는 것은 아니다. 서울의 채굴자와 뉴욕의 채굴자가 거의 동시에 새로운 블록을 만들 수도 있고 네트워크 지연 때문에 어떤 노드는 서울 채굴자의 블록을 먼저 받고, 다른 노드는 뉴욕 채굴자의 블록을 먼저 받을 수도 있다. 이런 상황에서는 체인이 잠깐 두 갈래로 나뉠 수 있는데 이걸 포크라고 한다. 

---

나카모토 컨센서스에서 포크가 발생하는 이유

비트코인은 포크가 절대 발생하지 않도록 막는 구조가 아니다. 예를 들면 다음과 같다.

• 서울의 채굴자가 새로운 블록 A를 만들었다.
• 뉴욕의 채굴자가 거의 동시에 새로운 블록 B를 만들었다.
• 어떤 노드는 블록 A를 먼저 받았다.
• 다른 노드는 블록 B를 먼저 받았다.
• 그 결과 잠깐 동안 체인이 A 방향과 B 방향으로 나뉜다.

이 상황이 바로 포크다. 포크가 발생했다는 것은 적어도 그 순간에는 모든 노드가 같은 블록을 보고 있지 않다는 뜻이다. 즉, Safety가 완벽하게 보장되는 상태는 아니다.

 

하지만 비트코인은 여기서 블록 생성을 멈추지 않는다. 포크가 발생하더라도 우선 블록 생성은 계속 이어진다. 이 점에서 비트코인은 Safety보다 Liveness를 더 우선시하는 방식에 가깝다.

---

Fork Choice Rule이란?

비트코인이 포크를 허용한다고 해서 포크를 그대로 방치하지 않는다. 포크가 발생하면 결국 여러 갈래의 체인 중 하나를 정답 체인으로 선택해야 한다. 이때 사용하는 규칙이 Fork Choice Rule이다.

 

비트코인에서는 더 많은 작업증명이 쌓인, 즉 더 많은 연산이 투입된 체인을 정답 체인으로 보는 것이다. 예를 들면 다음과 같다.

• 체인이 A, B 방향으로 나뉘었다.
• 이후 채굴자들이 A 체인 위에 더 많은 블록을 붙였다.
• A 체인에 더 많은 작업증명이 쌓였다.
• 네트워크는 A 체인을 정답 체인으로 받아들인다.
• B 체인에 있던 일부 블록과 거래는 버려질 수 있다.

---

피어코인이란?

피어코인은 지분증명에 대한 연구가 이루어지던 초기에 개발된 블록체인이다. 원문에서는 피어코인을 나카모토 컨센서스와 마찬가지로 Safety보다 Liveness를 우선으로 하는 합의 알고리즘의 예시로 설명한다.

 

피어코인의 합의 방식은 나카모토 컨센서스와 유사하지만, 새로운 블록을 생성하는 방식에서 차이가 있다. 비트코인에서는 채굴자가 작업증명 연산을 수행해서 블록을 만든다.

반면 피어코인에서는 coin-age라는 개념을 사용한다. 비트코인이 “얼마나 많은 연산을 했는가?”를 중요하게 본다면, 피어코인은 “얼마나 많은 코인을 얼마나 오래 가지고 있었는가?”를 중요하게 본다고 이해할 수 있다.

---

coin-age란?

coin-age는 코인을 얼마나 많이, 얼마나 오래 보유했는지를 나타내는 개념이다. 원문에서는 이것을 coin-days라는 방식으로 설명한다. 예를 들면 다음과 같다.

• A가 10개의 코인을 가지고 있다.
• A가 그 코인을 5일 동안 보유했다.
• 그러면 A는 10 × 5 = 50 coin-days를 가진다.
• coin-age가 늘어나면 블록을 생성하기 쉬워진다.

즉, 피어코인에서는 단순히 코인을 많이 가지고 있는 것만 중요한 것이 아니다. 그 코인을 얼마나 오래 보유했는지도 중요하다. coin-age가 시간이 지남에 따라 늘어나거나, 더 많은 코인을 보유하게 되면 블록을 생성할 가능성이 높아진다. 이런 방식을 원문에서는 체인 기반 지분증명이라고 설명한다.

---

피어코인의 Fork Choice Rule

피어코인도 Liveness를 우선시하기 때문에 포크가 발생할 수 있다. 그래서 피어코인에도 여러 포크 중 하나를 선택하는 Fork Choice Rule이 필요하다.

다만 비트코인과 선택 기준이 다르다. 비트코인은 더 많은 작업증명이 쌓인 체인을 선택한다. 피어코인은 더 많은 coin-age가 사용된 체인을 선택한다. 예를 들면 다음과 같다.

• 체인이 A, B 방향으로 나뉘었다.
• A 체인에는 총 90 coin-days가 사용되었다.
• B 체인에는 총 100 coin-days가 사용되었다.
• 피어코인은 더 많은 coin-days가 사용된 B 체인을 선택한다.

원문에서는 이 방식이 제대로 작동하지 않을 경우 Safety를 보장하기 어려워질 수 있다고 설명한다.

그 대표적인 문제가 바로 Nothing-at-Stake 문제다.

---

Nothing-at-Stake 문제란?

Nothing-at-Stake는 말 그대로 “잃을 것이 없다”는 뜻이다. 원문에서는 피어코인에서 포크가 발생했을 때 블록 생성자가 두 포크 중 하나를 선택할 필요 없이 두 포크 모두에 블록을 생성할 이유가 생긴다고 설명한다.

 

나카모토 컨센서스에서는 채굴자가 블록을 만들기 위해 많은 자원을 사용해야 한다. 전기 사용료나 노드 운영비용 같은 비용이 발생한다. 만약 채굴자가 만든 블록이 선택되지 않는다면 블록 보상을 받을 수 없다. 그래서 작업증명에서는 잘못된 포크에 블록을 만들면 잃을 것이 있다. 예를 들면 다음과 같다.

• 비트코인에서 A, B 체인이 동시에 존재한다.
• 채굴자가 A 체인 위에 블록을 만들려면 많은 연산 비용을 사용해야 한다.
• B 체인 위에도 블록을 만들려면 또 많은 연산 비용을 사용해야 한다.
• 나중에 A 체인만 선택되면 B 체인에 투입한 비용은 낭비될 수 있다.
• 그래서 채굴자는 선택될 가능성이 높은 체인 하나를 고르려는 원인이 생긴다.

하지만 피어코인은 상황이 다르다. 피어코인에서는 coin-age를 사용해 블록을 만든다. 원문에서는 coin-age를 사용하면 모든 포크에서 추가적으로 블록을 생성할 수 있다고 설명한다. 즉, 포크가 두 개 존재할 때 블록 생성자는 굳이 하나의 포크만 선택하지 않을 수 있다. 두 포크 모두에 블록을 생성하면, 이후 어떤 포크가 선택되더라도 보상을 받을 수 있기 때문이다. 예를 들면 다음과 같다.

• A, B 체인이 동시에 존재한다.
• 블록 생성자는 A 체인 위에도 블록을 만든다.
• 동시에 B 체인 위에도 블록을 만든다.
• 나중에 A 체인이 선택되면 A 체인에서 보상을 받을 수 있다.
• 나중에 B 체인이 선택되면 B 체인에서도 보상을 받을 수 있다.
• 블록 생성자 입장에서는 굳이 하나만 선택할 이유가 약해진다.

이것이 Nothing-at-Stake 문제다. 말 그대로 어느 쪽에 블록을 만들어도 크게 잃을 것이 없는 상황이 되는 것이다.

---

Nothing-at-Stake가 Safety를 약하게 만드는 이유

Nothing-at-Stake 문제가 발생하면 포크가 계속 유지될 수 있다. 원래 Fork Choice Rule은 여러 포크 중 하나를 선택하기 위한 규칙이다. 하지만 모든 블록 생성자가 하나의 포크만 선택하지 않고, 모든 포크 위에 계속 블록을 만든다면 어떻게 될까?

 

둘 중 하나의 포크가 명확하게 선택되기 어려워질 수 있다.

원문에서는 이런 경우 더 많은 coin-age를 소비한 포크를 선택하는 Fork Choice Rule만으로는 하나의 포크가 영원히 선택되지 않는 문제가 발생할 수 있다고 설명한다.

 

결국 단 하나의 포크로 합의되지 않은 상태가 이어질 수 있다. 이것은 Safety가 만족되지 않은 상태다.