Гарантії безпеки

Ця сторінка точно описує, що PiNS гарантує, а що — ні. Точність тут корисніша за заспокійливі формулювання: сильні сторони справді сильні, а розуміння меж — це саме те, що дозволяє на них покладатися.

Властивість системи: порушення очевидні

PiNS має властивість очевидності порушень (fraud-evident). Будь-яке порушення правил або в принципі неможливо довести, або воно публічно видиме кожному, хто подивиться, — а дані, потрібні щоб подивитися, опубліковані, тож для цього не потрібно ні дозволу, ні сприяння оператора.

Варто розуміти різницю між двома половинами системи. Володіння і переходи стану забезпечуються криптографією і просто не можуть бути порушені. Усе інше встановлюється незалежним відтворенням, де відхилення спростовується одразу всіма репліками. Обидва механізми сильні — але сильні по-різному, і ця сторінка прямо каже, де діє який.

Що неможливо в принципі

Це забезпечується математикою. Жодні дії оператора цього не обійдуть.

• Домен не можна відібрати у власника. Будь-яка зміна стану вимагає підпису Ed25519 тим ключем, якого вимагає операція, і перевіряється всередині схеми суворою верифікацією. Реєстратор не зберігає ваш ключ і не може його підробити.
• Ім'я не можна зареєструвати двічі. REG вимагає доказу відсутності, а вже наявне ім'я такого доказу дати не може.
• Продаж неможливий за ціною, яку продавець не підписував. BUY вимагає, щоб сплачена ціна дорівнювала виставленій, а та зафіксована в дереві підписаною продавцем командою LST.
• Корінь стану не можна закріпити без коректного доказу. Якірний контракт у BNB Smart Chain перевіряє кожен доказ відносно programVkey, перш ніж прийняти корінь. Некоректний перехід просто неможливо довести.
• Схему не можна підмінити непомітно. programVkey фіксує конкретну скомпільовану програму. Зміна одного рядка змінює ключ, а зміна ключа в блокчейні — двостороння дія, що вимагає участі і секвенсера, і власника.

Що перевіряється спостереженням, а не схемою

Деякі властивості не забезпечуються всередині доказу, а встановлюються будь-ким, хто відтворить публічні дані. Це інший механізм, але не слабший результат: такі властивості може перевірити будь-який спостерігач без жодного дозволу, і відхилення видиме одразу всім, а не обраним.

• Включення команд і їхній порядок. Пакети збирає реєстратор, отже, саме він розставляє команди по порядку. Але оскільки протокольна адреса і ключ перегляду опубліковані, кожен незалежний індексатор виводить той самий порядок із самого ланцюжка й обчислює той самий корінь. Пропущена чи переставлена команда дає корінь, який спростовується всіма репліками — одразу і без того, щоб хтось спеціально його шукав.
• Значення end_block_height, яке повідомляє пакет. Воно передається в публічні вихідні дані, а не обмежується всередині схеми, тому що відтворення вже його встановлює: індексатор, який програє ланцюжок, знає, який блок покривав пакет, тож неправильна висота виявляється так само, як будь-яке інше відхилення.
• Адреси призначення при виведенні коштів. Суми виплат, комісії та зобов'язання повністю перевірні за опублікованим ключем перегляду: кожна виплата має memo із зазначенням облікового запису, за яким вона проводиться, тож реєстр балансів може відновити будь-хто. Чого немає в публічному записі, так це адреси призначення, яку вказав користувач, — цей запит робиться на сайті. Цю частину підтверджує сам отримувач, у якого залишається підписаний ним запит. Див. Довіра та приватність.

Чому справжня гарантія — це відтворення

ZK-доказ відповідає на запитання: за цих вхідних даних — чи були дотримані правила?

Відтворення відповідає на запитання: а чи були це справжні вхідні дані?

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

Саме тому публічність ключа перегляду — не деталь. Це і є механізм.

Суверенний rollup, якщо казати точно

Структурно PiNS — це ZK-rollup:

• Доступність даних — кожна команда живе в полі memo транзакції PIVX, а платіж перебуває в тій самій екранованій ноті, тож намір і оплата пов'язані нерозривно.
• Виконання — поза блокчейном, у SP1 zkVM.
• Розрахунки — BNB Smart Chain зберігає закріплений корінь і перевіряє докази за секунди.

Від типового rollup це відрізняється тим, що шаром доступності даних слугує приватний ланцюжок, тому фраза «вхідні дані може прочитати будь-хто» вимагає публікації ключа перегляду — що й зроблено.

Як перевірити це самостійно

Ніщо зі сказаного вище не потрібно приймати на віру:

• Відтворіть programVkey, скомпілювавши генератор доказів і порівнявши результат із контрактом.
• Програйте ланцюжок з опублікованим ключем перегляду через власний індексатор і порівняйте корені.
• Перевірте будь-яке окреме розв'язання імені доказом Меркла плюс звіркою кореня в блокчейні — див. Перевірка доказів.