Протокол RGB++ и будущее Биткойна: выводы Cipher из Bitcoin, Сингапур, 2024 г.

9 марта во время конференции Bitcoin Singapore 2024, организованной совместно Nervos Foundation и ABCDE, Cipher, основатель CELL Studio и автор протокола RGB++, выступил с программной речью под названием «Обзор и перспективы протокола RGB++».

Вот краткое изложение основных моментов презентации Cipher:

Проблемы, с которыми сталкивается протокол RGB

Протокол RGB существует уже много лет, но не получил широкого распространения из-за нескольких факторов:

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

В транзакциях с участием BTC , ETH и т. д. получателю необходимо указать только адрес, а отправитель может перевести средства либо сегодня, либо завтра, что очень удобно. Напротив, каждая транзакция RGB требует, чтобы получатель сначала выставил счет. Затем отправитель должен создать транзакцию RGB и сгенерировать подтверждение истории активов для отправки получателю. Получив это подтверждение, получатель должен выполнить проверку на стороне клиента (CSV). После успешной проверки они должны сохранить это доказательство для будущих транзакций.

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

Проблемы с доступностью данных (DA)

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

Даже при правильном хранении данных рассмотрим сценарий, в котором Алиса хочет передать ресурсы RGB Бобу. Как она отправит ему исторические доказательства наличия этих активов? Используя электронную почту или WhatsApp? Очевидно, что передача через какой-либо централизованный канал нецелесообразна и требует использования специализированного P2P-канала. Однако каналы P2P поднимают вопросы конфиденциальности: зачем кому-то помогать в передаче этих конфиденциальных данных? Это приводит к ряду сложных проблем.

Проблемы совместимости

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

Проблемы со средой выполнения смарт-контрактов/скриптов

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

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

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

Транзакции RGB неразрывно связаны с транзакциями Биткойн посредством процесса сопоставления. Кроме того, транзакции RGB требуют автономной инфраструктуры, включающей доступность данных (DA), проверку на стороне клиента, P2P-сети, виртуальные машины, общие состояния и децентрализованные контракты. При рассмотрении такой инфраструктуры естественно приходит на ум блокчейн, учитывая его возможности в области управления данными, проверки, интеграции виртуальных машин, P2P-сетей, стимулирования и смарт-контрактов. Концепция протокола RGB++ основана на этой фундаментальной интуиции, предлагая использовать основанный на модели UTXO и полный по Тьюрингу блокчейн CKB в качестве замены автономной инфраструктуры, необходимой RGB.

RGB++ представляет концепцию, называемую технологией изоморфного связывания . Каждая биткойн-транзакция включает в себя выход. В случае транзакции RGB необходимо включить сегмент OP_RETURN в выходные данные Биткойна. Этот сегмент содержит определенные хэш-данные, называемые обязательством. Если это обязательство совпадает с хэшем транзакции в другом общедоступном блокчейне, и если входы и выходы обеих транзакций изоморфны — то есть они соответствуют по структуре — и если предположить, что UTXO (неизрасходованный вывод транзакции) этого альтернативного блокчейна обладает Тьюринг-полными вычислительными и возможности хранения состояния, то транзакция в блокчейне Биткойна становится полностью интегрированной или связанной с транзакцией в другом блокчейне. Блокчейн CKB (Common Knowledge Base) удовлетворяет этим предварительным требованиям. Следовательно, проведение транзакции в Биткойне фактически приравнивается к выполнению соответствующей транзакции в цепочке CKB. Любое изменение состояния транзакции Биткойн отражает изменение состояния транзакции в цепочке CKB, придерживаясь ограничений контракта, присутствующих в CKB. В этом заключена суть технологии изоморфного связывания. Однако эта концепция включает в себя множество сложных технических аспектов, включая поддержание согласованности транзакций и предотвращение двойных расходов, которые на данный момент подробно не рассматриваются.

Технология изоморфной привязки позволяет расширить возможности состояния Биткойна. Например, давайте рассмотрим btc_utxo#1, показанный на следующей диаграмме. Этот биткойн-UTXO (выход неизрасходованной транзакции) обычно имеет только два состояния: сценарий блокировки и сумму, последняя представляет собой баланс. Однако в соответствующей синей ячейке блокчейна CKB (Common Knowledge Base), как показано на схеме, возможности шире. В отличие от ограниченной функциональности Bitcoin UTXO, состоящей только в показе баланса, эта изоморфная ячейка в цепочке CKB может хранить не только данные баланса, но и различные другие типы данных.

Помимо компонента данных, Cell имеет скрипт типа. Этот скрипт служит определенной цели: он определяет условия получения активов и накладывает ограничения на типы активов.

Кроме того, ячейка содержит сценарий блокировки, который в данном случае явно связан с btc_utxo#1. Эта связь подразумевает, что ячейка в блокчейне CKB может быть потрачена только в том случае, если и когда израсходован btc_utxo#1.

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

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

Преимущество этого подхода заключается в том, что мы успешно внедрили сценарии Тьюринга в сферу Биткойн, сохраняя при этом статус безопасности, почти идентичный статусу Биткойна уровня 1 (L1). Это связано с тем, что все исторические записи, транзакции и обязательства связаны через цепочку UTXO в Биткойне L1.

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

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

Таким образом, мы реализовали концепцию RGB более простым способом и еще больше расширили ее возможности.

Раскрытие потенциала биткойн-активов L1

Вот упрощенное введение в концепцию прыжка.

Технология гомоморфной привязки , которую можно применить к Биткойну , в равной степени применима к Litecoin, Liquid и другим цепочкам на основе UTXO. Как упоминалось ранее, как в системах RGB, так и в RGB++ получателем платежа является биткойн-UTXO, наделенный исключительным правом тратить деньги. Когда я создаю транзакцию RGB++ в Биткойне, у меня есть возможность обозначить получателя платежа не как биткойн-UTXO, а как Litecoin UTXO. Следовательно, этот актив «перескакивает» в Litecoin, поскольку его последующее расходование требует разблокировки Litecoin UTXO. Точно так же этот актив может перейти в Liquid или даже вернуться в Bitcoin.

Конечно, следует рассмотреть особый случай. Когда актив попадает в блокчейн CKB, его уровень интерпретации данных, уровень контракта и право собственности находятся в CKB. Это означает, что он больше не зависит от какой-либо другой цепочки и может напрямую участвовать в транзакциях и взаимодействовать со смарт-контрактами на CKB. Это можно описать как переход к L2. На L2 пользователи могут проводить тысячи или даже десятки тысяч транзакций, пока кто-то не решит перевести актив обратно в Биткойн. Это то, что мы называем свертыванием транзакций. Будь то RGB или RGB++, транзакции происходят в блокчейне Биткойна, где плата за майнинг высока. Однако как только актив переходит в CKB и подвергается свертыванию транзакции, комиссии становятся значительно ниже, и он может легко вернуться в блокчейн Биткойна в любое время. Весь этот процесс не опирается на какие-либо мосты с несколькими подписями или доверие к каким-либо лицам; единственное требование — дождаться еще нескольких подтверждений блокировки. Для перехода от блокчейна Биткойн к блокчейну CKB необходимо дождаться 6 подтверждений блока Биткойн. Чтобы перейти от блокчейна CKB к Биткойну, необходимо 24 подтверждения блока CKB, чтобы предотвратить возврат блоков/r.

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

Будущие перспективы

Далее давайте обсудим масштабируемость. Скорость транзакций Биткойна составляет примерно 7 транзакций в секунду (TPS), тогда как пиковая скорость CKB составляет около 200 TPS. Если вы учтете затраты на выполнение контракта и проверку скриптов, TPS может сократиться примерно до 50, что менее чем в десять раз больше, чем у Биткойна. Этого недостаточно, так каковы варианты расширения? Мы видим два основных направления:

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

  
  

• Стек AppChain : создав решение уровня 2 (L2) на основе модели UTXO, L2 AppChain обеспечит свою привязку к CKB, изоморфно выравниваясь с ним. Такой подход позволяет нам разрабатывать инновационные стратегии масштабирования в рамках новой парадигмы. Это также является ключевым направлением деятельности CELL Studio в наступающем году.

  
  

Наконец, я хотел бы обрисовать миссию и план развития RGB++. Целью RGB++ является разработка базовых модулей протоколов для облегчения использования и интеграции сторонними разработчиками и пользователями. Дорожная карта протокола RGB++ выглядит следующим образом: протокол уже доступен в основной сети Bitoin, а 3 апреля был выпущен RGB++ SDK .

Шифр, основатель CELL Studio и автор протокола RGB++.