Tadge Dryja

コーヒーを買うたびに、世界中のノード、つまりビットコインの規則を確認するコンピューターがその支払いを個別に検証すると想像してください。自分のノードを動かすために、ますます高性能なコンピューターを求めずに支払いを増やせるでしょうか。Joseph Poon と Thaddeus Dryja は、支払いチャネルのネットワークを検討しました。リンク先のホワイトペーパーは設計を説明した文書で、2016年1月14日付、DRAFT 0.5.9.2 と記されています。発想の原点を知るための歴史的な提案であり、現在のソフトウェアの正確な規則は、それぞれの文書で確認する必要があります。 [1]

支払いチャネルは、あらかじめ入れたビットコインをどう分けるかについて、更新を続ける合意だと考えられます。支払いのたびに双方の取り分が変わります。参加者は変更に署名しますが、そのすべてを、共有の取引履歴であるブロックチェーンに公開する必要はありません。協力関係が終われば、Bitcoin のトランザクションによって配分を実行できます。Lightning は多くの更新をチェーンの外へ移しつつ、最終的な決済をビットコインの規則に結び付けています。 [1]

以前の合意には、その後お金を使った人の残高が多く記されているかもしれません。提案で説明される失効モデルでは、失効した状態を公開した相手に対し、もう一方がペナルティーのトランザクションで対応できます。ただし、定められた時間内に対応しなければなりません。そのため、本人か委任された監視者がブロックチェーンを確認する必要があります。暗号技術を使っていても、監視なしで永久に接続を切ってよいわけではありません。確実な監視体制も資金の保護に含まれます。 [1]

ビットコイン自体は、約束した日の為替レートを知りません。Discreet Log Contracts、略して DLC は、このような情報によって決済内容が変わる契約を扱います。二人の参加者が条件と可能な支払結果を事前に用意し、選んだ oracle、つまり外部データの提供者が、後で結果の発表に署名します。参加者はそれを使って対応する決済を行います。このモデルでは oracle は参加者の資金を預からず、誰が発表を利用するか知る必要もありません。他人のウォレットを管理するのではなく、情報を提供します。 [2]

デジタル署名は、誰がメッセージを発したか、内容が変更されていないかを確認する助けになります。しかし、情報が事実に合っていることまでは証明しません。Oracle が誤ったレートを発表したり、何も発表しなかったりする可能性があります。後者に備え、Dryja は期限後に公開できる返金トランザクションを事前に準備する方法を説明しています。お金が勝手に戻るわけではなく、契約にその仕組みを入れ、誰かが実行する必要があります。信頼できる情報源の選択と、その停止への備えは依然として重要です。 [2]

Dryja は、支払いを検証するノードが保持するデータ量も研究しました。UTXO は未使用のトランザクション出力で、使うための条件が付いた個々の金額です。Utreexo では、検証ノードがその集合をアキュムレーターと呼ばれる小さな暗号学的要約で表せます。支払いには、使用する出力がその集合に属する証明を添えます。減るのは現在の状態を保持するためのデータです。規則の検証をなくすことでも、ビットコインの全履歴を一つの小さなファイルにすることでもありません。 [4]

Utreexo の証明は検証者まで届けなければなりません。そのため、保存する状態が小さくなる一方で、通信量は増えることがあります。研究要旨は、2019年初めまでのブロックチェーンをダウンロードするシミュレーションを説明しています。有用なデータを一時保存するキャッシュに 500 MB を割り当てると、証明によりダウンロード量が約25%増えました。この 500 MB はノード全体のメモリー要件ではありません。特定の実験結果であり、現在の必要資源を保証する値ではないのです。ディスク、メモリー、通信を合わせて評価する必要があります。 [3]

MIT DCI が公開した回想で、Dryja は MIT での自然な始まりを語っています。コンピューターを持って訪れ、ビットコインについて話し、学生を手伝っていました。すると責任者の Neha Narula に、ここで働かないかと尋ねられたそうです。後には一緒に授業も担当しました。同じ別れの文章で、Bitcoin と Lightning の仕事を続けるため Lightspark に移ると発表しています。これは当時の経歴を記録したもので、現在の勤務先の確認にはなりません。一つの肩書きよりも、論文、コード、説明された発想から彼の貢献を理解できます。 [5]