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

Як це працює

Сервіс імен PIVX (PiNS) дозволяє реєструвати зрозумілі людині доменні імена (наприклад, myname.pivx), змінювати адресу, у яку вони розв'язуються, передавати їх іншим власникам і виставляти на маркетплейс, надійно пов'язуючи їх з адресами PIVX.

Оскільки PIVX — це блокчейн на моделі UTXO без універсальних смартконтрактів, він не може сам по собі вести складну базу даних на кшталт реєстру доменів. Щоб розв'язати це завдання, PiNS використовує архітектуру в стилі rollup: операції виконуються поза блокчейном, дані зберігаються в PIVX, а безпека закріплюється в BNB Smart Chain.

Систему утворюють п'ять пов'язаних між собою компонентів:

1. Блокчейн PIVX: шар доступності даних

Будь-яка дія користувача — реєстрація імені (REG), зміна адреси (UPD), передача прав (CHG), виставлення на маркетплейс (LST), зняття з продажу (ULT) чи купівля (BUY) — починається як звичайна транзакція PIVX. Транзакція містить структуровану текстову команду в полі memo (наприклад, PiNS:1:REG:domain:address:pubkey:nonce:signature).

  • Джерело істини — ланцюжок PIVX. Він назавжди зберігає кожну доменну команду. Жодна зміна стану неможлива без записаної транзакції PIVX.

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

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

3. SP1 zkVM: рушій нульового розголошення (від Succinct)

Пакет транзакцій надсилається до віртуальної машини з нульовим розголошенням SP1 (zkVM). Вона виконує спеціалізовану гостьову програму на Rust, яка працює як суворий суддя протоколу. Генератор доказів перевіряє кожну транзакцію пакета:

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

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

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

4. Контракт у BNB Smart Chain: якір

Отриманий ZK-доказ і його публічні вхідні дані надсилаються до смартконтракту PiNSAnchor у мережі BNB Smart Chain. Контракт виступає шлюзом розрахунків.

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

Чому BNB Smart Chain

Єдине завдання якірної мережі — зберігати корінь і перевіряти доказ, тому важливі лише дві речі: як швидко контрольна точка стає фінальною і наскільки можна бути впевненим, що вона такою і залишиться.

  • Час блоку близько 2 секунд, тож пакет закріплюється майже одразу після того, як доведений, і індексатори швидко сходяться на новій контрольній точці.
  • Глибоких реорганізацій на практиці не буває, тому контрольна точка, до якої індексатор синхронізувався, не піде в нього з-під ніг. Якірна мережа з глибокими реорганізаціями змушувала б індексатори відкочувати стан, який вони вже вважали остаточним.
  • Перевірка доказу коштує в блокчейні фіксовано й дешево незалежно від розміру пакета: одна перевірка Groth16 покриває всі операції пакета.

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

Запустити незалежний вузол-індексатор може будь-хто. Індексатори сканують блокчейн PIVX у пошуках доменних транзакцій, а контракт у BNB Smart Chain — у пошуках перевірених контрольних точок кореня. Вони застосовують транзакції локально, будують власне дерево Меркла і перевіряють, що їхній локальний корінь збігається з контрольною точкою в блокчейні.

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