Go to Qiita Advent Calendar 2024 Top
LoginSignup
5
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ERC・EIPAdvent Calendar 2023

Day 8
@cardene(かるでね)inCryptoGames株式会社

[ERC6170] 異なるブロックチェーン間でのメッセージ送受信インターフェースの仕組みを理解しよう！

Posted at

はじめに

初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

代表的なゲームはクリプトスペルズというブロックチェーンゲームです。

今回は、メッセージング・プロトコルと相互作用し、異なるブロックチェーン間でのメッセージ送受信を行うインターフェースの仕組みを提案している規格であるERC6170についてまとめていきます！

メッセージングプロトコル
コンピューターシステム間やソフトウェアコンポーネント間で情報を交換するための一連の規則と標準です。
これらのプロトコルは、データの形式、順序、タイミング、および伝送方法を定義し、異なるシステムやアプリケーションが効率的かつ正確に通信できるようにします。

メッセージングプロトコルは、特に分散型ネットワークやブロックチェーンのような環境で重要です。
これらの環境では、異なるノードやコントラクトが互いに通信するために共通のプロトコルが必要です。
メッセージングプロトコルを使用することで、異なるブロックチェーンやレイヤー間でのデータのやり取り、トランザクションの実行、スマートコントラクトの呼び出しなどが可能になります。

例えば、イーサリアムのスマートコントラクトが、ビットコインネットワーク上の別のコントラクトと情報を共有するためには、両者が理解できる共通のメッセージングプロトコルが必要です。
これにより、異なるブロックチェーン技術間での相互作用が実現され、より広範なデジタルアセットの操作やデータの交換が可能になります。

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

6170は現在（2023年12月8日）では「Draft」段階です。

他にも様々なERCについてまとめています。

概要

このEIPは、異なるブロックチェーン間でのメッセージ送受信のための「クロスチェーン任意メッセージブリッジ（AMB）」という共通インターフェースを導入することを目的としています。

この提案は異なるブロックチェーン間で情報を交換する「標準的な方法」を作ることです。
これにより、イーサリアムのようなブロックチェーン上のコントラクトが、ビットコインのような他のブロックチェーン上のコントラクトと簡単にやり取りできるようになります。

具体的な例としては、イーサリアムのコントラクトがビットコインのブロックチェーンにある情報を取得したり、そのブロックチェーン上で何か操作をすることが可能になります。
これは、異なるブロックチェーンが持つ特性を利用して、ブロックチェーンの世界全体の連携を強化することに役立ちます。

特に、ERC20やERC721トークンのようなアセットを異なるブロックチェーン間で移動させたい場合に非常に便利です。
さらに、異なるブロックチェーン間でスマートコントラクトが相互に作用することで、より複雑なデジタルアセットやデータの取り扱いが可能になります。

この規格はあくまでインターフェース（コントラクトの設計）の提案にとどめているため、具体的な実装については取り上げていません。

動機

現在、異なるブロックチェーン間でメッセージを送受信するためのシステム、つまりクロスチェーン任意メッセージブリッジ（AMB）は、統一された規格がなく、Layerzero、Hyperlane、Axelar、Wormhole、Matic State Tunnelなど様々な複雑な方式が競合しています。
これらは、ブロックチェーン固有のものであっても、別のメッセージブリッジであっても同様の問題を抱えています。

ここで提案されているのは、これらのAMBに共通の標準化されたインターフェースを導入することです。
これにより以下のような利点が期待されます。

開発の容易さ

共通のインターフェースがあれば、開発者はさまざまなブロックチェーンをまたいで動作するアプリケーションをより簡単に、かつスケール可能に構築できます。

スケーラビリティの向上

クロスチェーンアプリケーションは、複数のメッセージブリッジをより効率的に使用できるようになります。

セキュリティの向上

現在、各メッセージブリッジは異なるセキュリティ特性を持っています。
たとえば、Layerzeroではリプレイ攻撃を防ぐために「ナンス」が使われていますが、Hyperlaneでは「メルクルルートハッシュ」を使用しています。
標準化されたインターフェースによって、これらのセキュリティ要件を特定の基準に合わせることができます。

堅牢性の向上

オフチェーンコンポーネントを含むメッセージブリッジは、検閲に対して脆弱で、ダウンタイムが発生しやすいです。
その結果、これらの上に構築されたアプリケーションは、大規模な状態移行を強いられることになりますが、これは大規模で複雑なアプリケーションにとってはほとんど不可能です。
標準化されたインターフェースによって、これらの問題を軽減できます。

仕様

この規格に準拠したすべてのクロスチェーン任意メッセージ・ブリッジは、以下のインタフェースを実装しなければなりません。

// SPDX-License-Identifier: Apache-3.0

pragma solidity >=0.8.0;

/// @title Cross-Chain Messaging interface
/// @dev Allows seamless interchain messaging.
/// @author Sujith Somraaj
/// Note: Bytes are used throughout the implementation to support non-evm chains.

interface IEIP6170 {
    /// @dev This emits when a cross-chain message is sent.
    /// Note: MessageSent MUST trigger when a message is sent, including zero bytes transfers.
    event MessageSent(
        bytes to,
        bytes toChainId,
        bytes message,
        bytes extraData
    );

    /// @dev This emits when a cross-chain message is received.
    /// MessageReceived MUST trigger on any successful call to receiveMessage(bytes chainId, bytes sender, bytes message) function.
    event MessageReceived(bytes from, bytes fromChainId, bytes message);

    /// @dev Sends a message to a receiving address on a different blockchain.
    /// @param chainId_ is the unique identifier of receiving blockchain.
    /// @param receiver_ is the address of the receiver.
    /// @param message_ is the arbitrary message to be delivered.
    /// @param data_ is a bridge-specific encoded data for off-chain relayer infrastructure.
    /// @return the status of the process on the sending chain.
    /// Note: this function is designed to support both evm and non-evm chains
    /// Note: proposing chain-ids be the bytes encoding their native token name string. For eg., abi.encode("ETH"), abi.encode("SOL") imagining they cannot override.
    function sendMessage(
        bytes memory chainId_,
        bytes memory receiver_,
        bytes memory message_,
        bytes memory data_
    ) external payable returns (bool);

    /// @dev Receives a message from a sender on a different blockchain.
    /// @param chainId_ is the unique identifier of the sending blockchain.
    /// @param sender_ is the address of the sender.
    /// @param message_ is the arbitrary message sent by the sender.
    /// @param data_ is an additional parameter to be used for security purposes. E.g, can send nonce in layerzero.
    /// @return the status of message processing/storage.
    /// Note: sender validation (or) message validation should happen before processing the message.
    function receiveMessage(
        bytes memory chainId_,
        bytes memory sender_,
        bytes memory message_,
        bytes memory data_
    ) external payable returns (bool);
}

イベント

MessageSent

event MessageSent(
    bytes to,
    bytes toChainId,
    bytes message,
    bytes extraData
);

概要

クロスチェーンメッセージが送信された時に発行されるイベント。

詳細

このイベントは、メッセージが送信されるたびに、バイト数がゼロの転送を含むすべてのケースでトリガーされる必要があります。
これにより、別のチェーンにメッセージが送信されたことを外部のオブザーバーが監視できるようになります。

パラメータ

  • to
    • メッセージの送信先アドレス（バイト形式）。
  • toChainId
    • メッセージの送信先チェーンのID（バイト形式）。
  • message
    • 送信されるメッセージの内容（バイト形式）。
  • extraData
    • 追加データ（バイト形式）。

MessageReceived

event MessageReceived(bytes from, bytes fromChainId, bytes message);

概要

クロスチェーンメッセージが正常に受信された時に発行されるイベント。

詳細

このイベントは、receiveMessage(bytes chainId, bytes sender, bytes message)関数が成功した場合にトリガーされる必要があります。
これにより、別のチェーンからのメッセージが正常に受信されたことを外部のオブザーバーが確認できます。

パラメータ

  • from
    • メッセージの送信元アドレス（バイト形式）。
  • fromChainId
    • メッセージの送信元チェーンのID（バイト形式）。
  • message
    • 受信されたメッセージの内容（バイト形式）。

関数

sendMessage 

function sendMessage(
    bytes memory chainId_,
    bytes memory receiver_,
    bytes memory message_,
    bytes memory data_
) external payable returns (bool);

概要

異なるブロックチェーン上の受信アドレスにメッセージを送信する関数。

詳細

この関数は、指定された受信ブロックチェーンの固有識別子（chainId_）、受信者のアドレス（receiver_）、送信する任意のメッセージ（message_）、およびオフチェーンのリレイヤーインフラストラクチャに特有のエンコードされたデータ（data_）をパラメータとして受け取ります。
この関数はEVM（Ethereum Virtual Machine）と非EVMチェーンの両方をサポートするように設計されています。

引数

  • chainId_
    • 受信ブロックチェーンの固有識別子（バイト形式）。
  • receiver_
    • 受信者のアドレス（バイト形式）。
  • message_
    • 送信される任意のメッセージ（バイト形式）。
  • data_
    • オフチェーンリレイヤーインフラストラクチャ用のブリッジ固有のエンコードデータ（バイト形式）。

戻り値

  • 成功時にtrueを返します。

receiveMessage 

function receiveMessage(
    bytes memory chainId_,
    bytes memory sender_,
    bytes memory message_,
    bytes memory data_
) external payable returns (bool);

概要

異なるブロックチェーン上の送信者からメッセージを受信する関数。

詳細

この関数は、送信ブロックチェーンの固有識別子（chainId_）、送信者のアドレス（sender_）、送信者からの任意のメッセージ（message_）、およびセキュリティ目的で使用される追加のパラメータ（data_）を受け取ります。
送信者の検証やメッセージの検証は、メッセージを処理する前に行うべきです。

引数

  • chainId_
    • 送信ブロックチェーンの固有識別子（バイト形式）。
  • sender_
    • 送信者のアドレス（バイト形式）。
  • message_
    • 送信者からの任意のメッセージ（バイト形式）。
  • data_
    • セキュリティ目的で使用される追加のパラメータ（バイト形式）。

戻り値

  • メッセージ処理/保存の状態を示すtrueまたはfalseを返します。

補足

このEIP（Ethereum Improvement Proposal）は、異なるブロックチェーン間でのやり取りを効率化するための「クロスチェーン任意メッセージングインターフェース」の導入を提案しています。
このインターフェースは、必要な機能を備えながら最小限で軽量な設計を採用しています。
これにより、さまざまなブロックチェーン間でメッセージをやり取りする橋渡し役（メッセージブリッジ）が可能になり、リレイヤー（中継者）レベルでの技術革新の自由度が高まります。

このEIPにより、ブロックチェーンは使いやすく、スケールアップしやすくなると期待されています。
これは、イーサリアムや互換性のある第2層（L2）だけではなく、任意の2つのブロックチェーンを利用してクロスチェーンアプリケーションを構築することが可能になるためです。
例えば、イーサリアムとソラナ間でクロスチェーンアプリケーションを構築することで、それぞれのブロックチェーンが持つユニークな利点を活用できるようになります。

さらに、このインターフェースはアプリケーションやプロトコルにおけるシングルポイントオブフェイラー（SPOF）のリスクを減らすことも目的としています。
つまり、AMBアドレスを更新することにより、アプリケーションは障害が発生しても運用を続けることができるようになります。

シングルポイントオブフェイラー（SPOF）とは、システムやネットワーク内の一点に障害が発生した場合、その一点の故障が全体の機能停止を引き起こす状態を指します。
この用語は、特にIT分野や工学分野でよく使用されます。

例えば、コンピュータネットワークにおいて、すべてのデータが一つのサーバーを通過する場合、そのサーバーが故障するとネットワーク全体が機能しなくなります。
これがSPOFの典型的な例です。
同様に、電力供給が一つの電源からのみ来る場合、その電源に問題が生じた時、全体の電力供給に影響が出ます。

システムの設計においてSPOFはリスクとされ、通常は冗長性を持たせることで対策されます。
つまり、重要な機能や部品はバックアップを持つか、複数の代替ルートや部品を用意しておくことで、一箇所の故障が全体に影響を与えないようにします。
これにより、システム全体の信頼性や耐久性が向上します。

セキュリティ考慮事項

このEIP（Ethereum Improvement Proposal）は、誰でも許可なくメッセージを送信できるシステムが、プロトコルのセキュリティにとってリスクになる可能性があると指摘しています。
このため、メッセージングトンネルを統合する開発者は、その実装を細かくチェックすることが推奨されています。

送信者の認証がない場合、誰でも受信側のスマートコントラクトに任意のメッセージを書き込むことができるため、これは大きな問題です。

このEIPでは、メッセージがどのように送られ、受け取られるべきか、という特定の標準にのみ焦点を当てています。
しかし、統合を行う側は、data_ ラメータを利用して、受信機能内で独自の認証やメッセージトンネルに特有の操作を実装することが可能です。
これにより、セキュリティを高めるための追加的な措置を講じることができます。

引用

Sujith Somraaj (@sujithsomraaj), "ERC-6170: Cross-Chain Messaging Interface [DRAFT]," Ethereum Improvement Proposals, no. 6170, December 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6170.

最後に

今回は「メッセージング・プロトコルと相互作用し、異なるブロックチェーン間でのメッセージ送受信を行うインターフェースの仕組みを提案している規格であるERC6170」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！

5
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?