paint-brush
PIECHAIN デモ: 実用的なブロックチェーン相互運用性フレームワークの探究@interoperability
211 測定値

PIECHAIN デモ: 実用的なブロックチェーン相互運用性フレームワークの探究

長すぎる; 読むには

PIECHAIN は、ブロックチェーンの相互運用性を実現する Kafka ベースのフレームワークを導入し、アトミックなクロスチェーン トランザクションを保証し、Ethereum、Hyperledger Fabric、Quorum ブロックチェーンをサポートして、クロスチェーン オークションなどの実用的なアプリケーションを実現します。
featured image - PIECHAIN デモ: 実用的なブロックチェーン相互運用性フレームワークの探究
Interoperability in Software Publication HackerNoon profile picture
0-item

著者:

(1)ダニエル・レイスベルゲン、南洋理工大学、シンガポール、シンガポール

(2)アウン・マウ、シンガポール工科デザイン大学、シンガポール、シンガポール

(3)張静志、シンガポール南洋理工大学、シンガポール

(4)ティエン・トゥアン・アン・ディン、ディーキン大学、メルボルン、オーストラリア

(5)アンウィタマン・ダッタ、南洋理工大学、シンガポール、シンガポール。

コンテンツの概要

概要と序論

PIEChainの概要

PIEChainの実装

デモ計画

拡張機能

参考文献


抽象的な

近年、多種多様なブロックチェーン プラットフォームが登場していますが、その多くはサイロで運用されています。そのため、ブロックチェーンの相互運用性を実現するには、信頼性の高いクロスチェーン通信が必要です。ブロックチェーンの相互運用性は、通常、トランザクションを元に戻すことができないため困難です。そのため、1 つのトランザクションがコミットされた場合、プロトコルは関連するすべてのトランザクションもコミットするようにする必要があります。既存の相互運用性アプローチ (Cosmos や Polkadot など) は、独自のサブチェーン間の相互運用性しかサポートしていないか、既存のブロックチェーンに侵入的な変更が必要であるという点で制限があります。この制限を克服するために、私たちは、汎用の Kafka ベースのクロスチェーン通信フレームワークである PIECHAIN を提案します。私たちは、実用的なケース スタディ (複数のチェーンでトークンを保有するユーザーが別のチェーンで販売されるチケットに入札するクロスチェーン オークション) に PIECHAIN を使用します。PIECHAIN は、クロスチェーン通信の汎用フレームワークの初めての公開された実用的な実装です。


I.はじめに

ブロックチェーンは、敵対的な環境向けに設計された、複製された改ざん防止データベースです。これは、追加専用の台帳を管理する多数のノードで構成されており、その中には悪意のあるノードも含まれています。台帳には、いくつかのグローバル状態を変更するトランザクションが格納されます。標準的な例、つまり暗号通貨 [7] では、グローバル状態はユーザーアカウントとネイティブ (代替可能) トークンであり、台帳にはトークンをあるアカウントから別のアカウントに転送するトランザクションが含まれます。別の新しいアプリケーションでは、ブロックチェーンは、デジタルアート作品やコンサートチケットなど、資産を一意に表す非代替トークン (NFT) を保存します。多くのブロックチェーンは、ユーザーが独自の状態と状態を変更するコードを定義できるようにするスマートコントラクトもサポートしています。スマートコントラクトは台帳に保存され、すべてのブロックチェーンノードによって複製され、一貫性が保たれます。近年、多くの独立したブロックチェーンプラットフォームが登場し、ロングテールのエコシステムが形成されています。一方では、Ethereum や Hyperledger など、非常に人気のある汎用ブロックチェーンプラットフォームが少数存在します。一方、特定のアプリケーション向けに設計された小規模なブロックチェーンは数千種類存在し、そのほとんどは開発の初期段階にあります。これには、2023年初頭の時点で10,000種類以上の暗号通貨[3]や、ヘルスケア、アイデンティティ管理、IoT向けのブロックチェーンが含まれます。一般的に、これらのブロックチェーンは相互運用性がなく、サイロ化されています。そのため、ブロックチェーンの相互運用性、つまりユーザーが異なるブロックチェーン上で情報や資産を交換できる機能は、研究コミュニティからますます関心を集めているテーマです[6]、[10]、[4]、[1]、[11]。


図 1. PIECHAIN アーキテクチャ: クロスチェーン サービス (CC-SVC) は、Kafka ネットワークとの間でイベントの読み取り/書き込みを行い、基盤となるさまざまなブロックチェーン (BC) と対話します。


安全なブロックチェーン相互運用性フレームワークを設計する際の主な課題の 1 つは、アトミック性、つまり合意された一連のトランザクションのすべてのステップが正常に終了するか、まったく終了しないことを保証することです。ブロックチェーンでは、ブロックチェーン トランザクションは (原則として) 元に戻せないため、従来のデータベースよりも複雑です。たとえば、チェーン A の NFT の支払いがチェーン B ですでに行われている場合、アトミック性では、チェーン B のトランザクションを元に戻すことができないため、チェーン A のトランザクションを先に進める必要があります。アトミック性を保証する一般的な方法の 1 つは、取引に関係するすべてのトークンをスマート コントラクトにエスクローし、すべての当事者が署名したコミット メッセージを通じてのみトークンを解放することです [6]。ブロックチェーンの相互運用性におけるもう 1 つの重要な課題は、エスクローされたトークンが永久に凍結されないように、ライブネスを保証することです。ライブネスを保証するには、すべての当事者がエスクローから資産を引き出すことができる中止メッセージをノードが送信できる必要があります。


アトミック性と活性の両方を保証するために、相互運用性フレームワークは、あるブロックチェーンにコミットメッセージを送信し、別のブロックチェーンに中止メッセージを送信する敵対的なノードを許容できなければなりません。非同期ネットワーク(つまり、メッセージ遅延に制限がないネットワーク)では、信頼できる第三者(TTP)なしではこれを実現することは不可能であることが知られています[10]。この課題を克服するための主なアプローチは2つあります[6]。最初のアプローチは、同期の仮定と中止のクールダウン期間を組み合わせることです。つまり、コミット投票が生成されると、中止のクールダウン期間が終了する前に、影響を受けるすべてのブロックチェーンに追加できると仮定します。このアプローチは、ハッシュされたタイムロック契約などで採用されています[5]。2番目のアプローチは、TTPを別のブロックチェーンに置き換えて、有効なコミットメッセージまたは中止メッセージのいずれかが作成され、両方が作成されないようにすることです[6]、[9]。


両方のタイプのアプローチは科学文献で提案されていますが、公開されている実装がないか[5]、[6]、[9]、またはアプリケーションの範囲が限られています(別のブロックチェーン上の裏付け資産の作成[11]やトークンスワップ[8]など)。別の開発では、CosmosやPolkadotなど、デフォルトで相互運用性を可能にするブロックチェーンプラットフォームがいくつか登場しています。ただし、これらのプラットフォームは、独自のサブチェーン間の相互運用性のみをサポートするか、既存のブロックチェーンに侵入的な変更を必要とします。このため、既存のブロックチェーンプラットフォームを変更することなくインターフェースできる、汎用的で実用的な相互運用性フレームワークが必要になります。私たちの目標は、そのようなフレームワークを提供することです。


貢献と新規性: この目標を達成するために、PIECHAIN を紹介します。同期は実際には想定しにくいため、PIECHAIN は TTP の代わりにクロスチェーン サービスを使用します。クロスチェーン サービスは、効率性のために Apache の Kafka プロトコルを使用するイベント ログを使用して通信します。PIECHAIN の実用的な関連性を示すために、現実的なケース スタディであるクロスチェーン オークション用のクロスチェーン サービスを実装しました。PIECHAIN を、スマート コントラクトをサポートする最も人気のあるブロックチェーン プラットフォームである Ethereum、Hyperledger Fabric、Quorum とインターフェイスしました。最後に、ケース スタディ用の GUI を開発しました。オークション ケース スタディは、GitHub の PIEChain コード リポジトリでコードを見つけることができる 3 つのケース スタディ (2 つのオークションとフラッシュ ローン [6]) のうちの 1 つです。



II. PIECHAINの概要

A. エンティティ

PIECHAIN の主なエンティティは次のとおりです (図 1 も参照)。


ブロックチェーンは、ユーザーが保有する資産 (トークン、キーなど) を保存します。ユーザーは、複数のブロックチェーンに資産を保有できます。各ブロックチェーンには、読み取りおよび書き込みアクセス権を持つユーザーを決定する独自のプロトコルがあります。ブロックチェーンは通常、許可型 (つまり、固定されたノード セットに読み取りおよび書き込みアクセス権がある) または許可なし型 (つまり、全員が読み取りアクセス権を持ち、トランザクションを作成でき、十分なパワー (処理速度など) を持つノードは、ブロックチェーンにトランザクションを追加できます) のいずれかです。クロスチェーン サービス (CC-SVC) は、ユーザーが異なるブロックチェーン上の資産を交換できるようにします。各 CC-SVC は、ユーザー クライアントと対話してクロスチェーン通信を容易にするサーバーで構成されています。実際には、CC-SVC はユーザーに参加料を請求し、任意の数のブロックチェーンと対話できます。以下では、各 CC-SVC は、サーバーから Kafka 元帳に送信される資産のアトミック交換に関係する一連のイベントに対応しています。実際には、1 つのサーバーが複数の CC-SVC を操作する場合があります。


Kafka ネットワークは、CC-SVC によって生成されたイベントの追加専用ログとして機能します。イベントは、基盤となるブロックチェーンで行われたトランザクションに対応します。Kafka ネットワークは、イベントのアップロードに対して CCSVC に課金する固定のノード セットによって運用されます。


PIECHAIN では、CC-SVC は半信頼であり、商用アウトソーシング サービス プロバイダーと同様に、維持すべき評判があることで誠実に行動する動機があると想定しています。Kafka ネットワーク オペレーターは信頼されていませんが、基盤となるブロックチェーンとやり取りしないため、不正行為をする動機はありません。これにより、セキュリティよりも効率を優先するプロトコル (Kafka) を実行できます。別の設計としては、CC-SVC を信頼せず、Kafka ネットワークを信頼するというものがあります。この場合、各 Kafka ノードは基盤となるブロックチェーンごとに (軽量) クライアントを実行し、それらのチェーンへのトランザクションの組み込みを検証します。この場合、イベント ログは PBFT [2] などのより安全なプロトコルを使用する必要があります。このような設計は今後の課題とします。


B. プロセスフロー

セクションII-Aのエンティティを考慮すると、PIECHAINのプロセスフローは、Herlihyら[6]が提案したクロスチェーン取引と同じ構造を持ちます。クロスチェーン取引は、複数のユーザーが異なるブロックチェーン上で資産を交換するための合意であり、5つのフェーズで構成されます(図2も参照)。


  1. クリアリングフェーズ: CC-SVC は、取引に関係する資産をエスクローおよび転送するために使用されるさまざまなブロックチェーン上にスマート コントラクトを作成します。


  2. エスクローフェーズ: ユーザーは、出金資産をスマート コントラクトに転送してエスクローします。


  3. 転送フェーズ: 資産が暫定的に交換されます。つまり、スマート コントラクトの実行ロジックが指定されます。


  4. 検証フェーズ: 各ユーザーは、実行ロジックの結果が満足のいくものであるかどうかを確認します。


  5. コミット フェーズ: 当事者全員が満足している場合はコミットメントによって取引が締結され、そうでない場合は中止によって取引が締結されます。コミットメントとは、スマート コントラクトの実行ロジックが実行され、取引で指定されたとおりに資産が交換されることを意味します。中止とは、各スマート コントラクトの資産が元の所有者に返されることを意味します。


コミットするには、ユーザーが対話的にコミット投票を作成し、それが CC-SVC によって Kafka 台帳に送信されます。中止するには、1 人のユーザーが CC-SVC に中止メッセージを送信します。各 CC-SVC について、コミット メッセージまたは中止メッセージのいずれかを Kafka 台帳に追加できますが、両方を追加することはできません。Kafka 台帳へのコミット投票の包含証明は、さまざまなブロックチェーン上のすべてのスマート コントラクトによって受け入れられます。これにより、コミット投票が作成されると、すべての資産転送が実行されるか、まったく実行されないかのいずれかが保証されます。


図 2. 1 つの CC-SVC (上)、2 人のユーザー (中央)、2 つのブロックチェーン (下) の設定におけるセクション II-B の 5 つのステップの図解。Kafka ネットワークは示されていません。



III. PIECAINの実装

PIECHAINの実用性を示すために、私たちはPIECHAINをいくつかの一般的に使用されているブロックチェーンプラットフォームに接続し、科学文献[6]のアプリケーションであるデジタル資産のクロスチェーンオークションを実装しました。ブロックチェーンのサポートは、セクションVで説明するように、他のケーススタディにも拡張されています。


A. ブロックチェーンのサポート

基盤となるブロックチェーンを PIECHAIN と連携させるには、CC-SVC がそれらのチェーン上のトランザクションを検証できる必要があります。私たちの実装では、Ethereum (プライベート Ethereum の Proof-of-Work バージョンと Proof-of-Authority バージョンの両方)、Hyperledger Fabric、Quorum というブロックチェーン プラットフォームをサポートしています。後者 2 つは許可型ブロックチェーンをサポートしていますが、Ethereum には許可なしのメイン チェーンがありますが、同じ機能を持つプライベート チェーンもサポートしています。


B. オークション

私たちのケーススタディでは、競売人が1つのブロックチェーンで資産を販売し、別のブロックチェーンで資産の形で支払いを受け取ります。[6]と同様に、チケット販売者の例を使用します。チケットは専用ブロックチェーン上のNFTですが、もう1つのブロックチェーンはより一般的に使用される代替可能なトークン(例:Ether)をサポートしています。前者のブロックチェーンはチケットブロックチェーンと呼ばれ、後者はコインブロックチェーンと呼ばれます。これは、複数のコインブロックチェーンを持つ設定に簡単に一般化できます。以下では、ファーストプライスオークション(つまり、最高入札者が入札額を支払い、資産を受け取る)を検討します。プロトコルの5つのフェーズは次のようになります。


  1. オークション主催者は、チケット ブロックチェーンとコイン ブロックチェーン上にスマート コントラクトを作成する CC-SVC を採用します。


  2. オークション主催者はその資産(チケットの NFT)をチケット契約に転送し、入札者は自分の入札を自分のコイン ブロックチェーン上の契約に転送します。


  3. 実行ロジックは次のように決定されます。オークション主催者は、どの当事者がチケットを受け取り、どの入札がオークション主催者に転送されるかを指定して、各チケットおよびコイン コントラクトを更新します。(チケット チェーン上のコントラクトはコイン ブロックチェーンからデータを読み取ることができないため、このロジックはチケット コントラクトで事前に指定できないことに注意してください。)


  4. 各ユーザー (オークション主催者と入札者) は、転送プロトコルの結果が自分たちにとって同意できるものであるかどうか、つまり、チケットが実際に正しい相手に転送されたかどうかを判断します。


  5. すべてのユーザーはコミット投票を構築します。コミット投票が構築されると、各コントラクトに送信され、転送フェーズで指定された転送が実行されます。


PIECHAIN では、オークションにはリレーヤーと署名者の 2 つの (論理的な) タイプの CC-SVC が必要です。リレーヤーはコイン チェーン上のイベント (入札) をリッスンし、チケット ブロックチェーンに中継します。署名者はコミット投票の作成を支援します。


IV. 実証計画

このデモでは、クロスチェーンオークションを説明するために、React フレームワークを使用してグラフィカルユーザーインターフェイス (GUI) を開発しました。GUI は、図 3 に示すように既知のオークションのリストを表示するダッシュボードページ、図 5 に示すように個々のオークションの詳細ビュー、および新しいオークションを作成するためのページ (表示されていません) の 3 つのメインページで構成されています。このビューは、オークション主催者と入札者で同じです。ダッシュボードビューで、予定のオークション主催者は [Create New Auction] ボタンをクリックしてオークションを開始できます。オークション主催者は、CC-SVC、オークション対象の資産、入札を受け入れる他のブロックチェーン、異なるブロックチェーン間のトークンの交換レート (事前に固定する必要があります)、およびオークションが終了する時間を選択します。次に、リレー CC-SVC が関連する契約を作成し、資産チェーン上の契約のアドレスをオークション主催者に送信します。オークション主催者は、契約アドレスを追加して [Add Existing Auction] ボタンをクリックすることで、ダッシュボードにオークションを追加できます。同時に、入札候補者に対して契約アドレスを宣伝します。


入札者は、アセットコントラクトアドレスを知ったら、それをダッシュボードに追加することもできます。入札者がオークションを追加した後、オークションのパネルの「表示」ボタンを押して詳細表示ページに移動することで、オークションの詳細を表示できます。このページでは、入札者はオークションの作成時間と終了時間、入札リストなど、オークションに関する重要な情報を表示できます。最高入札額にはアスタリスクが付いています。オークションがまだ進行中の場合、入札者はブロックチェーンを指定して入札を追加できます。



図 4. ブロックチェーン クライアントのコンソール出力を表示するウィンドウ。



入札するトークンと入札するトークンの量を指定します。その後、関連するコイン コントラクトにトランザクションが実行され、その情報がリレー CC-SVC に送信されます。ユーザーは、CC-SVC 経由で行った入札を中止することもできます。


オークションが終了すると、リレー CC-SVC はすべての参加者に通知し、スマート コントラクトで商品の暫定的な転送を指定します。次に、CC-SVC はすべての参加者のクライアントにコミット投票の作成に参加するよう依頼します (参加しない場合はペナルティが科せられます [4])。コミット投票が作成されると、すべてのコントラクトに送信され、最終的な資産の転送が開始されます。この時点で、オークションが終了したことが GUI に表示されます。


デモの正確な流れは次のようになります。


  1. 1 人のユーザー (オークション主催者) が Web ブラウザー ベースの GUI を開き、それを使用して選択した資産のオークションを開始します。このプロセスでは、オークション作成ページのすべての機能が示されます。資産は、Hyperledger Fabric で実行されている専用のチケット チェーン上に存在します。契約は、関係するすべてのブロックチェーン上に作成されます (図 2 のステップ 1)。


  2. 別のマシンのブラウザ ウィンドウを使用する少なくとも 2 人の他のユーザーが、新しく作成されたオークションの詳細ページに移動し、資産に対して個別の入札を送信します (図 2 のステップ 2)。少なくとも 1 人の入札者は (プライベート) Ethereum を使用し、もう 1 人は Quorum を使用します。


  3. しばらくすると、オークションが終了し、落札者が決定されます (図 2 のステップ 3)。これにより、オークション主催者からリレー CCSVC に「オークション終了」イベントが送信されます。このタイプのイベントをリッスンしている署名者は、イベントに気付き、コミット投票を作成します (図 2 のステップ 4)。コミット投票はその後 Kafka に送信され、リレー ノードによってオークション コントラクトとコイン チェーン コントラクトに転送されます。この時点で、資産は落札者に転送され、落札額はオークション主催者に転送されます (図 2 のステップ 5)。


デモ全体を通して、図 4 に示すように、ターミナル ウィンドウを使用して、各ステップの後に基礎となるブロックチェーンの状態を照会します。これにより、視聴者はバックグラウンドで発生している変化を観察し、デモのフローと対話することができます。たとえば、新しいアクションを要求して、バックグラウンドの状態がどのように変化するかを確認することができます。


デモの流れを説明するために、仮のデモ スライドと、オークション主催者と入札者が 1 台のコンピューターを使用して操作を実行した場合の画面を示すビデオがオンラインで公開されています (これは PIECHAIN の制限ではありませんが、ビデオの録画が容易になります)。


図 5. アクティブなオークションの詳細ビュー。


V. 拡張

CC-SVCフレームワークとサポートされているブロックチェーンのインターフェースを使用すると、PIECHAINを他のユースケースに簡単に拡張できます。これらの1つは、[6]で説明されているクロスチェーンフラッシュローンです。裁定取引の機会は通常すぐに解決されるため、フラッシュローンのGUIは実用的な関連性が限られており、CC-SVCとのやり取りは通常、トレーディングボットによって行われます。ただし、時間が許せば、フラッシュローンのステップがさまざまな関連する契約の状態に与える影響を視覚化して表示します。


参考文献

[1] Rafael Belchior、Andre Vasconcelos、S´ergio Guerreiro、Miguel´Correia。ブロックチェーンの相互運用性に関する調査:過去、現在、将来の動向。ACM Computing Surveys(CSUR)、2021年。


[2] ミゲル・カストロ、バーバラ・リスコフ「実用的なビザンチンフォールトトレランス」OsDI、第99巻、173~186ページ、1999年。


[3] CoinLore. https://www.coinlore.com/all coins、2023年。


[4] ダニエル・エンゲル、モーリス・ハーリヒー、インジエ・シュエ。「失敗は(文字通り)選択肢である:分散型金融におけるアトミックコミットメントと選択性」SSS 2021、2021年。


[5] モーリス・ハーリヒー「アトミッククロスチェーンスワップ」ACM PODC、245~254ページ、2018年。


[6] モーリス・ハーリヒ、バーバラ・リスコフ、リューバ・シュリラ「クロスチェーン取引と敵対的商取引」VLDBジャーナル、2021年。


[7] サトシ・ナカモト。ビットコイン:ピアツーピアの電子キャッシュシステム、2008年。


[8] Sri AravindaKrishnan Thyagarajan、Giulio Malavolta、Pedro Moreno-Sanchez。ユニバーサルアトミックスワップ:すべてのブロックチェーン間でのコインの安全な交換。IEEE S&P、2022年。


[9] Victor Zakhary、Divyakant Agrawal、Amr El Abbadi。ブロックチェーン間のアトミックコミットメント。VLDB Endowment Proceedings、13(9)、2021年。


[10] Alexei Zamyatin、Mustafa Al-Bassam、Dionysis Zindros、Eleftherios Kokoris-Kogias、Pedro Moreno-Sanchez、Aggelos Kiayias、William J Knottenbelt。SoK:分散型台帳間の通信。Financial Crypto、2021年。


[11] Alexei Zamyatin、Dominik Harz、Joshua Lind、Panayiotis Panayiotou、Arthur Gervais、William Knottenbelt。Xclaim:信頼不要で相互運用可能な暗号通貨担保資産。IEEE S&P、2019年。


この論文はCC 4.0ライセンスの下でarxivで公開されています