レジストリは今日正確でありながら、昨日記録した内容を独立して証明する方法があなたに一切ない、ということが起こり得ます。
それが、GoDaddyのエージェント名サービスで私が最も興味深いと思う点です。
ANSは、エージェントのライフサイクルのイベントを記録するために、Merkleツリーの透明性ログを使用しています。重要なのは、単に記録を保存することではなく、暗号学的な証明によって履歴への変更が検知可能になるようにすることです。GoDaddyの設計では、さらに一歩進んで整合性（consistency）証明を用い、より新しいツリーが前のツリーを「書き換える」のではなく「拡張している」ことを示しています。
ただし、より深い信頼の問題があると思います。
レジストリの履歴に対して、独立した基準点を与えるのは誰でしょうか？
そこで @hashgraph が関係してきます。
HCS-27では、Hederaのコンセンサス層へ向けて、定期的なMerkleルートのチェックポイントを公開することを提案しています。レジストリデータをオンチェーンに置く必要はありません。公開ネットワークは暗号学的なコミットメントを記録し、一方で、基盤となるログやメタデータは台帳（レジャー）外に残ります。
私にとって、それは明確な役割分担を生み出します。
GoDaddyはレジストリを管理します。
Merkle証明により、その状態は監査可能になります。
Hederaは、これらのコミットメントに対する独立したタイムラインを提供します。
また、重要な制限もあります。
チェックポイントは、元のアイデンティティ主張が真実であったことを証明するものではありません。すでにコミット済みだった状態に対して、レジストリの後続の履歴が整合していることを証明するのに役立つだけです。元の検証と信頼モデルは、依然として重要です。
AIエージェントのアイデンティティの話をしていると、この区別は見落とされがちです。
エージェントが企業を表すようになり、権限を保持し、複数のシステムにまたがってアクションを引き起こすようになると、そもそも「エージェントが誰か」を知るだけでは不十分になります。
より重要な問いは、こうなると思います。
何が、いつ変わったのかを、独立して検証できますか？
ここから、検証可能な履歴はメタデータではなくインフラになっていきます。👍
$HBAR $ONT $AMP
#Hedera #HBAR #AI
それが、GoDaddyのエージェント名サービスで私が最も興味深いと思う点です。
ANSは、エージェントのライフサイクルのイベントを記録するために、Merkleツリーの透明性ログを使用しています。重要なのは、単に記録を保存することではなく、暗号学的な証明によって履歴への変更が検知可能になるようにすることです。GoDaddyの設計では、さらに一歩進んで整合性（consistency）証明を用い、より新しいツリーが前のツリーを「書き換える」のではなく「拡張している」ことを示しています。
ただし、より深い信頼の問題があると思います。
レジストリの履歴に対して、独立した基準点を与えるのは誰でしょうか？
そこで @hashgraph が関係してきます。
HCS-27では、Hederaのコンセンサス層へ向けて、定期的なMerkleルートのチェックポイントを公開することを提案しています。レジストリデータをオンチェーンに置く必要はありません。公開ネットワークは暗号学的なコミットメントを記録し、一方で、基盤となるログやメタデータは台帳（レジャー）外に残ります。
私にとって、それは明確な役割分担を生み出します。
GoDaddyはレジストリを管理します。
Merkle証明により、その状態は監査可能になります。
Hederaは、これらのコミットメントに対する独立したタイムラインを提供します。
また、重要な制限もあります。
チェックポイントは、元のアイデンティティ主張が真実であったことを証明するものではありません。すでにコミット済みだった状態に対して、レジストリの後続の履歴が整合していることを証明するのに役立つだけです。元の検証と信頼モデルは、依然として重要です。
AIエージェントのアイデンティティの話をしていると、この区別は見落とされがちです。
エージェントが企業を表すようになり、権限を保持し、複数のシステムにまたがってアクションを引き起こすようになると、そもそも「エージェントが誰か」を知るだけでは不十分になります。
より重要な問いは、こうなると思います。
何が、いつ変わったのかを、独立して検証できますか？
ここから、検証可能な履歴はメタデータではなくインフラになっていきます。👍
$HBAR $ONT $AMP
#Hedera #HBAR #AI
