[블록체인] 05. Mechanics of Bitcoin - Distributed Consensus

 

Distributed Consensus

 

Bitcoint's P2P(peer-to-peer) network

- purely decentralized (중앙에서 관할/관리/간섭하는 존재 없음)
- node의 leave / join이 자유로움.

- Alice가 Bob에게 pay하고 싶으면 transaction 만들어서 모든 노드에 broadcast 뿌리면 됨.
  Alice가 서명한 트랜잭션을 Bob의 public key를 이용하여 그 주소로 보냄.
  validity를 검증한 miner들이 valid하다고 판단하면 해당 트랜잭션을 포함해서 block을 만들고,
  그 block 채굴에 성공을 하면 그 block이 longest chain에 연결됨.(결제에 6confirm_60분 걸린다는 단점->솔라나)

- Alice가 보낸 pay를, Bob이 가지고 사용하기위해서 Bob이 항상 연결되어있어야 하는 것은 아님.
  수신한 bitcoin을 즉각 쓸 게 아니라면,
  Alice가 나에게 보낸 bitcoin이 longest chain에 포함되었다는 것을 확인한 후에
  Alice에게 물건을 보내고 bitcoin network와 무관하게 살아도 상관 없음.
  단절된 wallet에 private key만 안전하게 관리하고 있으면 Alice가 보낸 bitcoin을
  몇 년 후에도 언제든 필요할 때 들어가서 사용할 수 있음.

- 합의(consensus) : 비트코인 노드들 사이에서,
                               어떤 트랜잭션이 valid한지, 어떤 트랜잭션의 순서가 앞서는지를 결정하는 매커니즘

 

to reach consensus on in the Bitcoin network

- 다양한 user들이 트랜잭션을 broadcast
  -> 도달 시점 제각각. 특정 시점에서는 노드마다 보고있는 뷰의 불일치 가능성 있음.
      but 시간 지나면 먼 노드도 결국엔 수렴되도록 설계되었음. a single, global ledger !! 
- 목표 : 중앙집중되지않는 누구의 간섭/지휘도 받지않는 장부

- 각 노드는 transaction pool(채굴할 block에 들어갈 후보 트랜잭션)을 가지고 있음.
  어떤 노드가 트랜잭션 포함시켜달라고 보낸걸 받으면 pool에 저장해두고
  그중에 고른 트랜잭션들을 포함시켜서 block 만듦 (노드마다 각기 다른 pool을 가지고있음. 아직 합의X)

 

 

Consensus without Identity using a Block Chain

 

Bitcoin consensus algorithm (simplified)

1. 새로운 transaction이 all nodes에 broadcast(flood)됨.
   * P2P network : 각 노드가 client이자 server(서로 대등한 peer관계), 정형화된 구조X, 모양 들쑥날쑥
2. 각 노드는 채굴할 블럭에 들어갈 트랜잭션을 고름
3. random 노드(경쟁에 이긴, 채굴성공한 채굴자)가 해당 블록을 broadcast함
4. 다른 노드들은 해당 블록의 모든 트랜잭션이 valid하다고 판단하면 accept함
   * accept 했다는 소식을 굳이 전하는게 아니라, 해당 블럭의 hash를 포함해서 거기에 연결될
     다음 블록 채굴을 시작하면 그게 곧 그 블럭을 accept했다는 의미임
   
   

Why it works? (How to handle the below attacks?)

• Stealing Bitcoins
  B의 주소에 들어있는 비트코인을 공격자의 주소 A로 가져오려면 crypto 때문에 불가능함.
  B->A 트랜잭션은 B의 서명이 필요한데 A가 B의 private key를 모름.
  
  
• (Distributed) Denial Of Service attack ;DDOS
  hash power 큰 공격자가 채굴할 때 Alice가 요청한 트랜잭션을 고의로 포함하지 않고
  block이 계속 쌓이도록 트랜잭션 방치하기.
  -> 다른 채굴자들이 해당 트랜잭션 넣어서 채굴성공하면 공격자도 그 대세를 따라가야하므로 
      이 공격은 잠시동안만 가능함. 영구히 지속되지 않음.
  * DOS : 서비스 거부 공격 (다량의 traffic을 공격대상에게 보내서
               대상이 정상적 사용자에게 적절한 서비스를 제공하지 못하도록 하는 공격)
  
  
• Double-spend attack (2장 마지막 참고)
  판매자가, 자기에게 지불하는 트랜잭션 포함된거 확인 즉시 물건을 보내면 위험함.
  6 confirmation(60분) 이후에는 뒤집을 가능성 매우 낮음. 안전. 이중지불 불가능. 기다리자.
  
  
  

비트코인 내부

- full block chain의 모든 내용은 어디에 저장되어있을까?
: block chain size는 어마어마하게 큼. (2009.1.3 이후 평균1MB의 블럭이 10분에 1개꼴로 생성됨)
  채굴자(full node)들이 저장중임. 24시간 bitcoin network에 연결되어있음.
  다른 대부분의 사람들은 모든 내용 저장X, 필요한 부분만 가지고있음.

 

 

---

합의 (Consensus)

어떤 블록을 붙일지 서로 논의하지 않음. -> 일시적 불일치(합의X)
-> 시간이 지나면 곧 수렴됨(합의O)

 

합의 과정

아직까지는 서로다른 block chain 장부가 존재하지 않음.

어떤 branch를 따라갈지 각 node가 서로 상의하지 않음. 알아서 결정함. (C랑 D는 각각 자기 branch 따라감)

* Longest Chain Rule
: 순간적인 불일치는 있을 수 있고 잠시동안 불일치상태가 지속될 수 있지만,
  궁극적으로는 모든 노드가 자신의 이익을 따라서 행동하기 때문에 가장 긴 체인에 합류할 수 밖에 없음.
  즉, 대세를 따라 붙여나가는 게 각 노드 입장에서 자신의 이익을 극대화하는 방향임.

 

 

---

Node behavior

 

node 

- 모든 노드는 동등함. 관리자 노드/마스터 노드/계층.. 그런 거 없음.
 * 실제로 비트코인의 모든 노드가 평등한가?
  : 채굴 파워 차이는 있을 수 있음. 근데 채굴 파워가 70%라서 longest chain 역전할 수 있는 채굴자는 없음.
    있다해도 강력한 해시파워 가진 사람일수록 비트코인 신뢰성 유지를 원하므로 역전하는 일 발생하지 않음.

- TCP를 통해서 데이터 전달함. 랜덤한(비정형화된) 구조를 가짐.

- 새로운 노드가 언제든 참가하거나 떠날 수 있음. 네트워크는 dynamic하게 변함.
- 참가하려면 seed.bitcoinstats.com 등에서 peer가 될 이웃노드(seed node) 후보자들의 IP주소를 얻으면 됨.

 

to publish a transaction, it should be flooded into the entire network

1. Alice가 Bob에게 pay하고싶다면 Alice가 transaction 만들어서 그녀의 이웃에게 보냄.
2. 각 노드는 전달받은 트랜잭션을 받아들일지 결정하고 본인의 이웃에게도 전달함(broadcasting)
   i) 트랜잭션의 validity 체크. (invalid하면 다른 노드에게 전달하지도 않음)
    -> validity 체크위해 run script하려면 현재까지의 block chain이 필요함.
        2009년 genesis 블록부터 전부(Unspent Transaction Output) 가지고 있어야 함.
        왜냐면 옛날 output을 현재 누가 claim 할 수도 있으므로.
   ii) output이 아직 spent되지 않았는지 체크.
   iii) 이미 봤던 트랜잭션이면 무시.
   iv) 트랜잭션 script가 whitelist에 포함되는지 확인.(whitelist에 들어있는 것만 받아들임)
3. 트랜잭션을 pool에 넣음.
4. block에 포함시킬 트랜잭션을 pool에서 꺼내서 block에 넣고 채굴시도

 

nodes will end up with a different view of the pending transaction pool

1. Alice가 1btc를 가지고있는데, Bob과 Charlie에게 1btc씩 same coin 지불하는
   transaction 2개를 동시에 보내서 total 2btc에 해당하는 물건을 받으려고 함.
2. 어떤 노드는 A->B 트랜잭션을, 어떤 노드는 A->C 트랜잭션을 먼저 받음.
3. A->B를 먼저 받은 노드는 그 이후에 A->C를 받으면 drop함.(A->B만 valid, A->C는 invalid)
   마찬가지로 A->C를 먼저 받은 노드는 그 이후에 A->B를 받으면 drop함.
   어떤 노드도 절대로 이 두 트랜잭션을 동시에 넣어서 채굴할 수 없음. 둘 중 하나만 선택함.
   즉, double spend 불가능.
4. 노드마다 어떤 트랜잭션 넣을지 일시적 불일치 발생할 수 있지만(transaction race condition), 
   누군가 채굴 성공하고 대세되면 그거 따라가는걸로 수렴됨. 둘중에 누락된 트랜잭션은 버려짐.

 

logic for announcing new blocks

• block race condition
   : 두개의 블록이 동시에 채굴되면 그 중 하나만 대세 chain에 포함됨. 실패한 블록은 orphaned.
  
  
• 블록이 노드에 의해 검증됨
  - header가 이전 대세의 마지막 블록을 hash point하는지
  - hash 결과 < target num 이 맞는지
  - 블록에 포함된 모든 트랜잭션이 valid 한지
  -> 아니라면 해당 블록을 거부함
  - 검증 끝나면 forward해서 해당 블록이 대세되는 데에 박차를 가함.
  
  
• 대세가 아닌 branch 채굴(fork;가지치기) 성공 발표해봤자 아무도 인정하지 않음