106. Node and Miner

この文書はコンピューター工学知識なしでも理解できます。

Node And Miner

BlockchainサービスNetworkの構成は色んな形が有りますが、普通、NodeとMinerが中心になるP2P Networkを構成します。

Node

Blockchain P2P Networkに参加している全ての端末はNodeになります。

• Full Node : 全てのデータを保存するNode。
• Lightweight Node : 一部のデータ（普通、Block Header）のみ保存するNode。

Nodeそれぞれ元長データ(Ledger)を持ちますから、BlockchainをDistributed Ledgerと呼ぶことも有ります。

NodeはBlockやTransactionを他のNodeから伝達され、自分に繋がっている他のNodeへ伝送します。

Miner

Data Mining役割のNodeです。

MinerはBlockchain P2P Networkで発生しているTransactionをまとめ、Blockに書き込んで、作ったBlockをまた他のNodeへ伝送します。

Minerが多数存在する時、どのMinerにBlock生成権利が与えられのか、どのBlockが選ばれるのかはConsensusで決定されます。

Competition and Verification (競争と検証)

Nodeは互い競争し、互い疑って、互い検証します。

Blockchain P2P Networkの大切なポイントはCompetition（競争）とVerification（検証）です。 P2P Networkを考えると、Cooperation(協力)をイメージするになりますが、Blockchainでは各Nodeは協力関係じゃ有りません。

すでに、Byzantine Generals Problemを通じて理解したように、P2P Network中では誰でも私に嘘を話すことができます。 だから、Nodeは連結されている他のNodeを信頼していません。自分の持ちデータとルールだけ信頼して動きます。

Nodeが他のNodeからTransactionとかBlockを貰った時, TransactionやBlockが無効だと判断されるなら、このデータを無視して、伝播もしないです。

判断根拠は色々ですがConsensusによって定義されます。

• すでに消費されたAssetを使うとかエラを起きるTransaction
• 古いBlock

もし、Blockchainを使用するServiceを作るならば、直接Nodeを運営するのがおすすめになります。

• 私が管理しているNodeは私のServiceに嘘をついていません。
• 不特定管理者が運営する他のNodeはいつでも私のServiceに嘘ついている可能性が有ります。

Majority Vote (過半投票)

多数で決定されたことは正しさに関係無しで史実になります。

NodeはTransactionやBlockを受け入れることか無視することでTransactionとBlockに投票します。

P2P Network中、同じTransactionやBlockを伝達され、同じ選択をしたら、結果物も同じだと想像できます。 しかし、互い違う選択をしたら、Nodeは連鎖的に違う選択を起きる事になります。判断のデータ土台が互い違いますから、後の選択も影響を続き受けます。

それで、同じ選択をしているNodeでグループが決められます。このようにグループが別れ、互い違うBlockchainになることをHard forkと呼びます。

Hard forkは開発チームの作為で起きることも、技術的問題で起きることも有ります。

別れたBlockchainは別のBlockchainになって生存することも、多数Nodeが他のメーンBlockchainへ移動して掃滅することも有ります。 どれが正しい選択か悪い選択かは大切な問題じゃ有りませえん。多数が生存して少数は掃滅します。

Blockchain Nodeの運用者はいつもHard fork issueを確認してNodeがメーングループに入るように対応しなければなりません。

Discovery (発見)

Nodeは自分に起こったイベントだけ知ります。

Decentralizedを目標としているBlockchainなら、P2P Network中、全てのNodeを統率する存在がいません。 どんなNodeも他のNodeに自分の状態を報告しません。 それで、Nodeの持ちデータは自分がNetwork中で発見したデータに限定されます。

TransactionがNetwork中で伝播されている状況で, どのNodeはTransactionを発見して,どのNodeはTransactionを発見できなかった状態が共存できます。

例）

SeoulのNodeは101番Block同期を取って、New YorkのNodeは103番Block同期を取っていることができます。

• NodeはどのBlockがChainのラストBlockか知るのができません。近いあるNodeが教えてくれるラストBlockをラストBlockで取り扱いします。
• Nodeはどれほど同期を取っているのかで、API Queryに互い違う答えをすることが有ります。ちゃんと同期が取れていないNodeにAPI Callは注意が必要です。
• Nodeが近いNodeにTransactionやBlockを知らせないとか、ちゃんと伝播されていないなら、流失可能性が有ります。

Reference

• この文書は韓国語文書から翻訳されています。韓国語文書が原文になります。