見出し画像
Photo by fairview_square

クロスチェーンを見てみる ~TOKI② IBC~

bamb00.eth

概要は読んだけど、肝はきっとブリッジ部分の仕組み
TOKIについてはIBCを掘ってみる


特徴1：IBCのマルチ・プローバー・セキュリティ

  • 前提として、相互運用性担保して、エコシステム発展させるためには標準規格（IBC）の採用が必要

  • ただ、IBCの中でもブリッジの方式にいくつか選択肢があり、それぞれ一長一短がある

  • TOKIにおいては、運用コストが低い＆一定セキュリティも見込めるTEEを採用しつつ、重要な取引の訴求的な検証においては ZK-Proofを用いる。このことで相互補完を行う

なぜIBCなのか？

その答えは、IBCが他とは異なる真に包括的でオープンなメッセージング標準だからです。

最も包括的
IBC標準は、真にパーミッションのない接続と、非同期を含むあらゆる一般的なトランザクションのみを可能にします

ベンダーのロックインなし
 IBCは、ビジネスモデル、トークン、ビジネス上の利益に縛られない唯一のオープン・プロトコルであり、今日のTCP/IPのような完全な自由と柔軟性を保証します

実績No.1
月間29億ドルの取引量、悪用ゼロ、膨大な開発者コミュニティの貢献により、IBCは真に傑出しています。
さらに、1970年代や1980年代のプロトコル戦争のような、特定のエンティティ、ビジネスモデル、トークン、IPに結びついたスタンドアローンの標準は、長期的には生き残れないことは歴史が示している。

なぜマルチ・プルーバー・セキュリティなのか？

チェーン間の状態遷移の妥当性を検証するとなると、「どのように」検証するのか、そして「誰が」検証するのか、という2つの重要な疑問が生じる。 それは、「どのように」検証するかということと、「誰が」検証するかということである。 どのように検証するかについては、大きく分けてフルノード検証とライトクライアント検証の2つのアプローチがある。

フルノード検証
 現在のブリッジのほとんどがこの方式を採用している。 技術的に単純であるが、メンテナンスコストが高く、分散化にも限界がある
ライトクライアント検証
TOKIでは、軽量で効率的なライトクライアント検証方式を採用している

誰が検証するのか？

誰が、どこで、ライトクライアントを使用して検証するのかは、セキュリティを確保する上で極めて重要である。 いくつかのアプローチを紹介する。

コネクテッド・チェーン：Connected chains
このアプローチでは、接続された各チェーンにライトクライアントのスマートコントラクトを実装する。 最も信頼を最小化できる方法だが、特定のブロックチェーン、特にイーサリアムでは現在実行不可能である

ミドルPoSチェーン（経済的セキュリティ）：Middle PoS Chain (Economic Security)
 この方法は、PoSチェーンを仲介して証明の検証と提出を行う。 経済的な安全性は確保できるが、ブリッジとしては非効率的で持続不可能である。 例えば、5億ドルのFDVを持つPoSチェーンを維持し、トークンの7%をバリデータに割り当てる場合、年間約3,500万ドルのコストがかかる

TEE（ハードウェアセキュリティ）：TEE (Hardware Security)
このアプローチでは、SGX のような TEE 内にライトクライアントロジックを実装する。 TEEは実際には悪用されておらず、その高いセキュリティレベルが証明されています。 また、TEE はコスト効率と最小限のレイテンシを提供する。 しかし、潜在的なバグが懸念される

ZKP（ソフトウェア・セキュリティ）：ZKP (Software Security)
 この方式は、ゼロ知識証明（ZKP）を使って軽いクライアント・ロジックを実装する。 この方式は高度にトラスト・ミニマム化されているが、まだ始まったばかりであり、潜在的なバグ、高いガスコスト、待ち時間がある

マルチシグ：Multi-sig
このアプローチは何度も危険にさらされており、信頼性が低い。 また、フルノードに依存する傾向がある

要するに、万能の解決策はないのだ。 では、何が答えなのか？
それは、マルチ・プルーバー・セキュリティ・モデルであり、それぞれの方式の弱点を補うものである。
TOKIはTEEとZKPを組み合わせ、近い将来、経済的なセキュリティも取り入れる予定です。 これが、TOKIのマルチ・プルーバー・セキュリティ・モデルのハイレベルなアーキテクチャです。


TEEプルーバー：TEE Prover
検証プロセスを処理し、プライマリ・プローバとしてプルーフを生成する。 TEE ノードはステートレスであるため、運用コストが大幅に削減されます。 

ZKプルーバー：ZK Prover
TEE プローバ間の論争を解決し、高価値移転などの特定のケースに使用されます

経済的セキュリティ：Economic Security
 マルチプローバのセキュリティモデルを効果的に強化します。

マルチ・プローバの設定を行うモジュールをライト・クライアント・プロキシ（LCP）と呼んでいます。 LCPを利用することで、どのようなアプリケーションやブロックチェーンでも簡単に独自の設定を行うことができ、低い運用コストと強固なセキュリティの恩恵を受けることができます。 この柔軟性により、様々な事業者がLCPを設定することができ、下図に示すように分散化を促進し、イノベーションを加速させることができる。 LCPがなければ、少数の支配的なブリッジ・プロトコルがすべてをコントロールすることになり、これは望ましくない結果です。

特徴1について、もう少し追ってみる

結局LCPノードは何をやっているのか？

LCPのドキュメントを読んでみる

ざっくりな理解だが、LCP Nodeはリレーヤーから依頼されたトランザクショの検証を行い、検証が行なったことを示す署名を生成している。
そして、宛先チェーンにて、LCP Nodeで生成された署名を検証することで、トランザクションの内容が正しいことを確認しているよう

LCPのアーキテクチャ

  1. 最初にRelayerはchainA上でchainB宛のPacket送信を検出する

  2. RelayerはLCP NodeのAppにchainAを検証するように要求する

  3. LCP Node内で検証及び検証したことを示す署名を生成

    1. AppはLCP EnclaveにPacketを検証するためにVerifyPacketCommandを送信する。また、Handlerはcommandをhandleし、ELCにpacketの検証を要求する。

    2. ELCはchainAに対応するLight Clientによりpacket commitmentを検証し、そのcommitmentにEnclave Keyにより署名を行いproofを生成する

    3. 3-2.のcommitmentとproofをEnclaveは返し、AppはそれをRelayerに返す

  4. Relayerは3-3のcommitmentとproofをchainBに提出し、chainB上のLCP Clientによりpublic Enclave Keyを用いて検証される

LCP Nodeの署名の信頼性はどのようにして保証されるか

Intelのハードウェアの規格及びその検証の仕組みに依拠する形になっている

  • LCP Nodeの起動直後にIntelで作成している規格に沿って、鍵の生成が行われる

  • 鍵の真正性はIntel Attestation Service(IAS)を介して検証され、LCP Client（宛先チェーンのコントラクト等）に登録される

Enclave KeyはEnclave内のKey Managerにより生成・管理される署名鍵である。ELCは、この鍵を用いてcommitmentに対してsignを行うことでcommitment proofとしてsignatureを生成する。このsignatureは、on-chainのLCP Clientにより検証される。 なお、この文書ではEnclave keyの公開鍵を特にpublic Enclave keyと呼ぶ。

Key generation​
Enclave Keyの生成は、LCP Nodeの起動直後にAppによるInitEnclaveCommandの実行により行われる。生成されたEnclave KeyはLCP Node内でSGXが提供する]Sealing機能を用いて暗号化した上で保存される。Appの再起動時にはそれをUnsealingした上でメモリ上に再度読み込まれる。Sealing Policyとしては、MRENCLAVE policyを用いる。これにより、LCP Enclaveの更新後に再起動した際に以前のバージョンで暗号化されたEnclave Keyを再利用することを防ぐ。

Enclave Keyのsignature algorithmは変更可能であり、これによりEVMにおいて不要なprecompiled contractの追加を避けることができる。現在、signature algorithmとしてECDSA(secp256k1)をサポートしている。Seedには、sgx_read_rand(内部ではRDRAND op)を用いることで、Enclave外からは読み取りが不可能なseed値を得ることができる。このseedを元に、Enclave Keyを生成する。

Remote Attestation​
LCP Clientは、ELCのcommitmentを検証するためにEnclave Keyをtrustlessに登録する必要がある。このために、public Enclave Keyを含むLCP Enclaveに対してのQuoteを生成し、Remote AttestationによりVerifiable Quoteを生成する。このVerifiable QuoteはQuoteに関連づくenclaveが生成したことを検証可能にする。つまり、検証されたVerifiable Quoteの中に含まれるreport dataは期待するenclaveにより生成された、妥当なEnclave Keyである。

このRemote Attestationの実行は、新規LCP Nodeの起動、またはEnclave Keyの更新ごとに行う必要がある。

https://docs.lcp.network/ja/protocol/enclave-key

LCP Nodeが生成したQuoteは、Intelが定めるIASを介することでその真正性を検証できるよう

EKを生成〜IASを利用したQuoteに対するAVR受領までのフロー

特徴2：シングルサイドの統合流動性プール

  • まずは概要レベルを貼付
    （追って更新します、、）

先に説明した堅牢なメッセージング・レイヤーを基盤に、TOKIはファーストパーティーのアプリとしてシングルサイドの統合流動性プールを導入します。 この革新的な機能により、ラップトークンの複雑な管理が不要になり、異なるチェーン間でワンクリックで簡単にネイティブトークンのスワップが可能になります。

利点

スワップユーザー（For Swap Users）
ワンクリックでネイティブトークンを転送できるため、転送先チェーンでのトランザクションの失敗を心配する必要がありません。

流動性プロバイダー（For Liquidity Providers）
無常的な損失がなく、優れた資本効率と安全性が向上します。

私たちは、異なるブロックチェーンにまたがる片側流動性プールを仮想的に接続することで、普遍的な統一流動性ネットワークを構築し、上記のような大きなメリットを提供します。
もちろん、このシステムは、私たちの基盤となるメッセージングレイヤーの堅牢な特性を継承しています。

ワンクリック・ネイティブ・トークン転送（One-click native token transfer）


片面流動性プール

深い流動性を確保するため、TOKIトークンを発行し、流動性プロバイダーにインセンティブを与え、エコシステムの成長をサポートします。

特徴3：サードパーティアプリレイヤー（3rd-party app layer）

TOKIのインフラは、メッセージングレイヤーと流動性レイヤーの両方において高いコンポーザビリティを提供し、スワップ、送金、NFT購入、レンディングなど様々なユースケースにおけるクロスチェーン取引の複雑さを抽象化します。 TOKIのインフラを利用した注目すべき実績の1つは、日本の法律に準拠した安定コインの発行を可能にするプラットフォームを提供するProgmatとの連携です。 この統合により、TOKIはUSDCのCCTPと同様に機能し、チェーン間のシームレスなステーブルコイン送金を促進する。


この記事が気に入ったらサポートをしてみませんか？