通貨のためのインターネットアーキテクチャ

この論文はMeher RoyのGoogle Docsから翻訳されたものである。

著者: Meher Roy (著者は HyperLedger の開発者の 1 人で、Quora で見つけることができます)

翻訳・校正：Chu Xia Hu、Shen Zhihui、Chen Hao

導入

サトシ・ナカモトの最大の発明であるビットコインには、2 つの明確な特徴があります。

ビットコインは、基本的な台帳機能も備えた、公開された分散型の暗号化台帳です。
暗号化元帳は新しいビットコインの残高を追跡します。

ビットコインをベースにした並行金融システムが構築されています。暗号化された元帳は柔軟性の面で多くの利点があります。たとえば、マルチ署名アカウント、分散型通貨交換、マシン間取引の新しいアプリケーションなどが開発の原動力となっています。本稿では、現在の金融システムにおける暗号台帳の応用を分析し、以下の内容について議論を進めます。金融機関が公開暗号分散型台帳を使用し、基本的な台帳機能を備えている場合、資産と負債の残高を監視する際に、どのような速度、コスト、柔軟性の利点が得られるのでしょうか。

これらの元帳により、CHAPS や FedWire などのリアルタイム総額決済システム、および ACH、Bacs などの繰延ネット決済システムや、銀行、外国為替市場、証券取引所、その他の金融システムの柱に相当するシステムを構築する新しい方法が可能になります。この記事では、これらの分散要素をレイヤーベースの連続フレームワークに圧縮し、「お金のためのインターネットアーキテクチャ」と呼んでいます。

システムの導入とともに、マネーのインターネットアーキテクチャの認識される利点を列挙します。これらのメリットが招待の動機です。

略語と定義

ACH: 自動決済機関。遅延ネット決済ベースで米国の小売決済プロセスの実行可能性を保証するシステム。
Bacs: 英国で繰延ネットベースの小売決済が実行可能であることを保証するシステム
CHAPS: 英国の高額取引のための基本的なグロス決済ファンド取引システム
コンセンサスプール: 特定のマスターを持つサーバーグループで、フォールトトレラントアルゴリズムを使用して継続的に元帳のコンセンサス状態に到達します。健全なコンセンサスプールには通常、異なる相手方によって制御されるサーバーがあります。
DApp: 分散型アプリケーション
DE: 分散型取引所
DEP: 分散型トランザクションプロトコル（セクション7aで説明）
DNS: 遅延ネット
DNSP: 遅延ネットプロトコル（セクション7dで説明）
FedWire: 米国が高額取引を行うために使用する基本的な総決済資金取引システム
発行者: 暗号化された元帳上で資産を発行する相手方。この相手方は、銀行、企業、分散型匿名機関、政府、または個人である可能性があります。資産には、商品セキュリティトークン、通貨、諜報品、社内株式、航空会社のマイルを表すトークンなどがあります。
元帳契約: セクション 3 と 4 の説明を参照してください。
ODFI: 初期預金金融機関。自動決済ローンを作成する銀行。
OFI: Original Financial Institution (オリジナル金融機関)。FedWire ローンを発行する銀行。
RDFI: 預金受入金融機関、ACH ローンを締結する銀行。
RFI: 受取金融機関、FedWire ローンを締結する銀行。
RTGS: リアルタイム総合決済システム。
GTGSP: 7c で説明されているリアルタイム総合決済システムプロトコル。
SIPS: 重要な支払システム。
SL3P: 静的流動性支払プロセスプロトコル（7bで説明）
Tx: トランザクション

フレーム

OSI レイヤーモデルにヒントを得た通貨インターネットアーキテクチャは、図 1 のようになります。

次のセクションでは、各レイヤーの要件と機能について詳しく説明します。このホワイトペーパーは次のセクションに分かれています。

セクション 4 と 5 では、ビットコインおよびイーサリアムプロジェクトの概念的なアップグレードによってもたらされたイノベーションである元帳プロトコルについて説明します。総勘定元帳プロトコルは、この記事の複数のコンポーネントの基礎となります。セクション 4 のビットコインの説明は、抽象的には正しいものの、現在の実装とは異なっています。
セクション 6、12、および 13 では、総勘定元帳レイヤーについて説明します。第 6 節では全体的な仮定が示され、理由は省略されています。理由と詳細はセクション 12 にあります。13 小節のセクションの目的は 5 小節に書かれています。
7a、7b、7c、および 7d は、DEP、SL3P、RTGSP、および DNSP について説明しています。この段落では、マネーのインターネットの根底にある中核的なイノベーションについて説明します。
セクション 8 では、セクション 7 のプロトコルを 2 つの基本的な元帳操作に統合できることを示します。この組み合わせにより実装が扱いやすくなります。
セクション 9、10、11 では、それぞれターゲット層、プロトコル層、プログラム層について説明します。
第 14 章では、重要な観察事項と開発上の質問を示します。
参考文献はセクション 15 にあり、著者の詳細はセクション 16 にあります。

最後に、付箋の色分けです（この記事は翻訳であり、以下では参照されていません）。

セクションのタイトルには濃い青の太字フォントが使用されます。
セクションの見出しにはスカイブルーの太字フォントが使用されます。
緑の太字フォントは、複数フェーズの支払いおよび交換プロトコルのステージを区別します。
灰色の太字フォントは重要な定義、意見、または段落を示します。
必要に応じて、その他の色と形の規則についてもこの記事で詳しく説明します。

ビットコイン元帳契約

総勘定元帳プロトコルは、価値残高アカウントを追跡するためのプロトコルです。これにより、クライアントは自分のアカウントから X 単位を差し引くと同時に、別のアカウントに X 単位を入金することができます。重要な操作を実行するには、顧客の口座の残高が X を超えている必要があります。図 1 は、シティバンクの 2 人の顧客、アリスとボブを視覚化したものです。アリスが支払いを開始します。

上の図の動作では、ビットコインは元帳プロトコルを通じて富を増加させます。元帳契約は、残高を維持するアカウントが事前に決められたルールに従って動作するための方法です。アリスやボブのようなビットコイン外部のエンティティは、ルールセットが完了するまで、元帳プロトコルを使用して契約を締結することはできません。この実装はプロトコルのルールに違反しているため、Bitcoin ノードによって拒否されます。

たとえば、アリスはビットコインをボブに送金したいのですが、ボブは 2015 年 12 月 31 日以降にのみビットコインを使用できます。これは、ビットコインの一時的な残高を維持する元帳契約を作成することで実現できます。ボブの転送の場合、ビットコインは元帳プロトコルで設定された特定の日付以降にのみ取得できます。図 3 はこのプロセスを示しています。

元帳プロトコルは、アリスとボブの間の送金を仲介する中立的な自動化された第三者と考えることができます。読者は、上記の図は抽象的な概念であり、ビットコイン取引はさまざまな方法で実装できることを知っておく必要があります。

図 4 は 2 番目の注釈を示します。アリスは買い手であり、ボブは売り手です。商品取引には輸送時間が長くなります。トレントはアリスとボブの両方から信頼されている第三者です。このトランザクションでは、アリスは次の条件に従って購入金額を元帳契約に保存します。

資金が移動できないようにするには、3 者のうち 2 者が保証契約に署名する必要があります。
商品が誤って受け取られた場合、アリスとトレントはアリスに返金することができます。
売買は無事完了し、ボブとトレントはボブに代金を渡します。

図 4 は、販売が成功した場合のトランザクションフローを示しています。元帳プロトコルは、アリス、ボブ、トレント間の直接取引関係を仲介する中立的な自動化された第三者のように機能します。

Bitcoin 元帳プロトコルは、「Bitcoin スクリプト」と呼ばれるスタックベースのバイトコード言語でプログラムされています。各元帳プロトコルには、コードとキャッシュデータ構造があります。

Bitcoin プロトコルには 2 つの重要な制限があります。

価値の盲目性: プロトコルは、保管されている資金の合計額よりも低い金額のトランザクションを実行できません。つまり、申請者は検索時間内に一度にすべての資金を引き出さなければなりません。
永続的なストレージ/状態の欠如: プロトコルはデータを保存できないため、アプリケーションユーザーが分散トランザクションを実行できなくなります。

図 5 は、制限を強調する仮想的な状況を示しています。アリスは、元帳プロトコルを使用してビットコインをドージコインに交換したいと考えています。彼女は元帳プロトコルを構築し、取引はビットコインで行われることを規定しました。合意内容は、相手方がアリスのアドレスにDogecoinの支払い証明を提供すると、相手方が指定したアドレスにビットコインが渡されるというものです。

バリューブラインド制限とは、相手方であるボブが、契約でアリスが実際に指定した金額で取引しなければならないことを意味します。相手側は、取引量を少なくすることを希望し、総勘定元帳契約で資金の対応する部分を受け取る場合があります。この操作は、単一の Bitcoin 元帳プロトコルでは不可能です。

いくつかのトランザクションが可能であると仮定すると、ビットコイン元帳プロトコルは、使用可能な支払い資格情報を保存する必要があります。この預金が失われると、相手側は同じ資格情報を繰り返し提供して不正に資金を引き出すことができます。盲点を保存および評価できないため、分散型取引所などのプログラムは制限されます。

ここで挙げた例は、制限事項を強調することのみを目的としています。言及されていない他の欠陥もあります。分散型ビットコイン取引は、別の構造であるアトミッククロスチェーントランザクションでより適切に実装できます。ただし、価値の盲点の制限もあります。

次のセクションでは、ここで説明するプロトコルの基礎を築く Ethereum アプローチに重点を置きます。

イーサリアムを含む元帳契約

Ethereum プロジェクトには多くの革新が含まれていますが、この記事では次の点が重要です。

元帳プロトコルは価値を認識し、永続的なストレージ機能を備えています。
元帳プロトコルは、必要に応じて資金を入金/出金（ロード/アンロード）できます。入出金条件は契約コードによって実装されます。
データを含むメッセージを元帳プロトコルに送信できます。プロトコルはデータを返信し、値を入力に渡すことができます。

セクション 7 では上記の使用方法を説明します。したがって、ここでは例は省略します。その他の Ethereum のイノベーションはここでの議論の副次的なものであり、セクション 12 で説明します。

元帳プロトコルはランダムなデータを入力できます。目的は、投機的なアプリケーションにエントロピーソースを提供することです。
元帳プロトコルを作成するために使用される適応言語はチューリング完全です。
元帳契約により別の元帳契約を作成できます。したがって、アカウントを制御する部外者と同じ権限を持ちます。これは「契約第一級市民財産」を指します

ポイント b と c の間の接続は、Ethereum 台帳をアップグレードするときに無限ループが発生する可能性があることを意味します。停止問題は、任意のスクリプトが有限の時間内に終了するかどうかを推定する制限を提供するか、ネットワークノードがトランザクションを拒否して無限ループが発生するのを防ぎます。プログラムがノードによるトランザクションの拒否を防ぐために無限ループに陥ると、停止問題によってイノベーションに 2 つのリスクが生じます。

無限ループを防ぐための取引手数料アプローチは、いくつかの未知の状況において欠陥があります。
明示的に設計された悪意のあるプロトコルコードは、Ethereum 仮想マシンから逃げ出し、ネットワークノードに損害を与える可能性があります。

セクション 12 では、Ethereum の利点の一部を維持しながら、これらのリスクを軽減する方法について説明します。推進力は、招待実施の潜伏期間中にリスクと複雑さを回避することです。

セクション 6 ～ 10 では、Ethereum 元帳プロトコルの機能の完全なセットが利用可能であると想定しています。

総勘定元帳レイヤー

元帳レイヤーは、単一の当事者または取引相手グループが元帳を構築し、同時に要求に応じて資産を転送できるようにするプロトコルを使用して作成されます。各元帳には、資産発行者、元帳 ID のグループ、および資産発行 ID があります。

総勘定元帳の最小基準は次のとおりです。

元帳を維持するために、各元帳の資産発行者は異なるエンティティである必要があります。
元帳は分散型コンセンサスプロセスによって維持されます。コンセンサスプロセスに参加するノードのセットは、コンセンサスプールと呼ばれます。
元帳アカウントの残高、契約、取引は公開されます。
トランザクションは最初にデジタル署名を使用して作成されます。
マルチ署名アカウントは基本要件です。
すべての元帳には基本的な元帳プロトコル機能が必要です。最小限の機能セットについては、セクション 12 で詳しく説明します。
高速元帳トランザクションは、理想的には 2 秒以内に完全な確認を完了する必要があります。これは、コンセンサスプールノードの ID がわかっている場合に、分散型台帳に対して実行できます。以降の説明でも同様であると想定します。
コンセンサスプールと共同元帳の間には調整メカニズムが存在します。

第 11 節では、上記の特徴の根拠を説明します。 Hyperledger は、台帳を維持するための実用的なビザンチンフォールトトレランスコンセンサスアルゴリズムを確立し、台帳層プロトコルの例でもあります。

Bitcoin および Ethereum プロジェクトでは、ネットワークノードが匿名であると想定されています。ここでは、コンセンサスプールノードの ID が既知であると想定します。これは他の暗号通貨プロジェクトとの主な相違点の 1 つです。とりわけ、金融システムと商品担保通貨、ビットコインのような情報商品、株式、その他の資産との統合を調整することに重点が置かれています。結局のところ、招待システムによって必ずしも新しい通貨や資産が作成されるわけではありません。

図 6 は元帳レイヤーの一部を示しています。同じプロパティタイプを持つ元帳は同じ色になります。色付きの円内の黒い点はアカウントを表します。アカウントに対応する資産の発行者は既知です。発行者の名前は視覚化を容易にするために選択されました。大手銀行や企業は、当然のことながら保守的なゴーストライターであり、ここで説明するテクノロジーの最初のゲストではありません。

キャロルが元帳 4 に資産を持っている場合、キャロルは元帳 4 の発行者と信頼関係にあると想定されます。

アリスの場合、元帳 1 に USD があり、同じ元帳の同じ発行者を持つクライアントであるボブに USD を送金したいと考えています。つまり、元帳内振替は処理が簡単になります。次のセクションでは、元帳内転送について説明します。

支払いおよび取引レイヤー

このレイヤーは、アリスとボブのケースの 2 つのケースを解決するために割り当てられています。

シナリオ 1: アリスは、元帳 1 にシティバンクが発行した V ドルを保有しており、それを元帳 2 のボブの手にある W ユーロに交換したいと考えています。ユーロの発行者はフィドール銀行です。 7aはこの状況を説明しています。
シナリオ 2: アリスは、シティバンクが発行した V ドルを元帳 1 に保有しており、それをボブに支払いたいと考えています。 Bob は Wells Fargo Ledger 2 のゲストです。7b、7c、および 7d は解決策を示しています。

このレイヤーは、4 つのプロトコルの 1 つを実行する役割を果たします。 7a は DEP に関連し、7b は SL3P に関連し、7c は RTGSP に関連し、7d は DNSP に関連します。マイクロトランザクションの支払いについては付録 A に記載されています。

7a.DEP

分散型トランザクションは、トランザクション関係を仲介する 2 つの連動元帳プロトコルとして実装できます。図7a、7b、7c、7dに視覚化を示します。便宜上、2 つの契約を調剤契約と受入契約と呼びます。プロトコルには 4 つのフェーズがあります。アリスがボブに相手方として受け入れてもらうオファーを作成したと仮定します。

フェーズ1: アリスは2つの元帳に公開契約と受諾契約を確立する

図7aはステージ1を表す
アリスは元帳2に受諾契約を、元帳1に公開契約を確立する
合意の公開と承諾の間のリンクは、アリスのトランザクション招待（オファー）を構成します。価格情報は、両方のプロトコルのストレージエントリとして設定されます。
アリスの値Vを公開するためのプロトコル
承諾および解放契約の内容は下図の通りです。

ステージ2: ボブは契約を信じ、出版社に金銭を要求する

図7bはステージ2を視覚化したものである。
ボブは、契約の掲載と承諾が受け入れ可能なオファーを構成し、正しく構成されていることを確認します。
プロトコルが資金を、アリスが資金を引き出すためにフェーズ 3c からの宣言メッセージを必要とする状態で保持することを受け入れます。
ボブは元帳1の現在の出版契約の支払い証明書を提出します

フェーズ3: ボブにお金を貸す契約を公開し、アリスに明細書を送る

図7cはステージ3の状況を示している。
発行プロトコルは、支払い資格情報が以前に使用されていないことを確認しながら、支払い資格情報を検証します。完了したら、V を総勘定元帳 1 の Bob に転送し、支払い資格情報をプロトコルメモリに追加します。
発行契約は、元帳1のアリスに請求メッセージを送信します。アリスは、受信契約から資金を都合よくまたは即座に引き出すことができます。

フェーズ4: アリスは宣言メッセージを使用して受信プロトコルから資金を引き出す

図7dはステージ4を表す
アリスは受信プロトコルにステートメントメッセージを追加する
受信プロトコルはアナウンスメッセージを検証し、アナウンスメッセージが以前に使用されていないことを確認します。
宣言メッセージが有効な場合、受信プロトコルは元帳 2 で Alice に資金をリリースし、宣言メッセージのデータをストレージに追加します。

プロトコルの受信と公開の機能

出版契約は第三者Vが保有し、総勘定元帳2の支払証明書が確認できる必要があります。重複使用を防止するため、使用情報を保存する必要があります。
受信プロトコルは、元帳 1 の請求メッセージを検証できる第三者に W を配置する必要があります。再利用を防ぐために、使用された宣言メッセージをコントラクトメモリに書き込む必要があります。

上記のプロセスでは、トランザクションが自動であること、つまりリリースプロトコルの V が 1 つのトランザクションでのみ宣言されることを前提としています。ボブがフェーズ 2 で取引金額を W より少ない X に変更したい場合、それも可能です。

さらに、考慮すべき 2 つのエッジケースがあります。

1. 未解決残高のあるリリース契約: フェーズ 2 で資産を受入契約に移転する場合、当事者の数に制限がないため、ボブが金銭を要求するときにリリース契約の残高条件を満たさない可能性があります。ボブがお金を失うことを防ぐために、元帳 1 のボブに「取引が拒否されました」というメッセージを送信する追加機能を追加する必要があります。ボブは拒否通知を使用して元帳 2 からお金を引き出すことができます。アリスは拒否通知を受け取らないため、元帳 2 の資産のロックを解除することはできません。
2. アリスがコマンドをキャンセルする: アリスは、公開された契約から資金を引き出したり追加したりする権限を持っている必要があり、コマンドを取り消すこともできます。この機能は、前述のトランザクションフローに統合することはできません。出金による残高不足は、前述の拒否通知で処理できます。

DEP は信頼性が低く P2P ですが、情報サービスプロバイダーが異なる元帳間でトランザクションコマンドを追跡するための市場はまだ存在します。サービスプロバイダーは、コンセンサスプールノードに、総勘定元帳の合意が妥当であることを確認するためのコマンドを提供するように要求できます。参加者は、最新情報を入手するためにサービスプロバイダーに料金を支払います。純粋な情報サービスは、インターネットにおける通貨、つまりコマンドに相当します。

DEP の強みは、異なる取引相手間の通貨および株式取引を仲介する必要がなくなることです。図 8a は、アリスとボブの間の取引相手と株式取引の関係を示しています。図 8b (SEP) を図 8a と比較すると、潜在的な低コスト取引が強調表示されます。通貨取引の場合にも同様の類似点が存在します。

中央保管所と管理者の役割は、公開暗号化台帳に置き換えられます。ブローカーと証券取引所は、総勘定元帳の注文を追跡する情報サービスに置き換えられました。アリスとボブがお互いのリスクを許容できない場合、クリアリングハウスは必要ありません。プロトコルの実行にはボブはわずか 4 秒しかかかりませんでした。

最終的に、DEP は、イーサリアムやビットコインなどの通貨と情報商品の間の橋渡しとして機能します。

7b.SL3P

現在のシステムを進化させた分散型取引所とは異なり、SL3P は新しい支払いプロセスです。

図 9a の状況を想像してください。アリスは、シティバンクが発行した V ドルを元帳 1 に持っていて、それをボブに渡したいと考えています。ボブは、元帳 2 のウェルズファーゴ銀行のゲストです。アリスとボブに関連付けられ、両方の元帳の残高を管理するキャロルという名前の別の取引相手がいます。キャロル：

発行元であるシティグループとウェルズ・ファーゴの2社を信頼してください。
合計金額が一定である限り、2 つの元帳のそれぞれの残高に関して中立を保ちます。
ウェルズ・ファーゴ銀行に500万ドルを超える資産を保有
2つの元帳間ですぐに取引を行う必要はない、つまり彼女の残高は静的流動性である

トランザクションセットに従って、図 9b に示すプロトコルが支払いを解決します。

アリスはキャロルに元帳1のVドルを与える
元帳2でキャロルはボブにVドルを与える

SL3P は、トランザクションロジックを満たす必要がある複数の機能を保証するために、2 つの元帳プロトコルを使用します。

アリスは、キャロルに、元帳 2 でボブに支払うか、元帳 1 でお金が返金されることを保証する元帳契約を送信します。
総勘定元帳契約は維持できます。つまり、Carol が契約を一度作成すると、その契約によってさまざまな相手に自動的に支払いが行われます。
Carol は、静的な現金流動性を確保するために、支払い時に手数料を請求できます。

プロトコルには 4 つのフェーズが必要です。

フェーズ 1: Carol は 2 つの元帳にプロトコルを作成して SL3P チャネルを開きます。

図10aはステージ1を表す
キャロルは、元帳 1 に SL3P プロトコル 1 を作成し、元帳 2 に SL3P プロトコル 2 を作成します。
対称 SL3P プロトコル 1 と SL3P プロトコル 2 の接続は、SL3P チャネルと呼ばれます。プロトコルは各トランザクションの料金をデータエントリとして保存します。
キャロルは現在、プロトコル1の価値がX、プロトコル2の価値がYである。
SL3Pプロトコルの機能は次のとおりです。

ステージ2: アリスはSL3Pプロトコル1を信じ、SL3Pプロトコル2でボブにお金を求める

図10bは第2段階を示している
アリスはボブにVを支払い、SL3Pプロトコル2の残高がVより大きいことを確認したい。そうであれば、次のステップに進む。
アリスはVドルをSL3Pプロトコル1に転送する
SL3P プロトコル 1 は資金を特別な状態で保持します。これらの資金はフェーズ4の後にのみ引き出すことができます。そうしないと、SL3Pプロトコル2はフェーズ3dでボブに資金を提供しません。
アリスは上記の状況の証明を SL3P プロトコル 2 に提供し、元帳 2 上のボブのアカウントへの送金を作成します。

フェーズ3: SL3Pプロトコル2がステートメントを検証し、ボブに送金する

図10cはステージ3を示している
SL3P プロトコル 2 は支払い資格情報を検証し、それが以前に使用されたことがあるかどうかを確認します。検証後、V を Bob に転送し、ステータス変更メッセージを元帳 2 の Carol に送信します。支払い証明データはプロトコルストレージに追加されます。
キャロルは状態変更メッセージを使用して、フェーズ 2c の SL3P プロトコル 1 に資金を保管し、いつでも引き出すことができます。
残高が満たされない場合、プロトコルは「支払い拒否」メッセージを元帳 2 の Alice に送信します。Alice が使用できる限り、SL3P プロトコル 1 からお金を引き出すことができます。
プロトコルでは、ボブは転送が成功したことを確認するだけでよい。

ステージ4: キャロルはステータスメッセージを使ってお金を引き出す

キャロルは以前のSL3Pプロトコル1から状態変更メッセージを取得します。
SL3P プロトコル 1 は状態変更メッセージを検証し、そのメッセージを以前に再利用したメモリに保存し、後で V を Carol が使用できるようにします。
キャロルが後でSL3Pから引き出すことができるお金だけが参加できます。キャロルはステージ 3 を第三者に委任できます。第三者は SL3P プロトコルを監視し、静的な現金流動性への適切な参加を確保します。

SL3Pプロトコルの機能

SL3P プロトコルでは、残高を維持し、支払い資格情報とステータス変更メッセージを検証できる第三者が必要です。すでに使用されている資格情報と学校は、再利用を防ぐためにメモリストレージに保存する必要があります。
残高のない SL3P 支払いの場合、ターゲットプロトコルは発信者に「支払い拒否」メッセージを発行する必要があります。支払い拒否メッセージにより、別のプロトコルが支払いを行うことができます。
SL3P プロトコルでは、キャロルがプロトコルの条件に違反することなく資金を入出金できるようにする必要があります。キャロルの 2 つの契約のバランスが取れ、すべてのお金が引き出され、チャネルは閉鎖されました。

プロトコルの逆転も可能です。 SL3P プロトコルは対称的であるため、Dave は元帳 2 から元帳 1 への支払いを作成できます。

支払いプロセスは P2P モデルに変更され、競争的な市場の基盤が提供されました。このプロトコルは 2 つの転送プロトコル計算を連結したものなので、4 秒以内に完了できます。

対応する国内銀行は、2 つのアクセス発行者の 1 つである Carol として視覚化できます。たとえば、元帳 1 の発行者が発行者 1 であるとします。発行者1がSL3Pチャネル元帳2に預金を開くと、対応する国内銀行関係が確立されます。読者は、国内の対応銀行が時代錯誤の解決を絶えず加速していることを思い出すことができるはずだ。

SL3P では、発行者が支払いプロセスにおける信頼リスクを負わないため、繰延ネット決済が改善されます。延ネット決済における信頼リスクを軽減するために、発行者は決済機関に担保を提供する必要があります。 SL3P は、これは必要ないと主張しています。

もう一つの重要な利点は、支払い処理のための新しい流動性プールの作成です。流動性コストは、RTGS 支払いの価格設定において決定的な要素となります。現在のシステムの中心的な前提は、支払いプロセスにおける流動性要件は発行者によって提供されるということです。 SL3P はこの前提を打ち破り、より大きな流動性プールを構築することで、より手頃な支払いを実現できます。

7C.リアルタイム総合決済プロトコル (RTGSP)

SL3P と同様に、RTGSP は次の問題を解決します。アリスは元帳 1 にシティバンクからの V ドルを持っており、このドルをボブに転送したいと考えています。ボブは、Ledger 2 の Wells Fargo Bank のゲストです。

RTGSP と、米国で高額送金に使用されている FedWire システムは、招待制の合意に達しました。これにより、関係する発行者は、FR 元帳の支払いから内部銀行に負債口座を設定できます。図 11 は FedWire トランザクションフローを示しています。

Alice は、Citibank を OFI、Wells Fargo を RFI として FedWire ローンを作成します。シティバンクはアリスの口座から直ちに引き落とし、ウェルズ・ファーゴは数分後にボブの口座を確認します。

社内的には、シティバンクが FR に融資要請を提出し、それがウェルズ・ファーゴ銀行に渡されました。 FR は決済取引を実行し、FR の総勘定元帳でシティバンクからウェルズファーゴに資金を振り替えます。取引が実際に行われると、決済金額が送金されます。これは、リアルタイムグロス決済 (RTGS) と呼ばれる支払いプロセスの形式です。シティバンクとウェルズファーゴ銀行には信用リスクがないと仮定します。

この点についてさらに詳しく説明すると、シティバンクを発行者 1、ウェルズ・ファーゴを発行者 2 と見なします。目標は、シティバンク、ウェルズ・ファーゴ、FR を暗号台帳として使用するプロトコルを実証することです。

SL3P は、図 12 に示すようなパスを提供します。発行者は、FR 元帳と追跡プロパティ元帳の間に一方向の SL3P チャネルを開きます。図 12 に、発行者 2 によって管理される SL3P チャネルを示します。元帳 2 では、発行者 2 がチャネルの一端に資産と負債を作成します。濃いピンクでマークされています。

一方向 SL3P チャネルとは、支払い方向が一方向となる改良構造を指します。セクション 7b では、これは簡単に修正できます。

アリスは、V をパブリッシャー 1 に転送するトランザクションを作成します。トランザクションには、最終元帳とボブのアカウントを記述するデータが含まれています。これにより、アリスは事実上、発行者 1 によって発行されたプロパティを保持していることになります。

シティバンクに必要な流動性があると仮定すると、シティバンクは V を FR 元帳の発行者 2 によって管理されている SL3P プロトコルに転送します。次に、元帳 2 の相手方に支払い伝票を渡し、ボブの口座に送金を発行します。

十分なプロトコル残高があると仮定すると、Ledger 2 SL3P プロトコルは支払いバウチャーを検証して転送を完了します。パブリッシャー 2 は、RTGSP 転送を継続するために、定期的に資金をプロトコルにダウンロードします。合意残高に達しない場合、パブリッシャー 1 は再試行するか、チャネルの反対側からプロパティを取り戻すことができます。

RTGSP は実現可能であることが証明されていますが、RTGS システムの中心的な課題である流動性管理には対処していません。この問題については付録 B で説明します。

RTGSP は、FedWire およびその他の総決済システムの自動化を保証します。 FR の役割は、純粋な出版社としての役割に限定されています。 FR 元帳コンセンサスプールに到達できる限り、システムは動作します。現在、米国の FedWire システムの機能は、東部標準時の午前 9 時から午後 6 時までに制限されています。

FR 元帳と RTGS システムの分散化は、高品質な運用リスク管理とビジネス持続可能性ポリシーとして機能します。ノードは地理的に分散化できるため、さまざまな運動システムを互いに独立させ、データのバックアップを確立できます。全体として、システム上重要な決済システムはすべて、運用リスク管理の面で分散化から明らかに恩恵を受けています。

7D.繰延ネット決済契約（DNSP）

DNSP は、SL3P や RTGSP と同じ問題を解決します。アリスはシティバンクの元帳 1 に V ドルを持っており、そのお金をボブに送金したいと考えています。ボブは、Ledger 2 の Wells Fargo Bank のゲストです。

RTGSP のような決済ではなく、決済は FR 元帳上の振替として行われます。 DNSP は最終的に、シティからウォルマートへの負債を生み出します。複数の債務を集約することができます。両当事者が FR 元帳に同意する限り、純額は出版社間で転送されます。支払い決済は出版社間の債務関係の作成であり、支払い関係は FR 元帳上で転送されます。 DNSP は支払いが完了するまで支払いを延期します。プロトコルでは、発行者間の相互信頼が必要です。

DEP、SL3P、RTGSP 間の接続により、銀行取引の大部分を処理できます。完全性を保つために DNSP もカバーされています。米国のACHシステムに相当します。

Ryan Fugger と Ripple プロジェクトが主導するトラバーサルトランザクションが DNSP の中心を形成します。水平型元帳は、これまで考えられていた以上の機能を備えた水平型トランザクションを可能にします。

アカウントは他のアカウントと信頼できる接続を確立できます。信頼できる関連付けは、コンセンサスプール内のアカウント所有者の承認であり、プールは信頼できる関連付けで指定された値と当事者に従ってアカウント残高を変更できます。
コンセンサスプールは、信頼接続によって設定された制約に従って、あるアカウントから別のアカウントへの支払いを他のアカウントの残高に変換できます。

図 13 は、Eve、Frank、Gary、Harry の 4 人の参加者がいる USD 水平元帳を示しています。図 13a の左側は信頼接続を示しています。フランクからイブへの一言は百万ドルの価値がある。フランクは、イブが彼にMドル以下の負担を負わないことに同意していることを示しています。参加者は、信頼関係を動的に変更できます。

図13Bの右側は、イブとハリーの間のWドルの水平トランザクションの支払いを示しています。支払い前に、参加者は誰もお互いに負債を持っていないと想定しています。取引の後、イブはフランクWドルを負っており、フランクはゲイリーWドルを負っており、ゲイリーはハリーWドルを負っています。 KazakhsはこのWドルの支払いを受け入れました。

各アカウントの正味残高は、参加者が保有する負債を差し引いた請求に等しくなります。フランクとゲイリーのネットバランスは、取引後も変わらないままです。ゲイリーとフランクは、取引に積極的に関与していませんでした。ハリーの役割は、支払いを確認することです。

総勘定元帳にはより多くの参加者がいる可能性があるためです。コンセンサスプールテクノロジーの最適な支払いパスは、13Bの赤い矢印で表され、バランスは自動的に調整されます。

DNSPの場合、国内の水平方向の元帳の一部として複数の出版社を想定しています。水平方向の元帳は支払いおよび決済メカニズムになり、2つの出版社間で信頼関係が交渉されます。 DNSPには2つのフェーズがあり、図14aと14bに示されています。

フェーズ1：アリスが支払いを作成し、出版社1にパブリッシャー2プロパティを与えます

出版社は、元帳でサードパーティの契約を作成し、資産を追跡し、契約に資産をダウンロードします。第三者と契約する能力については、後で説明します。
Alice Vは、元帳1の出版社に富を出版社に転送します。トランザクションには、最終的な台帳とボブのメタデータアドレスが含まれています。
パブリッシャー1およびパブリッシャー2は、国内のクリアリング元帳でWの価値がある水平トランザクションを作成します。 WはVよりも小さく、0ドルから5ドルです。
パブリッシャー1は、総勘定元帳2のサードパーティプロトコルに上記の支払い証明を提供し、Vにプロトコルを要求することを要求します
第三者契約は支払い証明書を検証し、次のステップは証明書が正しいと仮定します
V以上のファンドがある場合、時間0とTの間にVにVに転送されます。パブリッシャー1がフェーズ2を完了すると、VはBOBにのみ転送できます。 Tは約1分です。
プロトコルが資金の譲渡を完了しない場合、WをBOBに転送し、「予約拒否」メッセージを出版社に送信します2。

フェーズ2：パブリッシャー1は、プロパティ（VW）をクリアリング元帳に転送し、ボブに支払うように依頼します

予約が成功したと仮定すると、パブリッシャー1はクリアリングアカウントから出版社へのお金（VW）を転送します2
パブリッシャー1は、Ledger 2のサードパーティプロトコルに支払いバウチャーを提供し、VをVに尋ねます
サードパーティの契約は、支払い券を検証し、正しい場合は、留置された資金をLedger 2のBOBに転送します。
パブリッシャー1がTIME T内でフェーズ2を完了できない場合、出版社1はボブWへの転送をリクエストできます。この場合、サードパーティはペナルティXを開始できます（x <w）

現在の状態では、DNSPには欠陥があります。フェーズ1では、サードパーティのプロトコルが使い果たされ、資産がWよりも少ない可能性があります。これにより、パブリッシャー1がWの損失を被ります。

危険にさらされている資産の量は低いです。 Wは約5ドルで、物理的な支払いシステムと比較して少量です。
サードパーティのプロトコルがなくなると、Ledger 2のすべてのDNSP支払いが停止し、Ledger 2が公開されるため、問題はエスカレートします。 Publisher 2の評判は、DNSPがダウンしている期間中に苦しみます。

DNSPを控除する出版社間の債務関係は、相互の同意後にFR元帳に確立されます。クリアリングは、FR Ledgerの2人の発行者間の単なる転送であるため、注釈はありません。

DNSPはクリアリングと決済プロセスを分離し、BOBへの速い転送（10秒未満）になります。米国のACHや英国のBACなどの多くの現在のシステムは、1日に1回だけ移動し、沈殿します。したがって、DNSPは改善を達成できます。さらに、クリアリング元帳のトラストリンク設計により、現在の2層配置の中央制御メンバーシステムが削除されます。出版社は、他の出版社との信頼関係を確保する限り、清算に参加できます。

対称的な体系的に重要な支払いシステムの場合、分散化されたクリアリング元帳は運用リスクを軽減し、ビジネスの継続性を確保する手段です。

ジョイント

前のセクションでは、プロトコルの各機能について詳しく説明しましたが、これは実装の点で少しイライラしていました。これらの明らかな複雑さは、実際のシステムの相互作用から生じます。これは、シンプルでエレガントなレベルの実装にも削減できます。

重要な観察は、DEPとRTGSPを活用する元帳プロトコルがSL3Pの派生物であることです。図15は、この結論を示しています。

上記の議論では、おそらく課題は、公開および受信プロトコルがSL3Pプロトコルの派生物であることを視覚化することです。 7bを参照して、アリスをキャロルに置き換えてください。アリスとボブをボブに置き換えます。さらに、元帳が単一の通貨のみを処理する代わりに、異なる通貨を処理します。これらの交換に続くトランザクションプロセスは、金銭的な取引です。

著者の情報はそれらを区別するのに役立ちますが、さまざまな名前でプロトコルを参照するのを止めることができます。

拡張（パスファンディング）レベル

拡張レベルでは、上記のプロトコルは自動的に5つのカテゴリに分類されると見なされます。

2つのアカウント間のプロパティの直接転送。実行時間が2秒未満であると仮定します。
DEPを介して異なるまたは同じ資産クラスを追跡する2つの元帳。実行時間が4秒未満であると仮定します。
SL3Pを介して同じ通貨を追跡する2つの元帳。実行時間が4秒未満であると仮定します。
RTGSPを介して同じ通貨を追跡する2つの元帳。実行時間が6秒未満であると仮定します。
DNSPを介して同じ通貨を追跡する2つの元帳。実行時間が10秒未満であると仮定します。

1つの暗号化された元帳から発信され、別の台帳で終わるグローバルな支払い、送金、資産の取得、またはトランザクションは、自動操作のために上記の5つのカテゴリに分けることができます。拡張レベルでのタスクは、自動化された操作の最適なセットを解決して、必要なプロパティ転送またはトランザクションを実行することです。

Small World Networkの知人ソーシャルネットワーク、短距離デュアルノードで接続されています。証拠なしに、金融のインターネットは小さな世界のネットワークでもあると仮定します。実際には、これは、グローバルな財務転送/取引を5〜7以下の自動操作で実行できることを意味します。 1分の世界最長の世界的な移転は、そのようなつながりの下で受け入れられるようです。

拡張アルゴリズムの生データは次のとおりです。

異なる元帳のリアルタイムDEPデータベース
元帳間で動作するSL3Pチャネルのセット
グローバルに認識されているRTGSPネットワークのセット
RTGSPネットワークに参加している出版社のいくつかのグループ
グローバルに認識されているDNSPネットワークのセット
DNSPネットワークで視聴者を引き付けるパブリッシャー
自動化された手順を実行するためのコスト関数データの金銭的コスト

RIP、OSPF、BGPなどのルーティングプロトコルを使用して、インターネットにも同様の課題が存在します。インターネットを通る通信パスでは、到達可能な情報を継続的にブロードキャストするためにルーターとノードが必要です。複数のルート/ノードにわたる準分布アルゴリズムは視覚的です。

通貨インターネットでは、集中サービスのパス要件を送信でき、受信した最適なパスは合理的です。データの収集と計算は、これらのサービスプロバイダーにアウトソーシングされ、顧客のワークロードを減らします。実際の計算最適パスフォースアルゴリズムは、議論のために将来の記事に任されます。

顧客が最適なパスを取得すると、パスはグローバルバリュー転送とトランザクションの自動操作を実行します。

図15は拡張を示しています。アリスは米国の総勘定元帳にスイスフランの資産を持っており、Appleでエクイティを購入したいと考えています。彼女はサーバーを拡張するためのパス要件を開始しました。拡張サーバーには、さまざまな一般的な元帳のRTGSPネットワークデータベース、DNSPネットワーク、およびプロトコルがあります。アリスの数を含む3つのオプションのパスを評価します。アリスの最適なパスを指摘し、支払いと取引手数料を説明します。

Aliceの顧客には、自動操作を必要とするアクションを実行するプロトコルソフトウェアがあります。彼女はまた、このように望んでいた公平性を得ました。

プロトコル層

プロトコル層により、相互価値と任意のコードが実行され、値のバランスが変更されます。これは、CodiusとGavin Andresenを実装するプログラム可能なOrclesプロジェクトを通じて達成できます。

プロトコル層の利点は、より低いレベルを単一のグローバル元帳にすることです。この抽象的な総勘定元帳は、1分以内にバランスを保ち、プロパティを移転できます。

エンティティの特別なグループによって管理されたファンドは、Nの複数の署名アカウントになります。プロトコルコードは、同時に各エンティティに送信されます。契約機関が契約にメッセージを送信したいたびに、彼らはオラクルにメッセージを与えます。仲裁はコードを実行して、参加者のバランスを計算します。エンコーディングが契約の執行が指定された住所に資金を引き出すために執行を引き起こす場合、仲裁サイクルは資金と標識を転送します。ファンドの転送は、通貨のインターネットの下層によって処理されます。図17は、このプロトコル層を示しています。

セクション12では、総勘定元帳層とプロトコル層の違いを定量化します。一般に、総勘定元帳プロトコルは、支払いおよびトランザクションプロトコルの構築に使用されます。その他のユースケースインテリジェントプロトコルは、プロトコル層に実装されています。

たとえば、ロンドンのブリュットには、アリスとボブの間に原油先物契約があります。プロトコルはコンピューターコードで表され、仲裁が実行されます。実行エンティティは、アリスとボブの外部データを取得して、決済時の新しいバランスを計算します。エンコーディングが実行された後、アリスとボブのバランスは低い通貨インターネットレイヤーを介して再び到達します。

もう1つの例は、図4で見ることができるプロの買い手と売り手の調停です。アリスは買い手であり、ボブは売り手です。彼らは、配達が成功した時間に基づいて支払い額を定義したいと考えています。ボブは長期配達の場合に罰金を支払います。アリスは、契約が確立された後、預金を支払います。契約のサービスは商品の配達を検証し、それに応じてボブを支払います。

3番目の例は、デジタル資産オークションです。オークションのルールを実施する契約を確立します。デジタル資産の所有者がプロジェクト仲裁に配信された場合、規則が施行されます。

アプリケーション層

TCP-IPプロトコルグループと同様に、このレイヤーにはアプリケーションとユーザー間の通信が含まれます。特に、以下のコンテンツはビジネスで特に重要です。

デビットおよびローンベースの支払いネットワーク

通貨インターネットは予見可能ですが、同時にバリュー転送の速度をグローバルに上げますが、一部のユースケースでは、ビザやマスターカードなどの支払いネットワークが必要です。次の場合があります。

転送認証には、店舗の購入などのバーストが必要です。
複数の自動転送とトランザクションの運用要件により、複数回使用するために独自の秘密キーが必要になります。支払いネットワークには追加のセキュリティがあります。
支払いネットワークは、買い手と売り手の間の仲裁を促進します。

支払いネットワークは、決済リスクを効果的に減らすことができます。テクノロジーを通じて支払いとトランザクションの時間を短縮します。 Visaの和解額は、2013年9月30日に5380万米ドルであると報告されました。

最終的に、プロトコル層は、ダブルデポジットエスクローなどのいくつかの新しい仲裁方法を実行可能にすることができます。

先物、オプション、デリバティブ、予測、その他の市場

この記事のコア概念の1つは、分類原則です。各通貨インターネットの特性は、異なるエンティティで動作します。たとえば、コンセンサスプールは総勘定元帳によって維持され、銀行は資産の発行とコンプライアンスを行い、拡張サービスは拡張によって行われ、他の企業は契約申請を行います。

合意とアプリケーション層は、先物、オプション、デリバティブ、および仲裁市場の開発を保証します。さまざまなサービスが市場をセグメント化できます。

スマートプロトコルに関するハザードのゲーム

例として、このゲームは次のルールを含むプロトコルとして見ることができます。

ルーレットホイールの回転は、エントロピーのモデルソースです
一般化されたエントロピーの入力は、参加者のバランスの変化として使用されます。
値の転送とトランザクションは、低通貨インターネットレイヤーを介して実行されます

証拠はないと主張しているため、Pokerを含むゲーム、Blackjackはスマートプロトコルで実装されています。

分散型アプリケーション

抽象的な総勘定元帳は、履歴書の分散化された適用の強力な礎石です。現在、新しいゴーストライターは、分散型ストレージ、メッシュネットワーク、評判システムなど、サービスに連絡するときに構築されています。通貨インターネットは、トークンを構築する方法を提供します。例えば。ハードディスクスペースを共有するDAPPは、付録Cに記載されています。

総勘定元帳を見てください

このサブセクションは、いくつかの問題について考えることにより、総勘定元帳の最小要件をよりよく理解します（サブセクション6）。

なぜ総勘定元帳を開発者に制御できないのですか？

支払いおよびトランザクションプロトコルは、開発者以外のエンティティが元帳上のトランザクションを実行できるように構築されています。たとえば、RTGSP：Publisher 1は総勘定元帳でBobに支払いを送信します。出版社2は参加しません。ここで、パブリッシャー2サーバーがコンセンサスプールの唯一のノードであると仮定します。

パブリッシャー2は、パブリッシャー1がボブへの支払いを完了したことがないと主張して、過去の記録に同意しない新しい総勘定元帳履歴を作成できます。 AliceとPublisher 1が古い歴史の時間を取得できない場合、新しい歴史をうまく議論することはできません。法的費用は、議論するときに予想よりも大きくなります。

仮説的な解決策は、分散型コンセンサスプロセスを通じて元帳を維持することです。地方分権化を通じて、出版社と顧客は総勘定元帳の公平性を確保することができます。したがって：

分散型サービスは、総勘定元帳の公平性と信頼を向上させることができます。コンセンサスプールに関与するノードがより多様であればあるほど、公平性の保証が強くなります。

固有の地方分権を比較検討することは効果的です。ノードは、プロセスを証明し、コンセンサスに達するために互いに通信する必要があります。このブロードバンド博士とコンピューティングは、同じ集中元帳よりも優れています。

地方分権化のための分散化は、主張される戦略です。この記事の見解は次のとおりです。

特定のユースケースの分散レベルは最適性の問題です

妥当性に影響を与える要因は、投資ノードの各NPVドルのトランザクション処理として定義されています。

コンセンサスプロセスの選択
ノードIDの仮定。ノードのアイデンティティがわかっていると、妥当性は劇的に増加します。ビットコインノードは匿名であり、ネットワークは毎年コンセンサスを維持するために高コストである0〜5億ドルになります。
ノード量。一般に、コンセンサスプールが大きいほど、有効性は低くなります。

総勘定元帳への公正な信念に影響を与える要因：

コンセンサスプールの構成。 Googleのような評判の良い会社がプールにノードを持っている場合、プールの自信が促進されます。すべてのGoogleノードの悪意のある行動は、市場の評判を損なうでしょう。 Googleの善意は、人生で数百万ドルの価値があるかもしれません。
コンセンサスプロセスの選択。たとえば、実際のビザンチンの断層トレランスは、プール内の悪意のあるノードの最大33％に対応できます。
コンセンサスプールでノードを制御するさまざまなエンティティの数。量が高いほど、信頼性が高くなります。

総勘定元帳の信頼性は、リスクの価値に基づいています。提唱される戦略は次のとおりです。

目標は、資産のバランスを危険にさらしているか、総勘定元帳を有効かつ信頼できるものに保つことです。

たとえば、均質なプールが高いほど、2つの食料品チェーンの忠実なポイントを追跡する可能性があります。シティバンクの総勘定元帳は、高い信頼/分散化の恩恵を受けます。

最適な総勘定元帳プロトコル

各ユースケースには異なる最適なプール構成とノードカウントがあるため、総台帳プロトコルは非常に柔軟である必要があります。契約、発展、開発の使用に制限はありません。コンセンサスプロセスは、部門間の状況で最良の効果をもたらす必要があります。

Hyper Ledgerプロジェクトは、この方向の先駆者です。うまくいけば、他のシステムの目標とのプロジェクトがフォローアップされていることを願っています。

なぜ総勘定元帳が公開されているのですか？

ここで説明したすべての支払いおよび取引契約は、公共台帳に基づいています。相手は、招待状を表示したり、民間総勘定元帳の支払いを確認したりすることはできません。

アプリケーションが価値を想定している場合、バランスの取れたプライバシーは、開発する必要があるテクノロジーを強化します。同様に、支払いには金融取引の監視が必要です。金融プライバシーを確保するためのコストが、分散型取引などのアプリケーションからの顧客による利益を超えない場合、通貨インターネットへの投資を見ることができます。

プライバシーの問題が解決されると、著者は、潜在的なグローバルトランザクションデータ収集の開示によってもたらされた経済理論と危機管理の改善の興奮を表明しました。

マルチ署名アカウントについて

顧客セキュリティの強化に加えて、マルチシグネチャアカウントには信頼できる実行も必要です。スマートプロトコルを検証する必要がありますが、複数の異なるプロジェクト仲裁が複数の差別化されたプロジェクト仲裁プールによって実行されます。

コンセンサスプールの時間配置メカニズムについて

時間配置メカニズムは、プールノードの時間校正の方法を提供します。優れたデザインは、効果的な最小構成を構築することから生まれます。このホワイトペーパーは、DNSPとMTXP（付録A）が時間ベースのトランザクションを利用しています。時間配置メカニズムを削除し、機能を保存する方法を発見する必要があります。

新進段階のリスクと複雑さを軽減します

意見と未解決の問題

暗号化された元帳の基本的な利点

この記事では、暗号化プロトコルの構築が暗号化された総勘定元帳を利用しているため、参加している出版社とゲストとの間の低信頼財務関係を確立することを前提としています。信頼関係が低いと、取引コストを削減でき、ゲストの純利益です。

スケーラビリティ分析とプルベースの支払い

電子署名を使用すると、すべての暗号化された総勘定元帳システムがプッシュベースになります。 ACHの現在の実装により、プルベースのACHデビットを実施できます。これには、保険の支払い、融資分割払い、公共施設の支払いなどの複数のアプリケーションがあります。

これらのアプリケーションは、メカニズムに依存するプロトコル/アプリケーションレイヤーに基づいて構築できます。アリスがボブのゲストであるとき、ユーティリティがあります。アリスとボブは、相互に信頼できる仲裁が保持しているスマートプロトコルを確立します。アリスは、毎月の使用として契約を支払いに注入します。この契約には、ボブが毎月お金を引き出すことができる条約が含まれています。

ID認証と匿名レイヤーの実装

ルールに従うことも問題を引き起こします。公開鍵の背後にあるアイデンティティは、組織（発行者など）によって接続されて、汚染分析などのいくつかの問題に抵抗する必要があります。発行者と総勘定元帳を検証する方法もあります。

参照

https://bitcoin.org/bitcoin.pdf
https://en.bitcoin.it/wiki/スクリプト
20〜28ページ、TCP-IPプロトコルスタック、第4版、Beloz A. Forouzan
http://hyperledger.com/
https://www.regaltek.com/docs/understanding-ach-network.pdf
https://github.com/tiernolan/bips/blob/bip4x/bip-atom.mediawiki
https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki
http://gendal.wordpress.com/2014/01/05/a-simple-explanation-of-how-shares-move-around-the Securities-setlement-system/
Page 323-374、TCP-IPプロトコルスタック、第4版、Beloz A. Forouzan
https://github.com/codius/codius/wiki/smart-oracles:- a-simple、powerful-approach-to-smart contracts
http://gavintech.blogspot.ch/2014/06/bit-thereum.html
http://www.sec.gov/archives/edgar/data/1403161/000140316113000011/r19.htm
http://bithalo.org/wp-content/uploads/2014/06/whitepaper_twosided.pdf
https://www.ethereum.org/pdfs/ethereumwhitepaper.pdf