RGB покращує масштабованість і конфіденційність Bitcoin і Lightning Network

TL, д-р

• RGB працює як рішення рівня 2/3 у парадигмі перевірки на стороні клієнта Bitcoin та Lightning Network, зберігаючи всі дані смарт-контрактів поза транзакціями Bitcoin. Така конструкція забезпечує роботу системи на вершині мережі Lightning, усуваючи необхідність модифікації протоколів LN.
  
• Розумні контракти RGB створені для масштабованості та конфіденційності. Система підтримує приватне та взаємне володіння, абстрагує та відокремлює проблеми, представляючи пост-блокчейн, повну за Тьюрингом форму надійних розподілених обчислень без необхідності введення нових токенів.
  
• Контракти RGB організовані в окремі сегменти, які називаються «шардами», кожен із яких має власну історію та дані, що покращує масштабованість і запобігає змішуванню історій із різних контрактів. Вони взаємодіють через протокол Bifrost у мережі Lightning, забезпечуючи скоординовані зміни між кількома сторонами, подібно до DEX, що працюють у мережі Lightning.
  
• RGB використовує одноразові пломби defiдля безпеки біткойн UTXO. Будь-яка сторона, яка володіє історією стану смарт-контракту, може перевірити його унікальність, використовуючи для цього сценарій Bitcoin define право власності та права доступу.
  
• У RGB державна власність і валідація є окремими сутностями. Право власності керується сценарієм біткойн, не повною системою Turing Complete. Правила перевірки, з іншого боку, продиктовані схемою RGB за допомогою сценарію Turing Complete Simplicity/Contractum/Rust.
  
• Кожен смарт-контракт RGB пов’язується з унікальним станом за допомогою одноразових печаток. Печатки та стан відповідають певним правилам і перевіркам, встановленим творцем контракту, керованим «схемою». Ця схема діє як набір правил для перевірки даних контракту на стороні клієнта, забезпечуючи високий рівень масштабованості та конфіденційності протоколу.
  
• Конструкція RGB добре сумісна з існуючими технологіями Bitcoin і Lightning Network, що сприяє бездоганній інтеграції з цими платформами та будь-яким майбутнім оновленням.
  
• На відміну від імперативного стилю програмування багатьох блокчейн-платформ, RGB використовує декларативний стиль. Цей підхід зосереджений на окресленні бажаного результату, а не на деталізації конкретних кроків для його досягнення.
  
• RGB використовує різноманітні передові технології, зокрема AluVM для детермінованих портативних обчислювальних завдань, PRISM для частково реплікованих нескінченних кінцевих автоматів обчислень і Storm для безнадійного зберігання на основі умовного депонування з використанням zk-proofs. Ці технології сприяють надійності, конфіденційності та розширюваності RGB.
  
• RGB (v0.10) представляє значні покращення для взаємодії з користувачем та процеси інтеграції, оптимізуючи операції та мінімізуючи залежності. Оновлена ​​версія має більш уніфікований бібліотечний API та інструмент командного рядка, що робить його більш доступним і зручним для користувача.

Короткий опис

RGB — це протокол, призначений для видачі токенів у мережі Bitcoin з підвищеною конфіденційністю та сумісністю з Lightning Network. Він ґрунтується на концепції «кольорових монет», подібних до тих, що використовуються в протоколі OmniLayer, де метадані в транзакціях біткойн вказують на передачу токенів. Наприклад, транзакції USDT на OmniLayer функціонують як транзакції біткойн, доповнені додатковими даними з детальною інформацією про рух токенів USDT. Однак ці методи стикаються з обмеженнями, такими як обмеження розміру даних у виходах OP_RETURN, інтенсивне сканування блокчейну та обмежена конфіденційність, що виникає через видимість у ланцюжку.

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

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

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

Вступ і бачення

Одностроковий: Перевірений клієнтом стан і система смарт-контрактів, що працює на рівні 2/3 у Bitcoin та Lightning Network.

Докладніше:

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

Розумні контракти втілюють принципи приватної та спільної власності, абстракції та поділу інтересів. Вони являють собою «постблокчейн», повну за Тьюрингом форму ненадійних розподілених обчислень, які не потребують впровадження токенів.

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

Хоча вони функціонують незалежно, контракти RGB можуть взаємодіяти через протокол Bifrost у мережі Lightning. Це дозволяє координувати зміни між кількома сторонами. Наприклад, це дозволяє DEX функціонувати через Lightning Network.

Технології та архітектура

Загальний огляд роботи RGB і одноразових пломб

Малюнок 1. Загальний огляд роботи RGB.
Джерело: LNP/BP Association Github.

Як механізм безпеки використовується RGB одноразові пломби defined над біткойнами UTXO, які надають можливість будь-якій стороні, яка має історію стану смарт-контракту, перевірити свою унікальність. По суті, RGB використовує сценарій Bitcoin для своєї моделі безпеки та defiРЕШ власність та права доступу.

Рисунок 2. Принцип роботи високого рівня RGB.
Джерело: «Стимулювання масового впровадження крипто: як протокол RGB висвітлює майбутнє біткойна» від Waterdrip Capital.

Кожен смарт-контракт RGB є defined by a стан генезису, створений емітент смарт-контракту (або, простіше кажучи, емітент) і спрямований ациклічний граф (DAG). переходи станів зберігаються як перевірені клієнтом дані.

Рисунок 3. Угоди, закрита печатка та свідок.
Джерело: LNP/BP Association Github.

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

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

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

Право власності та доступ: основні властивості

Рисунок 4. Право власності та доступ.
Джерело: LNP/BP Association Github.

Державна власність і валідація – це різні поняття. Правила перевірки вказують, як може змінитися стан, але не визначають, хто може здійснити зміну. 

З іншого боку, право власності контролюється сценарієм біткойн на рівні блокчейну біткойн, що не є повним Тьюрингом. Навпаки, правила перевірки регулюються схемою RGB, яка використовує сценарій Simplicity/Contractum, тобто є завершеною за Turing. 

Схема RGB

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

Малюнок 5. Схема RGB.
Джерело: LNP/BP Association Github.

Перевірка на стороні клієнта та принципи проектування

Рисунок 6. Перевірка RGB на стороні клієнта.
Джерело: LNP/BP Association Github.

1. Сильна власність: У RGB розумні контракти мають чітке значення defiнеобхідний власник або власники. Лише призначені власники мають повноваження змінювати стан контракту. Ці контракти окреслюють окремі права чи операції, класифіковані як публічні (доступні для всіх) або власність (обмежені власником).
2. Конфіденційність: Інформація в рамках договору є конфіденційною, відомою лише учасникам, особливо власникам держави. Учасники мають можливість зробити певні дані загальнодоступними, але за умовчанням уся інформація є конфіденційною. Ця конфіденційність запобігає доступу зовнішніх інструментів аналізу до даних, гарантуючи, що конфіденційна інформація не зберігається в загальнодоступних книгах.
3. Відокремлення концернів: RGB має модульну конструкцію з окремими шарами, кожному з яких призначено певне завдання. Ці рівні працюють незалежно, усуваючи необхідність для нижчих рівнів знати структуру вищих рівнів. Така конструкція покращує організацію та ефективність системи.
4. Розширюваність: Система легко розширюється, що дозволяє створювати та інтегрувати розширені смарт-контракти без необхідності змінювати основний протокол або перекомпілювати всю бібліотеку RGB.
5. детермінізм: Логіка перевірки RGB є детермінованою, постійно дає ідентичні результати з однаковими вхідними даними та переважаючим станом основного блокчейну або каналу Lightning Network. Ця послідовність досягається завдяки двом основним компонентам: a. Основна логіка перевірки, написана на Rust, однакова в усіх системах із RGB. b. Контрактна логіка перевірки працює на AluVM, віртуальній машині, яка забезпечує послідовний набір інструкцій незалежно від платформи.
6. Сумісність LNP/BP: RGB розроблений для бездоганної роботи з існуючими технологіями Bitcoin і Lightning Network. Він також створений для сумісності з будь-якими майбутніми оновленнями цих технологій.
   

Підхід RGB і підхід Pure Blockchain/L1

Команда RGB заявляє, що чистий підхід блокчейн/L1 є неправильним.

Рисунок 7. Коментарі RGB щодо підходу Blockchain/L1.
Джерело: LNP/BP Association Github.

Підхід RGB: декларативне проти імперативного програмування:

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

Декларативний характер смарт-контрактів RGB:

• RGB, з іншого боку, не використовує імперативного програмування. Замість цього він використовує спеціальну форму функціонального програмування, де є смарт-контракти defined декларативно.
• У декларативному програмуванні замість детального опису того, як щось зробити, ви описуєте, яким має бути результат. Це все одно, що описати, як має виглядати страва, а не надавати покрокові інструкції з приготування.
• «Схема» в RGB є декларативною defiпоняття смарт-контракту. Він визначає правила та умови контракту, але не точну послідовність операцій для їх досягнення.

Зміна парадигми в програмуванні:

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

Простота

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

Визнаючи відсутність надійного розкладу для Simplicity, ми розпочали вивчення альтернатив (WASM, EVM (як жарт), IELE тощо). Згодом стало зрозуміло, що розробка власної віртуальної машини для RGB була єдиним життєздатним варіантом, який замінив початкову залежність від Simplicity.

Тому ми вирішили створити AluVM – чисто функціональна, високопортативна віртуальна машина на основі Rust для перевірених на стороні клієнта смарт-контрактів (RGB), Lightning Network, детермінованих розподілених і периферійних обчислень.

Призма

PRISM розшифровується як «частково відтворені нескінченні автомати».

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

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

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

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

Рисунок 8. Розділення розподілених систем.
Джерело: LNP/BP Association Github.

Більш конкретні відмінності такі: 

Рисунок 9. Порівняння державних каналів і перевірки на стороні клієнта.
Джерело: LNP/BP Association Github.

AluVM

AluVM – (алгоритмічний логічний блок VM) – це чисто функціональна віртуальна машина RISC, розроблена для детермінованих портативних обчислювальних завдань

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

Основні характеристики: Без винятків, переносимість, пісочниця, безпека, розширюваність.

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

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

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

Малюнок 10. Порівняння AluVM.
Джерело: LNP/BP Association Github.

Контрактум

Contractum вирізняється з-поміж інших мов програмування смарт-контрактів, поєднуючи функціональні можливості Haskell із наближеністю до «голого металу» в Rust. Він займає нішу, яка раніше була недоступна для смарт-контрактів:

Рисунок 11. Порівняння Contractum, Simplicity та інших мов.
джерело: contractum.org

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

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

Рисунок 12. Характеристики Contractum.
джерело: contractum.org

Щоб займатися проектуванням Contractum, важливо ознайомитися з технологіями, які використовуються в смарт-контрактах RGB:

Малюнок 13. Технології, які використовуються смарт-контрактами RGB.
джерело: contractum.org

Останні оновлення в новій версії RGB v0.10

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

Глобальний стан у контрактах RGB

Функція Global State є важливою інновацією в RGB v0.10, що дозволяє кожному контракту підтримувати загальнодоступний стан. Цей стан доступний не лише для віртуальної машини RGB, але й для зовнішніх клієнтів, таких як гаманці та інші програми.

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

Контрактні інтерфейси

RGB v0.10 представляє «контрактні інтерфейси» як стандартизований протокол зв’язку для різноманітних смарт-контрактів. Ці інтерфейси функціонують подібно до контрактних ABI (бінарних інтерфейсів додатків) і ERC (запит на коментарі Ethereum).

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

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

Система строгого типу

Новий формат кодування в RGB v0.10 використовує систему «суворих типів». Ця система є новим підходом функціонального типу даних, розробленим для ефективного представлення та самоаналізу контрактних станів у рамках RGB.

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

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

Смарт-контракти на основі Rust

Розумні контракти RGB тепер можна створювати в Rust, використовуючи можливості мови для безпеки типів і продуктивності.

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

Розширені можливості самоаналізу стану

Розумні контракти в RGB v0.10 можуть перевіряти власний стан у коді перевірки, який виконується віртуальною машиною RGB.

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

Формат рахунку-фактури на основі URL-адреси

Оновлення представляє новий формат рахунку-фактури, який замінює попередню систему кодування Bech32m.

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

Підтримка WASM (WebAssembly).

Стандартна бібліотека RGB тепер сумісна з середовищами без доступу до вводу/виводу та файлової системи, такими як веб-сторінки або плагіни браузера.

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

Кореневі дескриптори та настроюване похідне

RGB v0.10 використовує зобов’язання OP_RETURN на основі taproot (іменовані tapret), що вимагає підтримки на рівні дескрипторів для гаманців для розпізнавання транзакцій із налаштованими виходами.

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

Спрощені залежності

Рівень консенсусу RGB у версії 0.10 зменшив свої залежності, зокрема, відійшовши від спеціальної куленепробивної реалізації, спочатку отриманої від проектів Grin.

Це зменшення залежностей підвищує стабільність API та загальну надійність системи.

Спрощений процес інтеграції

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

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

Удосконалення досвіду користувачів

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

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

Цей розділ містить особливу подяку Waterdrip Capital за висвітлення останніх функцій у їхній статті під назвою «Стимулювання масового впровадження криптовалюти: як протокол RGB висвітлює майбутнє біткойна».

Конкуренти RGB

Рисунок 14. FRGB проти Ethereum простими словами.
Джерело: LNP/BP Association Github

Корінь

Taproot Assets, раніше відомий як Taro, — це протокол, призначений для запуску токенів у мережі Bitcoin. Цей протокол використовує модель UTXO Taproot разом із відповідними рішеннями, такими як Tapscript і taptweak. Ці інструменти використовуються для зберігання інформації про постачання та баланс активу в даних транзакцій Bitcoin.

Рисунок 15. Схема зберігання інформації про токени Taproot Assets.
Джерело: «Taproot Assets: випуск активів на біткойнах» від Voltage

Taproot Assets використовує метод, аналогічний концепції Ordinals, згідно з яким токени BRC-20 зберігають інформацію про постачання в метаданих пронумерованих сатоші. Навпаки, Taproot Assets вбудовує цю інформацію в вихід Taproot транзакції біткойн, використовуючи так зване «розріджене дерево Меркла». По суті, Taproot Assets включає дерево Merkle в транзакцію Bitcoin, яке служить доказом балансу конкретного користувача та загальної пропозиції токенів. Це дерево, у свою чергу, відображає дані з «Всесвіту» — сховища, яке зберігає повну історію активів і яким керує емітент токенів.

Рисунок 16. Цифрове дерево стану.
Джерело: «Taproot Assets: випуск активів на біткойнах» від Voltage

Цифрове дерево стану – архітектура Taproot Assets пропонує два варіанти підтвердження балансу: дані поза ланцюгом із Всесвіту або розріджене дерево Merkle, вбудоване в UTXO.

Операційний механізм

1. Творець токена виконує транзакцію P2TR (Pay to Taproot) за допомогою протоколу Taproot Assets. 
2. Інформація про актив у формі дерева Merkle зберігається в UTXO цієї транзакції (фактично, блок генезису). 
3. Щоб передати маркер, власник ключа Taproot змінює інформацію про баланс у дереві Merkle, забезпечуючи постійність загальної пропозиції активів. 
4. Такі зміни вводяться через нову транзакцію Taproot. Однак для кожного переказу токена окрема транзакція в ланцюжку не потрібна. Подібно до зведень або Lightning Network, протокол дозволяє власнику обробляти «пакет» переказів, згодом публікуючи оновлений стан балансів.

Переваги Taproot Assets

• Однією з ключових переваг Taproot Assets є його повна сумісність із Lightning Network, що покращує можливості масштабування та знижує витрати на транзакції.
• Taproot Assets створює окремий рівень для запису операцій із спеціальними маркерами. Хоча він в основному покладається на дані поза мережею, він оприлюднює стан балансу в основній мережі. 
• Цей підхід є більш гнучким, масштабованим і комплексним порівняно з BRC-20, але він також створює більшу складність для недосвідчених користувачів.

BitVM

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

Основні функції та концепція BitVM

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

Керування онлайновою перевіркою в мережі з обмеженим обчислювальним ресурсом

Проблема виникає в тому, як провести перевірку роботи в мережі, яка за своєю суттю не підтримує такі обчислення. Щоб вирішити цю проблему, BitVM використовує дерево Merkle для створення логічної схеми воріт NAND, яка потім записується в транзакцію Taproot. По суті, дерево Merkle в даних транзакції діє як схема NAND, де кожна «гілка» містить одне з двох можливих значень: 1 або 0. Розрахунок у ланцюжку виконується біт за бітом, при цьому вихід однієї «гілки» стає вхід для наступного. Між сторонами розумного контракту відбуваються постійні обміни транзакціями для перевірки вартості. Якщо верифікаційна версія розрахунку виявляється неправильною, верифікатор отримує свої активи, заблоковані в транзакції Taproot.

Малюнок 17. Схематичне зображення NAND.
Джерело: «Велика справа з BitVM: довільні обчислення тепер можливі на біткойнах без форку» від журналу Bitcoin

Створення NAND за допомогою Taproot і Merkle Tree

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

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

Проблеми з двостороннім розумним контрактом

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

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

Для детального глибокого занурення не соромтеся прочитати BitVM Whitepaper - https://bitvm.org/bitvm.pdf 

Висновок

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

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

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

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

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

Останнє оновлення RGB, версія 0.10, позиціонує його як помітного суперника в еволюції технологій блокчейн, особливо проти таких нових протоколів, як Taproot Assets і BitVM. На відміну від Taproot Assets, яка зосереджена на використанні моделі UTXO Taproot для випуску токенів у мережі біткойн, RGB вирізняється розширеними функціями конфіденційності та позаланцюжною обробкою даних, пропонуючи окремий підхід до функцій смарт-контрактів і керування токенами.

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

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

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

Посилання на терміни: 

1. Turing Complete: На практиці система може виконати будь-яку обчислювальну задачу з достатнім часом і пам'яттю. Більшість сучасних мов програмування є повними за Тьюрингом, що означає їхню теоретичну здатність вирішувати будь-які обчислювальні проблеми.
   
2. Схема: Схема контракту служить фактичним кодом для смарт-контракту, який може використовуватися емітентами як «шаблон контракту» без необхідності кодування або перевірки спеціального коду, наданого із зовнішніх джерел. Схема RGB — це не сценарій, а структура даних.
   
3. Контракти дискретного журналу (DLC) у контексті державних каналів — це спеціалізовані смарт-контракти, які використовуються переважно в мережі Bitcoin. Вони дозволяють конфіденційно та ефективно виконувати складні фінансові угоди на основі зовнішніх подій, наприклад цін на активи. DLC працюють поза ланцюгом, зберігаючи конфіденційність деталей контракту та особи учасників. Вони використовують зовнішні джерела даних, або оракули, для вирішення контракту. Інтегровані з державними каналами DLC підвищують масштабованість, дозволяючи здійснювати численні транзакції без перевантаження блокчейну, що робить їх ідеальними для приватних ефективних фінансових транзакцій, які залежать від реальних результатів.
   
4. буря – надійне зберігання на основі умовного депонування з використанням zk-proofs. Storm поєднує надійне зберігання на основі умовного депонування з доказами нульового знання, щоб полегшити безпечні та приватні транзакції. У цій системі дані або активи зберігаються на умовному депонуванні та звільняються лише за виконання певних умов, забезпечуючи надійне середовище, де не потрібен центральний орган. Інтеграція zk-proofs дозволяє перевірити ці транзакції, зберігаючи при цьому максимальну конфіденційність, оскільки вони дозволяють перевіряти дані без розкриття будь-яких основних деталей.
   
5. Прометей – безнадійні розподілені обчислення на основі арбітражу. Prometheus представляє підхід до децентралізованих обчислень, поєднуючи механізми арбітражу для вирішення спорів, бездовірну взаємодію для безпечних і децентралізованих операцій і ефективність каналів стану для керування обчисленнями поза мережею.
   
6. A Комп'ютер зі зменшеними інструкціями це тип архітектури мікропроцесора, який використовує невеликий, високооптимізований набір інструкцій, а не вузькоспеціалізований набір інструкцій, який зазвичай зустрічається в інших архітектурах.