Peiling Ding氏「Ourea Community」講演：クロスチェーンプロトコルとForgeでの実装

講演： Peiling Ding

編集： Hongjunおじさん（Ourea Community）

9月26日、北京時間12時30分、ArcBlockのブロックチェーン基盤エンジニアPeiling Ding氏がOurea Community主催の第33回「価値探索」オンラインイベントに招かれ、クロスチェーン技術の難点と原理、そしてArcBlockの技術的な選択について語りました。

はじめに

皆さん、こんにちは。Peiling Dingです。ArcBlockでは主にバックエンドとブロックチェーン関連の設計・開発に携わっています。

以前はOCAP（Open Chain Access Protocol）のデータインデックスを担当し、BTCとETHのデータをチェーンから取得して、OCAPがそれらを効率的、完全かつ正確に返せるようにしていました。現在は主にクロスチェーンプロトコルとABT DID Authenticationプロトコルの設計・実装を担当しています。本日は、クロスチェーン機能を設計・実装する中で直面した問題と、そこから得た経験を皆さんに共有できることをうれしく思います。

クロスチェーンの重要性は皆さんよくご存じでしょうから、今日は「どのようにクロスチェーンを実現するか」を中心に話します。まず、実現に必要な基本要素と難点を全体的に説明し、次にArcBlockがクロスチェーン機能をどのように設計・実装したかをご紹介します。最後に質問があれば、できる限りお答えします。

01 クロスチェーンの概要

始める前に、Vitalik氏が以前示した見解を引用します。彼はクロスチェーンを、移転可能な資産（Portable assets）、アトミックスワップ（Atomic Swap）、クロスチェーンオラクル（Cross-chain oracles）、資産ロック（Asset encumbrance）、汎用クロスチェーンコントラクト（General cross-chain contracts）の5つに分類しました。

今日は取引に最も近い2番目のアトミックスワップだけに焦点を当てます。また、Forgeフレームワークで構築した2本のチェーン間での実装だけを扱います。アトミックスワップでBitcoinとEthereumを接続する方法は別の話題です。

02 クロスチェーンの基本要素

それでは本題に入り、クロスチェーンの基本要素を見ていきましょう。

現実世界では、リンゴを一つのかごから別のかごへ簡単に移せます。しかしブロックチェーンの世界では、あるチェーンのデータを別のチェーンへ運ぶことはできません。

クロスチェーン問題の本質は、従来のデータベース間データ転送と変わりません。できることは、一方のチェーンでデータを変更し、もう一方でもデータを変更することだけです。そして2つの変更は一定の論理関係を満たす必要があります。

銀行間送金でも、銀行が現金輸送車でお金を別の銀行へ運ぶわけではなく、それぞれのデータベースを書き換えているだけです。

03 クロスチェーンの難点

難しいのは、2つのデータ変更がアトミックでなければならないことです。つまり両方とも成功するか、両方とも失敗する必要があり、片方だけの成功は許されません。

従来の中央集権型データベースでは、最初のデータベースの変更結果に基づいて2番目を変更するか判断でき、最初の変更も容易にロールバックできるため、これは難しくありません。

しかしブロックチェーンの世界では非常に困難です。難しさは「基づいて」という言葉にあります。

あるチェーンから直接取得できないデータは、すべてオフチェーンデータと呼びます。AとBという2本のチェーンがあるとき、AにとってBの情報は直接取得できないためオフチェーン情報であり、BにとってもAの情報はオフチェーン情報です。

ブロックチェーンではオフチェーン情報に基づく判断が難しく、その理由はオフチェーン情報源の分散化にあります。

オンチェーンの情報については、チェーン上の全ノードがすでに合意しています。では、どうすれば全ノードがオフチェーン情報について合意できるでしょうか。

単一の情報源を使えば分散化の理念に反し、その情報源がチェーン全体を完全に支配します。複数の情報源を使うなら、許容できるコストで自チェーンの全ノードにそれらについて合意させるにはどうすればよいでしょうか。

したがって、クロスチェーンの本質はオフチェーン情報の取得です。Vitalik氏の5分類も、背後にある問題はすべてオフチェーン情報の取得です。

クロスチェーン取引の要素と難点を説明したので、設計と実装を見ていきます。採用した方法はAtomic Swap、つまりアトミックスワップです。まず全体の流れと実装上の考慮点を確認し、最後に先ほどの難点をどのように解決するかを振り返ります。

04 Hash LockとHash Key

Atomic Swapを説明する前に、Hash LockとHash Key、つまりハッシュロックとハッシュキーという概念を導入します。

Hash Lockはランダムな数値のハッシュ値であり、そのランダム値自体がハッシュキーです。

ランダム値xをハッシュ演算してハッシュ値yを得たとします。yをHash Lock、xをHash Keyと呼びます。形式的にはHash(x) = yと表せます。

05 Atomic Swap

この概念を踏まえて、Atomic Swapの方法を説明します。

AliceとBobがクロスチェーン取引をするとします。AliceはAチェーン上の100 tokenで、BobがBチェーン上に持つアドレスz123のassetを一つ購入したいと考えています。

Atomic Swapの前、AチェーンではAliceが100 tokenを持ち、Bobはtokenを持っていません。BチェーンではAliceはAssetを持たず、Bobが一つのAssetを持っています。

この初期状態からAtomic Swapを進めます。

第1ステップはAliceが開始します。Aliceはランダム値xをハッシュキーとして生成し、対応するハッシュロックを作ります。そしてこのハッシュロックでAチェーン上の100 tokenをロックします。ロック時には次の情報を指定します。

ロック後、100 tokenはAliceの名義から移され、再利用できなくなります。

このTransactionの内容はAチェーン上で公開されるため、Bobはすべての内容を明確に確認できます。

第2ステップでは、Aliceがtokenをロックしたことを確認したBobが、同じハッシュロックでBチェーン上のassetをロックします。ここでも次の情報を指定します。

第3ステップでは、Aliceが先にチェーン上のassetを解除します。解除時にAliceはハッシュキーを提示し、検証に成功するとロックされた資産を受け取れます。

第4ステップでは、BobがAチェーン上のtokenを解除します。AliceがBチェーンで解除したことでハッシュキーが公開されるため、Bobはキーを容易に知り、Aチェーンで解除してtokenを受け取れます。

この流れでAliceとBobはAtomic Swapを完了できます。最終状態は、Aチェーンでは100 tokenがAliceからBobへ移り、BチェーンではassetがBobからAliceへ移ります。

別のケースもあります。第3ステップでAliceが考えを変え、Bチェーンの資産を受け取らない場合です。この場合Aliceはハッシュキーを明かさないので、BobもAチェーンのtokenを取得できません。AliceとBobはロック期間後、それぞれのtokenとassetを取り戻せます。

06 フローのまとめ

このフローをまとめます。

Atomic Swapの全体像を把握したところで、Forge上での具体的な実装を見ていきます。

07 Forge上での実装

まずロックです。

ユーザーがtokenとassetsをロックできるForge TransactionとしてSetUpSwapを設計・実装しました。

このTransactionで送信者はReceiver address、Hash Lock、Locktime（ロック期間）、ロックするtoken数量とassetアドレスを入力します。

チェーンノードはTransaction実行時に、Locktimeが現在のブロック高より大きいか、送信者が該当するtokenとassetを保有しているかを検証します。条件を満たさなければTransactionは失敗します。

Transactionが通るとForgeはSwapStateを生成します。そのアドレスはTransaction Hashから生成されます。Forgeは同じTransaction Hashを許可しないため、SwapStateのアドレスも重複しません。

これにより各SwapStateは独立し、互いに影響しません。

SwapState自体はどのアカウントにも属さず、Atomic Swapのルールに従って動作します。SetUpSwap Transactionがチェーンに記録されると、Sender address、Receiver address、Locktime、Hashlock、Token、Asset addressesがSwapStateに記録されます。TokenとAssetsはSenderから移されるため、送信者は変更できなくなります。

第2ステップは解除で、対応するTransactionはReceiveSwap Transactionです。

このTransactionには、回収するSwapStateのアドレスと対応するHashkeyを入力します。

チェーンノードは、SwapState内のReceiverアドレスとTransaction送信者のアドレスが一致するか、HashkeyがHashlockと一致するか、SwapStateにTokenまたはAssetsが残っているかを検証します。

条件を満たしTransactionが成功すると、Hashkeyは誰でも確認できるようSwapStateに書き込まれ、tokenとassetsは該当アカウントへ移ります。途中で取引を中止するには、ロックしたtokenまたはassetsを撤回します。この処理にはRevokeSwap Transactionを使います。

このTransactionにはSwapStateのアドレスだけを入力します。

ForgeはSetUpSwap TransactionとRevokeSwap Transactionの送信者が同じかを検証します。また、現在のブロック高がSwapStateのLocktimeを超えているか、SwapStateにtokenとassetsが残っているかも検証します。

Transactionが成功すると、SwapState内のtokenとassetsはTransaction送信者へ移され、撤回が完了します。

設計・実装時には多くの詳細を検討しました。

チェーンへの記録やブロードキャストがなくても、少なくとも1ノードは検証します。そのノードが悪意を持てばHashkeyを記録できます。そのため、適切なLocktimeの設定が非常に重要です。Locktimeより前は、対応するReceiverだけがSwapState内のtokenとassetsを移せます。Receiverはこの時間に失敗原因を調べ、繰り返し再試行すべきです。

実際の失敗原因にはネットワーク問題やgas不足などがあります。そのためウォレットも最適化し、ReceiveSwap Transaction送信前に現在のブロック高とLocktimeを比較し、近すぎる場合は警告します。

08 Atomic Swapのまとめ

最後にAtomic Swapをまとめます。

講演の冒頭で、クロスチェーン最大の難点はオフチェーン情報の取得だと述べました。Atomic Swapの流れを理解した今、この難点をどのように解決したか考えてみてください。

お気づきのとおり、Atomic Swapでこの問題を本当に解決したのではなく、巧みに回避しただけです。

フロー全体で実際にチェーンをまたいだものは、Hashkeyという一つのランダム値だけです。最初に述べたように第1のチェーン情報に基づいて第2のチェーンを変更するのではなく、その責任をすべてHashkeyへ移しました。

この移転は妥協であり、問題を完全には解決していません。BobがHashkeyを知ることとAliceがassetを正常に受け取ったことを必要十分条件と仮定しているため、Bobがtokenを受け取る際、Aliceが本当にassetを受け取ったかを検証しません。しかし実環境では、安全性の話で述べたように、この仮定が正しくない可能性もあります。

それでも、オフチェーン情報源の分散化という巨大な障壁を前にすれば、この妥協には価値があると考えます。他の方法も検討しましたが、システムルールが極端に複雑になるもの（仲介者を導入してオンチェーン情報を検証するなど）や、ノード運用コストを大幅に増やしスケーラビリティを低下させるもの（ブロックチェーンをブロックチェーン網へ拡張するなど）でした。そのため最終的にAtomic Swapを選びました。

以上で本日の講演を終わります。ありがとうございました。

質疑応答

質問：Forgeは現在どの開発言語に対応していますか。多言語はどのようにサポートし、WASMのような仕組みを使っていますか。

Forgeはオンチェーンとオフチェーンの2つに分かれます。

オンチェーン部分は、Forge自体がErlang VM上に構築されたチェーンと言えるため、ErlangまたはElixirだけをサポートします。オフチェーン部分にはElixir、Javascript、Pythonなど各言語のSDKがあり、RustとC/C++にも対応中です。

現在ForgeではWASMを使っていません。

質問：ForgeはDapp開発向けですか、チェーン開発向けですか。それとも両方ですか。重点はありますか。開発者にとって、dapp開発とEthereumのような環境でのスマートコントラクトアプリ開発の主な違いは何ですか。

答える前に、まず私のDappに対する理解を説明します。Dappという概念はEthereumから生まれたのでしょう。

Ethereumにこの概念があるのは、Ethereumが「ワールドコンピューター」で、ネットワーク全体を一台のコンピューターとして模倣するからです。Ethereum自体がOS、上で動くスマートコントラクトがアプリケーションに相当します。Ethereumはパブリックチェーンなので、そのプログラムは自然にDAppと呼ばれます。

ここではチェーンとDappを分けて話すのが合理的です。しかしコンソーシアムチェーン、つまりカスタマイズ可能なチェーンにこのモデルを当てはめるのは不自然です。

コンソーシアムチェーンは、オンラインゲームや特定分野のサプライチェーンなど、特定のビジネスロジック専用に設計されます。

他者と共有するものではないため、別の人がDAppを容易にデプロイすることも認めません。

高度にカスタマイズされたチェーンはビジネスロジックを中心に実装されます。Forgeはコンソーシアムチェーン開発に注力するチェーン開発フレームワークです。Forgeで望む機能を持つチェーンを開発でき、その機能のために別途DAppを開発する必要はありません。チェーン自体がDappなのです。

したがって、この観点ではForgeはチェーンとDAppの両方を開発するためのものです。

Dappとスマートコントラクト開発の違いについては、先ほど述べたとおりDAppはスマートコントラクトだと考えます。周囲にオフチェーン部分もあるでしょうが、中心はオンチェーンのコントラクトなので、本質的な違いはありません。

Hongjunおじさん：OK。つまりカスタマイズされたチェーン自体が特定分野のアプリケーションであり、チェーンとdappを分けるのは難しいということですね。

質問：ArcBlockのチェーン開発ではどのようなガバナンス方法がありますか。アップグレードが必要な場合、一般的な流れと背後の原理は何ですか。

チェーンのアップグレードもTransactionで実現します。このTransactionは、アップグレード開始ブロックやバージョンなどの情報をGlobal Stateに書き込みます。各ノードはチェーンが指定の高さに到達すると停止し、実行ファイルを指定バージョンへ更新して再起動します。

もう一つは新しいTransactionのデプロイです。Ethereumと同様、対応するTransactionコードをGlobal Stateへ書き込み、以後チェーンは新しいTransactionを実行できます。基本原理は以上です。

質問：アップグレード時に過去のデータを再処理する必要はありますか。

ありません。以前のデータは旧バージョンのチェーンが生成したもので、アップグレード後のチェーンは既存データの上に新しいデータを生成します。簡単に言えば、オンチェーンの履歴は変更できません。これはブロックチェーン最大の特徴の一つです。

質問：Forgeが開発者にもたらす最大の価値は何ですか。学習コストの低さ、チェーン機能の強さ、柔軟性、それとも別の点ですか。

Forgeはチェーン開発フレームワークで、チェーンを開発する際に考慮すべきことを大幅に簡素化します。私たちはよくブロックチェーン分野のRuby on Railsに例えます。端的に言えば、Forgeの利点はRuby on Railsを使う利点と同じです。Rubyに詳しい方は、RubyだけがありRuby on Railsがなかった時代の開発体験を想像してみてください。

原文リンク： FORGEにおけるクロスチェーンプロトコルとその実装