Bitcoin の個人的勉強ノート

第 1 版（ 2014 年 4 月15 日）

@pizyumi

はじめに• 本文書は @pizyumi が Bitcoin について勉強するために作成して

いるノートです。決して完成されたものではなく、 @pizyumi が勉強していくに連れて新たな事項が追加されていきます。• 勉強中のため、本文書の記述には誤りが含まれているかもしれ

ません。• 一応、勉強がある程度進捗し、暗号貨幣に対する十分な知識が

得られた場合には、本ノートを基に暗号貨幣に関する文書（「暗号貨幣技術入門（仮題）」）を執筆する予定があります。

貨幣• 集中型の貨幣システムの問題• 口座が凍結される可能性がある。• 貨幣が没収される可能性がある。• 手数料が高い。

電子貨幣• 発行者に依存するもの：集中型• David Chaum. Blind signatures for untraceable payments. In Crypto, volume

82, page 199203, 1982.• Ronald L Rivest. Electronic lottery tickets as micropayments. In Financial

Cryptography, pages 307–314. Springer, 1997.• Beverly Yang and Hector Garcia-Molina. Ppay: micropayments for peer-to-

peer systems. In Proc. of Computer and communications security.

• 使用者間の貸借関係によるもの• Ryan Fugger. Money as ious in social trust networks & a proposal for a

decentralized currency network protocol. 2004.

Bitcoin とは• 電子貨幣（ digital currency ）システムである。• 最初の完全な分散型（ P2P 型）の電子貨幣システムである。

• 従来の電子貨幣システムは集中型（クライアントサーバ型）であった。• 全てのノードが完全な元帳を保持する。• ノードが取引を検証する。• 現金に近い。

• 取引はほぼ即時に処理される。• 払い戻し不可能（ non-refundable ）である。

• 現金でできることが世界規模で行える！

• 2008 年に始動。オープンソース。• 価格は急激に上昇。取引数も急激に上昇。

• 価格は一時 1BTC1000 ドル超え。取引数は 1 日 6 万件程度（ 1 秒間に 0.7 件）。• クレジットカード取引などと比較するとまだまだ小規模。

Bitcoin の目的（個人的考え）• ① 汎用的な決済手段を提供する。

• 決済とは、「代金や証券・商品、または売買差金の 受け渡しによって、売買取引を終了すること」。

• 決済手段を提供するためには、何らかの貨幣（又はそれに類するもの）が必要となる。• その貨幣を使って決済できるようにする。• 必ずしも独自の貨幣を作らなければならないという訳ではない。他人が作った貨幣を流用しても構わない。

• ② 中央機関を不要にする。• 法貨を発行することのできる政府、中央銀行などの機関を不要にする。• 決済を仲介する中央清算機関を不要にする。

• ただし、 Bitcoin の内部には中央清算機関は存在しないものの、 Bitcoin の周縁には中央清算機関が存在する。• 清算とは、複数の買い手と売り手の間で決済条件の照合を行い、決済を成立させたり、差額決済を行うこと

である。• 中央機関に頼らないでどのように貨幣を発行すれば良いのか？

• 利害関係人が全員で発行すれば良い。• 利害関係人が全員自由に参加できる P2Pネットワークを構築して、その中で（コンピュータコードという形で表現された）定められた規則に従って貨幣を発行する。

• P2Pネットワーク上で、中央機関に頼らないで、汎用的な決済手段を提供する（①の目標に②の目標を加味したもの）• には・・・、どうすれば良いのか？

• まずは、現実世界の決済を考える。• これを、（コンピュータコードという形で表現しなければなら

ないのでまずは）構造化する。• （執筆途中）

口座（ account ）• 256bit の楕円曲線DSA （ Elliptic Curve Digital Signature Algorithm ： ECDSA ）の公開鍵と秘密鍵の対。• 秘密鍵は Bitcoin を別の口座に送る際に署名をするために使用する。

• 口座の所有者（秘密鍵の所有者）のみが口座にある Bitcoin を別の口座に送ることができる。秘密鍵を知らない第三者は別の口座に送ることができない。

• 秘密鍵は厳重に保管されなければならない。• 秘密鍵を知った第三者は口座にある Bitcoin を別の口座に送ることができる。

• 公開鍵は公開され、署名を検証するために使用する。• 秘密鍵を知らない第三者は署名検証を通過することができない。つまり、秘密鍵を知らな

い第三者が口座にある Bitcoin を別の口座に送ろうとしても、署名検証の過程で署名が正当でないことが判明するので、送金は拒否される。

• 公開鍵のハッシュ値が口座番号（ address ）。• 口座を識別するために使用する。

取引（ transaction ）• 口座間における Bitcoin の移動を表現する。

• 採掘による Bitcoin の鋳造も特殊な形式の取引として表現される。• より具体的には、

• 1 つ以上の出金口座（ source account ）から 1 つ以上の入金口座（ destination account ）への Bitcoin の移動を表現する。• 取引によって、 1 つ以上の入力（ input ）と 1 つ以上の出力（ output ）が生成される。• 出力・・・ある口座に関連付けられている Bitcoin の額面を表す。

• 出力は 1回だけ使用することができる。• 取引によって古い出力が使用され、新しい未使用の出力が生成される。

• 入力・・・どの（未使用の）出力を支払いに使用するかを指定する。• 指定された出力が使用済みである場合には、取引は無効である。

• 1 つの取引の中にある 1 つ以上の入力が指し示す古い出力の額面の合計は、新しい出力の額面の合計以上でなければならない。• 小さい場合には、取引は無効である。• 古い出力と新しい出力の額面の合計の差が取引手数料である。

• 口座に出力が関連付けられる。• 口座に関連付けられている未使用の出力の額面を合計すれば、口座残高が求められる。

• 取引のハッシュ値。• 取引を識別するために使用する。

元帳（ ledger ）• 口座（ account ）間の全ての有効な取引が記録される。

• 検証に通らなかった無効な取引は記録されない。• 全ての口座の残高を求めることができる。

• 全てのノードが元帳を保持する。• 新しい取引が発生した場合には、その情報が全てのノードに伝えられる。

• 新しい取引を受け取ったノードは、その取引を検証してから、その取引が有効である場合には、元帳に記録する。• P2P なので、全てのノードに情報が伝わるのには時間が掛かる。• ある瞬間に全てのノードが保持する元帳が完全に一致するとは限らない。

• 問題 1 ：古い取引が伝わる前に新しい取引が伝わる可能性がある。• 古い取引が伝わるまで、新しい取引が有効かどうか分からない。

• 問題 2 ：二重消費攻撃（ double spending attack ）• ノード間の元帳が矛盾する。• どれが有効な取引か分からない。

ブロック（ block ）• ノード間で元帳の状態をほぼ一定間隔で同期するための構成単位。

• 二重消費攻撃に対処するための仕組み。

• 取引に優先順位を付ける• 矛盾する 2 つの取引があるとき、優先する取引が有効な取引となり、逆

に、劣後する取引が無効な取引として除斥される。• P2P なので、優先順位について（多数の）ノードの合意がなければなら

ない。• 全てのノードは暫定的に取引を収容し、それらの取引を含むブロックの

作成を試みる。あるノードがブロックの作成に成功した場合、そのノードはそのブロックを他のノードに送信する。

ブロック作成• 暫定的に収容された取引の内、どの取引をブロックに格納するかはノードの自由裁量に任されている。ただ

し、現在ブロックの大きさは 1MB までに制限されている。• ブロックを作成するには仕事証明（ proof-of-work ）に対する解（ nonce ）を発見しなければならない。

• 解は一定の（それぞれのノードの仕事に関して平等な）確率で発見できるようになっている。• ブロックの頭部と解を結合したもののハッシュ値の先頭何ビットかが 0 となるようにしなければならない

（ある値以下のハッシュ値となる解を発見しなければならない）。• この値を目標（ target ）と言う。• 目標はネットワーク全体で約10 分に 1 個のブロックが生成されるように、ノード間で合意される（ただし、 2016ブロッ

ク毎にしか調整は行われない）。• 解を求めるのは困難であるが、解が正当であるかを検証するのは容易である。虱潰し（ brute force ）に解を探索するしかない。

• ハッシュ値はブロックを識別するためにも使用される。• ブロック作成を試みるノードを採掘者（ miner ）と言う。ブロック作成を採掘（ mining ）と言う。

• ブロックを発見した採掘者は近接ノードにブロックを送信する。ブロックを発見した採掘者を、ネットワークの観点から見て、原点（ origin ）と言う。

• ブロックを発見した採掘者は報酬として新たに鋳造された Bitcoin を受け取る（ただし、ブロック鎖の頭部に接続できなければならない）。

• これが、採掘者が仕事を行う動機となる。

ブロック鎖（ blockchain ）• ブロックを作っただけでは、取引について矛盾がないことを保証できない。

• 複数のブロックの中に含まれている幾つかの取引が矛盾している可能性がある。

• ブロック間の優先順位が必要• ブロック間での優先順位が決まれば、ブロックの中に含まれている取引の優先順位も決まる。

• 全てのブロックは有向木（ directed tree ）として編製される。• 根（ root ）に当たるブロックを起源ブロック（ genesis block ）と言う。あるブロックから起源ブロックまで

の道の長さをそのブロックの深さ（ block height ）と言う。• 任意のブロックから起源ブロックまでの道の内、最長のものをブロック鎖と言う。ブロック鎖の中で葉に当

たるブロックをブロック鎖の頭部（ blockchain head ）と言う。• ブロックの頭部（ block header ）とは異なるので注意！

• これでブロック鎖の中でのブロックの優先順位を決めることができる。• ブロック鎖の中において、より小さい深さにあるブロックはより大きい深さにあるブロックに優先する。

• 従って、ブロック鎖の中において、より小さい深さにあるブロックの中に含まれる取引はより大きい深さにあるブロックの中に含まれる取引より優先する。

• 採掘者はブロック鎖の頭部に接続することのできる新しいブロックを発見した場合にのみ報酬を得られる。• それ以外のブロックに接続することのできる新しいブロックを発見しても意味がない。

ブロック鎖の役割• 1. 取引の順番を決定する。• 2.ハッシュ計算能力による安全性を提供する。• 3. 口座残高を管理する。

• これらの 3 つの役割を全て担っているのがブロック鎖。

採掘の要件•生成するのが困難• 検証するのが容易•採掘装置の最適化が困難（ ASIC耐性、 GPU耐性）

ブロック鎖分岐（ blockchain fork ）• ブロック鎖が 2 つ以上存在する状況が起こり得る。

• 起源ブロックからあるブロックまでは共通しているが、そのブロックから分岐し、別々の頭部を有する。• このような状況をブロック鎖分岐と言う。• 何れかが優先されなければ、取引について矛盾がないことを保証できない。• 通常は、時間が経てば、何れかが長くなり、それ以外は最早ブロック鎖ではなくなるので、問題はない。• 何らかの原因で、ネットワークが完全に幾つかに分裂すると、分裂したネットワークはそれぞれ独自のブロック鎖を有するようになる。• 更にまた、何らかの原因で、分裂したネットワークが統合すると、どれか 1 つのブロック鎖が生き残り、それ以外のブロック鎖は消滅する。

• そのため、ネットワーク分裂の検出は非常に重要である。• ネットワーク分裂の検出は、ネットワークの総計算能力の観測によって行う（ブロックの発見頻度が大きく減少した場合、ネットワークの分裂が疑われる）。

• ブロック鎖の一部ではなくなったブロックを破棄ブロック（ orphan block ）と言う。• 長くなったものが常に正しいと考える。

• ブロック鎖分岐が発生している状況では、何れのブロック鎖が長くなるか不確定なので、ブロック鎖分岐が発生したブロック以降のブロックに含まれている取引は、後になって取り消される可能性がある。

• ブロック鎖分岐が発生するかどうかも不確定なので、ある取引が有効であるか否かは確率的である。• 尤も、取引が実行されてから十分な時間が経過すれば取引が取り消される確率は実用上全く問題がない程極めて低くなる。

51%攻撃（ 51% attach ）• あるノードがネットワークの計算能力の多くの部分を支配して

いる場合には、そのノードは残りの全てのノードが全体として新しいブロックを発見するより早く別の新しいブロックを発見することができるので、任意の取引を取り消すことができる。• 取り消したい取引が含まれるブロック bd からその取引を除いた別の新

しいブロック bd’ を発見し、その新しいブロックに接続する新しいブロックを現在のブロック鎖の長さを越えるまで発見していけば、 bd’ を通る道が新しいブロック鎖となる。

•ギャンブラーの破産問題（ gambler's ruin problem ）

難易度•有効なブロックを作成するのがどれくらい難しいかを表す。• 有効なブロックを作成するためにはノード間で合意されている目標以下のハッシュ値を生成する解を求めなければならない。• 目標は 2016ブロック毎に調整されるので、難易度も 2016ブロック毎

に変化する。• 目標が小さい程難易度は大きい。目標が大きい程難易度は小さい。

時刻印（ timestamp ）

分散型電子貨幣システムを作ろうとすると顕在化する問題• どのようにして貨幣の元帳を保持するのか？• データが失われる可能性にどう対処するか？• Bitcoin では全てのノードが完全な元帳を保持する。

• 厳密には、新しい取引の情報が全てのノードに伝播するにはある程度時間が掛かり、取引を検証するにも時間が掛かるので、全てのノードが保持する元帳が完全に一致する訳ではない。しかし、最終的には、全てのノードが完全な元帳を保持する筈である。

• どのようにして取引の検証を行うか？• 不正な取引は拒否しなければならない。

bitcoind

• Nakamoto によって作られた概念実証を目的とする参照実装（ reference implementation ）であるが、現在でも尚最も広く使用されているクライアントである。

Bitcoinネットワーク• Bitcoind の場合。•接続数は 8 （ MAX_OUTBOUND_CONNECTIONS ）•接続数より小さくならないように常に接続を維持する。• Bitcoinネットワークに存在するノードが 8以下の場合には、当然なが

ら、接続数より少ない接続しかできない。• ポートが開放されていないノードは、最大で 8 個のノードまでしか接続しない。• ポートが開放されているノードは、 8 個より多くのノードと接続する

可能性がある。• 平均で 32 個のノードと接続しているらしい [1] 。

通信文（ message ）• 元帳の更新及び同期

• inv• あるノードが新しい取引やブロックの検証を終えると、新しい取引やブロックがあることを通知するために近接ノード

に inv通信文を送信する。• 取引のハッシュ値の集合とブロックのハッシュ値の集合

• getdata• 取得したい取引やブロックを通知する。• 取引のハッシュ値の集合とブロックのハッシュ値の集合

• tx• 取引の送信

• block• ブロックの送信

• 伝播遅延（ propagation delay ）• 取引やブロックがあるノードから別のノードに伝わり、検証されるまでに要する時間。• 伝送時間＋検証時間• inv + getdata + (tx or block) + 検証時間

• 遅延損失（ delay cost ）• 通信文の大きさが増えるとどれだけ遅延が大きくなるか。

Bitcoin の応用• 電子財産（ smart property ）• 電子契約• 第三者預託取引（ escrow transaction ）

Bitcoin の問題点 1

• 拡張性（ scalability ）• ノード数が増えた場合• 取引が増えた場合

• 現在ブロックの大きさは 1MB までに制限されている。また、ブロックは平均して 10 分に 1個ずつ生成されるように調整されている。従って、処理可能な取引数には上限がある（上限があるというよりは、ネットワークの処理能力を超過しないように制限を設定していると言った方が正しい）。

• 平均的な取引の大きさを考慮すると、現在の取引数の上限は約 3.3 取引 / 秒である。• データ転送量• 伝播遅延• 検証時間• ブロックの大きさの最大値

• ブロックの大きさが大きくなれば伝播遅延も大きくなる。• データ量（ブロック鎖の肥大化（ blockchain bloat ））

Bitcoin の問題点 2

• 取引や取引の有効性の確認に時間が掛かる• ブロック生成間隔は 10 分なので、取引がブロックに取り込まれて有効性が確認され

るまでに時間が掛かる。• ブロック鎖分岐が発生している可能性があるので、更に何ブロックか生成されるま

で待たないと、取引の有効性が覆される可能性がある。• かと言って、安易にブロック生成間隔を短縮すると、伝播遅延のために頻繁にブロック鎖分岐が発生する状況となり、どれが本当に有効な取引か分からない混乱状態に陥る可能性がある。

• 匿名性が低い• 採掘者が手数料のある取引をその取引を含んだブロックを作成するまで他

のノードに伝えない可能性がある。• 最小手数料が固定されている。

• 手数料の自動調整（ smart fee ）が実現すれば解決するが・・・。

拡張性の問題を改善する•簡易決済検証（ simplified payment verification ）• クライアントはブロックの頭部のみダウンロードし、ブロックが鎖状

に接続されているか確認し、ブロックの難易度が十分に高いかどうか確認する。• 取引が格納されている Merkle木の一部のみをダウンロードして取引がブロックに含まれているかどうか確認する。• 十分に古いブロックの頭部はダウンロードせず、十分に古くなったブロックの頭部は破棄する。

ブロック鎖の肥大化の問題を改善する 1

• ブロック鎖の剪定（ blockchain pruning ）• 更新取引（ refresh transaction ）

• 未使用の取引出力を有する古い取引を口座番号毎に 1 つに纏めた取引を作成する。• 誰が作成するのか（誰が作成するべきか）？

• 秘密鍵は不必要なので作成すること自体は誰でも可能。• 作成者に手数料を与えるべきか？

• 究極のブロック鎖圧縮（ ultimate blockchain compression ）• 全ての未使用の取引出力を口座番号毎に纏めた木を使用する。

• 未使用の取引出力を口座番号毎にダウンロードすることができ、口座番号毎に未使用の取引の検証を行うことができる。

• 通常 1 つの口座に含まれる未使用の取引出力のデータは非常に小さいので素早くダウンロードすることができる。

• 口座の残高を知るために最小限のデータしか必要ない。• この木は別のブロック鎖の頭部に含まれる。

• 統一採掘（ merged mining ）によって安全性が維持される。

ブロック鎖の肥大化の問題を改善する 2

• 制限的なブロック鎖• 口座木（ account tree ）

• 全ての空でない口座の残高を保持する。• 口座番号、口座残高、参照ブロック（ reference block ）• 参照ブロックは、口座における取引出力を使用する最後の取引が含まれているブロック

の番号。• できる限りデータの大きさが小さくなるようにすべき。

• 小型ブロック鎖（ mini-blockchain ）• 十分に古いブロックが削除されることによってブロックの数が制限的である以外は普通

のブロック鎖と同様である。• それぞれのブロックはそれらが生成された時点における口座木のハッシュ値を含む。

• 口座木が正しいことを検証することができる。• 証明鎖（ proof chain ）

• 起源ブロックから最新ブロックまでの一連の仕事証明の解からなる鎖。

そもそもブロック鎖の肥大化は問題なのか？• 全ての使用者が完全なブロック鎖を保持する必要はないのではないか？

• 分散の度合いが下がり、集中の度合いが上がる。• いつの間にか既存の銀行システムと同様なものとなり、今までやってきたことは何だっ

たんだということになるかもしれない。• 使用済みの取引出力しか有しない取引はブロック鎖から除去できる。

• 塵芥のような非常に小額の取引出力であっても、未使用の取引出力を有する取引は残存する。

• ブロック鎖外の取引（ off-chain transaction ）はブロック鎖には何の影響も及ぼさない。• 取引手数料がブロック鎖の保持費用を相殺する。• Moore の法則は健在であり、近い将来においてこの法則が崩れることはない

（継続的な技術革新によって拡張性の問題は吸収され、顕在化することはない）。

匿名性を向上させるには？• Darkcoin• Zerocoin, Anoncoin, Zerocash, Nxtcash, etc• NxtCash の場合

• 匿名性• 貨幣の送信者と受信者を結び付けることができない（誰が誰に送金したのかが当事者以外には分からない）。

• 無信用性• 信用できる第三者機関を必要としない。

• 分散性• 単一機関ではない。単一障害点（ single point of failure ）がない。

• 暗号学的な安全性• 悪意のある攻撃からの保護。

• 効率性• 多くの取引を処理することができる。

• ゼロ知識証明（ zero-knowledge proof ）• zk-SNARK

proof of

• proof of effort• proof of work

• Bitcoin, Litecoin, etc• 特定の値以下のハッシュ値を有する解を計算させることで、取引を有効にする。• proof of validity• proof of inclusion

• proof of stake• Peercoin, Nxt, etc

• proof of burn• Counterparty

• Proof of transaction• Fluttercoin

• proof of excellence• proof of bandwidth• proof of identification• proof of publication

Bitcoin 関連論文 1

• [1] Information Propagation in the Bitcoin Network, Christian Decker @ ETH Zurich, Switzerland, Roger Wattenhofer @ Microsoft Research

• An Analysis of Anonymity in the Bitcoin System

• Quantitative Analysis of the Full Bitcoin• Transaction Graph

• Beware the Middleman:• Empirical Analysis of Bitcoin-Exchange Risk

• Evaluating User Privacy in Bitcoin

• Bitter to Better—How to Make Bitcoin a Better Currency

Bitcoin 関連論文 2BITCOIN 14 workshop

• “Bitcoin: A First Legal Analysis – with reference to German and US-American law” By Franziska Boehm, Paulina Pesch, Institute for Information-, Telecommunication-, and Media Law, Muenster, Germany

• “The Bitcoin P2P network” By Joan Antoni Donet Donet, Cristina Pérez-Solà, and Jordi Herrera-Joancomartí, Dept. d’Enginyeria de la Informació i les Comunicacions Universitat Autònoma de Barcelona 08193 Bellaterra, Catalonia, Spain.

• “Empirical Analysis of Denial-of-Service Attacks in the Bitcoin Ecosystem” By Marie Vasek, Micah Thornton, and Tyler Moore, Computer Science and Engineering Department Southern Methodist University, TX, USA.

• “How Did Dread Pirate Roberts Acquire and Protect His Bitcoin Wealth?” By Dorit Ron and Adi Shamir, Department of Computer Science and Applied Mathematics, The Weizmann Institute of Science, Israel.

• “Fair Two-Party Computations via Bitcoin Deposits” By Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski and Łukasz Mazurek, University of Warsaw, Poland.

• “Increasing Anonymity in Bitcoin” By Amitabh Saxena and Janardan Misra, Accenture Technology Labs, Bangalore 560066, India and Aritra Dhar, Indraprastha Institute of Information Technology, New Delhi, India.

• “Game-Theoretic Analysis of DDoS Attacks Against Bitcoin Mining Pools” By Benjamin Johnson, University of California, Berkeley, CA, USA; Aron Laszka, Budapest University of Technology and Economics, Hungary; Jens Grossklags, The Pennsylvania State University, State College, PA, USA; Marie Vasek and Tyler Moore, Southern Methodist University, Dallas, TX, USA.

• “Towards Risk Scoring of Bitcoin Transactions” By Malte Möser, Rainer Böhme, and Dominic Breuker, Department of Information Systems, University of Münster, Germany.

• “Rational Zero: Economic Security for Zerocoin with Everlasting Anonymity” By Christina Garman, Matthew Green, Ian Miers, and Aviel D. Rubin, The Johns Hopkins University Department of Computer Science, MD, USA.

• “Challenges and Opportunities Associated with a Bitcoin-based Transaction Rating System” By David Vandervort, Xerox.

Information Propagation in the Bitcoin Network 1梗概

• 本論文では、• 全てのノードによって共有されている元帳を最新の状態に更新させる

ため、新しい取引やブロックを全てのノードに伝播させる際に、 Bitcoin がどのようにして多段中継の一斉同報通信（ multi-hop broadcast ）を使用するのか（どのように情報が伝播するのか）を分析する。• ネットワークの伝播遅延がブロック鎖分岐の主要な原因であるか検証

する。• クライアントの挙動に一方的な変更を加えるだけで、現在のプロトコ

ルに変更を加えず限界まで利用して、何を達成することができるか示す。

Information Propagation in the Bitcoin Network 2•ブロックの伝播について、その大きさを考慮しない場合

• 中央値は 6.5 秒。• 平均値は 12.6 秒。• ロングテール。• ブロックの伝播が始まってから 40 秒経過しても 5% のノードには未だ伝播していない。

• 取引とブロックの伝播について、その大きさを考慮した場合• 小さい取引やブロックは遅延の、大きさに対する比率が大きい。• 20kByte を超えるブロックでは遅延の、大きさに対する比率がほぼ一定。

• 20KByte を超えた場合は、ブロックが大きくなっても一定の比率でしか伝播遅延は増加しない。

• inv通信文と getdata通信文の往復に非常に時間が掛かっている

Information Propagation in the Bitcoin Network 3•矛盾する 2 つの取引やブロックを検出した場合にそれを他のノード

に転送しないとどうなるか？• 一方の取引やブロックが有効であると見做しているネットワークと他方の

取引やブロックが有効であると見做しているネットワークに分裂している状態であるから、その 2 つの分裂したネットワークの正に境界にあるノードのみが矛盾する 2 つの取引やブロックが存在することを認識しているだけである。

• 取引の場合は、スパム取引によるネットワークの不安定化を防止するため、矛盾する取引を転送しないのは妥当な選択だろう。• しかし、ブロックの場合は、矛盾するブロックを転送しないと、ブロック鎖分岐が発生したことを認識できるノードが極少数に限られてしまう。

Information Propagation in the Bitcoin Network 4•ブロック鎖分岐割合（到達できるノードのみに関して調べた値）• 1.69%• 伝播遅延が大きくなればなるほどブロック鎖分岐が発生しやすい。

•ブロック鎖分岐割合（理論値）• 1.78%

•微妙に実測値より大きいのは、ハッシュ計算能力が全てのノードに一様に分布しているという仮定がおかしいからだろう。• とは言え、実測値と十分良く一致している。

Information Propagation in the Bitcoin Network 5• 新しいブロックが見付かる毎に 11.37 秒分のネットワーク全体

のハッシュ計算能力が無駄になっている。• 伝播遅延が大きくなればなるほどハッシュ計算能力が無駄になる。

• つまり、元帳の安全のために実際に役に立っているハッシュ計算能力は投入されているハッシュ計算能力の 98.20%• 全体のハッシュ計算能力の過半数のハッシュ計算能力を支配していれ

ば 51%攻撃を実行できるとされているが、実際には 49.1% を超えれば51%攻撃を実行できる。• 伝播遅延が大きくなればなるほど 51%攻撃に必要なハッシュ計算能力

の割合が低下する。

Information Propagation in the Bitcoin Network 6•伝播遅延には悪影響が多い。• 何とかして伝播遅延をできる限り小さくしよう！

Information Propagation in the Bitcoin Network 7• 検証の最小化

• ブロックの検証には難易度の検証と取引の検証の 2 つがあるが、難易度の検証をして直ぐに inv通信文を発行するようにする。• たとえ無意味なデータを含んでいるブロックであっても、難易度の検証に通るように作る

のは、有効なブロックを作るのと同程度のハッシュ計算能力が必要になるので、 DDoS攻撃に悪用される心配はない。

• ブロック伝播の並列化• inv通信文を受信したら、直ぐに近接ノードにその inv通信文を転送する。

• 幾らでも虚偽の inv通信文を発行することができる。しかしながら、 inv通信文は 61 バイトしかないし、 tx通信文を発行することでも同様のことはできるので、影響は少ない。

• 接続数の増加• 接続数を 4000以上にすると全ての到達可能なノードに接続できる。

• 100MB/s 程度のデータ転送量が必要

Information Propagation in the Bitcoin Network 8• 全ての改良を施したクライアントでブロック鎖分岐割合を調べ

てみると、• 1.69% → 0.78%• 53.41% の向上！

Purely P2P Crypto-Currency With Finite Mini-Blockchain 1梗概

• 殆ど全ての分散型暗号貨幣はブロック鎖という仕組みを使って二重消費攻撃を阻止している。• しかしながら、ブロック鎖には肥大化の問題がある。

• 本論文では、制限的なブロック鎖を使用する分散型暗号貨幣を提案する。• 制限的なブロック鎖では、ブロック鎖の中にあるブロックの数が上限に達している場合には、新しいブロックが発見され、ブロック鎖に追加されると、ブロック鎖の中で終端に存在する最古のブロックが削除される。• ブロックの削除が引き起こす安全性低下の問題は証明鎖（ proof chain ）によって解決される。

• ブロックを削除するとブロックに含まれている未使用の取引出力も削除されてしまい口座残高の全部又は一部が消失するという結果を齎すが、それは空でない口座の残高を保持する口座木（ account tree ）を構築することによって回避される。

Purely P2P Crypto-Currency With Finite Mini-Blockchain 2• 制限的なブロック鎖

• 口座木• 全ての空でない口座の残高を管理する。• 口座番号、口座残高、参照ブロック（ reference block ）• 参照ブロックは、口座の取引出力を使用する最後の取引が含まれているブロックの番

号。• できる限りデータの大きさが小さくなるようにすべき。

• 小型ブロック鎖（ mini-blockchain ）• 十分に古いブロックが削除されることによってブロックの数が制限的である以外は普通のブロック鎖と同様である。

• それぞれのブロックはそれらが生成された時点における口座木のハッシュ値を含む。• 口座木が正しいことを検証することができる。

• 証明鎖• 起源ブロックから最新ブロックまでの一連の仕事証明の解からなる鎖。

Purely P2P Crypto-Currency With Finite Mini-Blockchain 3•制限的なブロック鎖• ネットワークの同期

• 1. 最大の累積難易度（ cumulative difficulty ）を有する証明鎖を取得する。• 2. 証明鎖に結び付けられている小型ブロック鎖を取得する。• 3. 最近ブロックの主ハッシュ値（ master hash ）に結び付けられている部分ハッ

シュ値（ sector hashes ）を取得する。• 4. 口座木を構築し、それぞれの部分（ sector ）のハッシュ値が部分ハッシュ値に

一致するか検証する。

Purely P2P Crypto-Currency With Finite Mini-Blockchain 4• 動的な最大ブロック長の決定• 採掘者がブロックに希望する最大ブロック長を格納する。

• 小型ブロック鎖に含まれる全てのブロックの希望最大ブロック長を平均したものが次のブロックの最大ブロック長になる。

• ある程度上限や下限を設定すべき。• 最大ブロック長と実際のブロック長がどれくらい近いか。

•失われた貨幣の再採掘• 一定期間使用されなかった貨幣は特別の取引を使って採掘者が取得す

ることができるようにする。

Accelerating Bitcoin‘s Transaction ProcessingFast Money Grows on Trees, Not Chains 1梗概

• Bitcoin の仕組みは非常に高い頻度の取引の発生にも耐えられるのか？• ノード間のデータ転送量の多寡や伝播遅延の長短は、取引の処理効率を左右し、延いては、一

定時間に処理可能な取引数を左右する要因である。• データ転送量の多寡より伝播遅延の長短の方が遥かに影響が大きい。

• Nakamoto の論文では、ブロック生成間隔に比べると、伝播遅延は無視できる程に短いと仮定している。• しかしながら、この仮定は必ずしも妥当ではない。

• ブロック生成間隔をもっと短縮したいという需要も存在する。

• そこで、本論文では、• Bitcoin のプロトコルが 1 秒間に安全に処理可能な取引数の上限を与える。• 完全な取引データの代わりに取引のハッシュ値を使用するという現在計画されているプロトコ

ルへの改善がこの上限を著しく緩和する効果があることを示す。• 攻撃者からの保護性能を向上させるブロック鎖の構成方法を提案する。

• 上述の上限を更に緩和する効果がある。• 取引の確認時間も著しく低減することができる。• ブロック生成間隔を安全に 1秒まで短縮することができる。

アドレス• 1.楕円曲線暗号の公開鍵• 2.1 の公開鍵の RIPEMD160ハッシュ値• 3.2 のハッシュ値にバージョン情報と確認コードを含めて

base58エンコードしたもの

Base58Check

• Bitcoin アドレスを符号化するために使用される独自の方式。• バイナリデータをテキストデータとして表現するための方式の一種。これと同種の方式とし

ては電子メールで使用されている Base64 が代表的。他にも様々なものがある。• Flickr では Base58 という方式が使われているが、それと Base58Check は異なる方式である。

• なぜ Bitcoin アドレスの表記では Base64 を使用せず、独自の Base58Check を使用しているのか？• Satoshi曰く、

• 0 （数字の 0 ）と O （大文字の O ）及び 1 （数字の 1 ）と l （小文字の l ）の間の混同を避けるためである。• これらが混同されると、

• アドレスを間違える可能性がある。• 同じ口座に見える異なる口座が作られ（詐欺などに使用され）る可能性がある。

• 数字と英文字以外の記号が入っているアドレスは口座番号としては受け入れにくい。• 電子メールでは通常改行するべき記号が現れるまでは改行されない。• ブラウザなどの UI ではダブルクリックするだけで簡単にアドレス全体を選択することができる。

分散ハッシュテーブル（ distributed hash table ： DHT ）

Kademlia1

• 分散ハッシュテーブル• 鍵空間は 160ビット。• 鍵は鍵空間上の 1点に対応する 160ビットの識別子である。• ノードは鍵空間上の 1点に対応する 160ビットの識別子を有する。

• ノードが送信する全ての通信文には識別子が添付される。• 識別子の距離はビット排他的論理和（ bitwise exclusive or ： XOR ）：

d(x, y) = x ^ y• d(x, x) = 0• d(x, y) > 0 if x != y• d(x, y) = d(y, x) （交換律）• d(x, y) + d(y, z) >= d(x, z) （三角不等式）

Kademlia2

• ノードは他のノードの情報を保持する。• ノード情報：（ IP アドレス、 UDPポート番号、識別子）• k- バケツ（ k-buket ）：ノードからの距離が 2i～ 2i+1 であるノードの情報を保持する 160 個のリスト。

それぞれのリストに格納されたノード情報は最後に通信を行った時間に基づいて整列される（最古のノード情報が先頭に、最新のノード情報が末尾に配置される）。• i が小さい場合は、 k- バケツは空であることが多い。• i が大きい場合は、 k- バケツは k 個のノード情報を含むことが多い。

• ノードが他のノードから任意の通信文を受信した場合には、 k- バケツを更新する• k- バケツに対応するノード情報が存在する場合は末尾に移動する。• K- バケツに対応するノード情報が存在しない場合は、

• k- バケツに格納されているノード情報が k 個未満の場合には末尾に追加する。• k- バケツに格納されているノード情報が k 個以上の場合には最古のノード情報に対応するノードに ping通信文を送信し、

応答を要求する。• 応答があった場合には最古のノード情報を最新のノード情報として末尾に移動する（新しいノード情報は破棄す

る）。• 応答がなかった場合には最古のノード情報を削除し、新しいノード情報を末尾に追加する。

• k- バケツが一定時間更新されなかった場合には k- バケツの範囲から無作為に 1 つ識別子を生成し、ノード探索を実行する。

Kademlia3通信手続き

• 4 つの遠隔手続き呼び出し• PING

• ノードが生きているか調べる。• STORE

• ノードに鍵と値の結合を格納する。• FIND_NODE

• 引数として識別子を取る。• ノードが知っている識別子に近い k 個のノードの情報を返す（ノードが k 個以下のノード情報

しか知らない場合には知っている全てのノード情報を返す）。• FIND_VALUE

• 引数として識別子を取る。• ノードが知っている識別子に近い k 個のノードの情報を返す（ノードが k 個以下のノード情報

しか知らない場合には知っている全てのノード情報を返す）。• ただし、鍵としての識別子に対応する値を有する場合には値を返す。

Kademlia4ノード探索（ node lookup ）、値探索

• 識別子に近い k 個のノードを探索する。• FIND_NODE• 探索ノードは識別子に近い α 個のノード情報を k- バケツから選出し、それらのノード情報

に対応するノードに対して FIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行する。• 新しく得たノード情報から識別子に近い α 個のノード情報を選出し、それらのノード情報

に対応するノードに対して FIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行する。• 識別子に近い k 個のノード情報に対応するノードで未だ FIND_NODE遠隔手続き呼び出しを実行していないノードに対して FIND_NODE遠隔手続き呼び出しを並列的に非同期的に実行する。

• 識別子に近い k 個のノード情報に対応するノードからの応答を得られたら終わり。• 識別子に近い k 個のノードを探索しながら、鍵に対応する値を探索する。

• FIND_VALUE• 上の場合とほぼ同様だが、値が取得できたら終わり。• 最後まで値が取得できなかったら、値は存在しない（可能性が高い。仮に存在していても

取得する術がない）。

Kademlia5

• 鍵と値の結合は鍵と識別子の距離が近いノードに格納される。• FIND_NODE + STORE

• 一定時間毎に鍵と値の結合を距離が近いノードに再格納する。• FIND_NODE + STORE

• 新しいノードを発見したら新しいノードの識別子と距離が近い鍵と値の結合を新しいノードに格納する。• STORE

• 鍵に対応する値を取得する。• 鍵と近いノードで鍵に対応する値を保持していないノードがあったら、値を取得した後にノードに値を格納

する。• 取得した値はキャッシュする。値との間に多くのノードがあるノード程早くキャッシュが削除される。• FIND_VALUE + STORE

• ネットワークに参加したいノードは何らかの方法で 1 個以上の既にネットワークに参加しているノードの情報を入手し、ノード情報を k- バケツに挿入し、自身の識別子と距離が近いノードを探索する。• FIND_NODE