Изучаем решения для масштабирования биткоина: RGB

Catalonec_Ambassador · 16 April 2024 16:59

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

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

Эта статья также опубликована на Medium：

RGB

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

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

Быстрое исследование для RGB

В этом разделе мы сосредоточимся на главном и сведем технические подробности к минимуму, чтобы сделать работу протокола простой и понятной.

Основы

Неизрасходованные транзакционные средства (UTXO) являются основным понятием во вселенной Биткойна. Если вы впервые знакомы с этим термином, вы можете углубиться в него с помощью этой статьи в Вики. Пока же давайте остановимся на этом понятии.

Дизайн RGB как платформы для смарт-контрактов тесно связан с UTXO. Для иллюстрации представьте, что на платформе RGB выпускается 100 единиц какого-либо актива. Затем эти активы привязываются к определенному UTXO. Когда владелец UTXO тратит этот 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 должны быть защищены от двойных расходов; в противном случае активы 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 наблюдатели не могут определить конкретную операцию, связанную с обязательством в блокчейне, что сохраняет конфиденциальность. Этот аспект называется скрытием.

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

Подтверждение публикации

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

RGB решает эту проблему с помощью концепции, известной как “доказательство публикации”. Основная идея заключается в том, что проверка состояния в распределенных системах не требует глобального исполнения всеми участниками. Вместо этого соответствующие стороны проверяют конкретные переходы состояний. При таком подходе переходы состояний не транслируются глобально, а кодируются в краткое криптографическое обязательство после того, как вовлеченные стороны подтвердят изменения (например, с помощью подписей). Как показано на диаграмме ниже, в то время как общее состояние контракта G включает все красные и серые узлы (представляющие исторические транзакции), проверка состояния узла P требует изучения только соответствующих красных узлов.

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

Связанные ресурсы

RGB++

Обзор и перспективы

RGB++ - это расширение протокола RGB, представленное командой Cipher from Nervos CKB. Nervos CKB - это публичный блокчейн, использующий модель на основе UTXO, называемую в его рамках “ячейками”. Основываясь на протоколе RGB, RGB++ сопоставляет структуру RGB UTXO с Cells Nervos CKB, используя скриптовые ограничения в сетях CKB и Bitcoin для обеспечения точности вычислений состояния и законности передачи прав собственности. Цель RGB++ - решить технические проблемы, с которыми сталкивается оригинальный протокол RGB в реальных сценариях, разгрузив клиентскую часть работы на блокчейн CKB.

Обзор протокола

Чтобы сохранить доступность изложения, в этом разделе мы не будем углубляться в сложные технические аспекты протокола. Вместо этого мы объясним работу протокола в простой форме.

Как это работает

Являясь расширением RGB, рекомендуется ознакомиться с протоколом RGB, прежде чем приступать к работе. Суть RGB++ заключается в переходе от традиционного подхода к проверке на стороне клиента к модели, в которой все данные открыто публикуются на блокчейне Nervos CKB, а CKB выступает в качестве механизма реализации. Мы продолжим использовать пример из протокола 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++ для отправки в сеть CKB: CKB_TX. Эта транзакция включает в себя необходимые данные для изменения состояния RGB.
Боб вычисляет вне сети значение обязательства commitment(0x345AB…D7654).

Отправка транзакции BTC

Боб создает и отправляет транзакцию Bitcoin, которая тратит UTXO1, включая вышеупомянутое обязательство (0x345AB…D7654) через операцию OP_RETURN.

Отправка транзакции CKB

Боб отправляет CKB_TX в сеть CKB.
Последнее состояние пользователя сохраняется в CKB_TX.output.data.
Для последующего изменения состояния (Алисой) потребуется UTXO4 и выход CKB_TX.

Верификация сети

Биткойн UTXO1 используется только один раз.
Через узел Bitcoin Light Node компания CKB проверяет значение обязательства в сети Bitcoin и убеждается, что соответствующий UTXO был потрачен.
CKB подтверждает, что переход состояния контракта в его сети соответствует предопределенным правилам контракта.

Надежность и безопасность

Поскольку безопасность является фундаментальным аспектом каждого протокола блокчейна, мы проанализируем с точки зрения “доверия” компоненты протокола и приложения, в которых пользователи должны быть уверены, и представим анализ.
Если не указано иное, мы считаем классические криптографические алгоритмы, используемые в протоколе, заслуживающими доверия (без учета квантовых компьютеров).

Пользователи должны доверять сети Биткойн.

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

Пользователи должны доверять механизму выполнения транзакций в сети CKB по тем же причинам, что и в случае с RGB.
Пользователи должны доверять тому, что сеть CKB получит доступ к последним транзакциям Биткойна для проверки. В противном случае в блокчейн могут быть записаны незаконные состояния.
Пользователи должны верить, что сеть CKB не будет подвергать их транзакции цензуре. Если транзакция пользователя подвергается цензуре и не может быть записана в блокчейн, он не получит результатов выполнения транзакции. Однако в таких случаях протокол может вернуться от RGB++ обратно к RGB, вновь задействовав парадигму проверки на стороне клиента для вычисления результатов транзакций в автономном режиме.
Пользователи должны иметь определенный уровень доверия к согласованности сети CKB (под согласованностью можно понимать то, будут ли подтвержденные транзакции откатываться назад).

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

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

Краткое описание RGB++: преимущества и недостатки

RGB++ - это расширение RGB, давайте проанализируем сильные и слабые стороны RGB++ по сравнению с его предшественником.

Преимущества:

Пользователям больше не нужно самим хранить данные; CKB берет на себя заботу о размещении данных.
Большая часть обязанностей среды исполнения возложена на 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.
Транзакция CKB для A не была записана из-за какой-то проблемы, например атаки цензуры на сеть CKB.
Транзакция 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 - это специально реализованный контракт, который, как мы предполагаем, может (через небольшой узел) считывать подтвержденную информацию о биткойне. В то же время любой может вручную сделать значение обязательства транзакции публичным через функцию openCommitment в 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 Russia