Зі зростанням популярності RGB++ та випуску пов'язаних з ним активів, дискусії про принципи протоколів RGB та RGB++ поступово стали темою, що цікавить все більше людей. Однак зрозуміло, що для того, щоб зрозуміти RGB++, потрібно спочатку зрозуміти протокол RGB. Оригінальний протокол RGB має дещо технічну структуру, з розрізненими довідковими матеріалами, і на сьогоднішній день не було багато систематичного та зрозумілого довідкового матеріалу. Geek Web3 раніше опублікував дві систематичні інтерпретації RGB та RGB++ (доступні в історії нашого публічного облікового запису), але, згідно з відгуками спільноти, ці статті були довгими та надто складними. Для того, щоб дати можливість більшій кількості людей швидко зрозуміти протоколи RGB та RGB++, автор цієї статті нашвидкуруч завершив коротку інтерпретацію RGB та RGB++ під час заходу в Гонконзі. Його можна прочитати всього за кілька хвилин, щоб допомогти більшій кількості ентузіастів спільноти краще та інтуїтивніше зрозуміти RGB та RGB++.

RGB Протокол: Користувачам потрібно особисто перевірити дані

RGB Protocol — це особливий тип протоколу P2P-активів, що працює в рамках обчислювальної системи Bitcoin chain. У певному сенсі це схоже на платіжні канали: користувачі повинні особисто керувати своїм клієнтом і перевіряти дії переказу, пов'язані з ними («Верифікація самостійно»). Навіть якщо ви просто одержувач активів, ви повинні спочатку підтвердити, що виписка про переказ від відправника правильна, перш ніж переказ набуде чинності. Цей підхід, відомий як «інтерактивна передача», помітно відрізняється від традиційних методів передачі та отримання активів. Навіщо це потрібно? Причина полягає в тому, що протокол RGB, щоб захистити конфіденційність, не використовує «протокол консенсусу», який є в традиційних блокчейнах, таких як Bitcoin та Ethereum (де дані, потрапляючи до протоколу консенсусу, спостерігаються майже всіма вузлами мережі, що ускладнює захист конфіденційності). Без процесу консенсусу за участю великої кількості вузлів, як можна забезпечити безпеку змін активів? Ось тут і з'являється ідея «верифікації клієнта» ( «Верифікуй сам»). Ви повинні керувати своїм клієнтом і особисто перевіряти зміни активів, пов'язані з вами.

Наприклад, розглянемо користувача RGB на ім'я Боб, який знає Алісу. Аліса хоче передати Бобу 100 токенів TEST. Після створення інформації про переказ «Аліса – Боб» Аліса надсилає інформацію про переказ та пов'язані з нею дані про активи Бобу, щоб він особисто перевірив. Лише коли Боб підтверджує, що все правильно, перенесення стає дійсним RGB-перенесенням. Так, протокол RGB вимагає від користувачів самостійно перевіряти достовірність даних, замінюючи традиційні алгоритми консенсусу. Однак без консенсусу дані, отримані та збережені різними клієнтами RGB, суперечливі. Кожен зберігає дані про активи, релевантні лише для себе локально, і не знає про статус активів інших. Хоча це захищає конфіденційність, воно також створює «острови даних». Якщо хтось стверджує, що має 1 мільйон токенів TEST і хоче переказати вам 100 000, як ви йому довіряєте? У мережі RGB, якщо хтось хоче передати вам активи, він повинен спочатку надати підтвердження активів, відстежуючи історію активів від початкової видачі до багаторазових переказів, гарантуючи, що токени, які вони хочуть вам передати, є законними. Це схоже на те, що коли ви отримуєте незрозумілі банкноти, ви просите відправника пояснити історію цих банкнот, чи були вони випущені призначеним емітентом, щоб уникнути фальшивих грошей.

(Джерело зображення: Coinex)

Вищезазначений процес відбувається під ланцюгом Bitcoin, і ці кроки самі по собі не створюють прямого зв'язку між RGB та мережею Bitcoin. Для вирішення цього RGB протокол використовує концепцію «одноразових печаток», які пов'язують RGB активи з UTXO (Unspent Transaction Outputs) на ланцюгу Bitcoin. Поки Bitcoin UTXO не буде подвійно витрачено, прив'язані RGB активи не будуть підлягати подвійній оплаті, використовуючи мережу Bitcoin для запобігання «Реорганізації» активів RGB. Звичайно, це потребує публікації Зобов'язань на ланцюгу Bitcoin та використання опкоду OP_Return.

Давайте намалюємо робочий процес протоколу RGB:

1. Активи RGB пов'язані з Bitcoin UTXOs, а Боб володіє певними Bitcoin UTXOs. Аліса хоче передати 100 токенів Бобу. Перш ніж отримати активи, Боб повідомляє Алісу, який Bitcoin UTXO з його коштів слід використовувати для прив'язки цих активів RGB.

(Джерело зображення: Geekweb3/GeekWeb3)

1. Аліса конструює дані транзакції для переказу активів RGB «від Аліси до Боба», разом із історією цих активів, і передає їх Бобу для перевірки.
2. Після того як Боб підтвердив, що дані правильні локально, він надсилає квитанцію Алісі, повідомляючи, що транзакцію можна проводити.
3. Еліс конструює дані переказу RGB «від Еліс до Боба» в дерево Меркля та публікує Корінь Меркля на ланцюжок Bitcoin як Зобов'язання. Ми можемо просто розуміти Зобов'язання як хеш даних переказу.
4. Якщо хтось у майбутньому захоче підтвердити, що переказ "Аліса до Боба" дійсно стався, йому потрібно зробити дві речі: отримати повну інформацію про переказ "Аліса до Боба" під ланцюгом Bitcoin, а потім перевірити, чи існує відповідне зобов'язання (хеш даних про переказ) на ланцюгу Bitcoin.

Bitcoin виступає в якості історичного журналу для мережі RGB, але журнал записує лише хеш/корінь Меркла даних про транзакції, а не самі дані про транзакції. Завдяки використанню перевірки з боку клієнта та одноразових печаток, протокол RGB пропонує надзвичайно високий рівень безпеки. Оскільки мережа RGB складається з динамічних користувацьких клієнтів у режимі P2P, без консенсусу, ви можете змінювати контрагентів транзакцій у будь-який час, не потребуючи відправляти запити на транзакції до обмеженої кількості вузлів. Таким чином, мережа RGB проявляє велику стійкість до цензури. Ця організаційна структура робить її більш стійкою до цензури порівняно з великомасштабними громадськими ланцюжками, такими як Ethereum.

(Джерело зображення: BTCEden.org)

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

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

Крім того, як ми вже зазначили раніше, мережа RGB не має консенсусу, і кожний клієнт працює в ізоляції, що ускладнює міграцію складних сценаріїв розумних контрактів з традиційних громадських ланцюжків на мережу RGB. Це тому, що DeFi протоколи на Ethereum або Solana ґрунтуються на глобально видимих і прозорих реєстрах. Як оптимізувати протокол RGB, покращити користувацький досвід та вирішити ці виклики, стає невідворотним питанням для протоколу RGB.

RGB++ представляє оптимістичний підхід до депонування, замінюючи перевірку на стороні клієнта.

Протокол під назвою RGB++ вводить новий підхід, поєднуючи протокол RGB з громадськими ланцюжками, що підтримують UTXO, такими як CKB, Cardano та Fuel. У цьому налаштуванні останній служить шаром валідації та зберігання даних для активів RGB, передаючи завдання перевірки даних, які спочатку виконувалися користувачами, стороннім платформам/ланцюжкам, наприклад CKB. Це ефективно заміняє перевірку на стороні клієнта на "перевірку на стороні децентралізованої платформи стороннього". Поки ви довіряєте платформам/ланцюжкам, таким як CKB, Cardano або Fuel, ви можете продовжувати. Якщо ви їм не довіряєте, завжди можете повернутися до традиційного режиму RGB.

RGB++ та оригінальний протокол RGB теоретично сумісні один з одним; це не випадок одного або іншого, але вони можуть співіснувати.

Для досягнення зазначеного ефекту нам потрібно використовувати концепцію, яка називається «гомоморфними зв'язками». Громадські ланцюги, такі як CKB та Cardano, мають свої розширені моделі UTXO, які пропонують більше програмованості порівняно з UTXO на ланцюзі Bitcoin. «Гомоморфне зв'язування» - це ідея використання розширених UTXO на ланцюзях, таких як CKB, Cardano та Fuel, як «контейнерів» для даних активу RGB. Параметри активів RGB записуються в ці контейнери та безпосередньо відображаються на ланцюзі. Кожного разу, коли відбувається транзакція з активами RGB, відповідний контейнер активів також може відображати схожі характеристики, схожі на відношення між сутностями та тінями. Це суть «гомоморфного зв'язування».

(Джерело зображення: RGB++ LightPaper)

Наприклад, якщо Аліса володіє 100 токенами RGB та UTXO (назвемо його UTXO A) на ланцюжку Bitcoin, а також UTXO на ланцюжку CKB, позначений "RGB Token Balance: 100" та розблокованими умовами, пов'язаними з UTXO A:

Якщо Еліс хоче відправити 30 токенів Бобу, вона може спочатку створити зобов'язання з відповідним заявленням: передати 30 токенів RGB, пов'язаних з UTXO A, Бобу та передати 70 токенів до іншого UTXO, який контролюється нею самою.

Далі, Аліса витрачає UTXO A на ланцюгу Bitcoin, публікує вищезазначену заяву, а потім ініціює транзакцію на ланцюгу CKB. Ця транзакція витрачає контейнер UTXO, що містить 100 токенів RGB, створюючи два нових контейнера: один, що містить 30 токенів (для Боба), і інший, що містить 70 токенів (під контролем Аліси). Під час цього процесу завдання перевірки достовірності активів Аліси та транзакційних заяв завершується за згодою вузлів в мережах, таких як CKB або Cardano, без участі Боба. На цьому етапі CKB і Cardano діють як шар валідації та шар DA (Доступність даних), відповідно, під ланцюгом Bitcoin.

(Джерело зображення: RGB++ LightPaper)

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

Важливо підкреслити, що RGB++ вводить значуще припущення довіри: користувачам потрібно оптимістично вірити, що ланцюг CKB/Cardano або мережева платформа, що складається з великої кількості вузлів за допомогою протоколу консенсусу, є надійними та безпомилковими. Якщо ви не довіряєте CKB, ви можете перейти до інтерактивного процесу спілкування та підтвердження за оригінальним протоколом RGB, запустивши свій клієнт самостійно.

За протоколом RGB++ користувачі можуть безпосередньо використовувати свої рахунки Bitcoin для управління контейнерами своїх RGB-активів на ланцюгах CKB/Cardano UTXO без необхідності виконання транзакцій між ланцюгами. Їм просто потрібно використовувати характеристики UTXO на вищезгаданих публічних ланцюгах та встановити умови розблокування контейнера Cell, щоб асоціювати його з певною Bitcoin-адресою/UTXO. Якщо сторони, що беруть участь в транзакціях з RGB-активами, довіряють безпеці CKB, їм може не знадобитися часте публікування Зобов'язань на ланцюзі Bitcoin. Замість цього вони можуть агрегувати та відправляти Зобов'язання на ланцюг Bitcoin після кількох відбутих переказів RGB. Це відомо як функція "складання транзакцій", яка може зменшити витрати на транзакції.

Важливо зазначити, що "контейнери", які використовуються в гомоморфних прив'язках, повинні підтримуватися публічними ланцюгами, які використовують модель UTXO або мають подібні функції у своїй інфраструктурі зберігання станів. Ланцюги на базі EVM не дуже підходять для цієї мети і можуть зіткнутися з багатьма проблемами. (Цю тему можна було б висвітлити в окремій статті, оскільки вона передбачає багато контенту. Зацікавлені читачі можуть звернутися до попередніх статей Geek Web3 під назвою «RGB++ та гомоморфні зв'язки: Як CKB, Cardano та Fuel надають сили екосистемі Bitcoin.“)

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

1. Використовуйте модель UTXO або подібні схеми зберігання стану.
2. Надайте достатню програмованість UTXO, що дозволяє розробникам писати сценарії розблокування.
3. Мати простір станів, пов'язаний з UTXO, який може зберігати стани активів.
4. Є наявні мости або легкі вузли, пов'язані з Bitcoin.

Disclaimer：

1. Ця стаття є перевиданням з [极客 Web3], Усі авторські права належать оригінальному авторові[Фауст]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманди, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонені.