⚔️
Cross-chain Communication系サービスのまとめ
最近様々なcross-chain communication系のプロジェクトがでてきてるので、LI.FIの記事から抜粋してまとめました。
LI.FIではcross-chain communicationのサービスをAMB（arbitrary messaging bridges）と定義しているみたいです。
前提知識を伴うもの説明を省いたり、詳細まで調べられてなかったりするのでメモ程度です。
最後に、感じたこと & 気になったことをまとめています
Multichain
【概要】
- Anyswapの前身
- SMPC(Secure MPC)ネットワークの参加者が署名する
- Lock & mint方式
- NFTブリッジもできる
【仕組み】
- クロスチェーンブリッジ（２つのチェーンのみ）
- userがsourceチェーンで分散管理アカウントに送信
- 分散管理アカウントで受け取りを確認したらdestinationでMPCでmint
- クロスチェーンルーター（２つ以上のチェーン）
- 概要
- すでに発行済みのもの（ネイティブトークン）は流動性プールを利用
- 手順
- UserがEthereumで100USDCをプールに追加
- Ethereumで100anyUSDが発行
- SMPCネットワークが検知し、Fantomで100anyUSDを作成
- EthereumでanyUSDをburn
anyUSDの差額は流動性に残されたり多くはらわれたりする
- multichainを使って最初にbridgeしたものはLock&Mint、すでにbridgeされているものは流動性プールを用意
- 概要
【セキュリティ】
- SMPCを信頼する必要がある
- connectivity and statefullnessを実現するために犠牲にしている
- オンチェーンアクティビティーの監視を常に行っている
- simplicity = security
- 不必要なコードを入れない
- ノードは誰でもなることができる（
ステーキングとかいらない？）。増えれば増えるほど良く、今までハッキングされたことはない - v2の時は脆弱性があった
【あとがき】
- EVM以外にも対応している数少ないプロトコル
Across
【概要】
- 最初はL2-L1に特化していた、V2になってからL2-L2をしている
- 片面の流動性提供
- relayer
- bridgeを手助けする人
- Optimistic oracle（UMA）にtxを提出し、意義がない場合に流動性から資産を引き出せる
- Optimistic Oracleに事前に資産を入れておく必要がある
いくらくらい？
- bridgeには、fastとslowがある。低速は単にsourceで資産を受け取ったけど、destでbridgeする資産がなかったか待ってくれってこと
【トランザクションの流れ】
- L1で十分に流動性を確保しておく
- L2でuserがbridgeを要求
- A Relayer posts a bond, along with the details of the transaction
what is bond?
- relayerがfastかslowを選択してrelayする
- 誰でも不正がどうか検証できる
- 資産を受け取ったらuserは手数料を支払う
【手数料】
- ①L2-L1はORの場合だと7日間かかるので、その金利分をaaveから取得し手数料にしている
- ②relayerへの手数料
- 詳細
【セキュリティ】
- Optimistic Oracleに依存している
- UMAトークンの50%以上を保有されたら悪意が起こる可能性がある
【今後】
- コミュニティーに移譲する予定
Nomad
昔調べたものがあったのでそこから抜粋
【トランザクションの流れ】
- source chainでtokenを送信
- 送信データをMerkle tree (message tree)に追加
- UpdaterがMerkle treeに署名をして、Relayerがsource chainに送る
- Watcherがsource chainで30分のfroud-proof
- 問題なければProcesserが承認
【ハッキングの原因】
- 前提
- NomadはBeacon Proxy PatternでUpgradableにしている
- Proxy patternではProxy に対してtxを投げProxyからImplementation ContractにdelegateCallする
- つまり、Proxyでstateを管理し、ImplementationでLogicを管理する
- 運用の際はImplementationコントラクトに意味はないが念のため、このコントラクトのinitializeを0xで叩いておく
- 原因
- Replica contract（Nomadのcore contract）をアップグレードする際に、ImplementationからInitializeを呼ぶ必要があった
- だが、間違えてProxyのconstructorの中にinitialize入れてたので、Proxy deploy時にinitializeが叩かれ0x00..が登録されてしまった
- Proxy contract address
- Implementationのcontract
- その際に0xのproofが登録され、そのproofを使ってbridgeされるようになった
- 0x00..が登録されてたしか言ってなくてどんなプロセスで0x00..が登録されたかを説明してる記事ほとんどなかった
https://rekt.news/nomad-rekt/](https://rekt.news/nomad-rekt/
Synapse
【概要】
- ETHとステーブルコインの流動性bridgeで始まったが、クロスチェーンメッセージングも始めている
- optimistic model = 一人でも正直な人がいればよい
- Cosmosへの接続（Axler, Gravity）と豊富なSDK
- Synapse chainのローンチ予定
【参加者】
- Notaries : それぞれのchainでmerkle rootを署名する人
- Broadcasters : home contractからreplica contractに更新を送信する
- Guards : メッセージを監視し、fraudproofを提出する
- Executer : optimistic window finalize後にdestでtxを送信
【トランザクションの流れ】
- source chainのmesseging contractにuserがtxを送信する
- messeging contractでtxをhash化し、merkle treeに追加する
- Notaryが署名する
- Guardsがproofに署名することで,guardが監視していることを知らせる
この時点では検証してない？
- Broadcasterがdestination chainに送信する
- Guardsが検証する
- optimistic window終了後にexecuterがtxを実行
【セキュリティ】
- Synapse chainはOptimistic rollup
- ガバナンス参加に最低10,000,000SYN必要
- Audit by
- PeckShield
- Certik、OpenZeppelin、Quantstamp for AMM contract
【疑問】
- `homeとreplicaが何か
- メッセージの詳細とどのようにexecuteしてるのか
- 全てのmessageをmerkle treeにしてる
- optimisticの検証方法
LayerZero
【概要】
- シンプル ： 開発者はLeyarZeroの受信と送信のみを組み込むだけ
- light client : オンチェーンにlight clientを置くのではなく、oracleとraleyrの二段構えのLight clientを実現している
- LayerZero scanを用意している
【トランザクションの流れ】
- トランザクションの識別子、実行するtxのデータ、destで実行するコントラクトの識別子など、txに関わる情報をcommunicatorに送信する
- Cummunicatorがデータをパケットとしてvalidatorに送信する
- validatorがrelayerに対してdestにtxを送信するように通知
- layerzero networkがblock id（block number?）をoracleに送信し、source chainのblock confを一定程度まち、指定のblockhashをdest chainに送信する
- validatorからrelayerにblockhashが送られる
- relayerは指定のblockにあるtxlistをdestに保存
- validatorがblockhashとtxlistを検証する
- 検証が終わったらcommunicatorにpacketとして渡す
【参加者】
- LayerZero Endpoint : それぞれのchainにあるコントラクト
- Network、Validator、Communicatorを管理している
- communicator : LayerZero Endpointを監視し、メッセージングが発生したらvalidatorに伝達
- network : oracleにblockhashを要求しvalidatorに伝達する
- validator : relayerに特定のブロックに含まれるtxlistを要求し、blockhashと検証する
- oracle ： sourceのblockhashをvalidatorに伝達する
- セキュリティ
- realeyrとoracleが共謀したとしても、特定のoracleとrelayerの話なのでネットワーク全体には影響がない
- シンプルendpointのみの提供をしている
- 独自のrelayerを構築できるため、oracleが不正してもrelayerで防げる
- pre-crime : dest chainをフォークしローカルでtxを試し悪意があるtxは弾くようにしている
- audit
- Quantstamp、Zokyo、Zellic、Trail of Bitsなど20以上
【疑問】
- relayerが検証するtxproofの形はどんなの？blockhashの検証？
- packetとは？なんでpacketにしてる？
- どこまでがオンチェーンで行われているか？（blockhashとtxlist保存とvalidation部分のみ？）
- relayerとoracleの分散性の現状。分散してもネットワークが成り立つかどうか
Hyperlane
【概要】
- 前身はAbacus
- クロスチェーンのオンチェーンAPI
- セキュリティ担保のために独自のバリデーターを追加できる
- DAOで運営
【トランザクションの流れ】
- 全てのチェーンで一つのIndoxとn-1のOutboxがある
- source chainでOutbox.dispatch()をcallする
- message, dest chain id, recipient addressなどが含まれる
- source chainのvalidaor setにより、Outboxの最新のMerkle rootは署名される
- application specificなvalidatorがいる場合はそれらも含まれる
- InboxValidatorManager.process()でdestにmessageを配信
- the message’s Merkle proof, the message, the signed rootが含まれる
- InboxValidatorManagerによる検証の後に、recipient.handle()を実行してmessageをapplicationに配信
【セキュリティ】
- validator setはPoS
- ABCtokenをstakeしdelegateすることでvalidatorを選択することができる
- 独自のvalidatorを追加できる
- 一つのメッセージではなく、Outbox全てのmessageをまとめたMerkle treeを署名するのでCensorship resistanceになる
- チェーンごとにvalidator setがあるので、全てのチェーンで同じセキュリティーではない
Axelar
【概要】
- Cosmosベースのチェーンなので、Osmosis, Junoにも対応している
- Axelarscanを用意している
- とにかく繋ぎ込みやすい！って書いてある
- 単一validatorによる署名、foundationによるgasの補填を行った、などなど
- curve on polygonのalUSDC/USDCプールは常に上位にある
- ほかプロジェクトと積極的に連携、チームメンバーぼ専門知識を持っている人が多い
【トランザクションの流れ】
- 前提
- ２つのレイヤーがある
- Core Infrastructure Layer
- txをexecuteするvalidator setの管理
- 他のblockchainと繋ぐgatawayもある
- Application Development Layer
- 開発者がCore Infrastructure Layerを使いやすいようにAPI/SDKを作っている
- userがbridgeのリクエストを行い、axelarのvalidatorがconfirmするのを待つ
- Validatorはsource chainを確認し、txが行われたかの投票を行う
- validatorの賛成が閾値を越えたら、sourceでのtxがaxelarで承認される
- 承認されたtxのリストをMPCを使って署名を行う。 quadratic votingが閾値を越えたら。
- 署名をGatewayに送信しrelayされ、destでtxが実行される
【セキュリティ】
- 何か問題があった場合にfreezeできる機能がある
- validatorはAXLのstakeする、今は最大50validator
- validatorの2/3の署名が必要。アプリケーション別にvalidatorとrelayerを選出することが可能
【疑問】
- destで叩くときは署名のを行ってから叩いてる？
- validatorによるsource txの検証はオフチェーンでやって、その結果をon-chainに書き込んでる感じ？
残り
- hyphen
- celer
- wormhole
- orbit bridge
- zeta chain
- Gravity
感じたこと
- Acrossの手数料徴収はおもしろかった
- destでuserがtxを実行することでcross chain messageを実現する設計にしておくと、destでのcomposabilityが上がりそう
- USDCのCCTPと同様：https://twitter.com/_ywzx/status/1617510334406840320
- チェーン間のtxはある程度限られた種類になるので、LayerZeroのようにtx typeをつけた設計は検証の範囲を限定できるためセキュリティ的によいと感じた
- Layer Zeroで独自にrelayerをたてoracleの検証をこなうこと、Hyperlaneの独自のvalidaorの追加はセキュリティを高める観点でよいと感じた
- どこもバグバウンティやっている
気になったこと
- 各プロジェクトで疑問点はまとめた
- validatorやrelayerは何かしらの資産をdepositしてると思われるが、閾値はいくらくらいなのか
- LayerZero、Hyperlaneあたりはmessageの抽象度をあげた設計になっているので、どのように網羅的に検証をしてるのが気になった
Discussion