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

У другій половині 2023 року екосистема різних протоколів деривативів BTC стрімко розвиватиметься. На додаток до відродження протоколу Ordinals і BRC20, такі протоколи, як Atomicals і Taproot Assets, також привернули широку увагу ринку.

Раніше Беосін аналізував ризики декількох типів протоколів деривативів BTC: «Вибух екосистеми BTC, аналіз потенційних можливостей і ризиків різних її деривативних протоколів». **У цій статті Беосін докладно пояснить дуже важливий протокол випуску активів в екосистемі BTC - протокол RGB. **

1. Розробка протоколу RGB

Роль протоколу RGB полягає в тому, щоб додати функціональність смарт-контрактів до Bitcoin у Lightning Network, протоколі державного каналу з нульовим розголошенням, який дозволяє користувачам проводити транзакції, що зберігають конфіденційність, поза мережею. **

RGB не є протоколом токенів, але він має можливість випускати та керувати кількома високомасштабованими, програмованими та конфіденційними активами, і може відігравати важливу роль у багатьох інших галузях за межами фінансів. Розробка його протоколу пройшла кілька важливих етапів, від початкової концепції до поточної версії RGB v0.10, яка надає функціональність смарт-контрактів Bitcoin і Lightning Network.

1 У 2016 році Джакомо Зукко запропонував початкову ідею протоколу RGB, засновану на ідеях Пітера Тодда.

2 У 2017 році BHB Network запустила оригінальну версію протоколу RGB, яка підтримувалася компанією Poseidon Group.

3 У 2019 році Максим Орловський і Джакомо Зукко заснували Асоціацію стандартів LNP/BP для просування RGB для практичного застосування, а доктор Максим Орловський розпочав редизайн протоколу RGB.

4 У 2021 році асоціація продемонструвала віртуальну машину Turing-Complete (AluVM) протоколу RGB, яка також почала працювати в мережі Lightning Network.

5. У 2022 році було запущено Contractum, нову мову для написання смарт-контрактів RGB для Bitcoin та Lightning Network, та її новий веб-сайт.

6. У квітні 2023 року було випущено RGB v0.10, що забезпечує повну підтримку смарт-контрактів Bitcoin та Lightning Network, що стало найважливішим етапом розвитку протоколу RGB.

2. Логіка проектування протоколу RGB

Основна ідея протоколу RGB побудована навколо консенсусу та зберігання даних поза мережею.

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

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

Базовим рівнем RGB є блокчейн Bitcoin, включаючи консенсус PoW Накамото та реєстр транзакцій. Хоча немає необхідності зберігати будь-які дані в мережі, все одно існує необхідність дотримуватися існуючої інфраструктури та використовувати транзакції Bitcoin як сховище для цих зобов’язань.

2.1 Аутентифікація клієнта

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

2.2 Смарт-контракт RGB

Базова структура смарт-контракту RGB складається з Genesis, State і Transitions, кожен з яких має різні функції та ролі:

Буття(创世)

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

State(状态)

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

Переходи(转换)

Переходи - це правила, які визначають переходи з одного стану в інший. Ці правила визначають, як змінюється стан на основі логіки контракту. op Vocation та op Transfer є прикладами перетворень, які визначають, як переходити з одного стану ідентичності в інший або як переходити між токенами.

Ці три компоненти забезпечують спосіб визначення та виконання різних операцій і протоколів. Genesis встановлює базові правила та параметри, State підтримує поточну інформацію контракту, а Transitions обумовлює логіку змін між станами, які разом утворюють основну архітектуру смарт-контракту RGB.

2.3 一次性密封(одноразові печатки)

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

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

Логічні кроки для одноразових печаток:

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

2. У договорі держава використовується для представлення поточного активу або конфігурації дозволу. Кожен статус пов’язаний з одноразовою інкапсуляцією, яка представляє поточне право власності або дозволи.

3. Коли необхідно передати або змінити активи чи дозволи, відбуваються переходи держави. Цей процес включає в себе закриття поточної одноразової інкапсуляції (представляє старий стан) і створення нової інкапсуляції (представляє новий стан).

4. Закриття упаковки передбачає перевірку її цілісності та позначення її як такої, що використовується для запобігання повторному використанню. Потім, на основі правил контракту, створюється нова інкапсуляція для представлення нового стану.

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

3. Характеристики протоколу RGB

Характеристики RGB відображені в інноваціях смарт-контрактів RGB, і нижче наведено кілька ключових моментів для вас:

1. Концепція схеми

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

2. Віртуальна машина AluVM

Протокол RGB також представляє віртуальну машину AluVM, віртуальну машину, повну за Тюрінгом, подібну до EVM Ethereum. Він може виконувати практично всі види обчислень, але обмежений кількістю етапів операції. AluVM обмежує обчислення за допомогою сукупного показника обчислювальної складності, подібно до механізму споживання газу в Ethereum.

3. Приклад визначення договору

З точки зору визначення контракту, протокол RGB використовує певні типи даних, такі як PgpKey, які не є прямою частиною контракту, але можуть бути спільними для кількох контрактів. Стан і дії контракту, такі як ідентифікація та відкликання, визначаються як компоненти стану контракту та можливі переходи стану.

4. Інстанції контрактів та переходи станів

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

5. Розширений функціонал контракту

Протокол RGB дозволяє розширити функціональність контракту, наприклад, додати токени IOU (I owe you), які представлені в контракті як стани, що належать IOYTokens. Крім того, існують глобальні держави, такі як IOYTicker і IOYName, які є глобальними властивостями контракту і не належать безпосередньо жодній стороні.

6. Концепція розширення держави

Концепція розширення стану дозволяє громадськості брати участь у певних логічних частинах контракту, наприклад, шляхом оголошення Burn. Операція розширення стану дозволяє будь-кому створити розширення стану, не беручи на себе ончейн-зобов’язання, подібно до транзакції Bitcoin, яка не інкапсульована в блок.

7. 合约接口(Contract Interface)

Стандартизований зв’язок: Інтерфейс контракту забезпечує стандартний спосіб зв’язку з вузлом RGB, вимагаючи від нього повернення семантично значущого стану та створення операцій.

Подібно до стандарту ERC Ethereum: ці інтерфейси схожі на стандарт ERC Ethereum, а загальний інтерфейс називається «RGBxx» і визначається як окремий стандарт LNP/BP.

8. Приклад створення універсального інтерфейсу токена

Визначення інтерфейсу: визначає глобальні стани (наприклад, тікер і назва) і стани власності (наприклад, інфляція та активи), а також операції (наприклад, випуски та перекази).

Реалізація інтерфейсу: Коли інтерфейс реалізовано, стан і робота певного режиму прив’язуються до інтерфейсу. Наприклад, інтерфейс FungibleToken реалізує глобальні та власні прив’язки станів для патерну DecentralizedIdentity.

4. Застосування протоколу RGB

Фінансові програми:

1 Використовується для створення токенів, які представляють акції компанії або проекту, випущені централізовано, але торгуються децентралізовано, підвищуючи ліквідність і прозорість ринку.

2. Керуйте позиками та облігаціями, автоматизуйте випуск та погашення позик та облігацій за допомогою смарт-контрактів.

3. Створюйте стейблкоїни, які працюють у мережі Lightning Network, і використовуйте ці стейблкоїни як платіжний засіб.

4. Створіть децентралізовану біржу (DEX).

5. Застосовуйте AMM-рішення, такі як алгоритмічно забезпечені стейблкоїни з надмірним забезпеченням, щоб забезпечити ліквідність і стабільність ринку.

Нефінансові додатки:

1. Використовується для управління автономними рішеннями для ідентифікації, які дозволяють людям контролювати та керувати своєю цифровою ідентифікаційною інформацією.

2. Створіть децентралізовану глобальну систему реєстрації імен, щоб люди могли реєструвати та керувати доменними іменами та іншими веб-ідентифікаторами.

3. Керувати правами власності та ліцензування цифрового контенту, включаючи авторські права та ліцензії.

4. Використовується для токенізації творів мистецтва, надаючи нову цифрову платформу власності та торгівлі для художників і колекціонерів.

5. Керуйте DAO для децентралізованого прийняття рішень та управління.

6. Використовується для створення доказової та перевіреної системи журналів аудиту для підвищення прозорості та довіри до бізнесу та проектів.

5. Ризики, пов’язані з поточним протоколом RGB

1 Нестабільність

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

2 Складність

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

Зведення

Протокол RGB все ще знаходиться на дуже ранніх стадіях. Протокол RGB продемонстрував свою інноваційність у сфері смарт-контрактів BTC завдяки унікальному визначенню схеми, віртуальній машині AluVM, гнучкому управлінню станом контракту та механізму масштабування, що підтримує випуск та переказ кількох активів у мережі Bitcoin та мережі Lightning. Однак в даний час протокол RGB не повністю сумісний з Lightning Network, а розробка і робота смарт-контрактів не є безпечними, тому користувачам необхідно знати про ризики при використанні протоколу RGB. **