Перейти до основного вмісту

робочий процес

Служба імен ZCash (zNS) дозволяє користувачам реєструватися, оновлювати адресу, що розпізнає, передавати іншим власникам і розміщувати зрозумілі для людини доменні імена (наприклад, myname.zcash) і безпечно зіставляти їх з адресами ZCash.

Оскільки ZCash — це блокчейн на основі UTXO без смарт-контрактів загального призначення, він не може запускати складну систему баз даних, наприклад реєстр домену. Щоб вирішити цю проблему, zNS використовує зведену архітектуру, яка виконує операції поза мережею, зберігає дані на ZCash та закріплює безпеку на Arbitrum.

Система живиться п'ятьма взаємопов'язаними компонентами:

1. ZCash Блокчейн: рівень доступності даних​

Кожна дія, яку виконує користувач — реєстрація імені (REG), оновлення адреси (UPD), передача права власності (CHG), розміщення на ринку (LST), вилучення зі списку (ULT) або покупка (BUY) — починається як рідна транзакція ZCash. Транзакція містить структуровану текстову команду в полі пам’ятки транзакції (наприклад, zNS:1:REG:domain:address:pubkey:nonce:signature).

  • Ланцюжок ZCash є джерелом правди. Він постійно зберігає кожну команду домену. Жодні зміни стану не можуть відбутися без записаної транзакції ZCash.

2. Вузол реєстратора: секвенсор​

Автоматичний вузол реєстратора сканує блокчейн ZCash. Він зчитує команди домену, перевіряє, що користувач сплатив правильну комісію за транзакцію, і ставить операції в чергу. Кожні 10 хвилин реєстратор об’єднує ці операції в один пакет.

3. SP1 zkVM: Механізм нульового знання (від Succinct)​

Пакет транзакцій надсилається до SP1 Zero-Knowledge Virtual Machine (zkVM). ZkVM запускає спеціалізовану гостьову програму Rust, яка діє як суворий арбітр протоколу. Провер перевіряє кожну транзакцію в пакеті:

  • Чи підписи дійсні та підписані фактичними власниками домену?
  • Чи суворо збільшуються nonces, щоб запобігти атакам відтворення?
  • Чи правильно відформатовано префікси домену?
  • Чи платить транзакція BUY точну ціну, указану в транзакції LST?
  • Чи правильно old_root переходить у new_root за допомогою математичних доказів Merkle?

Якщо всі правила виконуються, zkVM генерує криптографічний доказ ZK-SNARK (за допомогою Groth16). Цим доказом є крихітний сертифікат, який математично заявляє: «Починаючи з кореня стану A, після застосування цієї дійсної групи транзакцій новим коренем стану є B».

Кожна скомпільована версія цієї гостьової програми дає унікальний криптографічний ідентифікатор під назвою Ключ перевірки (vkey). vkey — це 32-байтовий хеш самої структури скомпільованої гостьової програми. Якщо хоча б один рядок коду перевірки змінено, програма компілюється в зовсім інший vkey.

4. Смарт-контракт Arbitrum: Якір​

Згенероване доказ ZK і його загальнодоступні дані надсилаються в zNSAnchor смарт-контракт на Arbitrum. Контракт діє як шлюз розрахунку.

  • Криптографічний зв’язок: усередині смарт-контракту programVkey (очікуваний 32-байтний хеш гостьової програми) зберігається в ланцюжку. Коли доказ надається, договір пересилає доказ і programVkey до шлюзу верифікатора Succinct SP1.
  • Перевірка блокування ключа: шлюз перевірки схвалить підтвердження, лише якщо воно було створено точною гостьовою програмою, що відповідає зареєстрованому programVkey.
  • Якщо підтвердження є дійсним і підтверджено зареєстрованим programVkey, контракт оновлює офіційний, глобально прийнятий кореневий стан до B і зберігає його в історії.
  • Якщо було порушено єдине правило або якщо доказ було згенеровано за допомогою модифікованої гостьової програми (яка створить інший vkey), контракт відхиляє транзакцію, запобігаючи несанкціонованим переходам стану.

5. Розподілені індексатори: Резолвери​

Кожен може запустити незалежний вузол індексатора. Індексатори сканують блокчейн ZCash на наявність транзакцій домену та сканують контракт Arbitrum на перевірені кореневі контрольні точки. Вони застосовують транзакції локально, обчислюють власне дерево Merkle та перевіряють, чи їхній локальний корінь відповідає контрольній точці Arbitrum.

  • Це гарантує, що всі індексатори, незалежно від того, де вони запускаються, завжди розв’язують домени за точною тією самою цільовою адресою (зберігаючи єдиний уніфікований стан на розподілених кінцях).