비트코인 백서로부터 시작한 블록체인의 역사
“Bitcoin: A Peer-to-Peer Electronic Cash System”라는 제목의 Bitcoin Whitepaper가 2008년에 Satoshi Nakamo라는 익명의 저자가 전 세계에 공개가 되었다. 그 후 2009년 1월 3일 Genesis Block이 생성이 되었다.
https://bitcoin.org/bitcoin.pdf
원본이 궁금한 분들은 위 글을 참고해주시고, 번역본으로 보고 싶은 분들은 정승원 님이 써 주신 번역본을 읽으면 될 거 같다.
https://medium.com/r?url=https%3A%2F%2Fsteemit.com%2Fkr%2F%40blockchainstudio%2Fbitcoin-whitepaper-github-repository
Redirecting you – Medium
medium.com
역사를 배우는 것부터 시작이다
우리 블루노드 온보딩팀은 첫 온보딩 세션으로 블록체인의 역사의 첫 시작인 비트코인의 백서 분석을 잡았다. 이렇게 잡은 이유는 비트코인 백서 안에 왜 비트코인을 생각했고, 블록체인 네트워크가 어떤 식으로 이루어져 있는지 내용이 들어있기 때문에 비트코인 백서를 분석하는 것이 온보딩 전체의 흐름을 관통한다고 생각했다.
백서에 나온 순서대로 글을 작성할 테고, 처음 비트코인 백서를 읽는 사람도 이해하기 쉽게 최대한 풀어서 쓰려고 한다.
비트코인을 만든 이유가 무엇일까?
Satoshi Nakamo가 설계한 비트코인은 순수한 p2p방식의 전자화폐이다. 지금까지의 전자상거래의 메커니즘을 한 번 살펴보자. 중간에 거래를 검증하는 회사부터 실제로 결제 승인을 내는 카드사까지 여러분들이 거래를 할 때 신뢰를 위해서 다양한 회사들이 수수료를 받으면서 검증을 하고 있다. 이 과정을 없애려고 한 것이다.
예를 한 번 들어보자. 네이버 페이 같은 경우를 생각하면 된다. 네이버페이로 결제를 하면 그 돈은 중간에 은행을 거치지 않고, 거래 상대방에게 간다. 그러나 중간에 제삼자가 검증한다. 네이버 페이의 과정을 보면 다음과 같다.
사용자
↓
네이버페이 (간편 결제)
↓
PG사 (KCP / KG이니시스 등)
↓
카드사 or 은행
↓
정산은행
↓
가맹점
금융기관이 껴있는 이상 불가능(non-reversible)한 거래는 불가능하기 때문이다. 금융기관은 법적으로 분쟁 중계를 피할 수 없다. 여러분이 물건을 사고, 갑자기 결제를 취소하고 환불을 하게 되는 경우를 상상해 보자. 금융기관은 물건이 잘 반품이 되었는지 판매자에게 확인한다. 그러고 나서 판매자에게 구매자에게 돈을 보내라고 중개를 하고, 돈을 잘 전달받았는지 확인까지 해야 한다. 필요하다면 법적 분쟁까지도 이어질 수도 있다.
이 모든 것이 비용이다. 이런 중개비용을 소비자는 감당하고 이런 최소한의 중개비를 감당하기 위해서 최소한의 거래비용을 설정한다. 판매자 입장에서는 블랙 컨슈머를 경계하기 위해서 최소한의 시스템을 만들고 이 모든 것이 비용이다. 밑의 기사처럼 온라인 몰이 블랙컨슈머 리스트 시스템을 만들고 있다.
www.consumernews.co.kr
소비자가 만드는 신문
소비자가만드는신문은 언론사가 직접 소비자 불만을 접수해 중재, 보도하는 사업모델을 정립한 세계 최초의 언론매체
www.consumernews.co.kr
비용은 비용대로 들어가고, 소비자에게 신뢰정보까지 요구한다. 온라인상에서의 거래는 일정 수준의 사기는 일어날 수밖에 없다. 비트코인이 등장하기 전까지는 이러한 문제를 해결하려면 대면 거래가 정답이었다.
비트코인은 암호학적 증명(SHA-256)을 바탕으로 신뢰할 수 있는 제삼자를 요구하지 않는다. 거래의 시간적 순서에 따라 거래를 증명을 하는 P2P 분산 타임스탬프 서버를 이용한다. 이는 정직한 노드의 컴퓨팅 파워의 합이 공격자 그룹의 노드의 합보다 클 때 유효하다. 만약 공격자 그룹의 컴퓨팅 파워가 51프로를 넘는다면 위협이 될 수 있고, 실제로 몇몇 코인이 51프로 공격에 당했다. 51프로 공격에 대해서는 온보딩 세션 때 추가적으로 다룰 예정이다.
비트코인(전자화폐)은 전자서명의 연속된 체인
비트코인이 거래의 연속성을 유지하는 방법은 다음과 같다. 각 소유자는 이전 거래 소유자와 다음 소유자의 공개키를 해시에 전자서명을 한 후 마지막에 추가하여 코인을 전달한다. 다음 소유자는 이 연속성이 올바른지 검증하기 위해 이 전자서명을 검증한다.

출처: Bitcoin: A Peer-to-Peer Electronic Cash System
이 과정의 문제는 수취인은 이전 소유자가 그전에 이중지불을 했는지 모른다. 이를 해결할 수 있는 방법이 있다. 한 번 거래가 끝날 때마다 조폐국이나 중앙기관이 검증을 하고, 새로운 코인을 찍어내는 것이다. 그런데 이 방식은 중앙집권적이다.
그래서 우리는 앞선 거래에서 이중지불이 일어나지 않았다는 증거가 필요하다. 물론 이전 소유자가 이후 소유자랑 거래 이후에 이중지불을 한 것은 중요하지 않다. 거래 전에 이중지불을 했는지가 중요하다. 어떤 거래가 먼저인지를 본다. 먼저 거래한 이후의 거래는 이중지불로 간주하면 된다.
그리고 이를 위해서 모든 거래는 공개적으로 공개가 돼있어야 하며, 참가자들이 거래의 순서에 대한 기록에 동의를 하는 시스템이 필요하다. 수취인은 거래할 때마다 노드들이 그 거래 순서가 유효하다고 알려주는 증명을 필요로 하고, 과반수의 노드들의 판단으로 정해진다.
타임스탬프 서버 (Timestamp Server)
Distributed Timestamp Server라는 표현이 Satoshi Nakamo가 작성한 Bitcoin: A Peer-to-Peer Electronic Cash System에 나온다. 타임스탬프 서버는 Transaction 데이터들을 해시처리 하고, 블록안에 묶은다음에 네트워크 전체에 퍼뜨려 해당 시점에 그 데이터가 해시 계산에 들어가기 위해서 명백히 존재했음을 증명하는 방식을 말한다. 여기서 이전의 기록들을 다음 블록이 알 수 있도록 이전 블록의 해시를 지금 블록의 해시를 추가한다.

출처: Bitcoin: A Peer-to-Peer Electronic Cash System
Proof-of-Work-비트코인의 작업 증명
1. 해시함수 정의 2. 비트코인 내에서의 해시함수 사용
해시함수 정의
타임스탬프 서버로 이루어진 것이 비트코인이다. 그러나 이런 서버를 구현하기 위해서 Adam Back의 해시캐시와 비슷한 작업증명 시스템을 사용할 필요가 있다고 Satoshi Nakamo는 이야기를 하고 있다. Hashcash는 Adam Back이 1997년에 만든 시스템으로 이메일 스팸 방지 목적으로 만들었다.
어떤 식으로 스팸을 방지할 수 있을까?
만약 내가 일반사용자라면 메일을 100만 통씩 보낼 일이 없을 것이다. 그런데 스팸 메일을 보내는 악성 사업자라면 100만통씩 100만 명에게 뿌릴 것이다. 이 과정에서 해시함수를 이용해서 0이 나오는 개수를 통해 스팸을 뿌리는 악성사업자에게 방대한 연산량을 요구한다.
해시함수에 들어갈 매개변수 값을 해시함수에 넣었을 때 2 cf24 dba… 이런 값들이 나온다. 여기서 중요하게 볼 것은 앞에 나온 0의 숫자이다. 만약 0이 연속해서 네 개가 나올 때 true라고 조건을 설정했다고 하자.
해시함수에 들어갈 매개변수를 사용자 메일 주소+date+nounce라고 하자. nounce는 0이 연속해서 네 개가 나오게 하는 값이 되고, 스팸 사업자는 0이 네 개가 앞에 나온 nounce를 찾아서 첨부해야 한다. 만약 100만 개를 스팸을 같은 내용으로 보낸다고 하면 100만 개의 nounce를 찾아서 첨부해야 하는 것이다.
예를 들어보면
SHA(사용자 메일 주소 + date + 1) = 2cf24dba…
SHA(사용자 메일 주소 + date + 2) = 32424dba…
SHA(사용자 메일 주소 + date + 3) = 2rgfg4dba…
SHA(사용자 메일 주소 + date + 4) = 0000cfrdba… => nounce는 4
이렇게 0이 네 개인 nounce 값을 찾는다. 하지만 검증자는 이런 과정들을 거칠 필요가 없다. 메일과 nounce를 전달받은 사람은 사용자메일+date+nounce를 넣어서 0이 네 개가 나오는지만 확인하면 된다.
즉, 소요되는 평균작업은 지수적으로 증가하지만, 검증은 한 번의 해시 계산으로 가능하다.
비트코인 내에서의 해시함수 사용
Satoshi Nakamo는 이 Hashcash 방식을 비트코인에 대입했다. 물론 Adam Back이 제안한 Hashcash 방식 하고는 다르다. Adam Back이 제안한 Hashcash방식은 SHA-1 방식이고, Satoshi Nakamo가 제안한 방식은 SHA-256(SHA -2 계열)이다.
SHA-1 방식은 2017년에 실제로 collision attack이 일어났다. 원래 해시 함수의 핵심 특징은 서로 다른 두 입력은 절대로 같은 해시값을 만들면 안 된다.
Hash(A)!= Hash(B)여야 한다. 그러나 2017년에 Google과 CWI Amsterdam 연구팀이 SHA-1 충돌을 실제로 생성했다. 이는 악성 사업자가 해시값이 같은 다른 파일로 증명을 해버릴 수 있는 문제로 심각한 보안 사고를 야기할 수도 있다.
SHA-256은 SHA-1보다 해시 길이가 길다. SHA -1은 160bit의 해시 길이를 가진 반면에 SHA-256은 256bit의 해시길이를 가진다. 이러한 이유로 해시 충돌을 찾는 평균 난이도는 SHA-256이 SHA-1과 비교해서 2⁴⁸ 배 난도가 높다.
그러나 비트코인은 여기서 더 나아가 SHA256(SHA256(data)) 구조를 사용하여 이중해싱을 한다. 이중해싱을 하는 이유는 가장 잘 알려진 이유는 length extension attack 방지이지만 이중해싱 자체가 네트워크끼리 보내는 TCP Segment에 들어가는 checksum 설계에도 쓰이는 범용적인 방법이기도 하다.
해시작업을 통한 작업증명의 난이도는 시간당 평균 블록 수를 목표로 하는 이동 평균에 의해 결정되며, 난이도는 이에 맞춰 조절되게 된다. 난이도를 조절하는 방법은 0의 개수(target)를 유동적으로 바꾸는 것이다.
비트코인은 hash(block header) < target 조건을 만족하는 nonce를 찾는다. target이 작을수록 앞에 0이 많은 해시가 필요해져 난이도가 높아진다. 조건을 만족하는 해시가 처음 발견되면 그 nonce가 블록의 nonce가 된다.

출처: Bitcoin: A Peer-to-Peer Electronic Cash System
작업증명은 대표 체인을 선택하는 문제도 해결한다. 가장 긴 체인이라면 누적된 해시파워가 다른 체인보다 크다는 것을 의미한다. 비트코인은 정직한 노드가 과반수 이상일 것이라고 가정하고, 정직한 노드들이 50프로 이상이라면 공격자가 공격할 틈이 존재하지 않는다. 만약 중간 블록을 바꾼다면 공격자는 그 이후의 모든 블록의 작업증명을 다시 해서 nounce값을 바꿔야 한다. 특정 거래 블록 위에 6개의 블록이 추가된 상태라면 이는 더욱 어려워진다.
네트워크 과정 (Network Step)
1) New transactions are broadcast to all nodes. 2) Each node collects new transactions into a block. 3) Each node works on finding a difficult proof-of-work for its block. 4) When a node finds a proof-of-work, it broadcasts the block to all nodes. 5) Nodes accept the block only if all transactions in it are valid and not already spent. 6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
이 내용을 좀 풀어서 정리해 보자.
만약 내가 비트코인 네트워크에서 거래를 발생시켰다고 하면 P2P방식으로 Dragos가 거래했다는 내용이 모든 노드한테 퍼지게 된다.
그 후 각 노드는 그 거래내용을 작업증명을 할 블록에 넣고, 다른 거래들과 이전 블록정보를 작업증명을 수행하면 해당 블록을 다시 퍼트린다.
노드들은 해당 블록이 유효한지를 판단하고, 이미 사용되지 않은 경우에 블록을 승인하게 됩니다. 이제 이 블록의 해시는 다음 블록 생성할 때 사용되게 된다.
그렇다면 만약 Dragos 블록하고 Arkstar블록이 거의 동시에 만들어졌다고 가정해 보자. 어떤 노드는 Dragos 블록을 먼저 전달받았고, 또 다른 블록은 Arkstar 블록을 먼저 전달받게 된다면 어떤 블록을 기준으로 해야 되는 걸까?
정답은 일단 진행한다는 것이다. 각 노드는 자기가 받은 체인 기준으로 채굴을 계속하고, 더 빠르게 다음 블록이 나온 체인이 더 길어지게 되고 이 체인을 대표 체인으로 합의를 진행하게 된다. 이때 버려진 블록을 고아 블록(orphan block)이라고 하고, 블록체인 경쟁 과정에서 버려진 블록을 의미한다.
Become a Medium member
왜냐면 노드들은 항상 긴 체인을 올바른 것으로 간주하기 때문이다.
만약 Dragos가 거래한 내용이 코뇽이한테 전달이 안되거나 늦어져서 코뇽이 만든 블록에 포함이 안되었다고 해도 다음 거래에서 내 거래가 포함이 안 돼있다면 다시 요청을 해서 추가시키도록 할 것이다. 이는 TCP 프로토콜에서 데이터 소실이 되었을 때 이루어지는 과정과 동일하다.
보상구조(reward)
어떤 채굴자가 작업증명을 통해 블록을 만들었다고 하자. 이때 채굴자는 coinbase transaction을 블록 안에 넣는다. 즉, 스스로 보상 거래를 넣는 것이다. 그리고 네트워크가 이 블록을 받아들이면 coinbase reward가 생성이 된다. 그러나 비트코인 규칙상 coinbase 보상은 100블록 이후에만 사용이 가능하다. 이는 fork(위에서 언급한 체인 쪼개짐)으로 내 블록이 사라질 위험 때문이다. 만약 내 블록이 선택을 받지 못한다면 보상을 받지 못하게 된다.
이러한 보상은 최초로 유통하는 인센티브를 제공한다. 그리고 거래 수수료로도 인센티브가 제공될 수 있다. 비트코인 지갑(예: Sparrow, Electrum 등) 같은 경우는 네트워크 혼잡도랑, memple 분석을 통해 수수료를 정하고, 이는 블록 생성자에게 전달이 되게 된다.
수수료가 높은 순서대로 블록에 들어가게 되며 수수료가 낮으면 순서가 뒤로 밀리게 된다. 노드들은 mempool 크기 제한이 있기 때문에 공간이 부족하면 거래가 네트워크에서 내 거래가 들어간 블록 생성 전에 사라진다. 그러면 다시 거래를 만들거나 더 높은 수수료를 보내 거래를 블록에 넣기 위해 노력한다. 대표적으로 2가지 방식으로 진행이 된다.
첫 번째 방식은 RBF (Replace-By-Fee)으로 말 그대로 더 높은 수수료로 보내는 것이다. 두 번째 방식은 CPFP (Child Pays For Parent)으로 부모거래를 자식거래를 같이 블록에 넣어서 전체 거래 수수료를 높이는 방식이다.
처음에는 채굴자는 coinbase보상이 크겠지만 coinbase 보상은 반감기를 거치면서 점차 줄어들게 된다. 반감기는 coinbase 보상이 절반으로 줄어드는 것을 말하며 210000 블록마다 발생한다. 2009년에 블록보상은 50 BTC였지만 현재는 3.125 BTC이다.
이는 비트코인 공급량을 제한하기 위해서이며 결국 코인이 모두 발행되고 나면 인센티브는 거래 수수료 체제로 전환되게 될 것이다.
이런 보상 시스템은 노드들에게 네트워크 생태계에 기여하도록 유도하여 정직한 상태가 되도록 한다. 왜냐하면 네트워크를 유지하는 것이 이득이 되기 때문이다.
저장 공간 재확보 (Reclaiming Disk Space)
거래가 많아질수록 이전에 사용된 거래들의 중요성은 점차 떨어지게 된다. 그렇다면 이 거래들을 압축하는 방법은 없을까? 실제로 pruned node는 이 거래들을 압축시키는 방법을 사용하고 있다.
머클 트리를 활용해서 Root Hash값만 저장시키는 것이다. 밑의 그림을 살펴보자 Tx0, Tx1, Tx2, Tx3는 Root Hash로 압축되어 Block에 저장되게 된다. 이렇게 되면 해시의 손실이 없기 때문에 작업증명을 할 때 문제될 요소가 없다.

출처:Bitcoin: A Peer-to-Peer Electronic Cash System
간소화된 지불 검증 (Simplified Payment Verification)
머클 트리를 활용하면 간소화된 지불 검증이 가능하다. 만약 내가 한 트랜젝션을 검증한다고 하면 타임스탬프가 포함된 블록과 연결해 주는 머클 브랜치만 얻으면 된다.
Tx3을 검증하려면 block header의 Merkle root와 Merkle branch(Hash4, Hash12)를 받아서 tx3의 해시와 결합하여 Merkle root를 계산하고, 이것이 block header의 Merkle root와 같은지 확인함으로써 tx3가 해당 블록에 포함되었음을 검증할 수 있다.
확인하는 과정은 다음과 같다.
H3 = hash(tx3)
H34 = hash(H3 + H4)
ROOT = hash(H12 + H34)
이런 식으로 tx3가 존재했다는 것이 증명된다.

출처:Bitcoin: A Peer-to-Peer Electronic Cash System
공격자가 네트워크를 장악하면 가짜 블록과 Merkle branch를 이용해 SPV 사용자를 속일 수 있다. SPV는 거래의 포함 여부만 확인하고 거래의 유효성 자체는 검증하지 않기 때문이다. 따라서 지불을 자주 받는 사업자들은 보다 독립적인 검증과 보안을 위해 자체 노드를 운영하는 것이 유리하다. 이때 pruned node 역시 전체 검증을 수행할 수 있기 때문에, 저장 공간만 줄일 뿐 검증 능력은 full node와 동일하다.
금액 병합과 분할 (Combining and Splitting Value)+ UTXO
이제 비트코인이 거래 잔액을 만드는 방법에 대해서 서술해 보겠다. UTXO는 Unspent Transaction Output이다.
사용자가 2 BTC를 가진다는 것은 총합이 2 BTC인 여러 UTXO를 사용할 수 있는 private key를 가지고 있다는 의미이다. 계좌의 잔액은 실제로 저장되는 값이 아니라 해당 주소가 사용할 수 있는 UTXO들의 합으로 계산된다. 예를 들어 3 BTC를 보내려고 할 때 1.5BTC, 0.5BTC, 1.4BTC에 해당하는 UTXO를 가지고 있다면 이 세 개가 input이 되고, output은 3BTC를 받는 주소와 거스름돈 0.4 BTC를 보내는 주소 두 개가 된다. 거래들은 서로 의존하며 fan-out 구조를 만들 수 있지만, 노드는 전체 거래 기록을 독립적으로 복사할 필요 없이 현재 UTXO set을 기준으로 거래의 유효성을 검증할 수 있다.
Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.

출처:Bitcoin: A Peer-to-Peer Electronic Cash System
프라이버시 (Privacy)
블록체인 네트워크에서는 모든 거래들이 공개적으로 브로드캐스팅된다. 이 방식은 전통적인 은행 방식인 거래정보를 믿을 수 있는 제삼자에게만 제공하는 방식보다 프라이버시가 보호되지 않을 수가 있다.
그래서 공개키를 익명으로 보존하여 지금 거래하고 있는 사람이 누구인지 아는 것을 막는다. 그러나 여러 개의 입력을 가지는 거래를 통해 이 거래가 동일한 키의 소유자인 것은 드러날 수밖에 없다. 이게 무슨 소리인지 예시를 들어서 설명해 보겠다.

출처:Bitcoin: A Peer-to-Peer Electronic Cash System
예를 들어 어떤 사람이 비트코인을 여러 번에 나누어 받았다고 가정해 보자. 그 사람의 지갑에는 다음과 같은 세 개의 코인이 각각 다른 주소에 들어 있다. 주소 A에는 1 BTC, 주소 B에는 0.7 BTC, 주소 C에는 0.5 BTC가 있다. 겉으로 보면 이 세 주소는 서로 아무 관련이 없어 보인다. 블록체인에서 보면 단지 서로 다른 주소에 있는 코인일 뿐이기 때문이다.
그런데 이 사람이 누군가에게 2 BTC를 보내려고 한다고 해 보자. 주소 A에 있는 1 BTC만으로는 부족하고, 주소 B나 C에 있는 코인을 함께 사용해야 한다. 그래서 하나의 거래(transaction)를 만들 때 입력(input)으로 주소 A의 1 BTC, 주소 B의 0.7 BTC, 주소 C의 0.5 BTC를 모두 사용한다. 그리고 출력(output)으로 2 BTC는 상대방에게 보내고, 남는 0.2 BTC는 자신의 새로운 주소로 거스름돈처럼 돌려받는다.
이 거래를 만들려면 주소 A, B, C에 있는 코인을 사용할 권한이 있다는 것을 증명해야 한다. 이를 위해 각각의 주소에 해당하는 개인키로 모두 서명해야 한다. 즉, 세 주소의 개인키를 모두 가지고 있는 사람이 이 거래를 만든 것이다.
블록체인을 보는 사람 입장에서는 이 거래의 입력에 주소 A, B, C가 동시에 등장하는 것을 볼 수 있다. 그러면 자연스럽게 이 세 주소는 같은 사람이 통제하는 주소일 가능성이 매우 높다고 추론할 수 있다. 왜냐하면 한 사람이 아니라면 세 주소의 개인키를 동시에 사용해서 하나의 거래를 만들 수 없기 때문이다.
여기서 더 중요한 문제가 생긴다. 만약 어느 순간 주소 B가 특정 거래소 계정이나 어떤 개인의 주소라는 사실이 밝혀지면, 이전에 같은 거래에서 함께 사용되었던 주소 A와 주소 C 역시 같은 사람이 소유한 주소일 가능성이 높다고 추정할 수 있게 된다. 이렇게 하나의 주소에서 시작된 정보가 다른 주소들까지 연결되면서 소유자를 추적할 수 있게 되는 것이다.
그래서 비트코인 백서에서는 여러 개의 입력을 사용하는 거래에서는 입력들이 같은 소유자라는 사실이 드러날 수 있고, 하나의 키의 소유자가 밝혀지면 그와 연결된 다른 거래들까지 같은 사람의 것일 가능성이 드러날 위험이 있다고 설명하고 있는 것이다.
공격자의 공격확률 계산
앞서서 공격자가 중간에 블록을 바꾸더라도 이후 블록을 전부 작업증명을 해야 되기 때문에 조작하기 어렵다고 했다. 그러면 이런 질문을 할 수가 있다. 마지막 근처 블록만 살짝 바꾸면 되지 않나?
예를 들어보자
Block 1 — Block2 — Block3 — Block4 — Block5
여기서 공격자가 Block4만 바꾼다고 생각해 보자 그러면 Block5에 대한 작업증명을 해야 한다. 그러나 그러나 그 과정에서 누군가는 Block 6을 만들었을 테고, 체인은 두 개로 Fork 되게 된다.
Chain 1) Block 1 — Block2 — Block3 — Block4(조작) — Block5(조작)
Chain 2) Block 1 — Block2 — Block3 — Block4 — Block5 — Block6 — Block7
블록을 조작하려는 공격자는 chain2를 따라잡아야 한다. 비트코인은 가장 긴 체인을 맞는 블록으로 인정되기 때문에 공격자는 chain2를 추월해야 한다. 백서에서는 이를 도박자의 파산 문제와 같고 설명하고 있다.
출처:Bit coin: A Peer-to-Peer Electronic Cash System
P> q라고 가정할 때 공격자가 따라잡을 확률은 블록이 증가함에 따라 지수적으로 증가한다. 일반적으로 6 confirmations 즉, 6블록이 진행되게 되면 사실상 P> q이면 뒤집기 어려운 상태라고 본다. 이를 완결성(Finality)된 상태라고 일반적으로 이야기한다.
“We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.”
멤 풀(Mempool)과 고아 블록(orphan block)
비트코인 네트워크에서 거래와 블록이 처리되는 과정에서는 멤 풀(mempool)과 고아 블록(orphan block 또는 stale block)이라는 개념도 중요하기에 백서에는 없지만 추가적으로 설명을 하고자 한다.
먼저 멤풀(mempool)은 아직 블록에 포함되지 않은 거래들을 각 노드가 임시로 저장해 두는 공간을 의미한다. 사용자가 비트코인 거래를 생성하면 그 거래는 네트워크 전체로 전파된다. 노드들은 해당 거래가 유효한지 검증한 뒤 문제없는 거래라면 자신의 멤풀에 저장한다. 이후 채굴자들은 블록을 만들 때 이 멤풀에 저장된 거래들 중 일부를 선택해 블록에 포함시킨다. 보통 채굴자들은 거래 수수료가 높은 거래부터 선택하기 때문에 수수료가 높을수록 더 빨리 블록에 포함될 가능성이 높다. 따라서 멤 푸른 일종의 “대기 중인 거래 목록” 또는 거래 대기열이라고 볼 수 있다.
그전에 설명한 고아 블록(orphan block)들은 그 블록에 포함되어 있던 거래들이 완전히 사라지는 것은 아니다. 이미 다른 블록에 포함된 거래를 제외한 나머지 거래들은 다시 멤풀로 돌아가게 된다. 그리고 합의된 체인 위에 새로운 블록이 생성될 때 다시 블록에 포함될 기회를 얻게 된다.
비잔틴 장군 문제(Byzantine Generals Problem)
블록체인 네트워크가 합의하는 과정을 설명할 때 비잔틴 장군 문제가 많이 언급된다.
비잔틴 장군 문제는 다음과 같은 상황을 가정한다. 모든 장군이 동시에 공격해야만 승리할 수 있으며 일부 장군이 후퇴하면 공격은 실패한다. 그러나 이들 중 일부는 배신자일 수 있으며, 거짓 정보를 보내거나 메시지를 조작할 수도 있다. 또한 메시지가 전달되는 과정에서 지연되거나 왜곡될 가능성도 존재한다.
블록체인 네트워크는 이러한 문제를 POW방식을 활용해 해결하고자 했다. 비트코인은 정직한 노드가 해시파워 50프로 이상을 차지할 것이라고 가정하고, 가장 많은 작업증명이 축적된 블록체인을 네트워크의 정식 기록으로 채택한다.
마무리하며
첫 온보딩 내용으로 비트코인 백서를 분석하고, 이해하기 힘든 부분은 구체적인 예시를 들면서 처음 보는 사람도 이해가 쉽도록 최대한 설명을 해보았다. 물론 백서의 내용을 벗어난 부분도 있고, ECC(타원 곡선) , 튜링 불완전, 소프트포크와 하드포크, 세그윗 업데이트 등 비트코인에 있어서 설명을 다 못한 부분이 많다. 천천히 같이 공부해 보자!



























