RGB усиливает масштабируемость и возможности конфиденциальности Bitcoin и Lightning Network

TL, д-р

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

Краткое описание

RGB — это протокол, предназначенный для выпуска токенов в сети Биткойн с повышенной конфиденциальностью и совместимостью с сетью Lightning. Он основан на концепции «цветных монет», подобных тем, которые используются в протоколе OmniLayer, где метаданные в транзакциях Биткойн указывают на передачу токена. Например, транзакции USDT в OmniLayer функционируют как транзакции биткойнов, дополненные дополнительными данными, подробно описывающими движение токенов USDT. Однако эти методы сталкиваются с ограничениями, такими как ограничения размера данных в выходных данных OP_RETURN, интенсивное сканирование блокчейна и ограничение конфиденциальности, обусловленное видимостью внутри цепочки.

RGB решает эти проблемы, перемещая большинство процессов проверки из блокчейна Биткойн. Он принимает проверку на стороне клиента и использует одноразовые печати для соединения токенов с UTXO Биткойна, сохраняя при этом конфиденциальность пользователя.

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

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

Введение и видение

Один лайнер: Подтверждаемое клиентом состояние и система смарт-контрактов, работающая на уровне 2/3 в сети Биткойн и Lightning Network.

Подробнее:

RGB — это масштабируемая и конфиденциальная система смарт-контрактов для Bitcoin и Lightning Network. Смарт-контракты RGB работают с проверка на стороне клиента парадигма, жилье все данные смарт-контракта снаружи Биткойн-транзакции, то есть состояние биткойн-блокчейна или канала Lightning. Это позволяет системе работать поверх сети Lightning без каких-либо изменений в протоколах LN, а также создает основу для высокого уровня масштабируемости и конфиденциальности протоколов.

Смарт-контракты воплощают принципы частной и взаимной собственности, абстракции и разделения ответственности. Они представляют собой «пост-блокчейн», полную по Тьюрингу форму распределенных вычислений, не требующих доверия, которые не требуют введения токенов.

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

Хотя контракты RGB функционируют независимо, они могут взаимодействовать через протокол Bifrost в сети Lightning. Это позволяет осуществлять скоординированные изменения между несколькими сторонами. Например, это позволяет DEX работать через сеть Lightning.

Технологии и Архитектура

Общий обзор работы RGB и одноразовых пломб

Рисунок 1. Общий обзор работы RGB.
Источник: Github Ассоциации LNP/BP.

В качестве механизма безопасности RGB использует одноразовые пломбы defiиспользуется через биткойн-UTXO, которые предоставляют возможность любой стороне, имеющей историю состояния смарт-контракта, проверить его уникальность. По сути, RGB использует биткойн-скрипт для своей модели безопасности и defiРЭШ собственность и права доступа.

Рисунок 2. Принцип работы RGB высокого уровня.
Источник: «Стимул массового внедрения криптовалют: как протокол RGB освещает будущее биткойнов», автор Waterdrip Capital.

Каждый смарт-контракт RGB defiсозданный состояние генезиса, созданный эмитент смарт-контракта (или, проще говоря, эмитент) и ориентированный ациклический граф (DAG) переходы между состояниями сохраняются как данные, проверенные клиентом.

Рисунок 3. Сделки, закрытые печатью и свидетелем.
Источник: Github Ассоциации LNP/BP.

Мы можем резюмировать это следующим образом: каждая транзакция имеет UTXO, и владение этим UTXO дает владельцу право владеть состоянием. Право собственности определяет, кто может изменять состояние блокчейна и «тратить» UTXO. Лицо, владеющее государством, называется партией. владеющее государством.

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

Этот процесс означает закрытие печати при переходе состояний, а пара, содержащая транзакцию расходов и соответствующие данные дополнительной транзакции о переходе состояний, называется Свидетель (изображено на изображении выше).

Право собственности и доступ: основные свойства

Рисунок 4. Право собственности и доступ.
Источник: Github Ассоциации LNP/BP.

Государственная собственность и валидация — это разные понятия. Правила проверки определяют, как может измениться состояние, но не определяют, кто может осуществить это изменение. 

С другой стороны, право собственности контролируется сценарием Биткойн на уровне блокчейна Биткойн, что не является полным по Тьюрингу. Напротив, правила проверки регулируются схемой RGB, использующей сценарий Simplicity/Contractum, т. е. являющуюся полной по Тьюрингу. 

RGB-схема

В смарт-контрактах RGB каждому контракту присваивается уникальное состояние с помощью одноразовых пломб. Эти печати, как и государственные, имеют особые правила и проверки, установленные создателем контракта вначале. Эта настройка регулируется «схемой», функционирующей как набор правил для проверки данных контракта на стороне клиента. Схема может включать сложные сценарии, являющиеся неотъемлемой частью логики контракта.

Рисунок 5. Схема RGB.
Источник: Github Ассоциации LNP/BP.

Принципы проверки и проектирования на стороне клиента

Рисунок 6. Проверка RGB на стороне клиента.
Источник: Github Ассоциации LNP/BP.

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

Подход RGB и подход Pure Blockchain/L1

Подход, основанный на чистом блокчейне/L1, неверен, утверждает команда RGB.

Рисунок 7. Комментарии RGB по подходу Blockchain/L1.
Источник: Github Ассоциации LNP/BP.

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

• Большинство блокчейн-платформ, включая Ethereum, используют смарт-контракты, написанные в императивном стиле. В этом подходе контракт функционирует как программа, которая явно направляет пошаговое выполнение задач, напоминая точный и подробный рецепт.
• Эти императивные программы часто весьма ограничительны и ограничены возможностями базовой платформы блокчейна. Хотя их иногда называют полными по Тьюрингу, они имеют существенные ограничения.

Декларативная природа смарт-контрактов RGB:

• RGB, с другой стороны, не использует императивное программирование. Вместо этого он использует специальную форму функционального программирования, в которой смарт-контракты defiнед декларативно.
• В декларативном программировании вместо подробного описания того, как что-то сделать, вы описываете, каким должен быть результат. Это похоже на описание того, как должна выглядеть еда, а не на предоставление пошаговых инструкций по приготовлению.
• «Схема» в RGB является декларативной. defiсоздание смарт-контракта. В нем указываются правила и условия контракта, но не точная последовательность действий для их достижения.

Смена парадигмы в программировании:

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

Простота

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

Признавая отсутствие надежного графика реализации Simplicity, мы начали рассмотрение альтернатив (WASM, EVM (в шутку), IELE и т. д.). В конце концов, стало очевидно, что разработка собственной виртуальной машины для RGB была единственным жизнеспособным вариантом, заменив первоначальную зависимость от Simplicity.

Поэтому мы решили создать АлуВМ – чисто функциональная, высокопортативная виртуальная машина на базе Rust для смарт-контрактов с проверкой на стороне клиента (RGB), Lightning Network, детерминированных распределенных и периферийных вычислений.

Призма

PRISM означает вычисления с «частично реплицируемыми бесконечными автоматами».

RGB-технология defines устанавливает правила развития смарт-контрактов на базовом уровне, называемом схемой, но не ограничивает все будущие действия контракта одним всеобъемлющим алгоритмом. Вместо этого каждый узел в сети выполняет отдельные операции, и как состояние контракта, так и сам контракт остаются действительными до тех пор, пока эти операции соответствуют правилам Схемы. 

Более того, этот подход не ограничивает историческую эволюцию контракта заранее определенным алгоритмом. Таким образом, контракт может демонстрировать различное поведение, если каждое изменение соответствует определенным правилам проверки. Этот метод фокусируется на локальных правилах, а не на глобальном алгоритме.

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

Ниже вы можете увидеть общее представление о различиях между каналами состояния и проверкой на стороне клиента: 

Рисунок 8. Разделение распределенных систем.
Источник: Github Ассоциации LNP/BP.

Более конкретные различия заключаются в следующем: 

Рисунок 9. Сравнение каналов состояний и проверки на стороне клиента.
Источник: Github Ассоциации LNP/BP.

АлуВМ

АлуВМ – (алгоритмически-логический блок VM) – чисто функциональная RISC-виртуальная машина, предназначенная для детерминированных портативных вычислительных задач.

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

Ключевые характеристики: Исключительность, переносимость, песочница, безопасность, расширяемость.

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

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

AluVM в основном предназначен для использования в распределенных системах, где согласованность и надежность на разных платформах важнее скорости обработки. Основные области применения AluVM с правильными расширениями ISA включают технологию блокчейна, вычисления, критически важные для достижения консенсуса в сетях, периферийные вычисления, многосторонние вычисления (которые охватывают детерминированное машинное обучение), проверку на стороне клиента, ограниченные вычисления в Интернете2 и генетические алгоритмы. Эти приложения выигрывают от способности AluVM работать стабильно и безопасно в различных средах.

Рисунок 10. Сравнение AluVM.
Источник: Github Ассоциации LNP/BP.

Контрактум

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

Рисунок 11. Сравнение Contractum, Simplicity и других языков.
Источник: Contractum.org

Contractum — это язык программирования, используемый для создания контрактов RGB. Контракты, заключенные с Contractum, проверяются с использованием метода, называемого проверкой на стороне клиента. Этот подход не добавляет никаких данных в блокчейн Биткойна, что можно сравнить с формой технологии шардинга, дополнительно улучшенной за счет использования доказательств с нулевым разглашением. 

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

Рисунок 12. Особенности контрактума.
Источник: Contractum.org

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

Рисунок 13. Технологии, используемые смарт-контрактами RGB.
Источник: Contractum.org

Последние обновления в новой версии RGB v0.10

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

Глобальное состояние в RGB-контрактах

Функция глобального состояния — это важнейшее нововведение в 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, позволяя ему беспрепятственно работать в широком спектре веб-приложений и расширений.

Дескрипторы Taproot и пользовательское происхождение

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 простыми словами.
Источник: Github Ассоциации LNP/BP.

стержневой корень

Taproot Assets, ранее известный как Taro, представляет собой протокол, предназначенный для запуска токенов в сети Биткойн. Этот протокол использует модель UTXO Taproot вместе с соответствующими решениями, такими как Tapscript и Taptweak. Эти инструменты используются для хранения информации о предложении и балансе актива в данных транзакций Биткойн.

Рисунок 15. Схема хранения информации о токенах Taproot Assets.
Источник: «Taproot Assets: выпуск активов на биткойнах» от напряжения.

Taproot Assets использует метод, аналогичный концепции Ordinals, в котором токены BRC-20 хранят информацию о поставках в метаданных нумерованных сатоши. И наоборот, Taproot Assets встраивает эту информацию в выходные данные Taproot транзакции Биткойн, используя так называемое «разреженное дерево Меркла». По сути, Taproot Assets включает в транзакцию Биткойн дерево Меркла, которое служит доказательством баланса конкретного пользователя и общего количества токенов. Это дерево, в свою очередь, отражает данные из «Вселенной» — репозитория, который хранит полную историю активов и управляется эмитентом токена.

Рисунок 16. Дерево цифровых состояний.
Источник: «Taproot Assets: выпуск активов на биткойнах» от напряжения.

Цифровое дерево штата. Архитектура Taproot Assets предлагает два варианта доказательства баланса: данные вне цепочки из Вселенной или разреженное дерево Меркла, встроенное в UTXO.

Оперативный механизм

1. Создатель токена выполняет транзакцию P2TR (Pay to Taproot) с использованием протокола Taproot Assets. 
2. Информация об активе в виде дерева Меркла хранится в UTXO этой транзакции (по сути, в генезис-блоке). 
3. Чтобы передать токен, владелец ключа Taproot изменяет информацию о балансе в дереве Меркла, гарантируя, что общее количество активов останется постоянным. 
4. Такие модификации вводятся посредством новой транзакции Taproot. Однако для каждой передачи токена отдельная транзакция в цепочке не требуется. Подобно накопительным пакетам или сети Lightning, протокол позволяет владельцу обрабатывать «пакет» переводов, впоследствии публикуя обновленное состояние балансов.

Преимущества активов Taproot

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

БитВМ

BitVM — это передовой проект, направленный на превращение Биткойна в полностью децентрализованную вычислительную платформу. В официальном документе BitVM, представленном 9 октября 2023 года, представлена ​​технология, которая в настоящее время находится на этапе тестирования и требует дальнейшего развития для полной реализации своего потенциала.

Основная функциональность и концепция BitVM

По своей сути BitVM использует концепцию оптимистических накопительных пакетов для вывода вычислений для смарт-контрактов из сети с последующей проверкой в ​​цепочке на основе «доказательств мошенничества». Теоретически, как только информация смарт-контракта записывается в транзакции Taproot (в виде двоичного кода), обмен данными и вычисления должны происходить непосредственно между сторонами. Этот подход предназначен для уменьшения перегрузки блокчейна. Однако если проверяющая сторона (доказывающая сторона, то есть владелец контракта) передает ошибочные данные, проверяющая сторона может инициировать проверку в цепочке. Этот процесс составляет основу концепции защиты от мошенничества.

Обработка ончейн-верификации в вычислительно ограниченной сети

Проблема возникает в том, как провести проверку работы в сети, которая по своей сути не поддерживает такие вычисления. Чтобы решить эту проблему, BitVM использует дерево Меркла для создания логической схемы вентиля NAND, которая затем записывается в транзакции Taproot. По сути, дерево Меркла в данных транзакции действует как схема NAND, где каждая «ветвь» несет одно из двух возможных значений: 1 или 0. Вычисления в цепочке выполняются постепенно, при этом выходные данные одной «ветви» становятся вход для следующего. Между сторонами смарт-контракта происходит постоянный обмен транзакциями для проверки стоимости. Если версия расчета проверяющего оказывается неверной, проверяющий получает свои активы, заблокированные в транзакции Taproot.

Рисунок 17. Схематическое изображение NAND.
Источник: «Большая сделка с BitVM: произвольные вычисления теперь возможны в Биткойне без форка», журнал Bitcoin Magazine.

Создание NAND с использованием Taproot и дерева Меркла

Подробную информацию о том, как BitVM облегчает построение NAND с использованием деревьев Taproot и Меркла, а также о ее влиянии на вычисления, можно найти в технической документации.

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

Проблемы с двусторонним подходом к смарт-контрактам

В BitVM сохраняется серьезная проблема из-за двусторонней структуры смарт-контрактов, обеспечивающей прямой обмен данными исключительно между проверяющим и проверяющим, исключая участие третьих сторон. Это ограничение препятствует развитию децентрализованных приложений и требует дополнительных решений для построения многосторонних контрактов. 

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

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

Заключение

Протокол RGB — это техническая разработка в экосистеме Биткойн, предоставляющая функциональные возможности для реализации смарт-контрактов и выпуска токенов, напрямую связанных с сетью Биткойн. Это достигается за счет сочетания проверки на стороне клиента и использования одноразовых печатей, которые связывают токены с UTXO Биткойна, сохраняя при этом конфиденциальность транзакций.

Одним из основных технических преимуществ RGB является подход к масштабируемости и конфиденциальности. Смещая основную часть работы по проверке с блокчейна Биткойн и используя криптографические методы для проверки транзакций, RGB эффективно снижает нагрузку на данные в блокчейне. Такой подход способствует поддержанию эффективности сети, особенно при увеличении объемов транзакций.

Совместимость RGB с сетью Lightning — еще один важный аспект, обеспечивающий более масштабируемую и эффективную обработку транзакций. Эта функция особенно актуальна, учитывая растущий спрос на более быстрые и экономичные методы транзакций в криптовалютном пространстве.

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

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

Последнее обновление RGB, версия 0.10, позиционирует его как заметного соперника в развивающемся мире технологий блокчейна, особенно в сравнении с новыми протоколами, такими как Taproot Assets и BitVM. В отличие от Taproot Assets, которая фокусируется на использовании UTXO-модели Taproot для выпуска токенов в сети Биткойн, RGB отличается расширенными функциями конфиденциальности и автономной обработкой данных, предлагая особый подход к функциональности смарт-контрактов и управлению токенами.

Аналогичным образом, в то время как BitVM представляет новую концепцию децентрализованных вычислений в Биткойне, достижения RGB версии 0.10 в области проверки на стороне клиента, интерфейсов контрактов и системы строгого типа демонстрируют ее уникальный подход к повышению масштабируемости и взаимодействия с пользователем в экосистеме Биткойн. Эти улучшения подчеркивают способность RGB решать проблемы масштабируемости и эффективности — области, в которых традиционные и новые протоколы часто сталкиваются с ограничениями.

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

В заключение отметим, что протокол RGB является значительным технологическим достижением в сети Биткойн, предлагая расширенные возможности для смарт-контрактов и выпуска токенов. Он решает ключевые проблемы масштабируемости и конфиденциальности, но сталкивается с проблемами с точки зрения сложности и потенциальной возможности аудита. Текущая разработка и будущие версии протокола, скорее всего, будут сосредоточены на балансировании этих расширенных возможностей с доступностью для пользователей и нормативными требованиями.

Ссылки на термины: 

1. Тьюринг завершен: С практической точки зрения система может выполнить любую вычислительную задачу, имея достаточно времени и памяти. Большинство современных языков программирования являются полными по Тьюрингу, что означает их теоретическую способность решать любую вычислительную задачу.
   
2. Схема: Схема контракта служит фактическим кодом смарт-контракта, который эмитенты могут использовать в качестве «шаблона контракта» без необходимости кодирования или аудита специального кода, предоставленного внешними источниками. Схема RGB — это не сценарий, а структура данных.
   
3. Дискретные контракты на бревна (DLC) в контексте государственных каналов — это специализированные смарт-контракты, используемые в основном в сети Биткойн. Они позволяют конфиденциально и эффективно заключать сложные финансовые соглашения на основе внешних событий, таких как цены на активы. DLC работают вне сети, сохраняя конфиденциальность деталей контракта и личности участников. Они используют внешние источники данных или оракулы для разрешения контрактов. При интеграции с каналами состояния DLC повышают масштабируемость, позволяя проводить несколько транзакций без перегрузки блокчейна, что делает их идеальными для частных, эффективных финансовых транзакций, которые зависят от реальных результатов.
   
4. буря – безопасное хранение на основе условного депонирования с использованием zk-proofs. Storm сочетает в себе безопасное хранилище на основе условного депонирования и доказательство с нулевым разглашением для облегчения безопасных и конфиденциальных транзакций. В этой системе данные или активы хранятся на условном депонировании и разблокируются только при выполнении определенных условий, обеспечивая надежную среду, в которой не требуется никакой центральный орган власти. Интеграция zk-proofs позволяет проверять эти транзакции, сохраняя при этом максимальную конфиденциальность, поскольку они позволяют проверять данные без раскрытия каких-либо основных деталей.
   
5. Прометей – распределенные вычисления без доверия на основе арбитража. Prometheus представляет собой подход к децентрализованным вычислениям, сочетающий в себе арбитражные механизмы для разрешения споров, доверительное взаимодействие для безопасных и децентрализованных операций, а также эффективность государственных каналов для управления вычислениями вне сети.
   
6. A Сокращенный набор команд компьютера — это тип архитектуры микропроцессора, в котором используется небольшой высокооптимизированный набор инструкций, а не узкоспециализированный набор инструкций, обычно встречающийся в других архитектурах.