SolanaにAI判定が到着しても、決済が完了したわけではない理由 @GenLayer SolanaのAIエージェントマーケットが、作業品質の判定をGenLayerに委託すると仮定しましょう。 検証者が結果に合意したとしても、Solana上でどのアカウントに報酬を記録するかは別の問題です。 GenLayer Foundationが公開したブリッジコードには、LayerZero V2とEVMハブを経由してGenLayerとSolanaの間でメッセージを伝達する構造が含まれています。 ここでAI判定を実行する場所と、その結果によってアプリの状態を変更する場所は分離されています。 Solana側でメッセージを受信する方法は、アカウントの構成によって異なります。 受信アカウントが事前に固定されている場合、DirectCpiReceiverパスを通じて登録された受信状態を即座に更新できます。 実際の外部プログラム呼び出しは、受信プログラムに応じて追加で実装する必要があります。 一方、注文やユーザーごとに変更されるアカウントが異なる場合、メッセージはまずStoreAndClaimで保存され、その後claim_message呼び出し時に必要なアカウントを指定します。 Solanaはトランザクションを実行する前に、使用するアカウントのリストを指定する必要があります。 したがって、ブリッジがメッセージを受け取ったという事実だけで、ユーザーへの決済が完了したと表示してはいけません。 メッセージの送信元も、判定とは別に検証されます。 公開実装は、信頼できるピアを検証し、一意のmessage_idを使用して同じリクエストの重複処理を防ぐように設計されています。 しかし、重複防止や正常なメッセージ伝達は、AI判定内容自体が正しいという証拠とは異なります。 私がStudioでPolicyGuardを作成する際に取り組んだのは、ドキュメントのルールが実際に変更されたかどうかを判定する問題でした。 他のチェーンのサービスにその結果を接続するには、判定基準だけでなく、伝達・受信・決済状態も同時に設計する必要があることを、今回のブリッジコードから確認できます。 現在公開されているリポジトリには、Base SepoliaとSolana Devnet間の双方向テスト記録がありますが、これをGenLayer AI判定を用いる商用Solanaサービスの運用実績として受け入れてはいけません。 クロスチェーンAIアプリに必要な成功の証拠は、以下の3つに分けられます。 GenLayer判定の最終確定、信頼できる送信元からのメッセージ、目的先アカウントの実際の状態変更。 公開コード: https://t.co/N4zVSxjYG7 #GenLayer #GenLayerDOKDOPioneer