UTXO зв'язування: детальний опис рішення BTC смарт-контрактів RGB, RGB++ та Arch Network

Вступ

BTC є найбільш ліквідною та безпечною блокчейн-системою на сьогоднішній день. Після вибуху напису екосистема BTC привернула велику кількість розробників, які швидко підписалися на питання програмованості BTC та проблем масштабування. За допомогою введення різних концепцій, таких як ZK, DA, сайдчейн, rollup, restaking та інших, процвітання екосистеми BTC досягає нових висот і стає головною сюжетною лінією поточного бичачого ринку.

Проте в багатьох таких рішеннях багато елементів базуються на досвіді масштабування Смарт-контрактів, таких як ETH, і потребують централізованого кросчейн-моста, що є слабким місцем системи. Мало розроблених рішень, що базуються на властивостях самого BTC, це пов’язано з недружелюбним досвідом розробників самого BTC. За певних обставин виконання Смарт-контрактів у ньому неможливе, подібно до ETH.

1. Скриптова мова BTC обмежується безпекою, що ускладнює виконання смартконтрактів, на відміну від ETH.
2. Водночас збереження блокчейну BTC призначено для простих транзакцій, а не для оптимізації складних смартконтрактів.
3. Найважливіше, що у BTC немає віртуальної машини для виконання смартконтрактів.

У 2017 році введення SegWit (SegWit) збільшило обмеження розміру Блоку BTC; Оновлення Taproot у 2021 році зробило можливим пакетну перевірку підписів, що дозволяє легше та швидше обробляти транзакції (розблокування атомних обмінів, МультипідписГаманець та умовні платежі). Це все робить програмованість BTC можливою.

2022 році розробник Кейсі Родамор запропонував свою “Ординальну теорію”, в якій описана схема нумерації Сатоші, яка дозволяє вбудовувати будь-які дані, такі як зображення, в транзакції BTC, відкриваючи нові можливості для безпосереднього вбудовування інформації про стан та Метадані у блокчейні BTC, що відкриває нові перспективи для додатків, які потребують доступних та перевірених даних про стан, таких як смартконтракти.

Зараз більшість проектів, що розширюють BTC, залежать від другорядної мережі BTC (L2), що потребує довіри до кросчейн моста, і стає великим викликом для отримання користувачів та Ліквідність L2. Крім того, BTC наразі не має власної Віртуальна машина або програмованості, що ускладнює комунікацію L2 та L1 без додаткових передплати на додатковий довіру.

RGB、RGB++ та Arch Network спробують виходити з властивостей BTC, щоб підвищити його можливості програмування, надавати можливості смарт-контрактів та складних угод за допомогою різних методів:

1. RGB - це схема смарт-контрактів, яка перевіряється клієнтом поза блокчейном, зміни стану смарт-контрактів записуються в UTXO BTC. Хоча вона має певні переваги у відношенні до конфіденційності, проте її використання є важким і відсутня можливість комбінування контрактів, що призвело до дуже повільного розвитку.
2. RGB++ є ще одним шляхом розширення Nervos на основі підходу RGB, все ще заснованим на зв’язці UTXO, але шляхом зроблення ланки самою собою валідатором з Консенсус , це надає рішення з Метадані для взаємодії Кросчейн з активами та дозволяє йому підтримувати передачу будь-якої ланки зі структурою UTXO.
3. Arch Network надає рішення для Смарт-контрактів на основі BTC, створюючи власну Віртуальну машину ZK та відповідну мережу валідаторівНоди, які за допомогою агрегації транзакцій реєструють зміни стану та рух активів у транзакціях BTC.

RGB

RGB - це ранній розвиток Смарт-контракту в спільноті BTC, який записує дані стану за допомогою упаковки UTXO, що надало важливу ідею для подальшого розширення BTC.

Зображення 1

RGB використовує поза блокчейном метод підтвердження, переміщуючи перевірку передачі Токену з рівня консенсусу BTC на поза блокчейн, де перевірка здійснюється відповідним клієнтом, пов’язаним з певною угодою. Цей підхід зменшує потребу в мережевому розповсюдженні та покращує конфіденційність та ефективність. Однак, цей метод підвищення конфіденційності також є дворідним мечем. Залучаючи до перевірки тільки Ноди, пов’язані з певною угодою, хоча забезпечується конфіденційність, водночас це змушує сторонніх осіб бути невидимими, ускладнює реальний процес операцій та погіршує користувацький досвід.

Крім того, RGB вводить поняття одноразової пломби. Кожен UTXO може бути витрачений лише один раз, що еквівалентно блокуванню UTXO при створенні і розблокуванню при витраченні. Стан смарт-контракту упаковується в UTXO і керується пломбою, що забезпечує ефективний механізм управління станом.

RGB++

RGB++ - це ще один шлях розширення Nervos на основі підходу RGB, який все ще базується на зв’язуванні UTXO.

RGB++ використовує UTXO-ланцюг (наприклад, CKB або інші ланцюги) з Повнота за Тюрінгом для обробки даних поза блокчейном та смарт-контрактів, що подальшим чином покращує програмованість BTC та забезпечує безпеку через ізоморфні зв’язки з BTC.

Рис. 2

RGB ++ використовує UTXO-ланцюг з Повнотою за Тюрінгом. З використанням UTXO-ланцюгу з Повнотою за Тюрінгом, як от CKB, як тіньового ланцюгу, RGB ++ може опрацьовувати дані поза блокчейном та Смарт-контракти. Цей ланцюг може не тільки виконувати складні Смарт-контракти, але й пов’язувати з UTXO BTC, що збільшує програмованість та гнучкість системи. Крім того, UTXO BTC та тіньового ланцюгу пов’язані гомоморфним зв’язком, що забезпечує консистентність стану та активів між двома ланцюгами та гарантує безпеку транзакцій.

Крім того, RGB++ розширюється не лише на всі ланцюжки UTXO, що повністю відповідають Повнота за Тюрінгом, а не лише на CKB, що підвищує Кросчейн взаємодія та Ліквідність активів. Ця підтримка кількох ланцюжків дозволяє RGB++ поєднуватися з будь-яким UTXO-ланцюжком, що повністю відповідає Повнота за Тюрінгом, що підвищує гнучкість системи. Водночас RGB++ забезпечує Кросчейн взаємодія без міста за допомогою UTXO-ізоморфного зв’язування, що відрізняється від традиційного моста Кросчейн взаємодія, таким чином уникнувши проблеми «фальшивих монет» та забезпечивши подальшу достовірність та узгодженість активів.

Через перевірку у блокчейні через тіньовий ланцюг RGB++ спрощує процес перевірки клієнта. Користувачам потрібно лише перевірити відповідні угоди тіньового ланцюга, щоб переконатися, що обчислення стану RGB++ є правильним. Цей спосіб перевірки у блокчейні не лише спрощує процес перевірки, але й оптимізує взаємодію з користувачем. Завдяки використанню тіньового ланцюга з Повнотою за Тюрінгом, RGB++ уникнув складного управління UTXO в RGB та надав спрощену та зручну для користувача взаємодію.

Мережа ARCH

Arch Network складається з Arch zkVM та мережі вузлів Arch, які використовують Доказ із нульовим розголошенням (zk-proofs) та децентралізовану мережу для забезпечення безпеки та конфіденційності смарт-контрактів. Він є більш простим у використанні, ніж RGB, і не потребує прив’язки до іншого ланцюжка UTXO, як у RGB++.

Arch zkVM використовує виконання RISC Zero ZKVM для смартконтрактів і генерує докази з нульовим розголошенням, які перевіряються мережею валідації нодів з децентралізованою перевіркою. Ця система працює на основі моделі UTXO, упаковуючи стан смартконтрактів в State UTXO для підвищення безпеки та ефективності.

Asset UTXOs використовується для представлення BTC або інших Токенів, та може бути управляти шляхом делегування. Мережа перевірки Arch використовує випадково обраного лідера Нода для перевірки вмісту ZKVM, і використовує схему підпису FROST для агрегування підписів Нода, що в кінцевому підсумку передає Трансляція транзакцій на мережу BTC.

Рис. 3

Arch zkVM надає Віртуальна машина Повнота за Тюрінгом для BTC, що може виконувати складні Смарт-контракт. Після кожного виконання Смарт-контракту, Arch zkVM генерує Доказ із нульовим розголошенням, ці докази використовуються для перевірки правильності контракту та зміни стану.

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

ARCH хоча й не має інноваційної структури блокчейну, але потребує мережі валідаторів. Протягом кожного епохи Arch система випадковим чином вибирає LeaderНода на основі власностей, який відповідає за розповсюдження отриманих повідомлень до всіх інших валідаторівНода у мережі. Усі zk-докази перевіряються мережею валідаторів, що забезпечує безпеку та стійкість до цензури системи, та генерують підпис для LeaderНода. Як тільки транзакцію підписано необхідною кількістю валідаторівНода, вона може бути розповсюджена в мережі BTC.

Висновок

У плані програмованості BTC RGB, RGB++ та Arch Network мають свої особливості, але вони всі продовжують ідею прив’язки UTXO, властивість одноразової авторизації UTXO більш підходить для запису стану в смарт-контракті.

Проте його недоліки також дуже очевидні, а саме поганий користувацький досвід, затримка підтвердження, яка відповідає BTC, та низька продуктивність, тобто функціональність розширюється, але продуктивність не покращується, це досить очевидно в Arch та RGB; тим часом, дизайн RGB++, хоч і забезпечує кращий користувацький досвід за рахунок використання високопродуктивного ланцюжка UTXO, також вносить додаткові припущення щодо безпеки.

З більшою кількістю розробників, що приєднуються до спільноти BTC, ми побачимо більше рішень щодо масштабування, таких як пропозиція щодо оновлення op-cat, яка активно обговорюється. Проте, рішення, що відповідає основним властивостям BTC, є ключовим. Метод прив’язки UTXO є найбільш ефективним способом розширення програмування BTC без оновлення мережі BTC, і якщо вдало вирішити проблему користувацького досвіду, то це буде великим кроком вперед для смартконтрактів BTC.