Який реальний потенціал протоколу випуску активів BTC RGB?

Автор**|**А Цзянь

Оригінальне посилання:

У цій статті робиться спроба надати стислий опис RGB, протоколу розподілу активів на BTC (який також можна розуміти як офчейн-систему смарт-контрактів), і вказується, чим він відрізняється від інших протоколів, які прагнуть досягти такої ж або подібної функціональності, що робить протокол RGB набагато більш масштабованим, ніж вони є, і залишає більше простору для програмування. На додаток до представлення вже готових дизайнів RGB, ми також розглянемо ці можливості програмування.

Що таке протокол RGB?

Ідея випуску активів на BTC існує вже давно. Однак BTC протокол має свої особливості: його стан виражається і тільки BTC UTXO («невитраченими виходами транзакцій»), UTXO несе лише дві частини даних: власний номінал (значення BTC) і «відкритий ключ скрипта» (також відомий як «скрипт блокування»), який використовується для програмування умов, за яких витрачаються кошти, таких як надання підпису для відкритого ключа, а коди операцій, які дозволяють запрограмувати сценарій блокування, забезпечуються правилами консенсусу BTC, які не можуть бути використані для реалізації довільних правил безпеки. Як наслідок, неможливо створити інші ресурси всередині UTXO — сценарії BTC не можуть запрограмувати перевірку безпеки для цих ресурсів. Це означає, що вся ідея випуску активів на BTC по суті є творчим використанням BTC блокового простору. Це означає, що нам потрібно розробити систему офчейн-смарт-контрактів і вимагати, щоб інформація про кроки, які змінюють стан контракту - наприклад, контракт А змінює параметри, Б передає певну кількість активу С - була завантажена в блокчейн, щоб останній стан системи смарт-контрактів можна було отримати, зібравши цю інформацію.

Груба ідея дизайну полягає в тому, щоб завантажити інформацію про кроки, які змінюють стан контракту, на BTC блокчейн неушкодженим. Звичайно, це може спрацювати, однак він зіткнеться з кількома проблемами: (1) через завантаження повної інформації він може займати більше місця в блоці, а коли користувачам потрібно змінити стан контракту (наприклад, перекази), їм також доведеться платити більше ончейн-комісій. Зокрема, коли ми хочемо, щоб така офчейн-контрактна система мала кращу програмованість, ніж BTC, підвищення програмованості може відбуватися за рахунок споживання більшої кількості блокового простору: (2) інформація майже в будь-якому місці блоку має потенціал змінити офчейн смарт-контракт, тому користувач повинен отримати всі дані BTC блоку, щоб отримати останній стан системи офчейн-контрактів, тобто це дорожче для перевірки, (3) залежно від дизайну системи офчейн смарт-контрактів, вона може отримати лише таку ж або навіть гіршу конфіденційність, як BTC, і якщо вона може забезпечити більше конфіденційності, йому, можливо, доведеться споживати більше місця в блоці。

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

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

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

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

Для читачів, які знайомі з ончейн-системами смарт-контрактів (такими як ETH Fang), одна з речей, яку важко зрозуміти про цей процес, полягає в тому, що якщо він не залежить від консенсусу блокчейну (а це означає, що початковий стан контракту та кожна зміна стану будуть перевірятися кожним вузлом), як гарантувати безпеку цієї системи смарт-контрактів, як переконатися, що активи, які ви отримуєте, є такими, які ви хочете, і як гарантувати, що активи не випущені незаконно?

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

Нарешті, давайте на прикладі проілюструємо характеристики протоколу RGB:

Тепер Аліса володіє UTXO A’, який володіє активом Y одиниць X, випущених за ліцензією RGB, і вона хоче передати Бобу Z-одиниці Y. Загалом знадобилося 5 попередніх власників (включаючи емітента) активів, щоб дістатися до Аліси. Тому Аліса хоче надати Бобу докази цих 4 переходів станів (перші 3 з яких були надані Алісі попереднім власником), включаючи початковий стан контракту та правила переходу стану, BTC транзакції, які використовуються для кожного переказу, кожну транзакцію RGB, здійснену BTC біржі, та докази того, що ці транзакції BTC були підтверджені блоком, і надіслати їх Бобу, який перевірить ці 4 відповідно до правил переходу штату контракту Переводити, не порушуючи правил, а потім вирішувати, приймати його чи ні. Коли Аліса будує транзакцію RGB, оскільки Z менше X, вона також організовує для себе UTXO, щоб отримати решту. Нарешті, Аліса вбудовує хеш транзакції RGB у BTC транзакцію, яка коштує UTXO A’ для завершення платежу.

Врешті-решт, завдяки використанню контейнерів UTXO, останній стан контракту RGB може бути представлений у вигляді точки на орієнтованому ациклічному графі, який ще не має нащадків (кожна точка представляє стан, що зберігається всередині контейнера UTXO). А для власника P на схемі нижче він буде знати тільки процес від початкового стану G контракту до нього, який є процесом, обведеним червоним, і нічого не знатиме про сірі точки:

Переваги RGB

Крутий статус, який можна перевірити

Як згадувалося вище, RGB значно знижує вартість валідації (певного стану контракту) в порівнянні з протоколами випуску активів (off-chain контрактними системами), які раніше з’явилися на BTC. У момент транзакції одержувачу більше не потрібно перебирати всі блоки, щоб зібрати інформацію про зміну стану контракту, а потрібно лише отримати серію BTC транзакцій, а також обіцяні цими біржами транзакції RGB, і блок, що містить докази цих BTC транзакцій (згідно з доказом Меркла заголовка блоку), щоб бути впевненим, що платник дійсно володіє певною сумою певного активу.

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

У порівнянні з деякими ончейн-контрактними системами, RGB також легший. Це виражається в тому, що RGB може спеціально перевіряти певний стан контракту, в той час як в системах, які не засновані на UTXO, через відсутність механізму контролю доступу, такого як UTXO, будь-яка транзакція може змінити будь-який стан, тому практично неможливо перевірити певний стан цілеспрямовано, а може визначити певний стан лише під час обчислення всіх останніх станів - у цьому сенсі ознака, виражена як «глобальний стан», насправді повинна називатися « Єдина держава», хоча він забезпечує перехресний доступ між контрактами, він також визначає, що це буде дорожче для перевірки та складніше для отримання без довіри.

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

Масштабованість

Масштабованість RGB подвійна:

1. У BTC транзакцію вбудовується тільки один хеш, а це означає, що немає обмежень на розмір транзакції RGB (крім правил, налаштованих контрактом) - навіть якщо ви розділите один актив RGB на 100 (сама транзакція RGB буде дуже великою), є тільки один хеш, який потрібно вбудувати в BTC транзакцію. Як зазначалося в Примітці 6, є два способи вбудувати такий хеш: або використовуючи вихід OP_RETURN, що означає, що він споживає один хеш ончейн-простору, або приховавши його в дереві скриптів, обіцяному відкритим ключем скрипта виводу Taproot, який не займає жодного місця в ланцюжку. Це також означає, що користувачам не потрібно жертвувати економікою заради програмованості – лише комісією в мережі.

2. Останній стан RGB-контракту є незалежною точкою на спрямованому ациклічному графі без нащадків - це означає, що ці стани можуть змінюватися незалежно один від одного, не впливаючи один на одного, тобто допускається паралелізм. Насправді це функція, успадкована від UTXO. Це також означає, що недійсні зміни (недійсні транзакції), які відбуваються в одній філії, не вплинуть на інші філії, не кажучи вже про те, що призведуть до заморожування всього договору, тому це також можна вважати перевагою безпеки.

RGB критикують за його масштабованість: з кожним переказом одержувачу необхідно перевіряти всі залучені транзакції від початкового стану до стану платника - зі збільшенням кількості переказів активів зростає навантаження на перевірку наступних одержувачів. Ця критика правдива. Оптимізувати його означає знайти спосіб повторного використання обчислень, які вже відбулися. Очікується, що технології Proof System, такі як SNARK, забезпечать таке рішення.

Диференціація визначення активів та механізму митного декларування

Остання перевага все ще пов’язана з UTXO, залежно від того, як ми розуміємо механізм блокування UTXO.

Скрипт блокування можна використовувати для програмування умов, за яких фонд буде розблоковано, щоб він міг реалізовувати правила зберігання. Наприклад, якщо скрипт блокування містить лише один відкритий ключ, це означає, що керувати ним може лише власник відповідного закритого ключа. Однак такі правила зберігання також є основою для BTC програмування договірних протоколів. Наприклад, UTXO, який використовує сценарій блокування мультипідпису 2 з 2, може бути блискавичним каналом, і під час роботи каналу дві сторони можуть платити один одному майже нескінченну кількість разів без будь-яких змін у ончейн-формі коштів. Іншими словами, на цьому етапі сценарій блокування з мультипідписом 2 з 2 являє собою механізм передачі вартості, який дозволяє обом сторонам передавати вартість, не змінюючи форму ончейн коштів.

Такий механізм може бути використаний для вартості BTC, що несе UTXO, і, природно, для активів RGB, які він несе. Ми можемо випустити ресурс RGB і приєднати його до UTXO з мультипідписом 2 з 2, використовуючи механізм каналу блискавки, щоб платити один одному необмежену кількість разів. Аналогічно, ресурси RGB також можуть використовуватися в інших контрактах на основі BTC скриптів.

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

RGB розроблено

Наведені вище функції справедливі практично для всіх протоколів, заснованих на одноразовому запечатуванні UTXO та перевірці на стороні клієнта. Але на додачу до цього, протокол RGB був додатково розроблений.

У поточному розвитку протоколу RGB розробники особливо стурбовані конфіденційністю протоколу, тому RGB посилює конфіденційність двома способами:

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

Досліджуваний простір

У цій частині я розповім про сфери, в яких протокол RGB може продовжувати досліджувати, в основному пов’язаних з програмованістю.

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

Обмеження

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

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

Поточні скрипти BTC не мають такої можливості, тому для ввімкнення обмежень на BTC скрипти потрібен софтфорк.

Однак, поки ми готові пожертвувати деякими перевагами «визначення активів та диференціації зберігання», ми можемо експериментувати з такою функцією на активах RGB, і ми можемо реалізувати цю функціональність на рівні RGB-контрактів – хоча вона може працювати лише для активів RGB, які її використовують (а не BTC), але це, безсумнівно, відкриє цікавий простір.

Дослідження існуючих обмежень показали, що він розширює простір програмування для транзакцій на основі UTXO, пропонуючи ряд функцій. Але ці дослідження в основному ґрунтуються на BTC, і ми були б трохи консервативнішими щодо BTC таких протоколів. На RGB ми можемо сміливо узагальнити основну здатність положення про обмеження – здатність читати транзакції, які коштують самі за себе на рівні скриптів – для забезпечення більш гнучкої програмованості: можливість перехресного доступу контрактів.

Перехресний доступ

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

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

Фактично, вже існують ончейн-контрактні системи, засновані на UTXO-подібних структурах (наприклад, Nervos Network), які використовують це для досягнення можливостей перехресного доступу для контрактів11. Це дуже нова сфера, яка відкривається для областей, яких рідко торкалися попередні BTC дослідження, і в ній можуть бути приховані деякі сюрпризи.

Висновок

У цій статті читач помітить, що існує одне поняття, яке часто згадується в процесі міркувань і фантазії: «UTXO». Це саме те, що я задумав. Якщо ви не розумієте UTXO, ви не можете зрозуміти відправну точку дизайну такого протоколу, як RGB, переваги дизайну протоколу RGB і те, як люди можуть його використовувати. Природа протоколу RGB значною мірою визначається його UTXO, формою одноразової печатки. Відповідно, дослідження UTXO, накопичені в BTC галузі досліджень, також можуть бути застосовані до дослідження RGB.

Це також пояснює, чому людям, які не розуміють BTC, буде важко зрозуміти RGB. А ті, кому BTC подобається, впізнають дизайни, які вже зробив RGB.