【完全保存版】MetaplexのOracleプラグインを学ぼう！

当記事はこちらを翻訳・編集したものです。（The Oracle Adapterまでです。）

Oracle Plugin | Core

１　オラクルプラグインとは？

１　概要

オラクルプラグインは、MPLコアアセットやコレクションとは別に、外部の権限によって作成されるオンチェーンアカウントです。

２　利用条件

使用のためには、アセットやコレクションにオラクルアダプタが有効になっており、オラクルアカウントが割り当てられている必要があります。

３　行われる検証について

オラクルアカウントはMPLコアプログラムによって読み込まれ、ライフサイクルイベントに対して検証が行われます。

オラクルプラグインは、作成、移転、焼却、更新という4つのライフサイクルイベントに関するデータを保存し、拒否検証を行うように設定することができます。

オラクルアカウントを更新したり変更したりする機能により、強力でインタラクティブなライフサイクル体験が可能になります。

４　対応可能なもの

MPLコアアセット・MPLコアコレクションで使用できます。

５　許可されている検証結果

オラクルアカウントからオラクルプラグインに返される検証結果は以下の通りです。

• 承認可能　❌

• 拒否可能　✅

• 通過可能　❌

６　オンチェーンオラクルアカウントの構造

オラクルアカウントには以下のオンチェーンアカウント構造が必要です。

７　オラクルアカウントのオフセット

アカウントのフレームワーク（Anchor、Shankなど）によってディスクリミネーターのサイズが異なります。

翻訳者注
ディスクリミネーター（Discriminator）とは、データ構造やアカウントが特定の型や構造であることを識別するための識別子です。

そのため、アカウント構造がわずかに異なる場合があります。

１　NoOffset

オラクルアカウントのデータセクションの最初にOracleValidation構造体がある場合、ValidationResultsOffsetにはNoOffsetを選択します。

２　Anchor

オラクルアカウントがOracleValidation構造体のみを含み、Anchorプログラムによって管理されている場合、ValidationResultsOffsetにはAnchorを選択します。

Anchorアカウントディスクリミネーターの後に構造体を配置できるようにします。

３　カスタム

オラクルアカウント内の他の場所にOracleValidation構造体が配置されている場合、カスタムオフセットを使用します。

８　オラクルアカウントの更新

オラクルアカウントは作成者/開発者によって作成・維持されるため、OracleValidation構造体はいつでも更新可能です。

これにより、ライフサイクルは動的に管理されることができます。

９　オラクルアダプタ

オラクルアダプタは以下の引数とデータを受け入れます。

翻訳者注
①ベースとなるアドレス、②そのアドレスの仕様、③オフセット情報（デフォルトはNoOffset）からなるのですね。

１０　オラクルプラグインのPDA（プログラム派生アドレス）の宣言

オラクルプラグインアダプタのデフォルトの動作は、アダプタに静的なbase_addressを提供し、それを読み取って結果として得られた検証結果を提供するものです。

より動的にオラクルプラグインアダプタを使用したい場合は、program_idをbase_addressとして渡し、さらにExtraAccountを使用して、オラクルアカウントアドレスを指す1つ以上のPDAを導出することができます。

これにより、オラクルアダプタは複数の導出されたオラクルアカウントからデータにアクセスできます。

なお、ExtraAccountを使用する場合、他の高度な非PDA仕様も使用可能です。

１１　ExtraAccountのオプション一覧

全てのアセットに共通のExtraAccountの例としては、コレクションのPubkeyを使用してオラクルアカウントを導出するPreconfiguredCollection PDAがあります。

より動的なExtraAccountの例としては、所有者のPubkeyを使用してオラクルアカウントを導出するPreconfiguredOwner PDAがあります。

２　オラクルプラグインの作成と追加

１　オラクルプラグイン付きのアセットの作成

下のように、「create」関数の中で追加していますね。

２　アセットへのオラクルプラグインの追加

「addPlugin」を使っています。

プラグインの中身はほぼ同じですね。（baseAddressConfigは今回省略したのですね。）

３　コレクションへの追加

やはりやっていることは同じです。

関数が変わっただけですね。

３　使用例について

１　特定期間の利用の禁止

資産は、UTCの正午から深夜までの間は譲渡できません。

任意のプログラムでオンチェーンのオラクルプラグインを作成します。

オラクルプラグインアダプターを資産やコレクションに追加し、拒否検証を行いたいライフサイクルイベントを指定します。

あなたはcron（スケジューリングプログラム）を作成し、正午と深夜にオラクルプラグインに書き込みと更新を行い、true/false/trueの検証ビットを反転させます。

翻訳者注
この辺がちょっとイメージ湧きにくいですが、正午になったら、「false」にして、深夜になったら、「true」にするのですね。
これを元に拒否検証を行うようです。

２　特定条件下での更新

資産はフロア価格が10ドル以上で、かつ資産に「赤い帽子」の属性がある場合にのみ更新できます。

任意のプログラムでオンチェーンのオラクルプラグインを作成します。

拒否検証を行いたいライフサイクルイベントを指定して、オラクルプラグインアダプターを資産に追加します。

開発者は、同じ事前設定された資産アカウントを導き出すオラクルアカウントに書き込めるAnchorプログラムを作成します。

開発者は、マーケットプレイスで価格を監視し、「赤い帽子」の特性を持つ資産のハッシュリストを知っているWeb2スクリプトを作成し、関連するオラクルアカウントに更新を行って書き込みます。

翻訳者注
つまり、「10ドル未満」または「赤い帽子でない」という条件の場合には「false」に設定するのだと考えました。
そして、「false」かどうかを拒否検証して、通った場合は更新可能とするのだと思います。