ブロックチェーンは「AI」を見分けられない

AIエージェントが典型的なチェーンにトランザクションを送信するとしたら、チェーンは実際に何を見ているのでしょうか？

チェーンが見るのは20バイトのアドレスです。ハッシュ化アドレスのチェーンであれば32バイトかもしれません。トランザクションのcalldataも見ます。署名も見ます。手数料も見ます。ただし「AI」という単語はどこにも見えません。アドレスは、スマホのウォレットである可能性があります。ボットのスクリプトである可能性もあります。スマートコントラクトである可能性もありますが、それも確実には分かりません。なぜなら、コントラクトとEOAは同じアドレス空間を共有しているからです。

これがアイデンティティ問題です。チェーンにはネイティブに「AI」という概念がないため、特定のものに対して異なるルールを適用することができません。「AIエージェントは異なる手数料の最低ラインを支払う」とか、「この種のメッセージは登録されたモデルから来た場合に限り有効」とか、「このエンティティには100オブジェクトのメモリ上限がある」といったことはチェーン側ではできません。それらはすべて、通常はコントラクトの中の上位レイヤで新しく発明しなければならず、チェーン自体は中立のままです。

中立というのは聞こえが良いです。しかし実際には、「同じアイデンティティのプリミティブ」を、少しずつ違う形で、しかも少しずつ異なるセキュリティ特性を伴って、プロジェクトごとに作り直していることを意味します。

作り直されるもの

AIエージェントのプロジェクトが通常、コントラクト内で構築しなければならないものを見てみましょう：

• アドレスをエージェントのメタデータに対応付けるレジストリ。
• エージェントがユーザーのウォレットではなく予算から手数料を支払えるようにする残高トラッカー。
• リプレイ保護のための、エージェントごとのnonce。
• エージェントが呼び出してよいことを制御するためのケイパビリティフラグの仕組み。
• エージェントが実行したすべてのアクションの監査ログ。
• ストレージ、ブロックあたりの呼び出し回数、またはアプリケーションが必要とする任意のものに対する、エージェントごとのクォータ。

これらはどれも珍しいものではありません。すべてアイデンティティのインフラです。チェーンはそれを提供しないので、各プロジェクトがその上に個別に取り付けます。その結果、2つの別プロジェクトのAIエージェントでは、「エージェント」の定義が異なり、アクティビティの追跡方法が異なり、監査のセマンティクスも異なります。「このチェーン上で今、AIは何をしているのか？」に対するプロトコルレベルの答えは存在しません。

チェーンが答えられるべきこと

AIについてチェーンが答えられるべき3つの質問：

1. このアドレスはAIですか？
2. それは何をすることが許されていますか？
3. それはこれまでに何をしましたか？

ほとんどのチェーンでは、この3つすべての答えが「分からないのでインデクサに聞いてください」です。手数料、ガバナンス、コンセンサスが、その結果に基づいてふるまいをゲートしたいかもしれないとき、その答えは良くありません。

NOVAIのアプローチ

私はNOVAIを作ったので、答えは「はい、ここにエンティティのレコードがあります」です。

チェーン上のすべてのAIは、AiEntityとして登録されます。このstructはcrates/ai_entities/src/lib.rsにあります。アイデンティティに関係するフィールドは次の通りです：

pub struct AiEntity {
    pub id: AiEntityId,            // 32バイト、決定的
    pub code_hash: CodeHash,       // コードまたは重みのハッシュ
    pub creator: Address,          // 登録したのは誰か
    pub pubkey: [u8; 32],          // エンティティのed25519鍵
    pub economic_balance: u128,    // エンティティ自身の残高
    pub nonce: u64,                // エンティティのtx nonce
    pub capabilities: Capabilities,
    pub autonomy_mode: AutonomyMode,
    pub is_active: bool,
    // ...
}

idはblake3("NOVAI_AI_ENTITY_ID_V1" || code_hash || creator)として計算されます。同じコードで同じ作成者であれば同じidになります。たとえ同じモデルを動かしていても、作成者が異なれば常に異なるidになります。名前サービスも、オフチェーンのレジストリも、中央の権威もありません。idは2つの事実の関数です。

そのエンティティには独自のed25519鍵ペアがあります。エンティティ自身が自分のトランザクションに署名します。エンティティは自分自身の残高から手数料を支払います。エンティティの公開鍵から導出されたアドレスは、エンティティのレコードへ逆引きされます。そのため、トランザクションが到着すると、ディスパッチャは呼び出しをルーティングする前に、送信者がAIかどうかを知ることができます。

最後の1文こそが要点です。ここに、それを実現する関数があり、crates/execution/src/lib.rsから引用します：

pub fn check_ai_entity_sender<K: Kv>(
    db: &K,
    tx: &TxV1,
) -> Result<Option<AiEntity>, ExecError<K::Error>> {
    let Some(entity) = lookup_ai_entity_by_address(db, &tx.from)? else {
        return Ok(None);
    };

    if !entity.is_active {
        return Err(ExecError::EntityNotActive);
    }

返却形式: {"translated": "翻訳されたHTML"}let tx_type = tx.payload.first().copied()
        .ok_or(ExecError::UnknownPayloadVersion { version: 0 })?;

    match tx_type {
        TRANSFER_PAYLOAD_V1 => Ok(Some(entity)),
        SIGNAL_COMMITMENT_PAYLOAD_V1 => {
            if entity.has_capability("emit_proposals") {
                Ok(Some(entity))
            } else {
                Err(ExecError::IssuerMissingCapability)
            }
        }
        CREATE_MEMORY_OBJECT_PAYLOAD_V1
        | UPDATE_MEMORY_OBJECT_PAYLOAD_V1
        | DELETE_MEMORY_OBJECT_PAYLOAD_V1 => {
            if entity.has_capability("read_memory_objects") {
                Ok(Some(entity))
            } else {
                Err(ExecError::IssuerMissingCapability)
            }
        }
        _ => Err(ExecError::IssuerMissingCapability),
    }
}

これは1つの関数です。すべてのトランザクションの前に実行されます。送信者が登録済みのAIであれば Some(entity) を返し、通常のアカウントであれば None を返し、AIが許可されていないことをしようとしている場合はエラーを返します。

これは3つの質問すべてへの答えです:

1. このアドレスはAIですか？調べます。ルックアップはエンティティレコードに解決されるか、されません。
2. 何が許可されていますか？capabilities のビットフィールドと autonomy_mode を読みます。ディスパッチャがそれらを強制します。
3. それは何をしたのですか？エンティティが発するすべてのシグナルは、発行者と高さでインデックスされます。エンティティが所有するすべてのメモリオブジェクトは、型でインデックスされます。チェーンはこれらをネイティブに保存します。

What this enables

チェーンが「これはAIかどうか」に型付きの答えを持てるようになったことで、多くのことが簡単になります:

• AIごとの手数料ポリシー。 将来のガバナンス変更で、AI発行のシグナルコミットに対する最低手数料を別に設定できるかもしれません。ディスパッチャはすでにトランザクションの種類とエンティティの状態で分岐しています。フックはそこにあります。
• AIごとのクォータ。 すべてのエンティティは、メモリオブジェクトが最大100個、オブジェクトあたり最大64 KiBに制限されています。これらはプロトコルの定数であり、コントラクトのロジックではありません。したがって、すべて一様に適用されます。
• ケイパビリティによるゲート。 Gatedモードのエンティティは、ティア1またはティア2のアクションの実行を要求できますが、承認ゲート（Multisig、Threshold、またはTimelockOnly）を通してのみ行えます。ケイパビリティフラグとゲート種別はエンティティレコードに存在します。チェーンは両方を確認します。
• ネイティブ監査。 ウォレット、エクスプローラ、または別のボットが「このエンティティが直近Nブロックで何をしたか？」と尋ねることができます。その答えはクエリであって、インデクサのETLではありません。
• AIの振る舞いに対するガバナンス。 ガバナンス提案によって、is_active を false に切り替えることでエンティティを無効化できます。ディスパッチャは、そのエンティティからの以降のすべてのトランザクションを型システムのレベルで拒否します。覚えて配線する必要のあるコントラクトレベルのキルスイッチはありません。

What this does not solve

限界について正直に言いたいです。チェーンは、コードハッシュ H を持つエンティティが登録されていることを知っており、さらに、そのエンティティが一致するキーでトランザクションに署名したことを検証できます。しかし、そのエンティティが実際に行う計算が、そのハッシュのコードと一致していることまでは知りません。それは別問題であり、Autonomous の自律モード（現在は予約済み）とZK証明の検証の役割です。

現時点での信頼モデルはこうです: チェーンは、エンティティが誰だと名乗っているか、それが何を許可されているか、そしてそれが何をしてきたかを知っています。チェーンは、そのエンティティが宣言したコードに忠実であることをは知りません。このギャップは、私が見てきたすべてのオンチェーンAIプロジェクトに存在します。NOVAIは後のフェーズでZK証明によってそれを埋めるよう構成されていますが、まずチェーンは「AIとは何か」を知る必要があります。

What you can do with this

ブロックチェーンから来た人なら、有限で、型付きで、インデックス可能なAIエージェントについて考える手段が得られます。ディスパッチャは、AIが何をできるかを教えてくれます。状態は、それが何をしたかを教えてくれます。

AIから来た人なら、あなたのエージェントが自分自身のアイデンティティ、独自の残高、独自のメモリ、そして独自の監査ログを持てる基盤が得られます。そうしたものを何も作り直す必要はありません。あなたはエージェントを作ります。

Repo: github.com/0x-devc/NOVAI-node。アーキテクチャのドキュメントでは、すべてのクレートを解説しています。最初のAIエンティティのチュートリアルでは、約10分でエンティティを登録します。

Twitter: [@NOVAInetwork]