なるほど……。 自分なりの理解でこのプロトコルを要約してみる。
論文に書かれていない運用上の細部は、 自分の「設計感覚」 が「これは必須の抜けだ」 「これは『当然の』 やり方だ」 と告げる部分で補っている。
まず、 人々は計算機のパワーを費やしてコインのプールを作り、 それをマネーとして使う。 各コインは、 そのコインが作られた時点でマネーに対して有効だった基準を満たすプルーフ・オブ・ワークだ。 作成時刻 ( ひいてはその時の基準 ) は後からでも検証できる。 なぜなら、 そのコインがトランザクションチェーンに登場した瞬間が見え、 そこから「合意ビュー」 におけるすべての使用履歴をたどれるからだ。 ( コイン生成をリンク追加と結びつける話は後述する )
コインを使う際、 買い手と売り手は ( ブラインド化された ) トランザクション記録にデジタル署名し、 それを多数のノードにブロードキャストする。 これらのノードの目的はコインの所有権に関する合意の追跡だ。 誰かが二重支払いを行った場合、 そのトランザクション記録はブラインドを解除でき、 不正者の身元が明らかになる。 これはかなり標準的なカットアンドチューズアルゴリズムで実現される。 買い手はいくつかのチャレンジに対して秘密分散の値で応答し、 売り手は「ブラインドを解除せよ」 と求めて、 一つを残して全部を検査する。 そして、 そのうちの任意の二つが揃えば買い手の身元を特定できる秘密分散値が確かに含まれていることを検証する。 この場合、 売り手はブラインド解除済みの使用記録が「おそらく」 有効な秘密分散値を含んでいると受け入れる。
コインの所有権に関する合意を追跡するノードはループの中にいる。 すべてのノードが、 これまで受信した最長のチェーンに「リンクを追加」 しようとしている。 各ノードは、 「合意」 された署名済みチェーンにまだ含まれていない、 報告されたトランザクションのプールを持っている。 これをプール「A」 と呼ぶことにする。 ノードはチェーンにリンクを追加するため、 プール A のすべてをプール「L」 に移し、 CPU 集約型のデジタル署名アルゴリズムを使って、 新しいブロック L を含むチェーンに署名する。 結果として、 プール L に保持していたすべてのトランザクション記録とそのノードのデジタル署名を含むブロックで、 チェーンが延長される。 この間にも新しいトランザクション記録は届き続け、 次の作業サイクルのために再びプール A に入る。
作業中に、 延長しようとしているチェーンと同じ長さのチェーンを受け取ることもある。 そのチェーンでは、 最後の数本の「リンク」 が、 自分が作業しているチェーンとは共通でないリンクだ。 そういうチェーンは無視する。 ( ? 本当に無視していいのか? 後でもう一度見直さねばならない状況はどんな時か? それらに基づく長いチェーンが現れれば、 そこに含まれているのだから、 という前提で )
しかし、 作業中に_より長い_チェーンを受け取った場合、 直ちに新しいリンク内のすべてのトランザクションをチェックする。 二重支払いが含まれていないこと、 およびすべての新しいリンクの「ワークファクター」 が適切であることを確認するためだ。 もし二重支払いが含まれていれば、 二重支払いの証拠となる「トランザクション」 を作成し、 自分のプール A に追加してブロードキャストし、 作業を続ける。 「新しい」 リンクのどれかに不適切なワークファクター ( つまり、 ルール上「正当」 と見なせるだけの CPU を誰かが投じていない場合 ) があれば、 そのリンクを作ったノードによるプロトコル違反の証拠となる新しい「トランザクション」 を作成し、 ブロードキャストし、 プール A に追加して、 そのチェーンを拒否する。 二重支払いがなく、 まだ見ていないすべてのリンクのワークファクターが適切な場合は、 その新しいチェーンを合意として受け入れる。
新しいチェーンが受け入れられた場合、 自分が現在追加中のリンクは諦め、 プール L からすべてのトランザクションをプール A に戻し ( 作業開始以降に受信または作成したトランザクションと合わせて )、 新しいチェーンの中のリンクの一部として既に含まれているトランザクション記録をプール A から除外し、 新しいチェーンを延長しようと再び作業を開始する。
自分の新しいリンクでチェーンの延長を完了したら、 それをブロードキャストし、 作業開始以降にプール A に蓄積したすべてのトランザクションを使って、 直ちにまた新しいリンクの作業を始める。
これで正しく理解できているだろうか?
最大の技術的問題:
「チェーン」 が最も速い 3〜4 ノードのみによって追加されたリンクで占められないことを保証する仕組みはあるのか? なぜなら、 ブロードキャストされたトランザクション記録がその 3〜4 ノードに届かないことは容易にあり得る。 そうなって、 かつそのノードがチェーンを支配し続ければ、 そのトランザクションは永久に追加されないかもしれない。
これを解決するには、 トランザクションの伝播可能性を証明できるようにするか、 あるノードのワークファクターを、 そのノードの直近のリンク追加から何リンク追加されたかに応じて変動させる必要がある。
残念ながら、 どちらの対策もソックパペット ( なりすまし複数アカウント ) で打ち破られる。 これはおそらく現状のこのプロトコルにおける最悪の問題だ。 ノードのアイデンティティ ( 鍵 ) を制御し、 人々が新しいソックパペットを作るのを防ぐ、 何らかの中央管理点が必要になる。
伝播可能性の証明とはこういう意味だ。 ボブがアリスから新しいチェーンを受け入れる際、 アリスが自分のプール「A」 と「L」 のすべてのトランザクションを持っているか ( あるいは入手するか ) を確認する必要がある。 ボブはそれらをアリスに送り、 アリスは受信した証拠として署名付きハッシュを返す。 アリスがこのトランザクションのブロックを受け取った後、 アリスが追加したリンクを含む後続のチェーンが、 そのリンクまでに、 もしくはそれ以前にこれらのトランザクションを含んでいなければ、 ボブはアリスに送ったブロックとアリスの署名を、 アリスがプロトコル違反した証拠として、 一つのトランザクションの形で公開できるはずだ。 ソックパペットはこれを打ち破る。 なぜなら、 アリスは後続のチェーンに署名する際、 新しい鍵を使って別ノードのふりをすればよいだけだからだ。
新規リンクの数に応じてワークファクターを変動させる方式を採れば、 結局のところ最も速い 3〜4 ノードによる支配に戻ってしまう。 ただし今度はその支配者たちに、 ワークファクターのペナルティを回避するために使われる 600 個ほどのソックパペットが加わるだけだ。
ソックパペット問題を解決するか、 もしくは新しい鍵の生成を制御する中央点があると受け入れるなら、 コインの生成は「合意」 チェーンにブロックを成功裏に追加する行為と結びつけるべきだ。 これは単純に実現できる。 コインの生成は一つのトランザクションであり、 そのブロック内の他のすべてのトランザクションと共に追加される。 ただし、 リンクごとに作れるコインは一つだけで、 当然ながら、 自分のバージョンのチェーンが受け入れられなかった場合、 「受理された」 ビューでは自分はそのコインを持っていないし、 使うこともできない。 これが、 合意データベースを維持する人々に CPU サイクルを費やす動機を与える。 とりわけ上で述べた、 自身の直近リンク以降に追加されたリンク数によるワークファクターの変動が、 最も速い 3〜4 ノードだけでなく全員に、 時折コインを作る機会を保証するからだ。
また、 チェーンにリンクを追加する作業要求は、 過去一週間にそのチェーンに追加されたリンクの数に応じて ( これも指数的に ) 変動させ、 コイン生成 ( したがってインフレ ) の率を厳格に制御できるようにすべきだ。
これがスケールするためにはコインの集約が必要だ。 誰かが額面 1 のコイン 10 枚を引退させ、 額面 10 の新しいコインを作るような「証明可能な」 トランザクションが必要になる。 これは難しくない。 すでに用意されているのと同じ基盤で実現できる。 単純にチェーンの一部となり、 そのチェーンが合意として受け入れられたとき、 全員がそれが起きたことを見ることができる。
Bear