この記事で学べること

分散型台帳ネットワーク間のクロスチェーンの相互運用に関する考察：EthereumとCordaを比較

目次

• 序論と要約
• 序文：合意・信頼・証明
• 事例紹介1：IBCにおけるコンセンサス・トランスクリプト
• Proof of Stake ネットワークにおけるコンセンサスの証明
• 事例紹介2：プライベートネットワークCordaにおける結果の証明
• エゴとアルターエゴ
• 考察と結論

序論と要約

この記事では、分散型台帳ネットワーク間の相互運用における基礎的な疑問について論じていきます。序文の後に、信頼できる相互運用を実現する中核メカニズムとして、ネットワークでの「行動の証明」の構築と別のネットワークでの検証方法について、2つの事例研究を詳しく解説します。プライベートブロックチェーンであり、パーミッション型ネットワークであるCordaの事例と、パブリックブロックチェーンであるEthereumの事例を対比させていきます。この2つの事例を対比させることは、CordaとEthereumのネットワーク間で信頼性の高いアセット・スワップ・メカニズムを実証することを目的としたHarmoniaプロジェクトの重要な要素に当たります。この記事の難易度やトレードオフは非常に緻密であり、事例紹介の議論はかなり技術的ですが、記事の最後にある程度の一般的な見解と結論が示されております。

ここでの主張は検証を信頼なしで行うことを目指し、リモートネットワーク上でのイベントが発生したという「証明」だけに頼ることは、時として現実的ではないということです。それを実現しようとする試みは、情報の出所や正確さについての証明ができない前提を隠しながら、暗号技術に基づく証拠を積み重ねる「見せかけの検証プロセス」が生じるかもしれません。代わりに、ネットワーク内の知識を評価する際には、「信頼できる情報源による証明」を利用して、どこに信頼を置くかを慎重かつ明確に考えることが望ましいかもしれません。

序文：合意・信頼・証明

分散型台帳は確実に発生したことを共有する記録として考えるのが有効です。何かが確実に発生したということは、関係する当事者間での拘束力のある合意があることを意味します。これは、合意に基づいた現実を生み出し、維持する共同作業です。

分散型台帳に記録された事実は、外部から直接確認することは通常不可能です。例えば、ある人が特定額のトークンを保有していると台帳に記録されていても、現実世界との相関関係が不明確な場合があります。しかし、トークンの発行や移転が合意に基づいて記録されているため、その記録内容を事実として受け入れることができます。例えば、トークンを発行する権限があるAがBに1000トークンを渡し、Bはそのうち500をCに、Cはさらに200をDに渡したので、Cは300トークンを持っていることになります。

現実世界の事実は、信頼できる情報源による証明のような形で台帳に記入されることがあります。例えば、1000トークンが実際にどこかの金庫に保管されている金によって裏打ちされている場合、その事実はそれを証明する信頼できる人々のデジタル署名で台帳に記されます。これらの人々が信頼される理由は、彼らが保証する内容に対して現実世界で実際に責任を持っているからです。例を挙げると、カストディアンが現実の資産を保管しているとデジタル署名にサインした場合、カストディアンは合意された条件が満たされた場合その資産を手放す義務があり、もし手放せなくなったら金銭的な損害や信用の失墜といったペナルティを受けることになる法的なContractがあるかもしれません。

分散型台帳技術のコンセンサスは、台帳の特性が暗号技術や他の確率的手段の組み合わせによって証明可能であるように設計されています。「確率的」とは、「もしXが起こるなら、Yが起こらない確率は極めて低い」として、「Xが起これば必ずYが起こる」と同等に扱うことを意味します。暗号学的証明についても確率的な側面があります。例えば、「十分な暗号強度のハッシュの元データを生成された場合、それは誰かが元データを推測したり計算したりしたのではなく、元々そのハッシュを作った当事者（またはその当事者から元データを開示された）から開示されたものである可能性が極めて高い」と考えるのが一般的です。暗号学方式が破られることがあると（時々起こることですが）、それに基づく証明はもはや証明として機能しなくなります。

時には、Proof of Stakeのコンセンサスのように、「極めて低い確率」というものには厳密な計算による数値的確率だけではなく、社会的・経済的要素が含まれることもあります。トランザクションブロックを最終決定するのに十分なステークを持つバリデータが全員で虚偽報告をする可能性はありますが、自身のステークを失うリスクや大規模な偽造の調整の難しさから、正直な行動を不正な行動よりもはるかに強く促進するようになっています。インセンティブに関するゲーム理論的な考え方は、パブリック・ブロックチェーン技術の設計の根幹であり、「絶対に起こらない」と「起こり得ない」を同等に扱うことに依存しています。

事例紹介1：IBCにおけるコンセンサス・トランスクリプト

IBC（Inter-Blockchain Communication）の仕様において、「コンセンサス・トランスクリプト」という新しい概念が紹介されています。これは、異なるブロックチェーンネットワーク間で信頼性のあるメッセージ伝達を行うプロトコルで、一方のネットワークの台帳に記録された確かな特性を監視し、その特性に関する検証可能な証拠をリレイヤー（中継者）が他方のネットワークに伝えることで実現します。これらの証明には「結果の証明」と「コンセンサスの証明」の二つの要素があります。「結果の証明」とは、トランザクションが最終的に承認されれば、発生元のネットワーク上で具体的な出来事が起こったことを示すものです。例えば、「トランザクションXにより、アドレスAからアドレスBへ100トークンが移動した」という事象の証明です。「コンセンサスの証明」とは、その結果が「確実に起こった」という意味で、発生元ネットワークが該当トランザクションについて合意に達したことを証明します。コンセンサス・トランスクリプトは、ソースネットワークのコンセンサスプロセスの要約であり、ネットワーク外の検証が合意に達したことを納得させるのに十分な情報を提供します。

Ethereumネットワーク上で、IBCにおける「結果の証明」はある値がコントラクトのストレージ内に存在し、その値が特定のIBCメッセージにコミットされていることを証明することによって達成されます。コントラクトのストレージへの変更は、各トランザクションの一部として記録されるため、関連の値がストレージに書き込まれ、そのトランザクションが特定のトランザクションブロックに含まれていることを証明できれば、そのブロックがその値を実現したことを証明できることになります。これらは全て、ハッシュとMerkle pathを用いて示すことができます。

HarmoniaのCordaクライアントが採用している別の方法では、トランザクションのイベントログのスクリプトを使用します。これらは、各ブロックのトランザクション・レシート・トライに保存されているトランザクション・レシートに記録されています。基本的には同じ手法が適用されますが、イベントログのスクリプトはコミットメント値としてではなく、明確な形で保存されます。これに対して、IBCのアプローチでは、IBCメッセージがソースネットワークには不透明なまま、ターゲットチェーンによって検証されることを可能にします。

コンセンサスの証明は、「Light consensus client (Ethereumのクライアントの一種)」（つまり、コンセンサスを観察はできるが、必ずしもそれを確立するために参加するわけではないクライアント）をソースチェーンに設置し、ソースチェーン上で合意に達するために必要な手順が踏まれたことを示す「容易に検証可能なコンセンサス・トランスクリプト」を構築することによって達成されます。例えば、Proof-of-Authorityによってコンセンサスに達したネットワークでは、トランザクションブロックのルートハッシュに対する固定されたバリデータプールの定数の署名を集めるかもしれません。この場合、スクリプトを検証可能にするためには、受信チェーンは関連のバリデータのIDを知り、トランザクションブロックが最終決定された証拠として彼らの署名を信頼する必要があります。

ここでは、既に二つのチェーン間にある程度の連携があります：一方のチェーンは、他方でコンセンサスの仲裁者として機能する権限を持つ者について何かを知っておく必要があります。さらに、それらの権威を信頼する根拠は何でしょうか？彼らは、受信チェーン上の関係者に対して、有効で最終確定したトランザクションブロックにのみ署名するという法的責任を負うのでしょうか？受信チェーン上の当事者は、彼らがソースチェーンのバリデータとして既に信頼されているという理由で信頼しているかもしれませんし、重要なのはそのチェーン上で合意が形成されたという事実です。しかし、技術的には、ソースチェーンのバリデータが共謀して偽のコンセンサス・トランスクリプト（つまり、偽のトランザクションブロックに署名すること）を作り上げ、リモートのチェーン上の誰かを欺く目的で、同時にソースチェーン上の仲間には真実の情報を提供することを防ぐものはありません。Light consensus clientは、ソースネットワークの見解を確認するためにそれらの仲間に問い合わせ、それがスクリプトと一致していることを確認するかもしれませんが、その場合Light consensus client自体も信頼の範囲に含める必要があります。

Proof of Stake ネットワークにおけるコンセンサスの証明

Proof of Stake を採用しているEthereumネットワークの場合、事情はかなり複雑です。潜在的なバリデータのプールは非常に大きく（50万以上）、署名アドレスが本当にバリデータのアドレスであるかどうかは、一定量のETHをステークしているかによって決まります。これは台帳自体を参照して初めて確認できる事実になります。トランザクションの最終確定は、ランダムに選ばれたバリデータコミッティがそのトランザクションを含むブロックチェーンの履歴を受け入れるかどうかに依存します。異なる履歴がある場合、最も高い合計ステークを持つコミッティによって検証された履歴が勝利し、間違った履歴を支持したバリデータはペナルティを受け、ステークの一部を失います。要するに、ネットワークに固有の非常に多くの情報が関わっており、コンセンサスプロセスの簡易に検証可能なスクリプトをダイレクトに構築する方法はありません。

「相互運用性」のシナリオを除き、この問題は通常起こりえません。なぜなら、リモートチェーンのコンセンサスプロセスのオフラインスクリプトを参照する代わりに、ローカルクライアントは単にビーコンノードに問い合わせてトランザクションの状態を確認するからです。ビーコンノード（個々のノードの侵害リスクを軽減するために慎重に選ばれた複数のビーコンノード）の完全性を前提として、トランザクションが最終確定されたことを確認し、次のアクションに移ることができます。しかし、たとえばIBCにはこのオプションは利用できません。なぜなら、リモートチェーンはソースチェーンに接触できないという前提があるからです：リモートチェーンは、ソースチェーンとの直接的な接触がないため、オフラインでコンセンサスの検証を実行する必要があります。

一つの選択肢は、Sync Committeeを使用することです。各スロットでチェーンの新しいヘッドとなるブロックヘッダーに継続的に署名することで小さな報酬を受け取るバリデータの回転プールです。この場合、受信チェーンはこのバリデータプールに属するアドレスを知る必要があります。オンラインクライアントは、以前に検証されたブロックのスクリプトを参照するか、ネットワークへの直接リクエストを通じて、将来のブロックのコミッティメンバーを確認します。しかし、オフラインのスクリプトでも、信頼できるスナップショットまでの以前に検証されたブロックの履歴を参照し、各ブロックのバリデータが次の関心のあるブロックまで検証していることを確認する必要があります。

私たちはまだ、最初のバリデータコミッティが偽のブロックに署名して、偽のコミッティの連続が偽のブロックに署名するシーケンスを設定しないという信頼をしなければならない状況にありますが、少なくとも同じスナップショットから派生した複数のコンセンサス・トランスクリプトを通じて提示されるブロック履歴の一貫性を確認する可能性はあります。あるいは、受信チェーン上にsync contractを設定してSync Committeeの履歴を追跡し、その後、任意の時点でブロックのバリデータが誰であるかについての信頼できる権威として参照されるかもしれません。これにより、バリデータセットが継続的に回転し、共謀を調整する難しさが増し、受信チェーンがソースチェーンのバリデータを信頼することが実現可能になります。ただし、その信頼はソースチェーンによって信頼されていたという事実にのみ基づいています

事例紹介2：プライベートネットワークCordaにおける結果の証明

Cordaではコンセンサスの証明は比較的容易です。トランザクションはNotaryによって観察され、署名されることで確定され、各確定トランザクションのInput Stateを消費済みとしてマークすることで、トランザクション入力の二重支払いを防ぎます。しかし、検証を行わないNotaryは、トランザクションの内容についての検証は行わず、単にトランザクションの重複を防ぐ役割に留まります。実際、トランザクションの詳細は、そのハッシュのみを含むノードでMerkleツリーに置き換えられることによって「切り離されます」。

これはCordaのプライバシーモデルの特徴であり、すべてのトランザクションを監視する中央当局が存在しないことを意味します（代わりにオブザーバーノードを配置している）。しかし、これはトランザクションの検証が関係する当事者に委ねられ、その後の当事者が、新しいトランザクションのInput Stateの履歴を、それらのOutput Stateとして生成した以前のトランザクションの「バックチェーン」に沿ってチェックすることを意味します。このpeer validationにより、ユーザーが不正に無効なトランザクションをNotaryに承認させることは理論上可能ですが、他の当事者がそのトークンを受け入れることはありません。なぜなら、そのトークンが無効なトランザクションから生じたものであることが検証過程で明らかになるからです。

Cordaのトランザクションにおける結果の証明は、受信チェーンがシリアライズされたCordaトランザクションを解読できたとしても、そのトランザクションがソースネットワーク上のピアによって有効と認めたかどうかを表す証明として、コンセンサスの証明を用いることは困難です。さらに、トランザクション自体の表現がネットワーク外の検証者にとってやや不透明であるという問題があります。トランザクションにシリアライズされたデータ構造を定義するクラス定義とContract検証メソッドは、ソースのCorDappのJavaバイトコードで表現されています。同じコードを共有するCorDappのアプリケーションネットワーク上のピアは、Cordaトランザクションを容易にデシリアライズして検証できますが、リモートネットワーク上のSolidity Contractでは容易に（または安価に）同じことを行うことはできません。

Harmoniaで使用されているメカニズムは次のとおりです。Cordaネットワーク上のピアは、「ドラフト」となるトランザクションを生成し、それが有効となるためには自身の署名が必要ですが、その署名を除いて別のピアに検証のために転送することができます。検証するピアは、Contractロジックを使用してドラフトの有効性をチェックし、そのInput Stateのバックチェーンに沿ったすべてのトランザクションの有効性を合わせてチェックすることができます。すべてが確認できた場合、検証するピアは、ドラフトトランザクションのハッシュに対するNotaryの署名と、ドラフトの作成者の署名が、結果の証明（トランザクションが作成者が言う通りの動作をする）とコンセンサスの証明の両方を構成すると証言できます。その後、作成者はこれらの署名を取得する責任があります（つまり、手形取引に署名してNotariseことによって）行動の証明を完成させるためです。

リモートチェーンがこの証明を利用するには、発信元のCordaネットワーク外で提示されたCordaトランザクションの結果を容易に判断する方法がないため、検証するピアを信頼する必要があります。繰り返しますが、CordaのUTXOトランザクションを完全に検証するには、シリアライズされたトランザクションデータをデコードする能力だけでなく、そのトランザクションだけでなく、そのバックチェーンにあるすべてのトランザクションに対してもContract検証コードを実行する能力が必要です。二つのネットワークを強く結びつけて一方のContract検証ロジックをもう一方で煩雑に再現するのではなく、信頼関係を利用することを選ぶかもしれません。EthereumのSync Committeeを使ってコンセンサスが達成されたことを保証するために、完全なコンセンサスプロセスのトランスクリプトを提示する必要がないのと同様に、検証プロセスの完全なトランスクリプトを構築して検証する必要を避けるために、信頼できる情報源を利用します。

ドラフトトランザクションのハッシュと、そのドラフトをレビューしたローカルの情報提供者による署名、そしてトランザクションを最終的に承認する作成者とNotaryの公開鍵が与えられた場合、ローカルの情報提供者を信頼する限り、この情報をトランザクションハッシュの結果の証明として扱うことができ、作成者とNotaryの署名がコンセンサスの証明を提供し、行動の証明を完成させます。特筆すべきは、これにより、証明された結果（資産移転の二段階実行の第一段階）を持つ特定のドラフトトランザクションにコミットするターゲットネットワーク上でのトランザクションを実行できることです。これにより連続するトランザクションを承認するために対応するコンセンサスの証明が必要になります（第二段階、移転の完了）。

エゴとアルターエゴ

特に先に述べた信頼と責任の関係を考慮すると、資産交換における信頼できる情報源の役割を誰が担うべきでしょうか？資産交換では、二つのネットワーク上の当事者のアイデンティティは利害の点において一致しています。ネットワークB上の受取人はネットワークA上の送信者の「アルターエゴ」と見なすことができ、その逆もまた然りです。この関係はインセンティブの観点から見るとアルターエゴが利益を得れば私も利益を得ることを意味します（例えば、私がネットワークで販売している資産の代金が支払いネットワークの私のウォレットに入金された場合）。信頼の観点からは、私はアルターエゴが彼らのネットワークで私のために行動することを信頼し、彼らも私がそうするよう指示することを信頼しています（例えば、資産の受取人として、私は支払いネットワーク上の自分のアルターエゴに売り手のウォレットへの支払いを指示し、彼らは私の指示に従って行動します）

これらの信頼関係を踏まえると、資産交換における証明の役割は、相手方が設定した条件が満たされた場合に一方的に行動する権限を提供することです。私は自分のアルターエゴが支払いを送ったという証明は必要とせず、確認だけが必要です。なぜなら、私のアルターエゴは自分の行動についての情報源として私に信頼されているからです。しかし、資産の売り手は、資産を私が彼らの条件を満たすことで一方的に取得できるロックされた状態に置くかもしれません。私が支払いが送られたという証明を提示する条件を満たした場合、彼らからのさらなる承認なしにです。私自身のアルターエゴへの信頼だけではこの条件を満たすことはできません。なぜなら売り手は私のアルターエゴを信頼していないからです。逆に、私が支払いを送った後に売り手が資産の送付を拒否することがないように保証を得たいので、売り手のアルターエゴが支払いを受け取ったことを彼らに確認した場合に売り手が資産を私に移転するという合意に頼ることはできません。支払いの証明が手元にある場合、自動的に資産を取得できるようにしたいのです。

仮に資産が移転されるネットワークがCordaネットワークであり、支払いネットワークがEthereumネットワークである場合、資産交換の「パターン」は以下のようになります：

• Cordaネットワークの売り手は、資産をロックに置き、支払いの証明があれば購入者が自動的に取得できるようにするドラフトトランザクションを準備します。
• Cordaネットワーク上の購入者はドラフトトランザクションを検証し、Ethereumネットワーク上の支払い者に対して、支払いを「コミット済み」状態に移動するよう指示します。Ethereumネットワーク上のContractは、受取人がドラフトトランザクションがファイナライズされた、つまり資産がロックされて購入者が支払いの証明を示せば取得できるようになっていることを証明できれば、このコミット済み状態から自分のウォレットに支払いを移動できることを保証します。
• 売り手はドラフトトランザクションに署名しNotariseすることで、受取人がEthereumネットワーク上で自分に支払いを移動するために使用できるCordaネットワーク上の行動の証明を完成させます。
• 受取人は行動の証明を使用して支払いを受け取ります。支払い者は支払いが行われたことを観察し、支払いの証拠を示すイベントログメッセージを含むトランザクションレシートがファイナライズされたEthereumトランザクションブロックに接続されていることを示す行動の証明を構築します。
• 購入者は支払いの証明を使用して、Cordaネットワーク上のロックから資産を取得します。

このパターンの鍵となるのは、Cordaトランザクションの結果の証明として信頼できる情報提供源による証明を受け入れる際に依存する信頼関係が、交換の当事者間の商業的および運用的関係において既に確立されているという点です。

考察と結論

これらの事例研究に基づき、以下の見解を述べていきます。

• 分散型台帳上で特定のこと（結果の証明）が確実に起こったこと（コンセンサスの証明）を知るためには、その台帳の履歴、プロトコル、ネットワーク構造、スマートコントラクトの規則、コンセンサスメカニズムなどに関する状況に応じた豊かな知識を必要とします。
• 分散型台帳の信頼できる参加者は、通常、この状況に応じた豊富な知識への直接アクセスを持っているか、スマートコントラクトのルールを検証し、コンセンサスプロセスに貢献するために、信頼できる方法で仲間から情報を集めるメカニズムを持っています。
• 状況に応じた豊富な知識は、ネットワークの範囲外で伝達し検証することが難しい場合があります。例えば、IBCが要求するような「安価に検証可能なコンセンサストランスクリプト」は、Proof of StakeのEthereumに対して構築するのが難しいかもしれません(コンセンサスの糸を引っ張り始めると、結局は全体を買わなければならないかもしれません)
• 証明への道を短縮するために信頼できる情報源による証明を利用することができます。これにより、証明の枝は元のネットワークの深みに広がるのではなく、信頼できる情報提供源の署名で終わることになります。
• EthereumのSync Committeeを使用してよりlightweight consensus transcriptsを構築するためのものであり、Cordaネットワークのピアによるドラフトトランザクションの検証はこの原則を実践している一例に当たります。

実際、相互運用するネットワークでは、ローカルの情報への依存を減らすために、信頼できる情報源を利用することが現実的に多くなることが多いです。別のネットワークのトランザクションデータを綿密に調べたり、バリデーターセットのメンバ ーを追跡したりする価値と、別のネットワーク内のあるネットワークのコンテキストの詳細を完全に忠実に反映するコストとを比較検討することが重要です。信頼関係を活用することで、行動が取られたことを確認するために必要な証拠の量や複雑さを減らすことが可能でしょうか？

この問題は、特にCordaネットワークが関与する場合に顕著です。なぜなら、Notaryが検証を行わない場合、Ethereumのように、最終性の証明が自動的に有効性の証明とはなりません。Ethereumのファイナライズされたトランザクションのレシートにあるイベントログを見ると、そのトランザクションを管理するContractのルールがネットワークのバリデータによって承認されたことが分かります。Contractのルールによって特定の結果が得られた場合にのみイベントが発生するとしたら、ファイナライズされたトランザクションによるイベントの発生を結果の証明として扱うことができます。しかし、検証なしにNotariseされたCordaトランザクションに対しては、同じ推論は利用できません。Cordaネットワーク内のどの当事者も無効なトランザクションをNotariseしないという強い仮定がなければ、IBCスタイルの相互運用は実現不可能です。完全性に必要な要素を欠いた「証明」の詳細なチェックは、コストがかかるだけでなく無意味です。見せかけの検証プロセスは傍観者を安心させるかもしれませんが、攻撃者を抑止することはできません。

Sync Committeeの例からは、ネットワーク内の事実を正確に報告する責任を一つの当事者が全て負う必要がないという信頼関係が見て取れます。交代制の立会人連盟は、中央集権的な権威に対する強力な選択肢です。または、例を用いた議論された資産交換のように、必要な信頼関係は、相互運用パターンの組織内で彼らが果たす役割にすでに暗示されているかもしれません。各事例では、証明・信頼・責任の相互作用を慎重に考慮する必要があります。