BitTorrent

BitTorrentは、Web上でtorrentを使って大容量ファイルを転送する際に広く使われているプロトコルです。その主な目的はメインサーバを経由することなく、ネットワーク内のさまざまなピア間でのファイル転送を容易にすることです。

BitTorrentクライアントを使うと、世界中の複数のコンピュータに接続してファイルをダウンロードします。.torrentファイルを開くと、コーディネーターのような役割を果たすマシン、いわゆる トラッカ に接続されます。トラッカはピアを見つけ出し、欲しいファイルを持っているネットワーク内のノードを示してくれます。

注釈：
トラッカ
・オンラインのノードをトラッキングする
・ノードが何のファイルを提供しているかを認識する
Seeder：シーダ
Leeche： リーチャ
破線：ファイル転送
実線：メタデータ転送
ネットワークのサンプル

ユーザには、 リーチャ と シーダ の2タイプの概念があります。リーチャはファイルをダウンロードするユーザ、シーダは同ファイルをアップロードするユーザです。

ピアツーピアネットワークが面白いのは、一般のユーザがネットワークに参加し、貢献できる点です。

BitTorrentやその先駆け（ Gnutella 、 Napster ）を使えば、ユーザは自主的にファイルをホストし、そのファイルを求めている別のユーザへアップロードすることができます。BitTorrentの人気が高い理由は、その種のソフトでは初めてネットワークへの貢献に対するインセンティブを提供したことです。それ以前のファイル共有プロトコルは常に、ユーザがファイルをダウンロードするだけで フリーライド （タダ乗り）をしてしまうという問題を抱えていました。

BitTorrentは、高速ダウンロードを提供する人に対して、シーダが他より多くをアップロードする仕組みを作り、フリーライド解決に一定の成果を上げました。ファイルのダウンロード中に、アップロードも行うよう促したのです。残念ながら、ダウンロードが完了してしまえばネットワーク内で活動する動機はなくなります。そのため、完全なファイルを持つネットワーク内のシーダが不足します。また、プロトコルはそういったユーザに大きく依存しているので、 プライベートトラッカ のような解決策が実現したのです。プライベートトラッカは、分散型ネットワークに参加したいユーザに対し、コミュニティ（招待制限定の場合が多い）のメンバーになることを要求します。

ファイル共有の分野は進歩を遂げ、トラッカを必要としないトレントも登場しました。これは、BitTorrent プロトコルのアップグレード版で、集中管理するトラッカではなく、新しいアルゴリズムでメタデータの収集とピアの探索を実行します。実例のひとつに、 Kademlia （ メインライン DHT ）があります。分散ハッシュテーブル（DHT）を使うと、他のピアを通じてピアを見つけることができます。つまり、各ユーザがトラッカの役割を果たすのです。

分散型台帳

分散型台帳は、分散ネットワーク内のすべてのノードに対して複製、同期、共有される不変の追加専用データベースであると考えてよいでしょう。

既知の規模 – 2018年1月4日、イーサリアムネットワークの1日の取引が130万件に達しました。

分散型台帳は イベントソーシング のパターンを活用し、過去のいつの時点の台帳の状態でも再構築できるようにします。

ブロックチェーン

ブロックチェーンは、分散型元帳に使用されている現在の基礎技術であり、事実上、分散型元帳が動き出すきっかけになりました。分散型空間におけるこの最新かつ最高の革新は、本当の意味で分散型である史上初の決済プロトコル、ビットコインの創出を可能にしました。

ブロックチェーンは、ネットワーク内で発生した全取引の注文リストを処理する分散型台帳です。取引はすべてグループ化され、ブロックの形で保存されています。ブロックチェーン全体はもともと、ブロックの 連結リスト です（ その名のとおり ）。そのブロックの生成の演算には高いコストがかかり、暗号を経由して互いに緊密に連結しています。

簡単に言うと、各ブロックが、現在のブロックのコンテンツ（マークルツリーの形式で）の特別なハッシュ（X個のゼロで始まるもの）に加え、それ以前のブロックのハッシュを内包しているのです。このハッシュの生成には総当たりしか方法がないため、膨大なCPUパワーがかかります。

注釈：
以前のブロックのハッシュ + マークルルート + ナンス + ハッシュ
略式化したブロックチェーン

マイナ（採掘者） とは、ハッシュの演算を試みる（総当たりによって）ノードを指します。すべてのマイナは、ランダムな文字列（ ナンス と呼ばれます）を求めて競争し合います。この文字列はコンテンツと結合する時に前述のハッシュを生成するのです。正しいナンスを見つけた人は、全ネットワークにそれを広めます。すると、当該の文字列自体が各ノードの認証を受けチェーンに組み入れられます。

この過程によって成り立つのは、ブロックチェーンを改変しようとすれば異常なコストがかかり、それが改ざんされていないことを確認するのは容易なシステムです。

ブロックのコンテンツの改変にコストがかるのは、それが異なるハッシュを生成するためです。後続の各ブロックのハッシュはその異なるハッシュに依存することに注意してください。上の図の1つ目のブロックにおける取引を改変しようとする場合、マークルツリーのルートを変更することになります。それにより順にブロックのハッシュが変わっていき（必須である先頭のゼロ群なしで変わることが多い）、ブロック#2以降のハッシュも変更されます。つまり、1つのブロックを改変したら、全ブロックに対して新たなナンスを総当たりで見つけなければなりません。

ネットワークは常に、最長の有効なチェーンを信用し複製します。システムを欺き、 最終的に 本物よりも長いチェーンを生成しようとすると、全ノードが使用しているCPUパワー総計の50%超が必要になるでしょう。

ブロックチェーンは、 突発的コンセンサス のための分散型メカニズムであると言えるでしょう。コンセンサスの達成は明示的ではありません。コンセンサスが発生する時に、投票や決定の瞬間などは存在しないのです。ここで言うコンセンサスとは、何千もの独立したノードの非同期的なインタラクションから 突発的に 発生したものであり、すべてプロトコルのルールに則っています。

この前例のない革新は、テック空間では Web 3.0 の幕開けの象徴になっていくだろうと予測され、最近ブームになっています。極度に困難かつ面白い課題が解かれるばかりに山積みになっており、目下のソフトウェア業界で最も刺激的な分野であることは間違いありません。

ビットコイン

かつての分散型決済プロトコルには、分散型の方法を用い、実際に 二度支払い問題 をリアルタイムで防ぐ手段に欠けていました。研究の積み重ねで興味深い案[1]はいくつか出てきていましたが、明らかに他の利点をしのぐ実用的な解決策を初めて実装したのはビットコインでした。

二重支払いの問題とは、1人の行為者（例えば、ボブ）が、彼の単一のリソースを2つの場所で消費できないということです。ボブが$1を持っているとして、アリスとザックの2人にそれを譲渡できるようではいけません。資産は1つであり、重複は不可です。分散型システムにおいて真にこの保証を達成することは本当に難しいことが分かります。ブロックチェーン以前から、 興味深い緩和のアプローチ がいくつか提案されていますが、解決策として完全な実用にはいたっていません。

二重支払いの問題は、ビットコインでは容易に解決します。チェーンに1度に追加できるブロックは1つだけだからです。単一のブロック内では二重支払いは起こり得ないため、たとえ同時に2つのブロックが作られたとしても、結果として最長のチェーンになるのは1つだけです。

ビットコインはCPUパワーの蓄積の困難さゆえに成り立っています。

投票システムである場合、ネットワークにノードを追加するだけで攻撃できてしまいますが（ネットワークへのフリーアクセスは設計上の狙いでもあるため、容易）、CPUパワーを基盤とした方式の場合、攻撃者は物理的な制約にぶつかります。常により強力なハードウェアへのアクセスが求められるからです。

これはまた、悪意あるノードのグループが実際に攻撃を成功させるためには、ネットワークの演算能力の50％超を制御しなければならない理由でもあります。それ以下では、残りのネットワークがさらに長いブロックチェーンを先に生成してしまいます。

イーサリアム

イーサリアムは、プログラム化の可能なブロックチェーンベースのソフトウェアプラットフォームであると考えてよいでしょう。独自の仮想通貨（イーサ）は、ブロックチェーン上で スマートコントラクト の展開を促す燃料です。

スマートコントラクトはイーサリアムのブロックチェーンに単一の取引として保存されるコードの断片です。コードを実行するには、スマートコントラクトを取引先として取引を発行するだけです。すると、マイナのノードが順にコードを実行し、どのような変更があってもその取引は発生します。コードはイーサリアムバーチャルマシン内で実行されます。

スマートコントラクトは、イーサリアムのネイティブプログラミング言語、 Solidity を使って記述します。チューリング完全なプログラミング言語で、イーサリアムブロックチェーンに直に接続でき、残高やその他のスマートコントラクトの結果の状態を問い合わせることを可能にします。無限ループを防ぐため、コードを実行する際は一定量のイーサが必要です。

ブロックチェーンはひと続きの 状態変化 であるとも言えるので、多くの分散型アプリケーション（ DApps ）がイーサリアムやそれに似たプラットフォームの上に構築されてきました。

分散型台帳の他の用途

存在の証明 — 特定のデジタルドキュメントが、ある時点で存在したという証明を匿名で安全に保存するサービス。ドキュメントの完全性、所有権、タイムスタンプを保証するのに便利です。

Decentralized Autonomous Organizations（DAO、分散型自動化組織） — 組織の改善案の合意に達する手段としてブロックチェーンを使用する組織。事例として Dashのガバナンスシステム 、 SmartCashプログラム が挙げられる。

Decentralized Authentication（分散型認証） — ブロックチェーンにIDを保存し、どこでも シングルサインオン （SSO）を使えるようにする。 Sorvin や、 Civic など。

その他にも数え切れないほどです。分散型台帳の技術は確実に無限の可能性を開きました。こうして話している間にも次々と発明されているはずです！

まとめ

本記事が取り上げた短い範囲の期間の中で、分散型システムとは何か、なぜそれを使うのかを定義しようと努め、各カテゴリを大まかに見てきました。覚えておきたい重要事項は次のとおりです。

• 分散型システムは複雑だ
• 分散型システムはスケールと価格の必要性から選択する
• 分散型システムの運用は単一のデータベースを用いるよりも難しい
• CAP定理  — 一貫性または可用性のトレードオフ
• 分散型システムには6のカテゴリがある  — データストア、演算、ファイルシステム、メッセージング、台帳、アプリケーション

実のところ、この記事は分散型システムのごくさわりとも言えないくらいです。たとえば次のような核心の問題を包括的に説明できていません。 コンセンサス 、 レプリケーションストラテジ 、 イベントの順序付けと時間 、 フォールトトレランス 、 ネットワーク全体へのメッセージ伝達 、 その他にもたくさんあります 。

注意

最後に前もって警告を。

分散型システムにはできる限り近寄らないことです。別の方法や既存の手段とは全く違うやり方で解決できる問題ならば、あえて分散型システムの複雑さと格闘する価値はありません。

難しい問題解決につきもののドタバタにハマってはいけない。問題設定が間違っていた場合、その苦労はただのムダになる。難しい問題を簡単な問題に落とし込む機会を逸した場合、その苦労はただのムダになる。インスピレーションは、問題解決そのものではなく経過の中に見出そう。

— @practicingdev

[1]
『Combating Double-Spending Using Cooperative P2P Systems（コーポラティブP2Pシステムを使って二重支払いと闘う）』 、2007年6月25-27日  — 各「コイン」に利用期限を設け、支払いの際に証人（バリデータ）を割り当てる解決策を提案する。

『Bitgold（ビットゴールド）』 、2005年12月  — ビットコインに酷似したプロトコルの高度な概要。ビットコインの先駆けとされる。

分散型システムを知るための資料：

『Designing Data-Intensive Applications（データ集約型アプリケーションの設計）』、Martin Kleppmann著 — 分散型システムのあらゆるトピックスを網羅した素晴らしい本。

『Cloud Computing Specialization（クラウドコンピューティング詳解）』、Illinois大学、Coursera — 分散型システムの概念とアプリケーションを概観する6コースの長期シリーズ。

Jepsen — 数多くの分散型システムテクノロジ（Elasticsearch、Redis、MongoDBなど）を説明しているブログ。

この長い（～5600ワード）記事に最後までお付き合いいただき感謝します！

もしも、この情報が便利で何かの役に立つと思われたら、どうかぜひ、価値を感じられた分だけ「拍手」をください。そしてこの驚きに満ちた研究分野に興味を持っているご友人に共有してください。

• Stanislav Kozlovski