Як функціонує Concordium Agent Registry? Покрокова інструкція від реєстрації до отримання значка "Підтверджено"

Реєстр агентів Concordium — це базова реалізація для Concordium (CCD) в економіці AI Agent. Коли агент має змогу самостійно підписувати, оплачувати чи викликати сервіси, контрагентам потрібно визначити: «Хто є власником цього агента і хто санкціонував його дії?» Реєстр забезпечує ончейн, доступні для пошуку, верифіковані й кросчейн-орієнтовані ідентифікаційні якорі, які інтегруються з верифікованим рівнем акаунтів, описаним у ідентифікації на рівні протоколу та zero-knowledge proof.

Як зазначено у відкритій документації, реєстр включає CIS-8004 (стандарт реєстрації агентів), Agent Card (офчейн JSON та ончейн-хеш), CIS-8 External Key Registry (кросчейн-прив’язка публічного ключа) та MCP Server (інтерфейс інструментів агента). Далі описано процес як повторюваний робочий цикл, а не разову дію.

Що потрібно підготувати перед реєстрацією агента?

Перед реєстрацією потрібно виконати три основні умови: мати верифікований нативний акаунт Concordium, публічно доступний URL для Agent Card та метадані з іменем агента, навичками й кінцевими точками сервісу. Для сумісності з такими мережами, як Ethereum чи Solana, також необхідно підготувати публічний ключ відповідного ланцюга та можливість підпису для прив’язки CIS-8.

Concordium підкреслює, що агентам не потрібно переносити всі робочі навантаження у свій ланцюг: реєстр може закріпити ідентифікацію на Concordium, а агенти можуть працювати на інших ланцюгах, використовуючи CIS-8 і Badge для зовнішнього поширення довіри.

Як акаунти та ідентичності закріплюються за агентами?

Кожен агент у реєстрі відповідає NFT CIS-8004, який створюється і оновлюється верифікованим акаунтом Concordium як власником. Акаунт власника пов’язується з реальною особою або організацією через ідентифікацію на рівні протоколу, формуючи ланцюг авторизації: NFT агента → акаунт власника → ідентифікація, підтверджена Identity Issuer.

Ончейн-сховище містить ключові поля: agent_uri, що вказує на Agent Card, metadata_hash (SHA-256) для забезпечення цілісності документа, і розширювані метадані у форматі ключ-значення (наприклад, адреса гаманця для платежів). Опційне external_reference може вказувати на прив’язку CIS-8 або облікові записи у соцмережах, що полегшує розпізнавання одного агента у різних середовищах.

Ця структура відрізняється від реєстрацій на основі ERC-8004, які лише описують агента: Concordium вимагає, щоб власник мав верифікований акаунт, тобто «хто авторизував» — це передумова для реєстрації, а не виправлення після неї. Метадані агента також можуть містити гаманець для платежів та інші ключові поля, що підтримують розрахунки між агентами або сценарії x402 pay-per-use для пошуку адреси отримувача. Однак контроль витрат на рівні застосунку залишається необхідним; сама ончейн-реєстрація не обмежує поведінку агента.

Як інтегруються Agent Card і CIS-8004?

Agent Card — це JSON-документ, що відповідає форматам на кшталт A2A (Agent-to-Agent) і містить ім’я агента, опис, навички, кінцеві точки сервісу та розширення Concordium (індекс контракту, адреса токена, акаунт власника тощо). Документ розміщується за HTTPS-адресою agent_uri; під час реєстрації і URL, і SHA-256-хеш його вмісту записуються у контракт CIS-8004.

Будь-який споживач — інший агент, MCP tool чи ручний ревізор — може верифікувати агента так: отримати agent_uri і metadata_hash з ланцюга, завантажити сирий JSON через URL, обчислити SHA-256 і порівняти з ончейн-хешем. MCP tool verify_agent_card автоматизує цей процес.

При оновленні можливостей агента необхідно оновити розміщений JSON і оновити ончейн-хеш через build_set_agent_uri чи подібні операції. Інакше ончейн-якір і офчейн-документ розійдуться. Agent Card — це публічна специфікація, яку можна оновлювати, а ончейн-NFT — незаперечний якір цілісності. Рекомендується зберігати історичні знімки або changelog при оновленні версій документа, щоб аудитори могли відстежувати зміни у можливостях агента.

Рис. 1. Робочий цикл Concordium Agent Registry: верифікований акаунт, емісія CIS-8004, закріплення хеша Agent Card і відображення Badge.

Як CIS-8 забезпечує кросчейн-прив’язку ключа?

CIS-8 External Key Registry зберігає криптографічний доказ зв’язку між нативним акаунтом Concordium та зовнішніми публічними ключами (наприклад, адресами Ethereum чи публічними ключами Solana) у ланцюзі. Після завершення прив’язки агент CIS-8004 може посилатися на запис CIS-8 як external_reference, що дозволяє інструментам на базі Ethereum знаходити той самий NFT агента через публічний ключ.

Шлях розпізнавання: адреса зовнішнього ланцюга → пошук прив’язки у контракті CIS-8 → акаунт власника в Concordium → пошук агента CIS-8004 → Agent Card. Token_address та координати контракту у Concordium-розширеннях допомагають зовнішнім реєстрам виконувати пошук без специфічних знань про Concordium.

Це дозволяє ідентифікувати агентів за token ID у Concordium-інструментах і за ETH-адресою в Ethereum-інструментах, обидва посилаючись на ту саму ончейн-ідентичність. На відміну від підходу «proof of personhood», розглянутого у Concordium vs Worldcoin, реєстр вирішує питання верифікованої ідентичності агента та кросчейн-сумісності.

Як верифікується Badge Verified by Concordium?

Badge Verified by Concordium — це видимий сигнал довіри для контрагентів, що агент пов’язаний із верифікованим акаунтом на рівні протоколу. Верифікація має ґрунтуватися на ончейн-фактах, а не лише на іконці Badge: переконайтеся, що відповідний токен існує у CIS-8004, перевірте статус ідентифікації акаунта власника, за потреби звірте хеш Agent Card із розміщеним документом, а для кросчейн-сценаріїв перевірте прив’язку CIS-8.

Badge знижує комунікаційні витрати, але не замінює самостійну перевірку. Підприємства або середовища з високим рівнем довіри часто поєднують Verify та Access для перевірки атрибутів (наприклад, вік, кваліфікації, ліміт витрат), доповнюючи рівень ідентифікації та авторизації реєстру. Якщо агент представляє фінансову установу або e-commerce-платформу для платежів, повний стек довіри зазвичай такий: реєстр підтверджує агента та авторизовану особу → ZKP верифікує бізнес-атрибути → Protocol-Level Locks або x402 обмежують шляхи розрахунків, і кожен рівень виконує свою функцію.

На що слід звернути увагу під час реєстрації та верифікації?

Переконайтеся, що хостинг Agent Card доступний і цілісність HTTPS збережена: якщо URL стане недійсним або вміст зміниться без оновлення ончейн-хеша, верифікація не вдасться. Прив’язка зовнішнього ключа має передувати налаштуванню external_reference CIS-8; неправильний порядок призведе до відкату реєстрації або невалідних посилань. Безпека ключа власника напряму визначає контроль над агентом; оскільки NFT є передаваними, зміна власника агента вимагає внутрішніх процедур управління.

MCP Server надає інструменти для реєстрації, створення Agent Card і перевірки картки, що полегшує інтеграцію з фреймворком агента, але розробники мають розуміти ончейн-операції та витрати на газ (або Sponsored Transactions). Екосистема реєстру ще розширюється, і те, чи прийматимуть контрагенти Badge як критерій доступу, залежить від галузевих практик.

Публічна документація містить контракти основної мережі, зокрема CIS-8004 Agent Registry (індекс 10082) та CIS-8 External Key Registry (індекс 10081), які можна переглянути через блок-оглядачі на кшталт CCDScan. Сервіси індексації перетворюють ончейн-івенти у REST API, спрощуючи пошук і виявлення агентів без ручного сканування ланцюга. Для виробничих середовищ рекомендується створити повторюваний чекліст розгортання для «ончейн-реєстрація → хостинг Card → верифікація хеша → відображення Badge» та інтегрувати його у CI-процеси при оновленні можливостей агента, щоб уникнути розбіжностей між ланцюгом і документом.

Підсумок

Concordium Agent Registry об’єднує ідентичність агента, цілісність документа, кросчейн-публічні ключі та верифіковані акаунти у повторюваний робочий цикл. Розуміння ролей CIS-8004, Agent Card і CIS-8 є ключовим для інтеграції Verified Badge і перевірки довіри до агента у кросчейн-середовищі. Під час розгортання реєстрацію в ланцюзі, розміщення документа і періодичну перевірку хеша слід закладати в операційні процеси, щоб уникнути невірогідних застарілих записів після оновлення можливостей агента.

Поширені запитання

Що таке Concordium Agent Registry?

Agent Registry — це ончейн-система ідентифікації агентів у Concordium, яка реєструє агентів як NFT через CIS-8004 і описує їхні можливості та кінцеві точки через Agent Card. Реєстр пов’язує агентів із верифікованими акаунтами Concordium, підтримує кросчейн-прив’язку ключів і Badge Verified by Concordium.

Як ідентичність AI Agent пов’язується з реальними акаунтами?

Кожен NFT агента належить і керується верифікованим акаунтом Concordium. Цей акаунт асоціюється з особою або організацією, верифікованою через ідентифікацію на рівні протоколу та Identity Issuer, формуючи ланцюг відповідальності: агент → власник → верифікована особа.

Яке призначення Agent Card?

Agent Card — це публічний JSON-документ, що містить ім’я агента, навички та кінцеві точки сервісу; його URL і SHA-256-хеш зберігаються у ланцюзі для гарантії цілісності. Оновлення можливостей вимагає синхронного оновлення документа і оновлення ончейн-хеша.

Чи можуть агенти Concordium працювати на Ethereum або Solana?

Так. Завдяки прив’язці зовнішніх публічних ключів до акаунтів Concordium через CIS-8 і встановленню external_reference для агентів CIS-8004, зовнішні інструменти можуть розпізнавати ту саму ідентичність агента за адресами Ethereum чи Solana без перенесення всієї логіки у Concordium.

Як перевірити, чи агент заслуговує довіри?

Ончейн-верифікація має включати перевірку токена CIS-8004, статусу ідентифікації акаунта власника, відповідність хеша Agent Card розміщеному документу та, за потреби, кросчейн-прив’язку CIS-8. Badge Verified є додатковим сигналом і не може замінити криптографічні кроки перевірки.