Запропоновані зведені пакети перевірки біткойна – Trustnodes

Рішення другого рівня на основі ZK-tech можуть з’явитися в біткойнах завдяки Джону Лайту з дослідницької стипендії ZK-Rollup Фонду прав людини, який висунув пропозицію, яка привернула увагу деяких розробників біткойнів.

У розгорнутому огляді зведених перевірок і того, як їх можна реалізувати в дуже обмеженій мові сценаріїв біткойна, Лайт спочатку корисно резюмує, що це за нові винаходи:

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

Зведені дані містять достатньо даних у ланцюжку для «підтвердження дійсності», щоб гарантувати, що нові блоки зведених даних відповідають правилам протоколу зведених даних.

Ці докази створюються за допомогою ZK-tech, нині переважно STARK, і, таким чином, фактично ви отримуєте метод стиснення, де ви можете виконати, скажімо, 100 транзакцій на цьому другому рівні, з переважною більшістю безпеки базового рівня, і все це означає просто одна транзакція в мережі.

Це має значні переваги в зручності використання порівняно з чимось на зразок Lightning Network, оскільки вам не потрібні такі речі, як застави, маршрутизатори тощо, ви просто вносите депозит у зведений пакет.

Для простих переказів їх в основному було реалізовано на ethereum, де зараз вони працюють над цілою віртуальною машиною Ethereum на основі zk, сподіваючись, що з часом рішення ZK можна буде застосувати до самого базового рівня.

Однак щодо біткойнів над ним не було багато роботи до цієї весни, коли Трей Дель Боніс, розробник біткойнів, опублікований приклади коду того, як зведення валідності можна реалізувати в біткойнах. світло говорить:

«Було б можливим створити зведений пакет валідності для біткойна, використовуючи рідну мову програмування біткойна, неповну Тьюрінга, Script, з відносно невеликими змінами (щодо обсягу коду) у кодах операцій, які підтримує Script…

За словами Дель Боніса, зміни, необхідні для підтримки зведення валідності в біткойнах, полягають у введенні кількох додаткових кодів операцій, які вмикають два основні примітиви його дизайну зведення — перевірку підтвердження валідності та рекурсивні ковенанти…

Рекурсивні умови — це тип смарт-контракту, який обмежує тип сценарію, на який BTC можна надсилати після того, як він витрачений.

Дель Боніс використовує рекурсивні ковененанти, щоб поширювати конструкцію зведення вперед із кожним оновленням стану, гарантуючи, що BTC, заблоковані в сценарії зведення та ще не вилучені їхнім власником, залишаються в сценарії від одного оновлення стану зведення до наступного.

Після того, як власник BTC у зведеному пакеті підтвердить дійсну транзакцію зняття коштів у зведеному пакеті, він зможе вийти з рекурсивного сценарію ковенанту зі своїм BTC на вказану ним адресу зняття L1.

Рекурсивні ковенанти – це зміна сценарію, яка вже давно розглядається спільнотою біткойнів. Однак наразі немає конкретних пропозицій, які б досягли широкого консенсусу серед спільноти розробників біткойнів щодо реалізації рекурсивних угод».

Концептуально це звучить просто. Рекурсивні контракти стосуються частини блокування або переказу коштів у зведенні та з них, тоді як деякі інші зміни потрібні для інтеграції доказів.

Проте біткойн, як відомо, повільно змінюється, але Лайт каже, що пропозиція повністю сумісна з духом біткойна, повідомляючи списку розсилки розробників біткойна:

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

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

Вони не потребують додаткової пропускної здатності чи пам’яті, тому забезпечують масштабованість без значних компромісів.

Проте їх впровадження в біткойн, ймовірно, буде дуже повільним, а Лайт пропонує:

«Проект сайдчейну Elements (і блокчейн Liquid, який базується на Elements) ще не підтримує докази дійсності, необхідні для підтримки зведення валідності, але він підтримує рекурсивні ковенанти.

Таким чином, реалізація підтримки доказів валідності в Elements разом із деякими іншими змінами, які Дель Боніс назвав приємними, може стати шляхом до тестування протоколу зведення валідності, який зрештою призначений для розгортання на біткойнах».

Liquid підтримується Blockstream, а Грег Сандерс із цього Blockstream зазначає в обговоренні списку розсилки:

«Чи існує односторінкова шпаргалка «запитів» для самоаналізу транзакцій/OP_ZKP(?) і їх використання як окремо, так і разом для різних архітектур зведення?»

Op_ZKP не зовсім існує, тому, можливо, він поставив знак питання, але питання цілком може вказувати на те, що, хоча концептуально це звучить просто, насправді реалізувати це на дуже обмеженій мові сценаріїв біткойнів, ймовірно, буде зовсім непросто.

Не в останню чергу тому, що це була б передова розробка, хоча й не зовсім оригінальна, оскільки розробники ethereum працюють над цими системами zk з 2019 року.

Транспортування, яке зараз досягло точки, де був викладений скелет для біткойнів. Проте до повного впровадження може знадобитися досить багато часу.

 

Джерело: https://www.trustnodes.com/2022/10/12/validity-rollups-proposed-for-bitcoin