протокол RGB: користувачі повинні самостійно перевіряти дані

Протокол RGB - це спеціальний протокол активів P2P та обчислювальна система в межах ланцюжка Bitcoin. У деяких аспектах він схожий на платіжний канал: Користувачам потрібно самостійно запускати клієнт та перевіряти свою власну поведінку передачі (перевіряти самостійно). Навіть якщо ви лише отримувач активу, вам спочатку потрібно переконатися, що в заяві про переказ активу відправника немає помилок, перш ніж ця заява про переказ набуде чинності. Очевидно, що це повністю відрізняється від традиційної форми відправлення та отримання активів. Ми називаємо це "інтерактивним переказом".

Чому так має бути? Причина полягає в тому, що для забезпечення конфіденційності протокол RGB не використовує «протокол консенсусу» в традиційних блокчейнах, таких як Bitcoin та Ethereum. (Після того, як дані пройдуть через протокол консенсусу, за ними спостерігатимуть майже всі вузли мережі, і конфіденційність не гарантується). Як гарантувати, що зміни активів будуть безпечними без процесу консенсусу за участю великої кількості вузлів? Тут використовується ідея під назвою «Верифікація клієнта» (Verify by yourself). Вам потрібно самостійно керувати клієнтом і особисто перевіряти пов'язані з вами зміни активів. Припустимо, є користувач RGB на ім'я Боб, який знає Алісу, і Аліса хоче передати Бобу 100 токенів TEST. Після того, як Аліса згенерує інформацію про передачу «Аліси Бобу», вона повинна спочатку надіслати інформацію про передачу та дані про активи Бобу, і дозволити йому особисто перевірити її, щоб переконатися, що вона правильна, перш ніж розпочати наступний процес, і, нарешті, вона стає дійсною передачею RGB. Таким чином, протокол RGB дозволяє користувачам особисто перевіряти достовірність даних, замінюючи традиційний алгоритм консенсусу. Але без консенсусу дані, отримані та збережені різними клієнтами RGB, суперечливі. Кожен зберігає дані про власні активи лише локально і не знає статусу активів інших. Захищаючи конфіденційність, це також є «островом даних». Якщо хтось стверджує, що має 1 мільйон токенів TEST і хоче переказати вам 100 000, як ви можете в це повірити? У мережі RGB, якщо хтось хоче переказати вам гроші, він повинен спочатку показати підтвердження активів, простежити історичне джерело активів від початкової випуску до багаторазової зміни рук і переконатися, що токен, який вам буде переказано, чистий. Це схоже на те, коли ви отримуєте банкноти невідомого походження і просите іншу сторону пояснити історичне джерело цих банкнот і те, чи були вони виготовлені призначеним емітентом, щоб уникнути фальшивої валюти.

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

Вищезазначені процеси відбуваються під ланцюгом Bitcoin, і лише ці процеси не можуть зробити RGB безпосередньо пов'язаним з мережею Bitcoin. У цьому відношенні протокол RGB використовує ідею, яку називають "печатка одноразового використання", щоб зв'язати активи RGB з UTXO на ланцюзі Bitcoin. Поки UTXO Bitcoin не подвійно використовується, зв'язані активи RGB не будуть подвійно витрачені. Таким чином, мережу Bitcoin можна використовувати для запобігання "Переорганізації" активів RGB. Звичайно, цей зобов'язання потрібно опублікувати на ланцюзі Bitcoin, і використовується опкод OP_Return.

Ось краткий опис робочого процесу протоколу RGB:

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

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

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

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

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

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

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

Чи можете уявити, що хтось хоче передати вам гроші, але вони повинні надіслати вам дані транзакції для підтвердження, і лише після отримання вашого повідомлення-квитанції процес передачі може бути завершений?

Крім того, ми зазначили, що у мережі 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 на ланцюжку BTC. «Ізоморфне зв'язування» полягає в тому, щоб використовувати розширені UTXO на ланцюжках CKB, Cardano та Fuel як «контейнери» для даних активів RGB, записувати параметри активів RGB в ці контейнери та відображати їх безпосередньо на блокчейні. Кожного разу, коли відбувається транзакція з активами RGB, відповідний контейнер активів також може показати схожі характеристики, схоже на відношення між сутністю та тінями. Це суть «ізоморфного зв'язування».

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

Наприклад, якщо Аліса володіє 100 токенами RGB та UTXO A на ланцюгу Bitcoin, а також має UTXO на ланцюгу CKB, цей UTXO позначений "Баланс токенів RGB: 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++ користувачі можуть безпосередньо використовувати свої біткойн-рахунки для управління контейнерами своїх RGB-активів на ланцюгах UTXO, таких як CKB/Cardano, без перехресного ланцюга. Просто використовуйте характеристики UTXO вищезгаданого загального ланцюга та встановіть умову розблокування контейнера Cell, щоб вона була пов'язана з певною адресою біткойн/біткойн UTXO. Якщо обидві сторони, що беруть участь у транзакціях з RGB-активами, можуть довіряти безпеці CKB, їм навіть не потрібно часто видачі Зобов'язань на ланцюгу біткоїн. Після багатьох переказів RGB може бути відправлено Зобов'язання на ланцюг біткоїн. Це називається функцією "згортання транзакції", яка може зменшити витрати на використання.

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

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

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

Disclaimer:

1. Ця стаття відтворена з [Гік Веб3] оригінальний заголовок - “RGB та RGB++ дизайн протоколу за кілька хвилин: прості інструкції”, авторське право належить оригінальному автору [Faust], якщо у вас є будь-які зауваження до повторного друку, будь ласка, зв'яжітьсяGate Learn Team, команда якнайшвидше вирішить це відповідно до відповідних процедур.

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

3. Інші мовні версії статті перекладені командою Gate Learn. Без посиланняГейт.іо, копіювання, поширення або плагіатування перекладених статей заборонене.