С ростом популярности RGB++ и связанной с ним эмиссии активов дискуссии о принципах протоколов RGB и RGB++ постепенно становятся темой интереса для все большего количества людей. Тем не менее, понятно, что для того, чтобы понять RGB++, нужно сначала разобраться в протоколе RGB. Первоначальный протокол RGB имеет в некоторой степени техническую структуру, с разрозненными справочными материалами, и на сегодняшний день существует не так много систематизированных и легко понятных справочных материалов. Geek Web3 ранее опубликовал две систематические интерпретации RGB и RGB++ (доступны в истории нашего публичного аккаунта), но, согласно отзывам сообщества, эти статьи были длинными и слишком сложными. Для того, чтобы дать возможность большему количеству людей быстрее разобраться в протоколах RGB и RGB++, автор этой статьи спешно завершил краткую непрофессиональную интерпретацию RGB и RGB++ во время мероприятия в Гонконге. Его можно прочитать всего за несколько минут, чтобы помочь большему количеству энтузиастов сообщества лучше и интуитивнее понять RGB и RGB++.

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

Протокол RGB - это особый тип протокола активов P2P, работающий в рамках вычислительной системы цепочки Биткоина. В некотором смысле он похож на платежные каналы: пользователи должны лично запускать свой клиент и проверять действия по переводу, касающиеся себя ('Проверьте сами'). Даже если вы только получатель активов, вы должны сначала подтвердить, что заявление о переводе от отправителя верное, прежде чем перевод начнет действовать. Этот подход, известный как 'интерактивный перевод', существенно отличается от традиционных методов передачи и приема активов. Почему это необходимо? Причина в том, что протокол RGB, чтобы обеспечить конфиденциальность, не использует 'протокол консенсуса', обнаруженный в традиционных блокчейнах, таких как Биткоин и Эфириум (где данные, однажды в протоколе консенсуса, наблюдаются почти всеми узлами в сети, что делает защиту конфиденциальности сложной). Без процесса консенсуса, включающего большое количество узлов, как можно обеспечить безопасность изменения активов? Именно здесь возникает идея 'подтверждения клиентом' ('Проверьте сами'). Вам нужно запустить свой клиент и лично проверить изменения активов, касающиеся вас.

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

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

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

Давайте опишем рабочий процесс протокола RGB:

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

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

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

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

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

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

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

Кроме того, как мы упоминали ранее, сети 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 на цепочке биткойна. «Гомоморфное связывание» - это идея использования расширенных UTXO на цепочках, таких как CKB, Cardano и Fuel, в качестве «контейнеров» для данных RGB-активов. Параметры RGB-активов записываются в эти контейнеры и непосредственно отображаются на блокчейне. Каждый раз, когда происходит транзакция RGB-актива, соответствующий контейнер для актива также может обладать похожими характеристиками, аналогично отношению между сущностями и тенями. В этом суть «гомоморфного связывания».

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

Например, если у Элис есть 100 токенов RGB и UTXO (давайте назовем его UTXO A) на цепи Bitcoin, а также UTXO на цепи CKB, помеченный "Баланс токенов RGB: 100" и разблокированные условия, связанные с UTXO A:

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

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

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

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

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

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

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

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

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

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

1. Эта статья взята из [极客 Web3], Все авторские права принадлежат оригинальному автору[Фауст]. Если есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они решат это незамедлительно.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.