Paka Labs 4D レポート: クロスチェーン技術のパノラマと申請フォーム (1)

星球君的朋友们

Odaily资深作者

2023-03-12 18:00 (UTC+8)

この記事は約13256文字で、全文を読むには約19分かかります

クロスチェーンに関する研究報告はすでに数多くありますが、この記事では先行研究に基づいて、テクノロジーの本質を深く掘り下げ、混乱を招く概念を区別して分析し、文脈とフレーム

AI要約

原作者: MIDDLE.X、Paka Labs 研究員

元の編集者: Shawn Lin、1 PAR Research 創設者

ありがとう：

バッファロー、Bifrost システムアーキテクト

ロビン・ウェイ氏、技術教育スペシャリスト、ダーウィニア

ChainX テクニカルディレクター Xu Licheng 氏

この記事の執筆中にコンサルティング支援が提供されました

最初のレベルのタイトル

1 はじめに

クロスチェーン技術はブロックチェーン分野の聖杯であり、1万チェーンの相互運用性を実現する鍵となる技術と考えられています。人々はよくその重要性をインターネットの TCP/IP と比較します。それはまさに、TCP/IP プロトコルクラスターが、データのパッケージ化、アドレス指定、送信、ルーティング、および宛先での受信方法を標準化するポイントツーポイントリンクメカニズムを提供し、世界中の端末が接続されるためです。ネットワークに進化し、今日私たちがインターネットとして知っているものに進化しました。

ブロックチェーン業界の急速な発展に伴い、さまざまなパブリックチェーンやパーミッションチェーンが登場し、百花繚乱の花を咲かせています。しかし、技術的、環境的、競争などの理由により、大部分のチェーンは相互に接続して通信することができず、ユーザー、資産、アプリケーション、データの断片化につながり、「アイランド効果」が形成されています。基本的にこの状況の主な理由は、ユーザーのニーズの多様化とブロックチェーンのスケーラビリティの限界です。

最初のレベルのタイトル

副題

2.1 トークン交換

各ブロックチェーンには独自のネイティブトークンがあります。トークンは、特定の権利と利益をカプセル化するため、価値の伝達者となります。チェーン内の証明書は確実に交換できますが、チェーン間の証明書の交換は「山のように別々のチェーン」になります。チェーン間で信頼できる証明書の交換を実現することによってのみ、「価値のインターネット」としてのブロックチェーンの重要な役割を実現できます。

副題

2.2 トークンの転送

トークン転送とは、あるチェーン上のネイティブ資産を別のチェーンに循環させることを指します。これは直接達成することはできず、トークンはそのホストチェーンにのみ接続できます。一般に、パススルーは、ソースチェーン上の元のアセットをロックし、同時にターゲットチェーン上の元のアセットをシミュレートする同等の量のアンカーアセットを発行することによって実現されます。このプロセスの安全性と信頼性をどのように確保するかが、クロスチェーン技術の大きな課題です。

副題

2.3 情報伝達

クロスチェーンの完全な意味では、実際にはチェーン間のあらゆるメッセージを確実に送信できるはずです。クロスチェーントランザクションは、基本的に一連のクロスチェーンメッセージ転送の組み合わせです。たとえば、クロスチェーントランザクションの一種であるトークン転送は、次の 2 つのクロスチェーンメッセージ転送で構成されます。

ソースチェーンは証明書をロックし、ロックアップメッセージとその証明をターゲットチェーンに送信します。
ターゲットリンクは情報を受信し、その信頼性を検証し、マッピングパスを作成し、レシートをソースチェーンに送り返します。

したがって、クロスチェーン情報転送にはクロスチェーントークン転送も含まれると言えます。クロスチェーン情報転送によって解決される問題は、クロスチェーントークン転送のスーパーセットです。

最初のレベルのタイトル

3. クロスチェーン技術の概要

現在のクロスチェーン技術形式の中には、ハッシュタイムロックやクロスチェーン DEX などのトークンの交換のみを実現するもの、チェーン上で一連の役割を確立することによってメッセージを転送してステータスを確認するもの、一連の通信を提案するものもあります。ブロックチェーン間の通信を実現し、より多くのブロックチェーンへのアクセスをサポートする新しいシステムアーキテクチャとチェーン構築プロトコルを提案する人もいます。

副題

3.1 ハッシュタイムロックに基づくアトミックスワップ

ハッシュタイムロックは、トラストレスなクロスチェーン資産トランザクションを実現できる一連の暗号化方式です。たとえば、1 BTC とあなたの 10 ETH トランザクションを使用する場合、トランザクションのアトミック性はハッシュロックを通じて実現できます。原理はおおよそ次のとおりです。

ユーザー A はランダムなパスワード r を生成し、r のハッシュ値 m=hash(r) を計算し、m の値をユーザー B に送信します。

同時に、ユーザー A がトランザクションを開始し、1 BTC をユーザー B に転送します。トランザクションの成功には条件があり、ユーザー B が成功するにはパスワード r を提示する必要があります。そうでない場合、トランザクションは事前に設定された時間が経過すると自動的に失敗します。

ユーザー B は、A が開始したトランザクションを確認した後、ユーザー A に 10 ETH を転送するトランザクションも開始します。このトランザクションの成功にも条件があります。ユーザー A が成功するには、r を表示する必要があります。事前に設定された時間を超過すると、トランザクションは終了します自動的に失敗します。ここで重要な点は、ユーザー B は、成功条件として r を使用してそのようなトランザクションを作成するためにパスワード r の値を取得する必要はなく、それを作成するには m の値だけを知っていればよいということです。また、ハッシュ操作は次のとおりであることがわかっています。 m がわかっていても r を推定することはできません。

ユーザー A は、B によって開始されたトランザクションを確認した後、r 値を提示し、B によって開始されたトランザクションが成功し、B によって転送された 10 ETH を取得し、r 値が公開されます。

ユーザー B も、前のステップで A によって提示された r 値を取得し、A によって開始されたトランザクションが成功し、A によって転送された 1 BTC を取得しました。

上記のメカニズムを通じて、2 つの異なるチェーン上のトランザクションは 1 つのイベントに結合され、全体として成功するか、全体として失敗することしかありません。A から B への転送が成功する状況はありませんが、B から B への転送は成功しません。 A が失敗する場合もあれば、その逆も同様です。

この仕組みの実現には、「条件付き成功トランザクション」と「条件付き失敗トランザクション」という2つの技術が必要であり、あらかじめ設定した時間を超えてハッシュ画像rが生成されない場合には、ハッシュロックやタイムロックと呼ぶこともできます。それぞれ。

BTC では、CLTV オペコードまたは CSV オペコードを通じてハッシュタイムロックを実装でき、イーサリアムなどのチューリング完全チェーンでは、スマートコントラクトを通じてハッシュタイムロックを実装できます。実際、スマートコントラクトは、ハッシュタイムロックよりもはるかに多様で複雑な条件付き成功トランザクションと条件付き失敗トランザクションを実装できます。

ハッシュタイムロックは、信頼を前提とすることなく、チェーン全体の 2 者間の仲介アトミックトランザクションを実現していることがわかります。同時に、この取引方法がユーザーフレンドリーではないことも認識しており、これは主に次の 3 つの側面に反映されています。

取引の両当事者は同時にオンラインである必要があり、参加プロセスは厳格に実施されるため、取引の開始者がオンラインの取引相手を見つけられない場合は、待機する必要があります。
BTCの場合、ハッシュタイムロック付きトランザクションの作成は最下層で2つのトランザクションを作成することで完了しますが、基盤となる仕組みが複雑なため、上記のトランザクション処理では簡略化して1つのトランザクションとして表現しています。トランザクションが成功した場合、両方のトランザクションをチェーンにアップロードする必要があり、追加料金を支払う必要があります。
実際の取引では為替レートの問題が発生し、相手方は為替レートが自分にとって有利かどうかで取引を完了するかどうかを選択できます。特に金額が大きい場合、取引相手のインセンティブが強いため、アトミックトランザクションは大規模なトランザクションには適さない可能性があります。
副題

3.2 証人

証人、英語は Notary で、公証人と訳されることもありますが、クロスチェーン情報の送信とクロスチェーン資産の保管のために設定された特別な役割です。 2012年にリップルは、第三者証人によるクロスチェーン転送を初めて実現したインターレッジプロトコル（ILP）をリリースし、それ以来、この証人メカニズムは主にBTCを中心とした多くのクロスチェーンプロジェクトに適用されてきました。

クロスチェーンプロジェクトが異なれば、証人の設定も異なります。証人は単一のサブジェクトである場合もありますが、ほとんどの場合は複数のサブジェクトです。証人の生成は許可されたアクセスまたは自由なアクセスである場合があります。アセットクロスチェーンを実現するには、証人が必要です。エスクロー口座を管理する必要があり、エスクロー口座の管理方法は独立管理または複数当事者による管理である可能性があり、証人に対するユーザーの信頼基盤は、証人自身の信用から得られる場合もあれば、証人が過大担保されている場合もあります。

3.2.1 証人の生成方法

最も簡単な方法は、許可された立会人グループを結成することです。メンバーは基本的に固定されており、メンバーの参加と脱退は現在のメンバーによって検討され、投票されます。この方法は比較的集中的であり、より分散化された方法はフリーアクセス方法であり、対応する資産を抵当に入れるなどの所定の条件を満たしている限り、誰でも証人になることができます。自由なアクセスはさらなるリスクにさらされ、悪意のある目撃者が現れる可能性があり、共謀のリスクが生じます。したがって、一部のクロスチェーンプロトコルでは、ランダム抽出メカニズムを追加することを選択します: 各操作はすべての証人によって署名されるわけではありませんが、適格な証人のセットから証人のグループがランダムに選択されます。このようにして、証人の数を増やすことができます。 . 共謀のコスト。

3.2.2 証人に対するユーザーの信頼基盤

証人は、証人の住宅ローンの価値がアカウントの保管資産の価値よりも大きい必要があることを意味する超過担保によって信頼を得ることができ、保管資産が失われた場合、ユーザーは預金から補償を得ることができます。過剰な担保により、ユーザーが管理する資産は非常に安全になりますが、過剰な担保は証人に資本コストをもたらし、証人の資本コストは高額なクロスチェーン手数料に変換されます。

証人は自分の善意に頼って支持することもでき、信頼という前提はありますが、クロスチェーン手数料が安く、無料の場合もあるため、依然として多くのユーザーを魅了しています。

3.2.3 資産保管方法: 独立制御アドレスとマルチパーティ制御アドレス

証人はそれぞれ独立した制御アドレスを制御して、ユーザーの信託を引き受けるための保管アドレスマトリックスを形成することができます。独立制御アドレスは必ずしも単一署名アドレスである必要はないことに注意してください。セキュリティ上の理由から、証人はマルチ署名と秘密鍵の断片化テクノロジを使用して独立制御アドレスを管理する場合があります。多くの企業では、証人のアドレスがマルチ署名および秘密キーのシャーディングを通じて、会社の複数の経営陣または株主によって共同管理される場合があります。ただし、どのような技術を用いてアドレスを管理しても、単一の主体によって管理されているアドレスを独立管理アドレスと呼びます。

多くの場合、エスクローアドレスは複数の当事者によって共同管理されるアドレスです。すべての証人がアドレスを共同管理することも、証人をグループに分けて各グループがアドレスを共同管理することも可能です。この場合、マルチ署名や秘密キーのシャーディングなどのマルチパーティ制御テクノロジを使用する必要があります。

3.2.3.1 マルチ署名

マルチ署名、またはマルチ署名、英語では Muti-Sig といい、複数の秘密鍵が共同してアカウントを管理する技術です。マルチ署名技術は、送金するには M-of-N の署名者がアドレスに署名する必要があることを実現できます。、1 ≤ M ≤ N。

BTC では、マルチシグネチャアドレスは P2SH タイプのアドレスであり、通常の BTC アドレスは公開鍵をハッシュすることによって取得され、マルチシグネチャアドレスはスクリプトハッシュに基づいています。このタイプのアドレスには N 値に制限 (N≤15) があり、イーサリアムなどのチューリング完全ブロックチェーンでは、スマートコントラクトを通じてマルチ署名アドレスを実現でき、N 値も無限にすることができます。

3.2.3.2 秘密キーのシャーディング

分散キー技術とも呼ばれる秘密鍵シャーディング技術は、安全なマルチパーティコンピューティング (sMPC、Secure Muti-Party Computation) としきい値技術を組み合わせて誕生した、理論上の安全性がより高いマルチパーティ制御技術です。 (TSS) は、M-of-N 署名管理も実装できます。この技術は、アカウントの秘密鍵をいくつかの断片に分割し、複数の署名者に割り当てることをサポートしており、署名された断片化された秘密鍵の数がしきい値に達した場合に、アカウント資産を操作できるようになります。具体的な実装に関しては、秘密キーのシャーディングには多くの技術的な実装方法があり、複雑な暗号化の知識が必要になりますが、この記事では詳しく説明しません。

秘密キーのシャーディングがより安全である理由は、シャーディングが常に更新されるためです。つまり、時々シャーディングが再度実行され、各ユーザーに与えられるシャードが変更されます。悪意のある人が全員のシャードを取得して資産を盗もうとする場合、同じ時間単位で異なる署名者の秘密鍵を取得する必要があります。そうでないと、ロバの口が間違っており、完全な秘密鍵を合成できません。

3.2.3.3 署名者グループのメンバー管理

マルチ署名でも秘密鍵シャーディングでも、署名者グループはメンバーが常に固定されたグループにはなり得ないため、署名者グループのメンバーの増減が伴います。秘密鍵シャーディング技術では、増減後に生成された新たな署名者グループにフラグメントを再シャーディングして配布するだけで済みます。マルチシグネチャテクノロジには、次の 2 つの状況があります。

イーサリアムなどのチューリング完全ブロックチェーンでは、署名者グループのメンバーの管理ルールをスマートコントラクトプログラミングを通じて設定できます。たとえば、既存の署名者の3分の2以上が署名し、新しい署名者の追加を承認することに同意します。古い署名者の削除。

BTC では、P 2 SH マルチ署名アドレスの署名者グループメンバーは編集できません。署名者の秘密鍵が漏洩した場合、または撤回する必要がある場合は、新しい P 2 SH マルチ署名アドレスを再作成することしかできません。新しい住所に転送されます。

3.2.4 分散化に向けた改善

副題

3.3 ライトノードのサイドチェーン

サイドチェーンの出現は、BTCを拡大しようとする人々の努力から生まれました。 2014 年 10 月、BlockStream チームは「アンカー」クロスチェーンソリューションを初めて提案した「サイドチェーンに関するホワイトペーパー」をリリースしました。アンカー(Pegged)は「楔」と訳されることもあり、アンカーチェーンに対してアンカーチェーンが読み取れる状態を表し、この状態を「アンカーチェーンがアンカーチェーンの側鎖である」ともいいます。

人々は最初、BTC トランザクションを BTC メインチェーンからサイドチェーンに移すことで BTC メインチェーンへの圧力を軽減することを期待していましたが、2016 年に RootStock チームによって開発された RSK は、BTC の最も初期のサイドチェーンであると考えられています。サイドチェーン技術の本質は、メインチェーンのライトノードをサイドチェーンに融合することで、メインチェーンをサイドチェーンが読み取れるようにすることです。この技術は、ソースチェーンのライトノードコントラクトをターゲットチェーンにデプロイするだけで、ターゲットチェーンをソースチェーンのサイドチェーンに変換し、クロスチェーンからの移行を実現するため、少しの変更でクロスチェーンに適用できます。ソースチェーンからターゲットチェーンへの一方向のクロスチェーン。

いわゆるライトノードとは、ブロックヘッダー情報のみを格納する小規模なノードを指します。ライトノードはチェーン上のすべてのトランザクションを保存するわけではありませんが、ブロックヘッダー情報を通じて特定のトランザクションがチェーン上に存在するかどうかを確認できます。ライトノードコントラクトは、ライトノードを含むスマートコントラクトです。ソースチェーンのライトノードコントラクトをターゲットチェーンに展開することで、ソースチェーンからのメッセージの信頼性検証を実現できます。プロセスは大まかに次のとおりです。

ソースチェーン A がターゲットチェーン B にクロスチェーントランザクション情報の送信を要求すると、トランザクション開始者はトランザクションの詳細な内容、ブロック高さ、およびトランザクションの SPV 証明書 (トランザクションの Mekre パスを参照) を送信します。トランザクション）B チェーンへ。

チェーン B にデプロイされたチェーン A のライトノードコントラクトは、SPV 証明を通じて、交換が配置されているブロックのブロックヘッダーのハッシュ値を再計算します。

取得したハッシュ値とライトノード内の対応するブロックヘッダハッシュ値を比較し、一致していればそのブロック内でトランザクションが発生したことを意味し、一致していなければそのブロック内にトランザクションが存在していないことを意味する。

誰でもトランザクションの詳細とその SPV プルーフをターゲットチェーンに送信できますが、実際のクロスチェーンアプリケーションでは、多くの場合、トランザクションの開始者ではなく、これを行うための専用のロールが存在します。この記事では、この役割を中継者と呼びます。ユーザーがクロスチェーンメッセージを渡すのを支援する責任に加えて、リレイヤーは、ライトノードコントラクトを確立するためにソースチェーンのブロックヘッダーをターゲットチェーンに渡す責任も負う必要があります。

中継者は監視者と同様、クロスチェーンメッセージを渡すための特定の役割ですが、中継者と監視者の間には 2 つの違いがあります。

リレイヤーは資産の保管には責任を負いません。サイドチェーンメカニズムを使用してクロスチェーンを実現する場合、クロスチェーンプロセス中にロックされたトークンは特定のエスクロー契約にエスクローされます。
中継者に対する信頼の仮定は、証人よりも緩やかです。証人の大多数が正直であることを信頼する必要がありますが、多くの中継者のうち少なくとも 1 人が正直である限り、クロスチェーンメッセージングは信頼できると信頼できます。これについてはセクション 3.3.3 で詳しく説明します。

リレイヤーは、クロスチェーンプロジェクトごとに呼び方が異なります。一部のプロジェクトでは、Realyer の役割が分割され、ブロックヘッダーの配信を担当する中継者 (ヘッド中継者) とトランザクションメッセージの配信を担当する中継者 (メッセージ中継者) の 2 つの役割として定義されています。一部のプロジェクトでは、専用の Relayer ロールが存在せず、Relayer の機能が他のロールに統合されており、たとえば、ソースチェーンのバリデーターが Relayer のロールを直接引き受けます。ただし、すべては同じままです。ライトノードのサイドチェーンソリューションの技術的本質は常に次のとおりです。リレイヤーは、ソースチェーンのブロックヘッダーをターゲットチェーンに転送し、ライトノードを確立し、その後、リレイヤーがトランザクション情報をターゲットチェーンに転送するときに、ソースチェーンからターゲットチェーンへの変換に使用されます。ライトノード上のブロックヘッダー情報は、トランザクション情報の正確性を検証します。

3.3.1 双方向アンカリング

私たちが理解する必要があるのは、主鎖と側鎖の関係は相対的であり、2 つの鎖は互いに側鎖になり得るということです。上で述べた「ソースチェーン」と「ターゲットチェーン」も相対的な概念であり、クロスチェーンメッセージングイベントでは、メッセージの送信元はソースチェーンと呼ばれ、メッセージの受信者はターゲットチェーンと呼ばれることがよくあります。

お互いのライトノードを埋め込むことで、チェーンを挟んだ双方が互いのチェーンの情報を読み取って通信することができ、この形式を双方向ペギング(Two-Way-Pegging)と呼びます。他人の側鎖。相互に情報を送信する役割を担う中継器グループが両方向にあります。もちろん、中継器の 2 つのグループ (B→A 中継器と A→B 中継器) は、同じ役割にマージされ、同じグループの人々である場合もあります。双方向の情報伝達を担当します。

3.3.2 サイドチェーンとサブチェーン

サイドチェーンに関しては、混同されやすい別の概念であるサブチェーンと区別する必要があります。サブチェーンには独自のコンセンサスメカニズムやネイティブ証明書はなく、そのセキュリティは一方向のメインチェーンに完全に依存しています。サイドチェーン自体は独立して動作するブロックチェーンであり、サイドチェーンとメインチェーンの関係は相対的な概念であり、双方向の性質を持っています。

イーサリアムの拡張チェーンには、サイドチェーンの形式のものもありますが、サブチェーンの形式のものもあります。プラズマ方式とサイドチェーン方式を使用した拡張チェーンはイーサリアムのサイドチェーンです（プラズマサイドチェーンはサイドチェーンの別の形式であり、ライトノードのサイドチェーンではありません）。一方、ステートチャネルとロールアップ方式を使用した拡張チェーンはイーサリアムのサイドチェーンです。エセリウムファングのサブチェーン。

サブチェーンは、メインチェーンからサブチェーンにトランザクションを移動させ、定期的に最終状態をメインチェーンと同期させることでメインチェーンの性能を拡張するため、「コミットチェーン」とも呼ばれます。サブチェーンの名前は、その技術的本質に近いものです。

サブチェーンの目的は容量を拡張することであり、容量拡張の本質はメインチェーンのリソースを節約することであるため、メインチェーンはサブチェーンによって送信されたトランザクションの検証にコンピューティングリソースを費やすことがなくなります。サブチェーン自体には、送信時に送信されたコンテンツの信頼性を証明するメカニズムが必要です。このうち、ステートチャネル、オプティミスティックロールアップ、およびアービトラムロールアップは証明に不正証明を使用しますが、Zk ロールアップとヴァリジウムは有効性証明を生成するためにゼロ知識証明を使用します。

サブチェーンとメインチェーンの間の一方向の情報送信の相互作用は、一部の文献ではクロスチェーン技術の一形態とも考えられていますが、Paka Labs は、サイドチェーンとサブチェーンは両方とも同じ領域で誕生したものであると考えています。ブロックチェーン拡張の取り組みですが、サブチェーン関連テクノロジーは拡張チェーンの作成にのみ使用でき、2 つの独立したブロックチェーン間のクロスチェーンには適用できず、クロスチェーンテクノロジーとして分類されるべきではありません。

3.3.3 ライトノードサイドチェーンの利点

監視機構がTrust(信頼)に重点を置くなら、ライトノードのサイドチェーン技術はVerify(検証)に重点を置く! トランザクション情報はブロックヘッダーで検証され、暗号化によって信頼性が保証される。確かに。

ライトノード契約ではフルノードと同様に厳密にブロック検証が可能であり、偽のブロックヘッダは検証を通過できないため、中継器が渡すブロックヘッダも改ざんすることは不可能です。ライトノードの検証手順は、ソースチェーンネットワークのマイナーノードの検証手順と全く同じであり、BTCを例に挙げると、次の手順で検証する必要があります。

ブロックデータ構造は構文的に有効です。

プルーフ・オブ・ワークを検証します。ブロック・ヘッダーのハッシュが目標難易度よりも低いです (確認には十分なプルーフ・オブ・ワークが含まれています)。

ブロックのタイムスタンプは検証時刻より 2 時間前です (時刻誤差は許容されます)。

ブロックサイズが長さ制限内であること、つまりブロックサイズが設定範囲内であることを確認します。

最初のトランザクション (最初のみ) はコインベースのトランザクション、つまりブロックであり、マイナーは自分自身に 1 回だけ報酬を与えることができます。

ブロック内のトランザクションを検証し、その有効性を確認します。MerkleRoot がブロック本体内のトランザクションから取得されたものであるかどうか、つまり、ブロックのマークルツリーを再構築することで取得されたツリールートであるかどうかを検証し、それが hashMerkleRoot と等しいかどうかを確認します。ブロックヘッダーの値。

悪意のあるリレイヤーが共謀して悪事を働く場合、唯一可能な方法はフォークされたチェーン上のブロックのブロックヘッダーを渡すことですが、健全なネットワークの場合、フォークされたチェーンは最終的に最長のチェーンにはならず、ライトノードの契約は終了します。十分な待ち時間だけで十分です。複数のブロックの確認だけで十分です (BTC ライトノードの場合は、6 ブロック待つだけです)。 BFT チェーンの場合、ライトノードコントラクトは、ブロックが最終的なものであるかどうかを知るために、ブロックの署名番号を検証するだけで済みます。

ソースチェーンまたはターゲットチェーン自体が再編成された場合にのみ、ライトノード契約のセキュリティが影響を受けます。 Relayer がネットワークに引き起こす可能性のある損害は、せいぜいネットワークのサービスを停止させる集団ストライキに限定されます。

さらに、中継者は保管資産を管理する責任を負わず、悪意のある中継者は悪意のある証人のように保管資産を盗むことはできません。クロスチェーンによってロックされたアセットはコントラクト内でホストされており、コントラクトコードに問題がない場合、コントラクト内でホストされているアセットのセキュリティは、コントラクトが配置されているチェーンのレベルになります。

リレーレイヤーが悪を行うための条件は厳しく、害が少ないため、ライトノードのサイドチェーンのリレーレイヤーは証人のように過剰に担保する必要がありません。より多くのクロスチェーンアンカー資産の発行を、より少ないコストで実現できます。

ライトノードのサイドチェーンソリューションは、クロスチェーンのコストとセキュリティの点でウィットネスソリューションよりも多くの利点があり、2 つのチェーン間のクロスチェーンを実現するための好ましい技術ソリューションであることがわかります。ただし、チェーンによってはスマートコントラクトに対応しておらず、ライトノードコントラクトやエスクローコントラクトを導入できない場合もあり、この場合は監視方式を採用するしかありません。

3.3.4 ライトノード技術の発展：「スリム化」と「負担軽減」

BTC のブロックサイズは 1 M で、そのブロックヘッダーはわずか 80 バイトであることがわかっていますが、この記事が公開されるまで、BTC の過去のブロックヘッダーサイズは 60 M (高さは約 690,000) を超えていません。歴史的なブロックヘッダーの総量は 5 G (高さは約 1,300 万) を超えています。ブロックチェーンの開発の多様化に伴い、一部の新興ブロックチェーンは高い TPS に重点を置いており、ブロック生成の速度は非常に高速です。その量は間もなくその量を超える可能性があります。イーサリアム。

この傾向はライトノードのサイドチェーンに課題をもたらしており、それは主に次の 2 つの側面に反映されています。

ブロックヘッダーが大きくなると、ライトノードコントラクトが煩雑になり、ターゲットチェーンの巨大なストレージスペースを占有します。
ソースチェーンのブロック生成速度が速くなることで、ライトノードコントラクトが頻繁に同期して新しいブロックを検証するようになります。

これらは両方とも、ターゲットチェーン上のライトノードコントラクトのガス消費量が膨大になり、深刻な場合には、クロスチェーンを実現するためにライトノードのサイドチェーンテクノロジーを使用することが経済的に不可能になります。

何をするか？証人の計画に戻りますか？しかし、ライトノードのサイドチェーン技術の優位性は非常に魅力的であるため、今後も使用していきたいと考えています。 SPV検証機能を失うことなく、ライトノード契約を変革し、拡張する方法はあるのでしょうか?

ブロックチェーン業界の研究者は、ライトノードのサイドチェーン技術を 2 つの方向で改善しました。 1 つ目は、ライトノードコントラクトを「スリム化」してより小さくし、ブロックの増加に伴って直線的に増加しないようにすることです。2 つ目は、ライトノードコントラクトの「負担を軽減」し、ブロック検証リンクをチェーンから外すことです。ライトノード契約はトランザクションの SPV 検証のみを行うようにします。

3.3.4.1 ライトノード契約の「スリム化」

私たちは「FlyClient」と呼ばれる新しいプロトコルを理解する必要があります。これは、スタンフォード大学の Benedikt Bunz らが論文「FlyClient: Super-Light Clients for Cryptocurrency」で提案した新しいライトノードプロトコルです。 Flyclient ライトノードはすべてのブロックヘッダーを保存する必要はなく、最新のブロックヘッダーのみを保存する必要があります。最新のブロックヘッダーを使用すると、すべての過去のブロックヘッダーをいつでも「復元」できます。この機能は「メルケルマウンテン」と呼ばれる暗号アルゴリズムによって実現されている。

マークル山脈 (MMR) 略してメルケツリーの変種です。ブロックチェーンのすべての歴史的ブロックのハッシュ値をリーフノードとして使用し、MMR アルゴリズムを通じて MMR ルート値を生成し、この値を最新のブロックヘッダー。すべての過去のブロックヘッダーを検証するために使用できます。

FlyClient ライトノードは、履歴ブロックヘッダーを継続的に削除し、最新のブロックヘッダーのみを保持して「ライト」を維持できます。特定のブロックヘッダーを復元する必要がある場合、リレイヤーを介してフルノードから再度取得でき、最新のブロックヘッダーのMMRルート値を使用して、復元されたブロックヘッダーが正しいかどうかを検証できます。

ソースチェーンが確率的最終チェーンの場合、Flyclient ライトノードがリレイヤーから配信された最新のブロックヘッダーを受信すると、追加の検証ステップが必要になります。これは、スポットチェックのために特定の履歴ブロックヘッダーをランダムに提供するようにリレイヤーに要求することです。。これは、Flyclient ライトノードに特有の新たな形式の詐欺を防ぐために行われます。具体的な不正手法やスポットチェックアルゴリズムについては比較的複雑であるため、このセクションでは詳しく説明しませんが、以降の事例紹介の章で具体的なクロスチェーンプロジェクトを紹介します。

Flyclient ライトノードは、まさに「象をビスケットに圧縮する」ことを実現し、ターゲットチェーンにデプロイされるソースチェーンライトノードコントラクトを軽量かつシンプルにすることができ、ライトノードサイドチェーンのクロスチェーンをより経済的に実現可能にします。しかし、現在のブロックチェーンのほとんどでは、MMR ルート値はブロックヘッダーの固定部分ではないため、リレーラーは完全なノード自体を実行し、MMR ルート値を計算し、MMR 値をブロックヘッダーに追加して渡す必要があります。ライトノードへ。一部の新しいブロックチェーンでは、すでに MMR ルート値をブロックヘッダーの固定部分にしていますが、既存の比較的成熟したパブリックチェーンの一部では、MMR ルート値をブロックヘッダーの固定構造に追加するソフトフォークアップグレードも提案しています。ブロックヘッダーに固有の MMR 値を持つブロックチェーンは、クロスチェーン開発により適しています。

3.3.4.2 ライトノード契約の「負担軽減」

ライトノード契約の場合、最新のブロックヘッダーの検証が最もガスを消費するリンクです。このリンクの消費量は、ユーザーのクロスチェーンリクエストの数とは関係なく、ブロックの生成速度のみに関係します。ソースチェーン。ソースチェーンのブロック生成速度が速い場合、このリンクのガス消費量が許容できないほど大きくなる可能性があります。

副題

文章

より広範なクロスチェーンネットワークを構築するには、2 つのチェーンだけでなく、多くのチェーンを接続する必要がある場合が多く、各 2 つのチェーン間に上記の双方向のくさびが確立されると、相互の側の関係が確立されます。チェーンの数が増加すると、接続数と適応コストが指数関数的に増加するため、リレーというアイデアが提案されています。リレーチェーンを確立し、他のすべてのチェーンがリレーチェーンに接続されると、自宅の端末機器とルーターを接続するのと同じです。このようにして、コストは n(n-1)/2 から n に即座に低下します (n はチェーンの数です)。

リレー方式はサイドチェーン方式の変形であり、技術方式としてサイドチェーンと分類するのが妥当です。リレー方式はスケーラビリティが高く、現在最も広く使われているクロスチェーン方式ですが、本記事ではリレー方式を完全に説明するために別途記載します。

場合によっては、デュアルチェーンクロスチェーンモデルでは、リレイヤーは独立したブロックチェーンのバリデーターとして動作します。この独立したチェーンは、ブロックヘッダー処理とクロスチェーンメッセージ処理の機能を引き受けるために全体として見なされ、リレイヤーは内部にあります。移動する情報について合意に達します。このタイプの独立したブロックチェーンはブリッジチェーンと呼ばれることが多いですが、リレーチェーンではありません。たとえば、Polygon の PoS ブリッジと Near の PoA レインボーブリッジは単なるブリッジチェーンであり、リレーチェーンではありません。

2 つを区別する鍵は、クロスチェーン通信パスの違いにあります。

ブリッジチェーンは単なるリレーレイヤーのコンテナとして理解でき、その機能は依然としてブロックヘッダーとクロスチェーンメッセージを搬送することですが、リレーチェーンは各アクセスチェーンとの相互サイドチェーン関係を確立するメッセージ転送ステーションです。多くの文献ではこれら 2 つの概念を厳密に区別していませんが、この 2 つの本質は完全に異なります。

3.4.1 既存のブロックチェーンの接続

リレーモードでは、リレーチェーンのバリデーターは多くの場合、リレー機能を引き受けてチェーン間メッセージを転送する責任を負います。双方向アンカリングと比較して、リレーチェーンモードは拡張性が高く、リレーチェーンに接続されているチェーンはアクセスチェーンと呼ばれます。

既存のブロックチェーンに接続するには、リレーチェーンを使用してアクセスチェーンをそれぞれ適応させる必要があります。リレーチェーンモードは接続コストを大幅に節約しましたが、依然として次の課題に直面しています。

異なるアクセスチェーンの特性に応じて異なる適応スキームを策定し、積極的な互換性を実現する必要があるが、これには多大な作業負荷が必要となる。
異なるチェーンのセキュリティは異なり、クロスチェーンネットワーク全体のセキュリティを保護するために、異なるアクセスチェーンのクロスチェーンクレジットの付与が必要になります。
新しいブロックチェーンが次々と登場しており、新しい機能を備えたアクセスチェーンがあれば、新たな適応ソリューションを開発する必要がある

3.4.2 通信プロトコルクラスタ + チェーン構築プロトコル

アクティブな互換性と比較して、よりトラブルのない方法は、まったく新しいブロックチェーンチェーン構築標準を作成することです。この標準に従って開発されたブロックチェーンは、同じ暗号化プリミティブ、コンセンサスメカニズム、および通信アーキテクチャを備えています。パッシブ互換性を実現するためにリレーチェーンに接続されます。クロスチェーンデュオである Polkdot と Cosmos はこのアイデアを実践し、両社が一連のチェーン構築標準を作成し、Polkdot が Substrate を作成し、Cosmos が Cosmos SDK を作成しました。それにもかかわらず、既存の重要なブロックチェーンには積極的な互換性が必要です。 Polkadot と Cosmos はどちらも、イーサリアムチェーンと BTC チェーンを接続するための異種クロスチェーンモジュールを設計しました。

通信プロトコルクラスター + チェーン構築プロトコルのクロスチェーンプロジェクトが楽観的である主な理由は、クロスチェーン問題を完全に解決すると期待されているからです。おそらく、私たちが期待している Wanchain 相互接続のビジョンは、最終的にはネットワーク構造ではなく、ツリー構造です。つまり、特定のリレーチェーンをブロックチェーン世界のレイヤー 0 にし、大部分の同型チェーンを含む他のチェーンを作成することです。少数の異種チェーンは、レイヤー 1、レイヤー 2…の形で接続されます。

副題

3.5 共有バリデーター

Cosmos と Polkadot も通信プロトコルクラスター + チェーン構築プロトコルであり、どちらも中継という概念を含んでいますが、少し注意してみると、この 2 つの違いは非常に大きいことがわかります。

Cosmos のハブとゾーンは典型的な「双方向アンカー」関係を確立します。Cosmos のクロスチェーンメッセージングプロトコル IBC は依然として受信チェーンに組み込まれたライトノードコントラクトに依存してクロスチェーンメッセージの SPV 検証を実行しますが、Polkadot のクロスチェーンメッセージングプロトコル XCMP は、クロスチェーンメッセージの正当性を検証するためにライトノードテクノロジを使用しません。しかし、Paka Labs が抽出し、クロスチェーンテクノロジの別のカテゴリとしてリストされている「Shared Verification People」と呼ばれる別の方法を使用します。 (XCMP と IBC に関する詳細な分析は、後続の章で例とともに実行されます。)

共有バリデータースキームとは、複数のチェーンが同じバリデーターセットを共有するスキームを指し、これらの共通のバリデーターがクロスチェーンメッセージの検証を担当します。 Polkadot は、ブロックの収集と検証を 2 つの機能に分離し、コレクター (Collator) とバリデーター (Validator) という 2 つの役割グループを担当します。各パラチェーンには独自のコレクターがありますが、パラチェーンには独自のバリデーターがありません。ブロックの検証はリレーチェーンのバリデーターの責任です。これは、各パラチェーンがコンセンサスプロセスの一部をリレーチェーンに転送することに相当します。したがって、Polkadot のパラチェーンは、同じブロックチェーンの異なるパーティションのように相互作用でき、追加の信頼メカニズムは必要ありません。

Polkadot では、すべてのバリデーターがすべてのチェーンを検証できるわけではありませんが、より経済的なアプローチを採用していることに注意してください。特定の時点では、各パラチェーンの検証者グループは異なります。各パラチェーンの検証者グループはリレーチェーンによってランダムに割り当てられ、時々再割り当てされます。このようなランダムな割り当てメカニズムを通じて、悪意のあるバリデーターが協力して悪を行おうとしている。この仕組みは、古代中国の宋の時代の軍事制度にたとえることができます。つまり、兵士には常任の将軍はなく、将軍にも常駐の兵士はいません。

最初のレベルのタイトル

4. クロスチェーン技術の枠組みを理解する

現在、約 100 のアクティブなクロスチェーンプロジェクトが存在します。異なるクロスチェーンブリッジは、異なるクロスチェーン技術ソリューションを採用しています。同じ種類の技術ソリューションを使用するプロジェクトは、設計が異なり、システムロールの名前も異なります。分割、追加ロールの作成、マージ役割機能や一部の役割を省略したり、複数のクロスチェーン技術を総合的に活用したプロジェクトなどは、眩しいとも言えますが、クロスチェーン技術の本質をしっかり理解していれば、虚偽を排除し、真実を保つことができます。をしっかり理解しておきましょう。このためには、クロスチェーンテクノロジーを理解するための認知フレームワークが必要です。

チェーン全体で解決すべき問題から始めることができます。

4.1 クロスチェーントランザクションのアトミック性を確保する方法

この問題は、完全なクロスチェーントランザクションが全体として成功するか失敗する必要があり、部分的に成功したり部分的に失敗したりすることはあり得ず、さもなければクロスチェーン機能を使用するユーザーが資産の損失に直面する可能性があることを指します。これを実現するには 2 つの方法があります: 1 つは、ハッシュタイムロックに基づくアトミックスワップスキームなどの暗号化手段を介して、クロスチェーントランザクション内の複数のサブトランザクションを結合する方法であり、もう 1 つの方法は、クロスチェーントランザクションを複数のサブトランザクションにすることです。トランザクションには厳密なタイミングがあり、タイミングには次の 3 つの意味が含まれます。

サブトランザクション 1 が完全に成功した場合にのみ (完全な成功とは、トランザクションがブロックにパッケージ化されてファイナリティを形成することを意味します)、サブトランザクション 2 を実行できます。以下同様に、サブトランザクション 2 が完全に成功した場合にのみ実行できます。サブトランザクション 3 が実行されます。
サブトランザクション 3 が失敗した場合、サブトランザクション 2 の成功ステータスが維持され、ユーザーはサブトランザクション 3 を繰り返し再試行できます。
サブトランザクション 3 が常に失敗した場合、ユーザーはサブトランザクション 2 とサブトランザクション 1 を連続して引き出すことができます。

ハッシュタイムロックを除いて、他のほとんどのクロスチェーンソリューションは、クロスチェーントランザクションのアトミック性を確保するために後者の方法に依存しています。これには、トランザクションがファイナリティを形成したことをどのように判断するかという問題が含まれます。ブロックチェーンには多くの種類のコンセンサスメカニズムがありますが、そのファイナリティ形成メカニズムにより、証明可能なファイナリティと確率的ファイナリティの2種類に分けられます。ブロックは最終的なものであり、元に戻すことはできません。ただし、非 BFT ブロックチェーンの場合、最も長いチェーンが最終チェーンとみなされますが、フォークにより最も長いチェーンが変化する可能性があるため、パッケージ化されたトランザクションが取り消される可能性があります。ブロック内で取引が取り消される可能性が極めて低くなるまで、さらなるブロック確認を待つことです。

副題

文章

ブロックチェーンシステムは、他のブロックチェーンシステムとは独立して閉じられており、各チェーンは「ウォールドガーデン」であり、他のチェーン内のトランザクションとそのステータスを直接認識することはできません。あるチェーンは別のチェーンにとってオフチェーンシステムであるため、あるチェーンを別のチェーンに対して認識することは、実際には神託の問題となります。

したがって、どのようなクロスチェーン技術も、それがどのように進化しても、「仲介者」の役割を避けることはできず、システムは相互に独立しています。マップされたアセットを発行する前にソースチェーンのロックされたポジショントランザクションは完了しましたか?信頼できる「仲介者」が、2 つのチェーン間のクロスチェーンメッセージの送信と検証を担当します。仲介者は、証人スキームでは、単一主体または複数主体の証人セットとして具体化され、サイドチェーン/リレースキームでは、中継器セットとして具体化され、共有バリデータースキームでは、共有バリデーターセットとして実現されます。ハッシュタイムロックテクノロジのみが原則として仲介者を必要としませんが、トランザクションの開始者とカウンターパーティが同時にオンラインである必要があります。エクスペリエンスを向上させるためには、パブリックカウンターパーティとして機能する仲介者が必要です。流動性プロバイダー。

副題

4.3 先取特権資産を安全に保管する方法

クロスチェーン資産移転のシナリオには、保有資産の保管の問題が存在します。前述したように、クロスチェーン資産転送の本質は、資産をソースチェーンにロックアップし、ターゲットチェーン上にシミュレートされた資産を生成することです。したがって、保持された資産の保管セキュリティはクロスチェーンセキュリティの重要な部分です。

カストディアドレスには、独立したコントロールアカウント、マルチパーティマルチ署名アカウント、マルチパーティ秘密キーシャードアカウント、およびコントラクトアカウントの 4 つのタイプがあります。最初の 3 つと監視メカニズムの組み合わせにより、監視メカニズムのさまざまなサブタイプが形成されます。 ; チェーン/リレークロスチェーンソリューションでは、契約アカウントを使用して保有資産を管理します。実際、サイドチェーン/リレーソリューションは、非契約アカウントのカストディソリューションと組み合わせることもできますが、契約アカウントの方がセキュリティが高いため、このように設計されているプロジェクトはほとんどありません。一部のプロジェクトが実際にこのように動作する場合でも、おそらく、これはエスクロー契約の開発が完了する前の過渡的な解決策です。

副題

4.4 マルチチェーン適応の実行方法

サイドチェーン方式のマルチチェーン適応の解決策はリレー方式です. リレーチェーンを通じて, アクセスチェーンとの関係がサイドチェーンとして1つずつ確立されます. アクセスチェーン間でこの関係が確立されるのと比較して,流通コストもはるかに低くなります。それでも、リレーチェーンが複数の異種アクセスチェーンに積極的に対応するのは非常に面倒であり、個別に適応させる必要があるため、通信規格とチェーン構築規格を上から下まで一度確立したほうがよいでしょう。すべて、より多くの新しいチェーンが直接的かつ受動的に互換性のある同型チェーンになるようにします。

監視スキームとハッシュタイムロックスキームは、サイドチェーン/リレーチェーンスキームよりも一般的であり、前者は新しいアクセスチェーンにエスクローアカウントを設定するだけで新しいアクセスチェーンとの互換性が完成しますが、後者はそれを実現します。は、アクセスチェーンがハッシュロックおよびタイムロック機能をサポートしている場合にのみ互換性があります。

副題