робочий процес
Служба імен PIVX (PiNS) дозволяє користувачам реєструвати, оновлювати, перераховувати та передавати зрозумілі людині доменні імена (наприклад, myname.pivx) і безпечно зіставляти їх з адресами PIVX shielded (Sapling).
Оскільки PIVX — це блокчейн на основі UTXO без смарт-контрактів загального призначення, він не може запускати складну систему баз даних, як-от реєстр домену. Щоб вирішити цю проблему, PiNS використовує зведену архітектуру, яка виконує операції поза мережею, зберігає дані на PIVX та закріплює безпеку на Arbitrum.
Система живиться п'ятьма взаємопов'язаними компонентами:
1. PIVX Блокчейн: рівень доступності даних
Кожна дія, яку виконує користувач — реєстрація імені (REG), оновлення адреси (UPD), передача права власності (CHG), розміщення на ринку (LST), вилучення (ULT) або покупка (BUY) — починається як рідна транзакція PIVX. Транзакція містить структуровану текстову команду в полі пам’ятки транзакції (наприклад, PiNS:1:REG:domain:address:pubkey:nonce:signature).
- Ланцюжок PIVX є джерелом правди. Він постійно зберігає кожну команду домену. Жодні зміни стану не можуть відбутися без записаної транзакції PIVX.
2. Вузол реєстратора: секвенсор
Автоматичний вузол реєстратора сканує блокчейн PIVX. Він зчитує команди домену, перевіряє, що користувач сплатив правильну комісію за транзакцію, і ставить операції в чергу. Кожні 10 хвилин реєстратор об’єднує ці операції в один пакет.
3. SP1 zkVM: Механізм нульового знання (від Succinct)
Пакет транзакцій надсилається до SP1 Zero-Knowledge Virtual Machine (zkVM). ZkVM запускає спеціалізовану гостьову програму Rust, яка діє як суворий арбітр протоколу. Провер перевіряє кожну транзакцію в пакеті:
- Чи підписи дійсні та підписані фактичними власниками домену?
- Чи суворо збільшуються nonces, щоб запобігти атакам відтворення?
- Чи правильно відформатовано префікси домену?
- Чи платить транзакція
BUYточну ціну, указану в транзакціїLST? - Чи правильно
REG0__ переходить уREG1__ за допомогою математичних доказів Merkle?
Якщо всі правила виконуються, zkVM генерує криптографічний доказ ZK-SNARK (за допомогою Groth16). Цим доказом є крихітний сертифікат, який математично заявляє: «Починаючи з кореня стану A, після застосування цієї дійсної групи транзакцій новим коренем стану є B».
Кожна скомпільована версія цієї гостьової програми дає унікальний криптографічний ідентифікатор під назвою Ключ перевірки (vkey). REG2__ — це 32-байтовий хеш самої структури скомпільованої гостьової програми. Якщо хоча б один рядок коду перевірки змінено, програма компілюється в зовсім інший REG3__.
4. Смарт-контракт Arbitrum: Якір
Згенероване доказ ZK і його загальнодоступні дані надсилаються в розумний контракт PiNSAnchor на Arbitrum. Контракт діє як шлюз розрахунку.
- Криптографічний зв’язок: у смарт-контракті
REG4__ (очікуваний 32-байтовий хеш гостьової програми) зберігається в ланцюжку. Коли доказ надається, договір пересилає доказ іREG5__ до шлюзу верифікатора Succinct SP1. - Перевірка блокування ключа: шлюз перевірки схвалить підтвердження, лише якщо воно було створено точною гостьовою програмою, що відповідає зареєстрованому
REG6__. - Якщо підтвердження є дійсним і підтверджено зареєстрованим
REG7__, контракт оновлює офіційний, глобально прийнятий кореневий стан доREG8__ і зберігає його в історії. - Якщо єдине правило було порушено або якщо доказ було згенеровано за допомогою модифікованої гостьової програми (яка створить інший
REG9__), контракт відхиляє транзакцію, запобігаючи неавторизованим переходам стану.
5. Розподілені індексатори: Резолвери
Кожен може запустити незалежний вузол індексатора. Індексатори сканують блокчейн PIVX на наявність транзакцій домену та сканують контракт Arbitrum на перевірені кореневі контрольні точки. Вони застосовують транзакції локально, обчислюють власне дерево Merkle та перевіряють, чи їхній локальний корінь відповідає контрольній точці Arbitrum.
- Це гарантує, що всі індексатори, незалежно від того, де вони запускаються, завжди розв’язують домени за однаковою цільовою адресою (зберігаючи єдиний уніфікований стан на розподілених кінцях).