Ідентичність на рівні протоколу — це фундамент для розуміння унікальності Concordium (CCD) серед публічних блокчейнів. Якщо більшість мереж прирівнюють «адресу до ідентичності» та перекладають KYC на централізовані платформи, то Concordium інтегрує зв’язок між верифікованими суб’єктами й обліковими записами безпосередньо в протокол. Це гарантує, що всі наступні транзакції, реєстрації Agent і перевірки атрибутів базуються на єдиній системі підзвітності.
Часте питання користувачів: якщо потрібна відповідність, чому не розмістити результати KYC одразу на ланцюгу? Відповідь Concordium: ланцюгу потрібні підтверджені авторизації та висновки щодо атрибутів, а не постійне зберігання чутливих даних. Zero-Knowledge Proofs (ZKP) — це міст між цими вимогами.
Які проблеми вирішує ідентичність на рівні протоколу? Чим вона відрізняється від «анонімності адрес»?
У більшості публічних блокчейнів застосовується псевдонімність: адреси можна відстежити, але не завжди пов’язати з реальними підзвітними суб’єктами. Для простих переказів цього достатньо; проте для підпису Agent, доступу до сервісів за кваліфікацією чи корпоративних PayFi контрагентам потрібно знати, «хто відповідає» і «чи дотримано вимог відповідності», не розкриваючи особисті дані.
| Модель |
Розташування ідентичності |
Основне обмеження |
| Анонімність адрес |
Відсутня прив’язка на рівні протоколу |
Підзвітність ускладнена, відповідність залежить від офчейн-платформ |
| KYC на платформі |
Централізована база даних |
Дані ізольовані, обмежене міжзастосункове визнання |
| Ідентичність на рівні протоколу |
Прив’язка під час створення облікового запису |
Потрібна підтримка екосистеми видачі ідентичностей |
Ідентичність на рівні протоколу в Concordium означає, що кожен обліковий запис обов’язково пов’язаний із фізичною або юридичною особою, верифікованою Identity Issuer, і цей зв’язок забезпечується як частина мережевих правил, а не як додатковий DApp. Це дозволяє реєстрації та перевірці Agent Registry відслідковувати Agent до підтверджених, уповноважених суб’єктів.
Як Concordium пов’язує облікові записи з реальними особами або організаціями?
Прив’язка складається з офчейн-верифікації та ончейн-референції. Користувачі подають документи Identity Issuer, визнаному екосистемою Concordium; після завершення KYC чи KYB видавець надає обліковому запису об’єкт ідентичності. На ланцюгу видно лише посилання на ідентичність і криптографічну структуру, а не відкриті копії документів.
Об’єкт ідентичності формує для облікового запису «верифіковане походження»: будь-яка підписана дія (створення Agent, ініціація транзакції, пред’явлення доказу атрибуту) може бути співвіднесена з суб’єктом, підтвердженим видавцем. Відкликання, оновлення й термін дії регулюються протоколом і політиками видавця, з параметрами, визначеними документацією мережі.
Це відрізняється від моделі «відкрити акаунт на CEX і потім вивести кошти ончейн»: KYC на CEX залишається внутрішнім, а ончейн-адреса — анонімною. Concordium забезпечує, щоб ончейн-облікові записи мали підтверджуваний ланцюг підзвітності від самого початку.
Як працюють Zero-Knowledge Proofs? Які атрибути вони підтверджують?
Zero-Knowledge Proofs дозволяють доказувачу довести верифікатору, що «твердження істинне», не розкриваючи зайвої інформації. У Concordium такі твердження стосуються атрибутів: чи користувач старше 18, чи проживає у певній країні, чи є акредитованим інвестором, чи не перевищує дозволений ліміт витрат.
Процес складається з чотирьох кроків: Identity Issuer перевіряє документи офчейн і записує облікові дані до об’єкта ідентичності; користувач локально генерує ZKP; верифікатор (ончейн-контракт, застосунок чи Agent) перевіряє дійсність доказу; результат повертається як так/ні або порогове значення, а оригінальний сертифікат не потрапляє до ланцюга.
| Тип доказу |
Що отримує верифікатор |
Що видно ончейн/публічно |
| Віковий поріг |
«≥18» істинне |
Дата народження не розкривається |
| Місце проживання |
«У юрисдикції» істинне |
Адреса не розкривається |
| Кваліфікація |
«Має інвестиційний рівень» істинне |
Дані про доходи чи активи не розкриваються |
Інтерфейси Verify and Access дозволяють застосункам, Agent і фронтендам отримувати чіткі сигнали авторизації перед доступом до обмежених сервісів. У порівнянні Concordium і Worldcoin: World ID фокусується на «унікальній людині», тоді як ZKP Concordium перевіряє, «чи відповідає обліковий запис конкретним вимогам відповідності чи бізнесу».
Для корпоративних клієнтів це означає, що онбординг може вимагати «верифікований обліковий запис плюс доказ атрибуту» без створення повного KYC-сховища. Для фреймворків Agent перевірки авторизації можна вставляти перед викликом інструменту, блокуючи доступ непідтверджених Agent до обмежених API. Життєвий цикл об’єкта ідентичності включає оновлення й відкликання: при зміні статусу користувача чи політики видавця облікові дані можуть бути перевидані або анульовані, дозволяючи підзвітності змінюватися разом із вимогами відповідності.
Рис. 1. Потік доказу атрибуту з нульовим розкриттям у Concordium: від об’єкта ідентичності до результату перевірки, оригінальні персональні дані не потрапляють до ланцюга.
Чим ідентичність на рівні протоколу відрізняється від традиційного ончейн-KYC?
«Ончейн-KYC» часто сприймають як зберігання імен і номерів посвідчень у блоках. Concordium цього не робить: на ланцюгу зберігається прив’язка ідентичності та можливість перевірки доказів, а не PII. Порівняльна таблиця:
| Параметр |
Традиційний ончейн-KYC (міф) |
Ідентичність на рівні протоколу Concordium |
| Дані на ланцюгу |
Можливе відкриття чи хешування PII |
Об’єкт ідентичності + результат доказу |
| Конфіденційність |
Важко відкликати після публікації |
ZKP дозволяє вибіркове розкриття |
| Сумісність |
Повторний KYC для різних платформ |
Докази багаторазові для одного облікового запису |
| Підзвітність |
Залежить від платформи |
Ланцюг авторизації на рівні облікового запису |
Для RegTech і Agent екосистем це означає, що контрагенти перевіряють криптографічні висновки й підтвердження видавця, а не довіряють копіям форм. У сценаріях PayFi, випуску стейблкоїнів і токенізованих фондів часто потрібно підтвердити відповідність інвестора чи юрисдикції без повного профілю — саме для цього створено поєднання ідентичності на рівні протоколу та ZKP: «верифіковано, але мінімально розкрито».
З точки зору розробника, застосунки зазвичай не працюють із сирими KYC-пакетами: вони викликають Verify and Access або генерацію доказу у гаманці для отримання булевих чи перерахованих результатів авторизації, а далі вирішують, чи дозволяти транзакції, виклики Agent чи доступ до контенту. Це знижує навантаження на відповідність для фронтендів і смарт-контрактів, але вимагає чіткої логіки: які дії потребують яких доказів атрибутів.
Які переваги й обмеження ідентичності на рівні протоколу?
Переваги: перевірки відповідності відбуваються на рівні протоколу, зменшується необхідність повторної інтеграції модулів ідентичності; ZKP роз’єднує «доказ відповідності» та «розкриття даних»; верифіковані облікові записи забезпечують єдине коріння авторизації для Agent Registry. В корпоративних сценаріях аудит зосереджується на облікових записах і подіях доказу, без поширення сирих KYC-пакетів.
Обмеження: якість ідентичності залежить від охоплення й стандартів Identity Issuer, юрисдикційні відмінності впливають на набір атрибутів. Користувачі мають знати, що ZKP генеруються локальними гаманцями й залежать від статусу облікових даних, тому операції складніші, ніж із анонімними адресами. Якщо видавці чи облікові дані втрачають чинність, докази потрібно оновлювати. Ідентичність на рівні протоколу не гарантує захист від усіх офчейн-шахрайств — вона забезпечує «верифіковані атрибути та підзвітність для ончейн-взаємодій».
Також ідентичність на рівні протоколу не скасовує потребу в офчейн-аудитах: регулятори або партнери можуть офіційно запитати записи у видавців, але ці записи не мають бути публічно доступними у глобальному реєстрі через одну ончейн-взаємодію. Для проєктів важливо прозоро пояснювати продукт, щоб збалансувати приватність і відповідність, уникнувши міфу, що ZKP означає «повну невідстежуваність».
Підсумок
Ідентичність на рівні протоколу Concordium інтегрує «верифікованих суб’єктів» у модель облікового запису, а докази з нульовим розкриттям дозволяють перевіряти атрибути без розголошення оригінальних даних. Це критично для подальшого вивчення Agent Registry, Verify and Access та сценаріїв PayFi.
Поширені запитання
Що таке ідентичність на рівні протоколу Concordium?
Це означає, що облікові записи Concordium прив’язані до фізичної або юридичної особи, верифікованої Identity Issuer під час створення. Ланцюг зберігає об’єкти ідентичності й криптографічні посилання, але не відкриту персональну інформацію. Це дає обліковим записам підзвітні джерела авторизації та підтримує подальші докази атрибутів із нульовим розкриттям.
Як Concordium здійснює перевірку ідентичності?
Перевірка має два рівні: офчейн Identity Issuer проводить KYC/KYB і видає об’єкт ідентичності; ончейн або через інтерфейси, як-от Verify and Access, перевіряються докази з нульовим розкриттям, згенеровані користувачем. Верифікатори отримують лише висновки про відповідність атрибуту, а не оригінальний сертифікат.
Як Zero-Knowledge Proofs захищають приватність?
Zero-knowledge proofs дозволяють доказувачу надати верифікатору підтвердження, що «умова виконана», не розкриваючи чутливих деталей. Наприклад, доказ «старше 18» без дати народження. Concordium застосовує це для мінімізації розкриття PII на ланцюгу в умовах відповідності.
Який зв’язок між ідентичністю на рівні протоколу та Agent?
Agent Registry пов’язує Agent із верифікованими обліковими записами Concordium. Ідентичність на рівні протоколу формує корінь ланцюга підзвітності Agent: контрагенти, які перевіряють Agent, можуть відстежити його до уповноваженої особи, підтвердженої Identity Issuer. Без цього ончейн-ідентичність Agent не може бути надійно пов’язана з реальними відповідальними суб’єктами.
Які обмеження має ідентичність на рівні протоколу?
Серед обмежень — охоплення Identity Issuer, регіональні вимоги до відповідності, оновлення й терміни дії облікових даних, а також навчальна крива для роботи з гаманцями ZKP. Ідентичність на рівні протоколу забезпечує підзвітність і докази атрибутів на ланцюгу, але не замінює офчейн-контроль ризиків чи всі антифрод-процеси.
