🙆

[Astar]コントラクト備忘録28(クロスコントラクトについて)

2023/03/05に公開

本日は、クロスコントラクトについて学びました。

こちらがかなりしっくり来ましたので、日本語訳をしつつ、解説いたします。

https://substrate.stackexchange.com/questions/4778/how-does-cross-contract-calling-with-openbrush-work-exactly

プロジェクトでの作業中、2種類のクロスコントラクトの相互作用が発生することがあります。

  1. あるコントラクトが別のコントラクトをインスタンス化する場合。
  2. あるコントラクトが、すでにインスタンス化された別のコントラクトのメソッドを呼び出すとき。

つまり、このようになります。

OpenBrushのWrapperでは、この後者のインタラクションを行うことができます(必要なのはTraitの知識だけです)。将来的には、改良され、最初の種類もできるようになる予定です。

現在は、下のような状態のようです。

{}Ref({}はコントラクトの名前)は、両方の種類のインタラクションを行うことができますが、依存関係として別のコントラクトをインポートする必要があります。

Refのコンストラクタを呼び出して、引数を渡すことができます。コンパイル時にink!はそれをホスト関数の低レベル呼び出しに展開します。しかし、引数以外は指定も必要です。

つまり、こういうこと?

endowment - 転送したいトークンの量。コンストラクタが支払い可能であることが必要であることを忘れないでください。
code_hash - デプロイされたコントラクトのコードハッシュです。
salt - 1つのトランザクション中に複数のコントラクトをデプロイしたい場合、各コントラクトはいくつかのソルトを付けてデプロイされるべきです。これは、コントラクトを一意にするために必要なものです。この例のバージョンは、新しいコントラクトをデプロイした後に、毎回インクリメントされる数値です。

これまでの部分のchatGPTの説明です。

chatGPT

OpenBrushの例では、{}Refとwrapperの両方を使用しています。{Refは、コントラクトをインスタンス化するために使われます。Wrapperは、コントラクトの相互呼び出しに使われます。

あなたの質問の答えになることを願っています。もしそうでなければ、コメントで質問していただければ、投稿を編集します。

今回は以上です。

Discussion