Протокол RGB: пользователи должны сами выполнять проверку данных

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

Почему так должно быть? Причина в том, что для обеспечения конфиденциальности протокол RGB не принимает «протокол консенсуса» в традиционных блокчейнах, таких как Bitcoin и Ethereum. (После того, как данные пройдут через протокол консенсуса, они будут наблюдаться почти всеми узлами в сети, и конфиденциальность не гарантируется). Как гарантировать, что изменения активов безопасны без процесса консенсуса, включающего большое количество узлов? Здесь используется идея под названием «Проверка клиента» (Verify by yourself). Вам необходимо самостоятельно запустить клиент и лично проверить связанные с вами изменения активов. Предположим, что есть пользователь RGB по имени Боб, который знает Алису, и Алиса хочет передать Бобу 100 токенов TEST. После того, как Алиса сгенерирует информацию о передаче «Алисы Бобу», она должна сначала отправить информацию о передаче и соответствующие данные об активах Бобу, а затем позволить ему лично проверить их, чтобы убедиться в их правильности, прежде чем переходить к следующему процессу, и, наконец, они становятся действительными передачами RGB. Таким образом, протокол RGB позволяет пользователям лично проверять достоверность данных, заменяя традиционный алгоритм консенсуса. Но без консенсуса данные, получаемые и хранимые разными клиентами RGB, несогласованы. Каждый хранит только свои собственные данные об активах локально и не знает о состоянии активов других. Защищая конфиденциальность, он также представляет собой «остров данных». Если кто-то утверждает, что у него есть 1 миллион токенов TEST и хочет перевести вам 100 000, как вы можете в это поверить? В сети RGB, если кто-то хочет перевести вам деньги, он должен сначала предъявить доказательство активов, проследить историю происхождения активов от первоначальной эмиссии до нескольких смен рук и убедиться, что токен, который будет передан вам, чист. Это похоже на то, как если бы вы получили банкноты неизвестного происхождения и попросили другую сторону объяснить историческое происхождение этих банкнот и были ли они изготовлены назначенным эмитентом, чтобы избежать фальшивой валюты.

(Источник изображения: Coinex)

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

Вот краткое изложение рабочего процесса протокола RGB:

1. Активы RGB привязаны к Bitcoin UTXO, и у Боба есть определенные Bitcoin UTXO. Алиса хочет передать 100 токенов Бобу. Прежде чем получить активы, Боб заранее сообщает Алисе, какой Bitcoin UTXO Боба следует использовать для привязки этих активов RGB.

(Image source: Geekweb3/GeekWeb3)

1. Алиса конструирует «Алиса к Бобу» данные о передаче RGB-активов, вместе с историческими источниками этих активов, и передает их Бобу для верификации.
2. После того как Боб локально подтвердит, что данные в порядке, он отправляет квитанцию Алисе, сообщая ей, что транзакция может быть выполнена.
3. Алиса строит RGB передачу данных "Алиса к Бобу" в дереве Меркля и публикует корень Меркля в цепи Биткоина как Обязательство. Мы можем просто понимать Обязательство как хэш передачи данных.
4. Если кто-то захочет подтвердить в будущем, что упомянутый выше перевод «От Алисы к Бобу» действительно произошел, ему нужно сделать две вещи: получить полную информацию о переводе «От Алисы к Бобу» на цепочке Биткоина, а затем проверить, есть ли соответствующая транзакция на цепочке Биткоина (хэш данных о передаче), вот и все.

Биткойн здесь выступает в качестве исторического журнала сети RGB, но в журнале записывается только хэш/Merkle root данных транзакций, а не сами данные транзакций. Благодаря клиентской проверке и одноразовому запечатыванию, протокол RGB обладает чрезвычайно высоким уровнем безопасности; поскольку сеть RGB состоит из динамичных пользовательских клиентов в форме P2P без консенсуса, вы можете в любое время изменить контрагента, не отправляя запросы на транзакции ограниченному числу узлов, поэтому сети RGB обладают чрезвычайной устойчивостью к цензуре, эта организационная форма устойчивее к цензуре, чем большие публичные цепочки, такие как Ethereum.

(Источник изображения: BTCEden.org)

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

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

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

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

RGB++: Проверка с клиентской стороны становится оптимистичным доверием

Протокол под названием RGB++ предлагает новую идею. Он объединяет протокол RGB с публичными цепочками, поддерживающими UTXO, такими как CKB, Cardano и Fuel. Последний служит слоем верификации и слоем хранения данных для активов RGB, преобразуя данные, изначально обрабатываемые пользователями, в верификационную работу и передавая их сторонним платформам/публичным цепочкам, таким как CKB. Это эквивалентно замене клиентской верификации на «платформу сторонней децентрализованной верификации», пока вы доверяете публичным цепочкам, таким как CKB, Cardano, Fuel и т. д. Даже если вы им не доверяете, вы также можете вернуться к традиционному режиму RGB.

RGB++ и оригинальный протокол RGB теоретически совместимы друг с другом.

Для достижения вышеупомянутых эффектов нам нужно использовать идею, называемую «изоморфным связыванием». У публичных цепей, таких как CKB и Cardano, есть свои расширенные UTXO, которые более программируемы, чем UTXO на цепи BTC. «Изоморфное связывание» заключается в использовании расширенных UTXO на цепях CKB, Cardano и Fuel в качестве «контейнеров» для данных RGB-активов, записи параметров RGB-активов в эти контейнеры и их непосредственного отображения на блокчейне. Всякий раз, когда происходит транзакция с RGB-активом, соответствующий контейнер активов также может показать сходные характеристики, как отношение между сущностями и тенями. В этом суть «изоморфного связывания».

(Источник изображения: RGB++ LightPaper)

Например, если у Алисы есть 100 токенов RGB и UTXO A на цепочке биткоина, а также есть UTXO на цепочке CKB, этот UTXO помечен как "Баланс токенов RGB: 100", а условия разблокировки связаны с UTXO A.

Если Алиса хочет отправить 30 токенов Бобу, она может сначала создать Обязательство. Соответствующее утверждение: передача 30 токенов RGB, связанных с UTXO A, Бобу, и передача 70 другим UTXO, которыми она управляет.

Позднее Алиса тратит UTXO A на цепочке Bitcoin, публикует вышеуказанное заявление, а затем инициирует транзакцию на цепочке CKB для потребления контейнера UTXO, несущего 100 токенов RGB, и создания двух новых контейнеров, один из которых содержит 30 токенов (для Боба), а другой - 70 токенов (контролируемый Алисой). В процессе выполнения этой задачи проверка действительности активов Алисы и правильности заявления о транзакции завершается сетевыми узлами, такими как CKB или Cardano, с помощью консенсуса, без вмешательства Боба. В это время CKB и Cardano служат в качестве уровня проверки и уровня DA под цепочкой Bitcoin.

(Источник изображения: RGB++ LightPaper)

Данные об активах RGB каждого хранятся в сети CKB или Cardano, которая имеет глобально проверяемые характеристики и способствует реализации Defi, таких как пулы ликвидности и протоколы залога активов. Конечно, вышеуказанный подход также жертвует конфиденциальностью. Суть заключается в поиске компромисса между конфиденциальностью и удобством использования продукта. Если вы стремитесь к абсолютной безопасности и конфиденциальности, вы можете вернуться к традиционному режиму RGB; если вам все равно, вы можете безопасно использовать режим RGB++, все зависит от ваших личных потребностей. (Фактически, благодаря мощной функциональной полноте публичных цепочек, таких как CKB и Cardano, ZK можно использовать для реализации частных транзакций)

Здесь следует подчеркнуть, что RGB++ вводит важное доверие: пользователи должны быть оптимистичны относительно того, что цепочка CKB/Cardano или сетевая платформа, состоящая из большого количества узлов, полагающихся на протоколы согласования, надёжна и безошибочна. Если вы не доверяете CKB, вы также можете следовать интерактивному процессу коммуникации и верификации в оригинальном протоколе RGB и запустить клиент самостоятельно.

По протоколу RGB++ пользователи могут напрямую использовать свои учетные записи Bitcoin для работы с контейнерами RGB на цепочках UTXO, таких как CKB/Cardano, без кросс-цепочности. Просто используйте характеристики UTXO в вышеупомянутой общедоступной цепочке и установите условие разблокировки контейнера Cell, связанное с определенным адресом Bitcoin/Bitcoin UTXO. Если обе стороны, участвующие в сделках с активами RGB, могут доверять безопасности CKB, им даже не понадобится часто выпускать Обязательства на цепочке Bitcoin. После множества сделок с активами RGB может быть отправлено Обязательство на цепочку Bitcoin. Это называется функцией «сворачивания транзакции», которая может снизить затраты на использование.

Но будьте осторожны, «контейнер», используемый в изоморфной привязке, требует публичной цепи, поддерживающей модель UTXO, или инфраструктуры с аналогичными характеристиками в хранилище состояний. Цепь EVM не подходит и столкнется с множеством подводных камней. (Эта тема может быть описана отдельно и включает в себя много контента. Заинтересованные читатели могут обратиться к предыдущим статьям Geek Web3.)«RGB++ и изоморфное связывание: как CKB, Cardano и Fuel усиливают экосистему биткойна»；

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

1. Используйте модель UTXO или аналогичную схему хранения состояния;
2. Имеет значительную программу UTXO, позволяющую разработчикам писать скрипты разблокировки;
3. Существует пространство состояний, связанное с UTXO, в котором можно хранить статус актива;
4. Есть мосты или легкие узлы, связанные с Bitcoin;

Отказ от ответственности:

1. Эта статья воспроизводится из [ Гик Веб3] , оригинальное название - «RGB и дизайн протокола RGB++ за несколько минут: простые инструкции», авторские права принадлежат оригинальному автору [Faust], если у вас есть возражения против перепечатки, пожалуйста, свяжитесь Команда Gate Learn, команда обработает это как можно скорее в соответствии с соответствующими процедурами.

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

3. Другие языковые версии статьи переводятся командой Gate Learn. Без ссылкиGate.io, копирование, распространение или плагиатирование переведенных статей запрещено.