Вивчаємо рішення для масштабування біткоїна: RGB

Catalonec_Ambassador · 16 April 2024 18:13

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

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

Ця стаття також опублікована на Medium：

Швидке дослідження для RGB

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

Основи

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

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

У UTXO1 зберігається 100 RGB-активів. Після витрачання вони перетворюються на UTXO2 та UTXO3 (вказані чорними стрілками). Угода також описує передачу активів RGB (червоні стрілки), розділяючи 100 одиниць на 30 і 70 частин, відповідно пов’язаних з UTXO3 і UTXO4.

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

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

Цей інноваційний підхід відомий в протоколі RGB як одноразові печатки.

Індикація операцій RGB в Біткойн

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

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

Такий підхід забезпечує приватність транзакцій RGB. Не учасники протоколу RGB можуть бачити лише наступну дію в мережі:

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

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

Верифікація на стороні клієнта

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

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

Використовуючи наведений вище приклад, Боб, власник UTXO1, хоче передати 70 активів RGB Алісі, яка володіє UTXO4.

В ході транзакції створюються додаткові дані, data2, і Аліса отримує від Боба всі дані, включаючи data0, data1 і новостворені data2.
Вивчивши дані RGB (data0, data1 та data2), Аліса може відстежувати зміни стану активів RGB (синя пунктирна лінія).
Потім Аліса перевіряє наявність хешу даних RGB (data2, data1 тощо) у блокчейні та підтверджує, що пов’язана з ними транзакція була підтверджена мережею біткойнів, тим самим гарантуючи справжність даних (Зелена пунктирна лінія). Аліса повинна підтвердити достовірність усіх даних RGB з моменту розгортання контракту (відповідного транзакції data0 в мережі, не зображеної на малюнку) і до самої останньої транзакції. Боб виконує ідентичний процес перевірки після отримання Алісою активів.

Клієнт дотримується досить суворого підходу до забезпечення конфіденційності. Варто зазначити, що навіть оригінальний Розробник контракту RGB, не маючи доступу до data2, не зміг би виявити транзакцію між Бобом та Алісою.

Довіра та безпека

Враховуючи важливість безпеки, ми обговоримо різні компоненти протоколу та додатків, яким користувачі повинні довіряти, та проведемо аналіз з точки зору “довіри”.

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

Користувачі повинні довіряти мережі Bitcoin:

Транзакції в мережі Bitcoin повинні бути захищені від подвійних витрат; в іншому випадку активи RGB також можуть опинитися під загрозою.
Транзакції в мережі Біткойн повинні залишатися без будь-якого підпису; в іншому випадку транзакції RGB можуть бути заблоковані від додавання в мережу.

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

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

Додаткова інформація

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

Компанія RGB розробила віртуальну машину, що відповідає вимогам Тьюрінга, відому як AluVM, що розширює її можливості.

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

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

TVL

Враховуючи особливості конфіденційності, властиві RGB, відстеження Total Value Locked (TVL) не представляється можливим за допомогою існуючих методів.

Огляд RGB: плюси і мінуси

Переваги:

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

Недоліки:

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

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

Більше деталей

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

Реплікація механізмів станів і позамережеві обчислювальні механізми

Фундаментальна проблема технології блокчейн полягає в забезпеченні того, щоб всі вузли підтримували узгоджену облікову книгу. Ми почнемо з обговорення широко поширеного підходу, відомого як" реплікація машини станів", який використовується в Bitcoin і інших блокчейнах для досягнення відмовостійкості. Цей метод широко використовується в розподілених системах для вирішення проблеми узгодженості декількох копій. Наприклад, на цьому принципі засновані як розподілені бази даних, так і блокчейн. Процес простий:

Кожна копія ініціалізується певним станом як початкова точка.
Переходи між станами відбуваються наступним чином:

До отримання нового вхідного сигналу стан кожного екземпляра залишається незмінним.
Отримавши вхідний сигнал i у стані s, екземпляр переходить у новий стан s’. Цей перехід є детермінованим, тобто при однакових вхідних даних I і стані s результуючий стан s’ буде однаковим для всіх копій.

Якщо гарантувати, що всі копії починаються з одного початкового стану s0 і обробляють однакові входи (i0, i1 ,i2…in) в одному і тому ж порядку, їх кінцеві стани будуть узгоджені.

У контексті біткойна ми називаємо цим" станом " усі невитрачені транзакційні суми (UTXO) у системі.

Кожен вузол біткойна починає з блоку генезису як свого початкового стану.
Переходи між станами здійснюються наступним чином:

Стан реєстраційної книги залишається незмінним до тих пір, поки не буде отримана нова транзакція (блок).
Після отримання нової транзакції (блоку) реєстраційна книга переходить в новий стан. Цей процес детермінований; при однаковому стані книги та транзакції (блоку) отриманий стан книги буде послідовним.

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

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

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

Такі протоколи, як Inscription та Rune, дотримуються подібної моделі, але стикаються з додатковою проблемою відсутності стандартизованої реалізації на ранніх стадіях розвитку екосистеми. При різних реалізаціях механізмів виконання поза ланцюжком (індексаторів) перевірка результатів може бути ускладнена.

Схеми фіксації

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

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

Хешування - це часто використовувана Техніка для розробки схем фіксації. Наприклад, дерево Меркла, добре відома концепція в технології блокчейн, є одним з видів схеми фіксації зобов’язань. Зобов’язання також часто використовуються в інших додатках blockchain, наприклад, у двоетапному процесі реєстрації в ENS, який допомагає запобігти випередженню інших осіб при реєстрації доменних імен.

Підтвердження публікації

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

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

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

Пов’язані ресурси

RGB Blackpaper
RGB website
CoinEx Research: A Brief Analysis of RGB: A Scalable, Confidential Smart Contract Protocol Built on Bitcoin
RGB presentation slides

RGB++

Огляд та перспективи

RGB++ - це розширення протоколу RGB, представлене командою Cipher from Nervous CKB. Nervos CKB-це публічний блокчейн, що використовує модель на основі UTXO, звану в його рамках “осередками”. Грунтуючись на протоколі RGB, RGB++ зіставляє структуру RGB UTXO з Cells Nervos KB, використовуючи скриптові обмеження в мережах CKB і Bitcoin для забезпечення точності обчислень стану і законності передачі прав власності. Мета RGB++ - вирішити технічні проблеми, з якими стикається оригінальний протокол RGB в реальних сценаріях, розвантаживши клієнтську частину роботи на блокчейн CKB.

Огляд протоколу

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

Як це працює

Будучи розширенням RGB, рекомендується ознайомитися з протоколом RGB, перш ніж приступати до роботи. Суть КПІ++ полягає в переході від традиційного підходу до перевірки на стороні клієнта до моделі, в якій всі дані відкрито публікуються на блокчейне Nervos якщо, а якщо виступає в якості механізму реалізації. Ми продовжимо використовувати приклад з протоколу RGB, щоб проілюструвати це, як показано на малюнку нижче (будь ласка, зверніть увагу: цей малюнок є спрощеним поданням базового функціонування RGB++ тільки в ілюстративних цілях).

У прикладі Боб передає Алісі 70 активів RGB. На відміну від попередньої перевірки на стороні клієнта, тепер усі дані, пов’язані з RGB, знаходяться у відкритому доступі в мережі CKB, а CKB бере на себе роль механізму виконання для управління та підтримки стану контракту RGB.

Боб може легко перевірити через Nervos CKB, що він має 100 активів RGB, пов’язаних з його UTXO1.
Коли Боб надсилає активи Алісі, немає необхідності ділитися з нею даними data0 та data1; Аліса може самостійно отримати доступ до поточного стану контракту або історичних даних на блокчейні.
Після підтвердження транзакції Bitcoin, що включає зобов’язання (0x345ab … D7654), Боб може відправити транзакцію з даними RGB (data2) в CKB. Вузли CKB, що працюють під управлінням полегшеної версії вузла Bitcoin, перевіряти існування зобов’язання в мережі Bitcoin.
Після того як CKB обробить транзакцію, Аліса побачить, що тепер на її UTXO4 знаходиться 70 активів RGB.

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

Деталі процесу транзакції

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

Обчислення поза мережею

Боб вибирає наступний UTXO, який буде використовуватися для транзакції BTC, наприклад UTXO1.
Боб виконує обчислення поза мережею, щоб створити транзакцію КПІ++ для відправки в мережу Лі: ЛІ_ТХ. Ця транзакція включає необхідні дані для зміни стану RGB.
Боб обчислює поза мережею значення зобов’язання commitment (0x345ab … D7654).

Відправка транзакції BTC

Боб створює та надсилає транзакцію Bitcoin, яка витрачає UTXO1, включаючи вищезазначене зобов’язання (0x345ab…D7654) через операцію OP_RETURN.

Надсилання транзакції CKB

Боб надсилає KB_TX до мережі CKB.
Останній стан користувача зберігається в СЛІ_ТХ.output.data.
Для подальшої зміни стану (Алісою) буде потрібно UTXO4 і вихід CKB_TX.

Верифікація мережі

Біткоіни UTXO1 використовується тільки один раз.
Через вузол Bitcoin LightNode компанія KB перевіряє значення зобов’язання в мережі Bitcoin і переконується, що відповідний UTXO був витрачений.
CKB підтверджує, що перехід стану контракту в його мережі відповідає заздалегідь визначеним правилам контракту.

Надійність і безпека

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

Користувачі повинні довіряти мережі Bitcoin.

Транзакції в мережі Bitcoin не повинні бути подвійними, інакше активи RGB(++) також будуть схильні до ризику подвійного витрачання.
Транзакції в мережі Bitcoin не повинні піддаватися цензурі; в іншому випадку транзакції RGB(++) не зможуть бути записані в блокчейн.
Користувачі повинні довіряти механізму виконання транзакцій у мережі CKB з тих же причин, що і у випадку з RGB.

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

Як і у випадку з зобов’язаннями в Bitcoin, зловмисники не можуть створити іншу транзакцію CKB з іншим змістом виконання. Користувачам не потрібно турбуватися про подвійне витрачання активів RGB через невідповідність мережі CKB.
Однак користувачам слід враховувати, що якщо в мережі CKB відбудеться відкат, це може призвести до втрати даних транзакцій. Якщо користувачі не зберегли відповідні дані транзакцій, це може призвести до постійної втрати даних RGB++.

Слід зазначити, що наведений вище аналіз довіри не враховує розширені можливості, заплановані проектом RGB++, такі як “згортання транзакцій” та “глобальні клітинки стану”.

Короткий опис RGB++: переваги та недоліки

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

Переваги:

Користувачам більше не потрібно самим зберігати дані; якщо бере на себе турботу про розміщення даних.
Більшість обов’язків середовища виконання покладено на CKB, що дозволяє користувачам отримувати доступ до останнього стану контракту RGB безпосередньо з мережі CKB без необхідності кожного разу ініціювати весь процес обробки даних RGB.
CKB автоматично перевіряє транзакції через легкі вузли Bitcoin, позбавляючи користувачів від необхідності проводити власну перевірку.

Недоліки:

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

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

Як рішення для масштабування біткойна, переваги та недоліки RGB++ полягають у наступному:

Переваги:

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

Недоліки:

Рішення не дозволяє ефективно вирішити проблему масштабованості. (Складання транзакцій, запропоноване в документі RGB++ Light Paper, може дещо пом’якшити цю проблему; для отримання додаткової інформації читачам рекомендується вивчити наступні матеріали).

Докладно

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

Ізоморфне зв’язування

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

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

Формування транзакцій

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

Загальний стан і його ризики для безпеки
Щоб розширити можливості контракту, RGB++ вводить поняття “глобальної комірки стану”. Про цю можливість розповідається в технічному документі RGB++ “Shared State and Unhosted Contracts”:

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

Посередня реалізація в цьому контексті означає, що існує ризик того, що клітинка глобального стану зайнята іншим користувачем, що призведе до збою CKB TX, оскільки зазначений глобальний стан utxo не існує. Оскільки Bitcoin TX повинен бути відправлений і обчислений в зобов’язання перед CKB TX, подальша перевірка стає неможливою.

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

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

Коли вводяться такі елементи, як глобальний стан, Це змінює динаміку, оскільки порядок розкриття транзакцій A і b на різних шляхах може вплинути на результат. Розглянемо наступний сценарій:

Обидві транзакції A і b зареєстрували свої зобов’язання в мережі BTC.
Транзакція якщо Для А не була записана через якусь проблему, наприклад атаки цензури на мережу сію
Транзакція B вже змінила глобальний стан після виконання.
Якщо транзакція A врешті-решт буде записана на CKB, вона може дати інші результати або навіть не вдатися, що потенційно може призвести до втрати активів.

Рішення Intent Cell, представлене в технічному документі, не повністю вирішує цю проблему. Хоча він забезпечує виконання транзакцій, переданих CKB, він не гарантує, що результат виконання A і b буде відповідати очікуванням. В оригінальному протоколі RGB, поки клієнт правильно будує перехід стану і зобов’язання, контракт працює так, як очікувалося. Однак в RGB++ результат виконання транзакції за зобов’язанням, прийнятим першим на Bitcoin, тепер контролюється CKB, що знижує початкову “безпеку першого рівня”. Включення комірки глобального стану в RGB може бути не найбезпечнішим вибором.

Пов’язані ресурси

Light Paper по протоколу RGB++
Спецификация контракта RGB++

Додаток: обговорення побудови псевдокоду механізму виконання RGB в EVM

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

BTC_STATE-це спеціально реалізований контракт, який, як ми припускаємо, може (через невеликий вузол) зчитувати підтверджену інформацію про біткойн. У той же час будь-хто може вручну зробити значення зобов’язання транзакції публічним через функцію open Commitment в RGB_CONTRACT, використовуючи EVM як механізм виконання для виконання транзакцій RGB. Тут ми припускаємо, що значення зобов’язання транзакції передається в мережу.

// BTC_STATE can read bitcoin confirmed state
contract BTC_STATE {
stuct TXO {
uint256 btcTxId;
uint256 outputIndex;
}
// a bitcoin tx will have at most 1 OpReturn
function readBitcoinOpReturn(uint256 btcTxId) returns (bytes);
// or
function readBitcoinTransactionOutputScript(TXO txo) returns(bytes);

function isBitcoinTransactionOutputSpent(TXO txo) returns(boolean);
// …
function readBitcoinOrdinalIndex(TXO txo, uint256 satoshiIndex) returns (uint256);
// …
function readBitcoin…(uint256 btcTxId) returns (bytes);
}

contract RGB_CONTRACT {
struct RGB_DATA {
TXO input; // could be multiple, only for reference
TXO output; // could be multiple, only for reference
bytes payload;
}
mappinp(uint256 => bytes) utxoStatus;
mappinp(uint256 => boolean) utxoPermission;
function openCommitment(RGB_DATA calldata data, bytes32 salt) public {
isValidOpen(data, salt);
utxoPermission[calcTxoHash(data.input)] = false;
utxoPermission[calcTxoHash(data.output)] = true;
execute(data.payload);
}
function calcTxoHash(TXO txo) pure returns (uint256);
function calcCommitment(RGB_DATA calldata data, bytes32 salt) pure returns (bytes32);
function execute(bytes payload) internal;
function isValidOpen(RGB_DATA calldata data, bytes32 salt) {
require(utxoPermission[calcTxoHash(data.input)], “from utxo should have permission”);
require(
calcCommitment(data, salt) == BTC_STATE.readBitcoinOpReturn(data.input.btcTxId)
);
_;
}
}

Посилання на оригінал: Exploring Bitcoin Scaling Solutions: RGB

Приєднуйся до спільноти Conflux Ukraine