Реестр может быть точным сегодня и при этом оставить вас без независимого способа доказать, что он записал вчера.
Вот что в Сервисе имен агентов (Agent Name Service) от GoDaddy я нахожу наиболее интересным.
ANS использует журнал прозрачности на основе дерева Меркла (Merkle-tree) для фиксации событий жизненного цикла агента. Важное свойство заключается не просто в хранении записей, а в том, чтобы сделать изменения в истории обнаруживаемыми с помощью криптографических доказательств. В проекте GoDaddy также предусмотрены доказательства согласованности (consistency proofs), которые показывают, что более новое дерево расширяет предыдущее, а не переписывает его.
Но, мне кажется, здесь есть более глубокий вопрос доверия:
Кто дает истории реестра независимую точку отсчета?
И вот где relevant становится @hashgraph.
HCS-27 предлагает публиковать периодические контрольные точки (Merkle-root checkpoints) в слой консенсуса Hedera. Данные реестра не нужно размещать в On-chain. Публичная сеть фиксирует криптографическое обязательство, тогда как лежащий в основе журнал и метаданные остаются вне реестра (off ledger).
Для меня это создает четкое разделение.
GoDaddy поддерживает реестр.
Доказательства по Мерклу делают его состояние проверяемым.
Hedera предоставляет независимую хронологию для этих обязательств.
Здесь есть еще важное ограничение.
Контрольная точка не доказывает, что исходное утверждение об идентичности было истинным. Она помогает доказать, что более поздняя история реестра согласуется с состоянием, которое уже было зафиксировано. Исходная проверка и модель доверия по-прежнему имеют значение.
Эту разницу легко упустить из виду, когда говоришь об идентичности AI-агентов.
Когда агенты начинают представлять компании, иметь разрешения и запускать действия в разных системах, знать, кто такой агент, будет недостаточно.
Я думаю, что более важный вопрос звучит так:
Могу ли я независимо проверить, что изменилось и когда?
Вот где проверяемая история начинает становиться инфраструктурой, а не просто метаданными. 👍
$HBAR $ONT $AMP
#Hedera #HBAR #AI
Вот что в Сервисе имен агентов (Agent Name Service) от GoDaddy я нахожу наиболее интересным.
ANS использует журнал прозрачности на основе дерева Меркла (Merkle-tree) для фиксации событий жизненного цикла агента. Важное свойство заключается не просто в хранении записей, а в том, чтобы сделать изменения в истории обнаруживаемыми с помощью криптографических доказательств. В проекте GoDaddy также предусмотрены доказательства согласованности (consistency proofs), которые показывают, что более новое дерево расширяет предыдущее, а не переписывает его.
Но, мне кажется, здесь есть более глубокий вопрос доверия:
Кто дает истории реестра независимую точку отсчета?
И вот где relevant становится @hashgraph.
HCS-27 предлагает публиковать периодические контрольные точки (Merkle-root checkpoints) в слой консенсуса Hedera. Данные реестра не нужно размещать в On-chain. Публичная сеть фиксирует криптографическое обязательство, тогда как лежащий в основе журнал и метаданные остаются вне реестра (off ledger).
Для меня это создает четкое разделение.
GoDaddy поддерживает реестр.
Доказательства по Мерклу делают его состояние проверяемым.
Hedera предоставляет независимую хронологию для этих обязательств.
Здесь есть еще важное ограничение.
Контрольная точка не доказывает, что исходное утверждение об идентичности было истинным. Она помогает доказать, что более поздняя история реестра согласуется с состоянием, которое уже было зафиксировано. Исходная проверка и модель доверия по-прежнему имеют значение.
Эту разницу легко упустить из виду, когда говоришь об идентичности AI-агентов.
Когда агенты начинают представлять компании, иметь разрешения и запускать действия в разных системах, знать, кто такой агент, будет недостаточно.
Я думаю, что более важный вопрос звучит так:
Могу ли я независимо проверить, что изменилось и когда?
Вот где проверяемая история начинает становиться инфраструктурой, а не просто метаданными. 👍
$HBAR $ONT $AMP
#Hedera #HBAR #AI
