В этой статье делается попытка дать краткое описание RGB, протокола выпуска активов в Биткойне (его также можно понимать как автономную систему смарт-контрактов), и указывает, что он сильно отличается от других проектов, целью которых является Для достижения таких же или похожих функциональных протоколов эти различия делают протокол RGB гораздо более масштабируемым, чем они, и оставляют более широкое пространство для программирования. Помимо представления готовых проектов RGB, мы также изучим возможности программирования.
Что такое протокол RGB?
Идея выпуска активов на биткойнах существует уже давно. Но протокол Биткойн имеет свои особенности: его состояние выражается только биткойн-UTXO («вывод неизрасходованных транзакций»); UTXO несет только две данные: свой собственный номинал (значение биткойна) и «открытый ключ сценария» (также известный как «скрипт блокировки»), используемый для программирования условий расходов этого фонда, например: предоставление подписи определенного открытого ключа; разрешение кода операции, используемого для программирования сценария блокировки, определяться правилами консенсуса Биткойна при условии, что они не могут использоваться для реализации произвольных правил безопасности. Следовательно, внутри UTXO невозможно создавать другие активы — скрипт Биткойн не может запрограммировать проверки безопасности для этих активов. Это означает, что все идеи по выпуску активов в Биткойне по сути представляют собой творческое использование пространства блоков Биткойна. Это означает, что нам необходимо разработать систему смарт-контрактов вне сети и потребовать выполнения шагов по изменению состояния контракта — например, контракт A меняет параметры, а B передает определенное количество определенного актива в C —— Информация загружается в блокчейн, поэтому путем сбора этой информации можно получить последний статус системы смарт-контрактов.
Грубая идея проекта состоит в том, чтобы загрузить информацию о шагах, которые меняют состояние контракта, в блокчейн Биткойна без изменений. Это, конечно, работает, но сталкивается с несколькими проблемами:
(1) Поскольку загружается полная информация, она может занимать больше места в блоке.Когда пользователям необходимо изменить статус контракта (например, передачу), им также придется платить больше комиссий за обработку внутри цепочки. В частности, когда мы надеемся, что такая внесетевая контрактная система имеет лучшую программируемость, чем Биткойн, увеличение программируемости может произойти за счет потребления большего количества блочного пространства;
(2) Практически любая информация в блоке может изменить смарт-контракт вне цепочки.Поэтому пользователи должны получить все данные блока Биткойн, чтобы получить последний статус системы контрактов вне цепочки, то есть проверка обходится дороже;
(3) В зависимости от конструкции системы смарт-контрактов вне сети вы можете получить только конфиденциальность, сравнимую с конфиденциальностью Биткойна, или даже хуже; и если вы можете обеспечить большую конфиденциальность, вам, возможно, придется занять больше места. блокировать пространство.
В прошлом широко используемый протокол под названием «Omni» не загружал полную информацию о транзакциях контракта вне сети, а только хеш-значение транзакции. Этот подход решает вышеуказанные проблемы и отделяет сложность транзакций контрактов вне цепочки от их экономических затрат; однако пользователям все равно необходимо получить полный объем данных блока Биткойн, чтобы получить последний статус протокола Omni; кроме того, он не предназначен специально для повышения конфиденциальности.
RGB использует новую парадигму под названием «одноразовые пломбы». Его использование очень просто: RGB требует, чтобы каждое состояние каждого контракта было привязано к определенному биткойн-UTXO; и как только вы захотите изменить это состояние, вы должны потратить этот UTXO и позволить транзакции, которая его тратит, получить подтверждение в блокчейне; кроме того, транзакция биткойнов, которая их тратит, также должна предоставить хэш содержимого перехода состояния, чтобы указать UTXO, прикрепленный к измененному состоянию.
Для разработчиков RGB дизайн похож на пронумерованную пластиковую пломбу: легко определить, была ли она удалена, и как только она будет удалена, ее нельзя будет использовать повторно. Однако другая точка зрения состоит в том, чтобы рассматривать одержимый UTXO как контейнер или керамическую копилку в этом состоянии: если вы хотите вынуть деньги из копилки, вы должны разбить копилку. в новую банку.
Этот дизайн резко контрастирует с предыдущими протоколами, которые рассматривали весь блок как большую доску для записи: использование UTXO в качестве контейнера означает, что транзакции, которые не тратят этот UTXO, не могут иметь никакого влияния на состояние контракта в контейнере. определенное состояние определенного контракта, нам не нужно получать данные всех блоков.Все, что нам нужно, это серия биткойн-транзакций, свидетельство того, что эти биткойн-транзакции существуют в определенном блоке, и эти биты.Преобразование состояния RGB, обещанное достаточно обмена валюты (пара один к одному с соответствующей транзакцией биткойнов). Эти данные, которые можно объединить в цепочку, должны позволить нам проследить исходное состояние этого контракта, что позволит нам выявить суть этого состояния.
Читателям, знакомым с системами смарт-контрактов внутри цепочки (такими как Ethereum), трудно понять одну вещь в этом процессе: если он не опирается на консенсус блокчейна (что означает, что начальное состояние контракт и каждое изменение состояния будет проверено каждым узлом), как гарантируется безопасность этой системы смарт-контрактов? Как гарантировать, что активы, которые вы получаете, являются именно теми, которые вы хотите, и как гарантировать, что активы не были выданы незаконно?
Ответ тоже очень простой, он называется «проверка на стороне клиента» — вы сами проверяете. В системе контрактов on-chain узлы проверяют каждую операцию перехода состояний в соответствии с общедоступными правилами перехода состояний, отклоняют недопустимые операции, а затем вычисляют последнее состояние на основе начального состояния. Однако, пока известны правила перехода состояний и исходное состояние, проверка посредством консенсуса в цепочке — не единственный способ.Пользователи могут проверить, следует ли каждый шаг перехода состояния первоначально определенному переходу состояния на основе информации, предоставленной правило плательщика. Таким образом, проверяющая сторона (предполагаемая получателем актива) также может обнаружить незаконные переходы состояний и отказаться их принимать.
Наконец, мы используем пример, чтобы продемонстрировать характеристики протокола RGB:
Теперь Алиса владеет UTXO A, который содержит X единиц актива Y, выпущенных по протоколу RGB. Она хочет передать Z единиц Y Бобу. Эта партия активов прошла через пять предыдущих владельцев (включая эмитента активов), прежде чем попасть в руки Алисы. Следовательно, Алисе необходимо предоставить Бобу доказательства этих четырех переходов состояний (первые три из которых были предоставлены Алисе предыдущим владельцем), включая начальное состояние контракта и правила перехода состояний, а также биты, используемые для каждой передачи. Биткойн-транзакции, транзакции RGB, совершенные каждой биткойн-биржей, а также доказательства того, что эти биткойн-транзакции были подтверждены определенным блоком, отправляются Бобу. Боб проверит, что эти четыре перевода не нарушают правила в соответствии с правилами перехода состояний. контракта., а затем решить, принимать ли его. Когда Алиса конструирует транзакцию RGB, поскольку Z меньше X, ей также необходимо организовать для себя UTXO, чтобы получить оставшуюся часть. Наконец, Алиса встраивает хэш-значение этой транзакции RGB в транзакцию Биткойн, которая требует UTXO A' для завершения платежа.
Наконец, благодаря использованию контейнеров UTXO последнее состояние контракта RGB может быть представлено как точка на ориентированном ациклическом графе, не имеющем потомков (каждая точка представляет состояние, хранящееся в контейнере UTXO). Более того, для владельца P на рисунке ниже он будет знать только процесс из начального состояния G контракта, который до него доберется, то есть процесс, отмеченный красным кружком, и ничего не будет знать о серых точках:
#RGB ПРЕИМУЩЕСТВА
Легкое проверяемое состояние
Как упоминалось выше, по сравнению с предыдущими протоколами выпуска активов (оффчейн-контрактными системами), появившимися в Биткойне, RGB значительно снижает стоимость проверки (определённого состояния контракта). Во время транзакции получателю больше не нужно проходить все блоки для сбора информации об изменениях статуса контракта, а достаточно получить серию транзакций Биткойн, а также транзакции RGB, обещанные этими биржами, и блоки этих Биткойн. транзакции содержат Доказательства (на основе доказательств Меркла в заголовке блока), вы можете быть уверены, что плательщик действительно владеет определенным количеством определенного актива.
Такое снижение затрат на проверку также значительно снижает зависимость (доверие) пользователей к крупным поставщикам инфраструктуры. В предыдущих протоколах из-за высокой стоимости проверки пользователям было сложно самостоятельно рассчитать последний статус контракта, поэтому пользователям приходилось доверять некоторым поставщикам (например, поставщику статуса контракта, используемому их кошельком); в то же время время, потому что они могли себе такое позволить. Меньше поставщиков для расчета затрат, что также означает централизацию поставщиков. Но в RGB пользователям нужно использовать только легкий клиент Bitcoin для проверки части транзакции с Bitcoin и протокол RGB для проверки части транзакции RGB, и они могут себе это позволить.
По сравнению с некоторыми ончейн-контрактными системами RGB также легче. Это выражается в том, что RGB может специально проверять определенное состояние контракта; на тех системах, которые не основаны на UTXO, из-за отсутствия механизма контроля доступа, такого как UTXO, любая транзакция может изменить любое состояние, поэтому вы Практически невозможно специально проверить определенное состояние, а определить определенное состояние можно только при расчете всех последних состояний - в этом смысле характеристики, выраженные как «глобальное состояние», на самом деле должны быть Это называется «единым состоянием». обеспечивает функцию перекрестного доступа между контрактами, а также определяет, что стоимость его проверки будет выше и будет сложнее добиться недоверия.
В этих протоколах контрактов в цепочке основной мерой оптимизации является требование, чтобы заголовок блока фиксировал последнее состояние («корень состояния»), тем самым позволяя легким клиентам проверять определенное состояние контракта, полученное из полного узла на основе эти обязательства. . Это метод повторного использования уже произошедших вычислений (вычислений, выполненных полным узлом), и он также очень эффективен, поэтому, если не учитывать недоверие, его можно считать более эффективным, чем RGB. Однако в конечном итоге это означает, что легкие узлы полагаются на полные узлы для базовой проверки транзакций и расчета статуса контракта. В кошельке RGB, который использует легкий клиент Bitcoin, предположение о доверии, на которое он опирается, заключается в том, что соответствующая транзакция Bitcoin является действительной транзакцией, а часть, связанная со статусом контракта, была лично проверена клиентом, поэтому она вызывает больше доверия. бесплатно. . Недостатком является то, что задержка проверки увеличивается и необходимо хранить больше данных.
Масштабируемость
Масштабируемость RGB отражается в двух аспектах:
В транзакцию Bitcoin встроено всего лишь хеш-значение, а это означает, что нет ограничений на объем транзакции RGB (за исключением пользовательских правил контракта) — даже если вы разделите один актив RGB на 100 частей (транзакция RGB сам по себе будет очень большим), и в транзакцию Биткойн необходимо включить только одно хеш-значение. Как упоминалось в примечании 6, существует два способа встроить такое хеш-значение: один — использовать вывод OP_RETURN, что означает, что он будет использовать пространство цепочки хеш-значения; другой — скрыть публичный вывод скрипта. в ключе Taproot — это не занимает места в цепочке. Это также означает, что пользователям не придется жертвовать экономикой ради программируемости — учитываются только внутрисетевые комиссии.
Последнее состояние контракта RGB — это независимая точка на ориентированном ациклическом графе без потомков — это означает, что эти состояния можно изменять независимо, не затрагивая друг друга, а значит, разрешен параллелизм. На самом деле это функция, унаследованная от UTXO. Это также означает, что недопустимые изменения (недействительные транзакции), происходящие в одной ветке, не повлияют на другие ветки, не говоря уже о том, что они приведут к зависанию всего контракта, поэтому это также можно рассматривать как преимущество безопасности.
Один момент, который подвергался критике за масштабируемость RGB, заключается в том, что каждый перевод требует от получателя проверки всех задействованных транзакций от исходного состояния до состояния плательщика - по мере того, как количество раз, когда актив переходит из рук в руки, увеличивается, нагрузка проверки на последующих получателей увеличивается. будет становиться все тяжелее и тяжелее. Эта критика верна. Оптимизация означает, что нам также необходимо найти способ повторного использования уже выполненных операций. Технологии систем доказательств, такие как SNARK, обещают предоставить такое решение.
Дифференциация определения активов и механизма хранения
Последнее преимущество по-прежнему связано с UTXO и зависит от того, как мы понимаем механизм сценариев блокировки UTXO.
Сценарий блокировки можно использовать для программирования условий разблокировки фонда и, следовательно, для реализации правил хранения. Например, если сценарий блокировки содержит один и только один открытый ключ, это означает, что только владелец соответствующего закрытого ключа может управлять им. Однако такие правила хранения также являются основой для программирования протокола контракта Биткойн. Например, UTXO, использующий сценарий блокировки мультиподписей 2 из 2, может быть Lightning-каналом; во время работы канала две стороны могут платить друг другу почти бесчисленное количество раз без каких-либо изменений в ончейн-форме фонды. Другими словами, в настоящее время сценарий блокировки с несколькими подписями 2-из-2 представляет собой механизм передачи стоимости, который позволяет обеим сторонам передавать стоимость без изменения формы средств в цепочке.
Такой механизм можно использовать для стоимости биткойнов, переносимых UTXO.Естественно, его также можно использовать для активов RGB, переносимых им. Мы можем выпустить актив RGB и прикрепить его к UTXO с мультиподписью 2 из 2, тем самым используя механизм канала Lightning для выплаты этого актива друг другу неограниченное количество раз. Таким же образом активы RGB можно включать в другие контракты на основе биткойн-скриптов.
Здесь сценарий UTXO и протокол RGB образуют функциональную дифференциацию: первый предназначен для реализации правил хранения и передачи стоимости; а второй фокусируется на определении активов. Таким образом, хранение активов и определение активов могут быть разделены. Это важное улучшение безопасности, к которому стремятся люди в некоторых других системах контрактов на блокчейне.
RGB-дизайн уже создан
Вышеуказанные характеристики фактически справедливы для всех протоколов, основанных на однократном запечатывании UTXO и проверке клиента. Но на этой основе был разработан протокол RGB.
В текущей разработке протокола RGB разработчики особенно обеспокоены конфиденциальностью протокола, поэтому RGB усиливает конфиденциальность в двух аспектах:
Слепой УТХО. В транзакции RGB получателю необходимо использовать только замаскированный идентификатор UTXO для получения актива, не раскрывая характеристики UTXO, который фактически получил актив. Это не умаляет возможности получателя предоставить доказательства следующему владельцу, в то же время позволяя последующим получателям активов защитить себя от любопытных глаз предыдущего владельца активов.
Пуленепробиваемый. Может использоваться для сокрытия конкретной суммы в каждой транзакции. Однако последующие владельцы активов все равно смогут убедиться, что до этого не было никакого дополнительного выпуска.
Пространство, которое нужно исследовать
В этом разделе я буду обсуждать возможности, которые протокол RGB может продолжать исследовать, в основном связанные с программируемостью.
В настоящее время предложенные шаблоны контрактов (схемы) RGB ориентированы на выпуск активов. Однако, поскольку RGB использует парадигму «проверки на стороне клиента», мы фактически можем добавлять к ней любые характеристики, которые могут быть обеспечены проверкой на стороне клиента — ограничиваясь только структурой UTXO.
Ограничения
На основе UTXO концепция, которая может расширить возможности программирования, называется «заветами». Первоначальная цель ограничительной статьи — ограничить пункт назначения, куда может быть переведена денежная сумма. Благодаря этой способности мы можем программировать множество интересных приложений, таких как:
Пул средств для неинтерактивного вывода средств. Мы можем объединить средства многих людей в одном UTXO и использовать положения об ограничениях, чтобы гарантировать, что любой из них сможет вывести свои собственные средства без помощи других. Это может помочь людям покинуть места повышенного риска с низкими затратами, когда спрос на блочное пространство высок.
Контракт Хранилища. Средства сначала должны быть где-то потрачены и пройти временную блокировку, прежде чем их можно будет потратить свободно; в период временной блокировки владелец сейфа может прервать этот процесс аварийным ключом и немедленно перевести средства в другое место. Это устройство может стать отличным подспорьем для автономного содержания.
Текущий биткойн-скрипт не имеет такой возможности, поэтому для включения ограничений биткойн-скрипта требуется софт-форк.
Однако до тех пор, пока мы готовы пожертвовать некоторыми преимуществами, предоставляемыми «дифференциацией механизмов определения активов и хранения», мы можем экспериментировать с такими функциями на активах RGB. Только не работает для активов RGB, которые его используют (а не Биткойн), но определенно откроет интересное пространство.
Существующие исследования положений об ограничениях показывают, что они могут расширить пространство программирования транзакций на основе UTXO и предоставить множество функций. Но эти исследования в основном основаны на Биткойне, а на таких протоколах, как Биткойн, мы будем более консервативны. Что касается RGB, мы можем смело обобщить основную возможность ограничительных предложений — возможность читать транзакции, которые тратятся на уровне сценария, — чтобы обеспечить более гибкую программируемость: возможность перекрестного доступа к контрактам.
Перекрестный доступ
Минимально ограничительные условия означают, что при расходовании UTXO его сценарий может считывать выходные данные транзакции расходов. Но полностью обобщенное ограничение означает, что оно может читать все части транзакции, на которую оно было потрачено. Это означает, что он также может читать другие входные данные транзакции.Если мы не ограничиваем другие входные данные из одного и того же контракта, это означает, что он может читать статус других контрактов.
В RGB по умолчанию каждый контракт представляет собой независимую вселенную со своим собственным направленным ациклическим графом. Однако пользователь по-прежнему может сохранять статус двух разных контрактов одновременно. Если бы транзакции RGB позволяли одновременно расходовать активы из обоих контрактов, такие возможности перекрестного доступа могли бы найти применение (хотя, возможно, это могло бы усложнить проверку транзакций).
Фактически, уже существуют внутрисетевые контрактные системы, основанные на аналогичных структурах UTXO (например, Nervos Network), которые используют это для достижения возможностей перекрестного доступа к контрактам. Это совершенно новая область, открывающаяся в области, редко затрагиваемые предыдущими исследованиями Биткойна, и там могут быть спрятаны некоторые сюрпризы.
в заключение
В этой статье читатели обнаружат, что существует концепция, которая часто упоминается и проходит через все процессы рассуждений и фантазий: «UTXO». Это именно мое намерение. Если вы не понимаете UTXO, вы не сможете понять отправную точку разработки такого протокола, как RGB, не сможете понять преимущества разработки протокола RGB и не сможете представить, как люди его используют. Характеристики протокола RGB во многом определяются его одноразовой запечатанной формой UTXO. Соответственно, исследования UTXO, накопленные в области исследований Биткойна, также могут быть применены к исследованиям RGB.
Это также объясняет, почему людям, которые не понимают Биткойн, будет трудно понять RGB. Люди, которым нравится Биткойн, узнают дизайн, созданный RGB.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Узнайте истинный потенциал протокола выпуска активов RGB в одной статье.
Автор: А Цзянь
В этой статье делается попытка дать краткое описание RGB, протокола выпуска активов в Биткойне (его также можно понимать как автономную систему смарт-контрактов), и указывает, что он сильно отличается от других проектов, целью которых является Для достижения таких же или похожих функциональных протоколов эти различия делают протокол RGB гораздо более масштабируемым, чем они, и оставляют более широкое пространство для программирования. Помимо представления готовых проектов RGB, мы также изучим возможности программирования.
Что такое протокол RGB?
Идея выпуска активов на биткойнах существует уже давно. Но протокол Биткойн имеет свои особенности: его состояние выражается только биткойн-UTXO («вывод неизрасходованных транзакций»); UTXO несет только две данные: свой собственный номинал (значение биткойна) и «открытый ключ сценария» (также известный как «скрипт блокировки»), используемый для программирования условий расходов этого фонда, например: предоставление подписи определенного открытого ключа; разрешение кода операции, используемого для программирования сценария блокировки, определяться правилами консенсуса Биткойна при условии, что они не могут использоваться для реализации произвольных правил безопасности. Следовательно, внутри UTXO невозможно создавать другие активы — скрипт Биткойн не может запрограммировать проверки безопасности для этих активов. Это означает, что все идеи по выпуску активов в Биткойне по сути представляют собой творческое использование пространства блоков Биткойна. Это означает, что нам необходимо разработать систему смарт-контрактов вне сети и потребовать выполнения шагов по изменению состояния контракта — например, контракт A меняет параметры, а B передает определенное количество определенного актива в C —— Информация загружается в блокчейн, поэтому путем сбора этой информации можно получить последний статус системы смарт-контрактов.
Грубая идея проекта состоит в том, чтобы загрузить информацию о шагах, которые меняют состояние контракта, в блокчейн Биткойна без изменений. Это, конечно, работает, но сталкивается с несколькими проблемами:
(1) Поскольку загружается полная информация, она может занимать больше места в блоке.Когда пользователям необходимо изменить статус контракта (например, передачу), им также придется платить больше комиссий за обработку внутри цепочки. В частности, когда мы надеемся, что такая внесетевая контрактная система имеет лучшую программируемость, чем Биткойн, увеличение программируемости может произойти за счет потребления большего количества блочного пространства;
(2) Практически любая информация в блоке может изменить смарт-контракт вне цепочки.Поэтому пользователи должны получить все данные блока Биткойн, чтобы получить последний статус системы контрактов вне цепочки, то есть проверка обходится дороже;
(3) В зависимости от конструкции системы смарт-контрактов вне сети вы можете получить только конфиденциальность, сравнимую с конфиденциальностью Биткойна, или даже хуже; и если вы можете обеспечить большую конфиденциальность, вам, возможно, придется занять больше места. блокировать пространство.
В прошлом широко используемый протокол под названием «Omni» не загружал полную информацию о транзакциях контракта вне сети, а только хеш-значение транзакции. Этот подход решает вышеуказанные проблемы и отделяет сложность транзакций контрактов вне цепочки от их экономических затрат; однако пользователям все равно необходимо получить полный объем данных блока Биткойн, чтобы получить последний статус протокола Omni; кроме того, он не предназначен специально для повышения конфиденциальности.
RGB использует новую парадигму под названием «одноразовые пломбы». Его использование очень просто: RGB требует, чтобы каждое состояние каждого контракта было привязано к определенному биткойн-UTXO; и как только вы захотите изменить это состояние, вы должны потратить этот UTXO и позволить транзакции, которая его тратит, получить подтверждение в блокчейне; кроме того, транзакция биткойнов, которая их тратит, также должна предоставить хэш содержимого перехода состояния, чтобы указать UTXO, прикрепленный к измененному состоянию.
Для разработчиков RGB дизайн похож на пронумерованную пластиковую пломбу: легко определить, была ли она удалена, и как только она будет удалена, ее нельзя будет использовать повторно. Однако другая точка зрения состоит в том, чтобы рассматривать одержимый UTXO как контейнер или керамическую копилку в этом состоянии: если вы хотите вынуть деньги из копилки, вы должны разбить копилку. в новую банку.
Этот дизайн резко контрастирует с предыдущими протоколами, которые рассматривали весь блок как большую доску для записи: использование UTXO в качестве контейнера означает, что транзакции, которые не тратят этот UTXO, не могут иметь никакого влияния на состояние контракта в контейнере. определенное состояние определенного контракта, нам не нужно получать данные всех блоков.Все, что нам нужно, это серия биткойн-транзакций, свидетельство того, что эти биткойн-транзакции существуют в определенном блоке, и эти биты.Преобразование состояния RGB, обещанное достаточно обмена валюты (пара один к одному с соответствующей транзакцией биткойнов). Эти данные, которые можно объединить в цепочку, должны позволить нам проследить исходное состояние этого контракта, что позволит нам выявить суть этого состояния.
Читателям, знакомым с системами смарт-контрактов внутри цепочки (такими как Ethereum), трудно понять одну вещь в этом процессе: если он не опирается на консенсус блокчейна (что означает, что начальное состояние контракт и каждое изменение состояния будет проверено каждым узлом), как гарантируется безопасность этой системы смарт-контрактов? Как гарантировать, что активы, которые вы получаете, являются именно теми, которые вы хотите, и как гарантировать, что активы не были выданы незаконно?
Ответ тоже очень простой, он называется «проверка на стороне клиента» — вы сами проверяете. В системе контрактов on-chain узлы проверяют каждую операцию перехода состояний в соответствии с общедоступными правилами перехода состояний, отклоняют недопустимые операции, а затем вычисляют последнее состояние на основе начального состояния. Однако, пока известны правила перехода состояний и исходное состояние, проверка посредством консенсуса в цепочке — не единственный способ.Пользователи могут проверить, следует ли каждый шаг перехода состояния первоначально определенному переходу состояния на основе информации, предоставленной правило плательщика. Таким образом, проверяющая сторона (предполагаемая получателем актива) также может обнаружить незаконные переходы состояний и отказаться их принимать.
Наконец, мы используем пример, чтобы продемонстрировать характеристики протокола RGB:
Теперь Алиса владеет UTXO A, который содержит X единиц актива Y, выпущенных по протоколу RGB. Она хочет передать Z единиц Y Бобу. Эта партия активов прошла через пять предыдущих владельцев (включая эмитента активов), прежде чем попасть в руки Алисы. Следовательно, Алисе необходимо предоставить Бобу доказательства этих четырех переходов состояний (первые три из которых были предоставлены Алисе предыдущим владельцем), включая начальное состояние контракта и правила перехода состояний, а также биты, используемые для каждой передачи. Биткойн-транзакции, транзакции RGB, совершенные каждой биткойн-биржей, а также доказательства того, что эти биткойн-транзакции были подтверждены определенным блоком, отправляются Бобу. Боб проверит, что эти четыре перевода не нарушают правила в соответствии с правилами перехода состояний. контракта., а затем решить, принимать ли его. Когда Алиса конструирует транзакцию RGB, поскольку Z меньше X, ей также необходимо организовать для себя UTXO, чтобы получить оставшуюся часть. Наконец, Алиса встраивает хэш-значение этой транзакции RGB в транзакцию Биткойн, которая требует UTXO A' для завершения платежа.
Наконец, благодаря использованию контейнеров UTXO последнее состояние контракта RGB может быть представлено как точка на ориентированном ациклическом графе, не имеющем потомков (каждая точка представляет состояние, хранящееся в контейнере UTXO). Более того, для владельца P на рисунке ниже он будет знать только процесс из начального состояния G контракта, который до него доберется, то есть процесс, отмеченный красным кружком, и ничего не будет знать о серых точках:
#RGB ПРЕИМУЩЕСТВА
Легкое проверяемое состояние
Как упоминалось выше, по сравнению с предыдущими протоколами выпуска активов (оффчейн-контрактными системами), появившимися в Биткойне, RGB значительно снижает стоимость проверки (определённого состояния контракта). Во время транзакции получателю больше не нужно проходить все блоки для сбора информации об изменениях статуса контракта, а достаточно получить серию транзакций Биткойн, а также транзакции RGB, обещанные этими биржами, и блоки этих Биткойн. транзакции содержат Доказательства (на основе доказательств Меркла в заголовке блока), вы можете быть уверены, что плательщик действительно владеет определенным количеством определенного актива.
Такое снижение затрат на проверку также значительно снижает зависимость (доверие) пользователей к крупным поставщикам инфраструктуры. В предыдущих протоколах из-за высокой стоимости проверки пользователям было сложно самостоятельно рассчитать последний статус контракта, поэтому пользователям приходилось доверять некоторым поставщикам (например, поставщику статуса контракта, используемому их кошельком); в то же время время, потому что они могли себе такое позволить. Меньше поставщиков для расчета затрат, что также означает централизацию поставщиков. Но в RGB пользователям нужно использовать только легкий клиент Bitcoin для проверки части транзакции с Bitcoin и протокол RGB для проверки части транзакции RGB, и они могут себе это позволить.
По сравнению с некоторыми ончейн-контрактными системами RGB также легче. Это выражается в том, что RGB может специально проверять определенное состояние контракта; на тех системах, которые не основаны на UTXO, из-за отсутствия механизма контроля доступа, такого как UTXO, любая транзакция может изменить любое состояние, поэтому вы Практически невозможно специально проверить определенное состояние, а определить определенное состояние можно только при расчете всех последних состояний - в этом смысле характеристики, выраженные как «глобальное состояние», на самом деле должны быть Это называется «единым состоянием». обеспечивает функцию перекрестного доступа между контрактами, а также определяет, что стоимость его проверки будет выше и будет сложнее добиться недоверия.
В этих протоколах контрактов в цепочке основной мерой оптимизации является требование, чтобы заголовок блока фиксировал последнее состояние («корень состояния»), тем самым позволяя легким клиентам проверять определенное состояние контракта, полученное из полного узла на основе эти обязательства. . Это метод повторного использования уже произошедших вычислений (вычислений, выполненных полным узлом), и он также очень эффективен, поэтому, если не учитывать недоверие, его можно считать более эффективным, чем RGB. Однако в конечном итоге это означает, что легкие узлы полагаются на полные узлы для базовой проверки транзакций и расчета статуса контракта. В кошельке RGB, который использует легкий клиент Bitcoin, предположение о доверии, на которое он опирается, заключается в том, что соответствующая транзакция Bitcoin является действительной транзакцией, а часть, связанная со статусом контракта, была лично проверена клиентом, поэтому она вызывает больше доверия. бесплатно. . Недостатком является то, что задержка проверки увеличивается и необходимо хранить больше данных.
Масштабируемость
Масштабируемость RGB отражается в двух аспектах:
В транзакцию Bitcoin встроено всего лишь хеш-значение, а это означает, что нет ограничений на объем транзакции RGB (за исключением пользовательских правил контракта) — даже если вы разделите один актив RGB на 100 частей (транзакция RGB сам по себе будет очень большим), и в транзакцию Биткойн необходимо включить только одно хеш-значение. Как упоминалось в примечании 6, существует два способа встроить такое хеш-значение: один — использовать вывод OP_RETURN, что означает, что он будет использовать пространство цепочки хеш-значения; другой — скрыть публичный вывод скрипта. в ключе Taproot — это не занимает места в цепочке. Это также означает, что пользователям не придется жертвовать экономикой ради программируемости — учитываются только внутрисетевые комиссии.
Последнее состояние контракта RGB — это независимая точка на ориентированном ациклическом графе без потомков — это означает, что эти состояния можно изменять независимо, не затрагивая друг друга, а значит, разрешен параллелизм. На самом деле это функция, унаследованная от UTXO. Это также означает, что недопустимые изменения (недействительные транзакции), происходящие в одной ветке, не повлияют на другие ветки, не говоря уже о том, что они приведут к зависанию всего контракта, поэтому это также можно рассматривать как преимущество безопасности.
Один момент, который подвергался критике за масштабируемость RGB, заключается в том, что каждый перевод требует от получателя проверки всех задействованных транзакций от исходного состояния до состояния плательщика - по мере того, как количество раз, когда актив переходит из рук в руки, увеличивается, нагрузка проверки на последующих получателей увеличивается. будет становиться все тяжелее и тяжелее. Эта критика верна. Оптимизация означает, что нам также необходимо найти способ повторного использования уже выполненных операций. Технологии систем доказательств, такие как SNARK, обещают предоставить такое решение.
Дифференциация определения активов и механизма хранения
Последнее преимущество по-прежнему связано с UTXO и зависит от того, как мы понимаем механизм сценариев блокировки UTXO.
Сценарий блокировки можно использовать для программирования условий разблокировки фонда и, следовательно, для реализации правил хранения. Например, если сценарий блокировки содержит один и только один открытый ключ, это означает, что только владелец соответствующего закрытого ключа может управлять им. Однако такие правила хранения также являются основой для программирования протокола контракта Биткойн. Например, UTXO, использующий сценарий блокировки мультиподписей 2 из 2, может быть Lightning-каналом; во время работы канала две стороны могут платить друг другу почти бесчисленное количество раз без каких-либо изменений в ончейн-форме фонды. Другими словами, в настоящее время сценарий блокировки с несколькими подписями 2-из-2 представляет собой механизм передачи стоимости, который позволяет обеим сторонам передавать стоимость без изменения формы средств в цепочке.
Такой механизм можно использовать для стоимости биткойнов, переносимых UTXO.Естественно, его также можно использовать для активов RGB, переносимых им. Мы можем выпустить актив RGB и прикрепить его к UTXO с мультиподписью 2 из 2, тем самым используя механизм канала Lightning для выплаты этого актива друг другу неограниченное количество раз. Таким же образом активы RGB можно включать в другие контракты на основе биткойн-скриптов.
Здесь сценарий UTXO и протокол RGB образуют функциональную дифференциацию: первый предназначен для реализации правил хранения и передачи стоимости; а второй фокусируется на определении активов. Таким образом, хранение активов и определение активов могут быть разделены. Это важное улучшение безопасности, к которому стремятся люди в некоторых других системах контрактов на блокчейне.
RGB-дизайн уже создан
Вышеуказанные характеристики фактически справедливы для всех протоколов, основанных на однократном запечатывании UTXO и проверке клиента. Но на этой основе был разработан протокол RGB.
В текущей разработке протокола RGB разработчики особенно обеспокоены конфиденциальностью протокола, поэтому RGB усиливает конфиденциальность в двух аспектах:
Слепой УТХО. В транзакции RGB получателю необходимо использовать только замаскированный идентификатор UTXO для получения актива, не раскрывая характеристики UTXO, который фактически получил актив. Это не умаляет возможности получателя предоставить доказательства следующему владельцу, в то же время позволяя последующим получателям активов защитить себя от любопытных глаз предыдущего владельца активов.
Пуленепробиваемый. Может использоваться для сокрытия конкретной суммы в каждой транзакции. Однако последующие владельцы активов все равно смогут убедиться, что до этого не было никакого дополнительного выпуска.
Пространство, которое нужно исследовать
В этом разделе я буду обсуждать возможности, которые протокол RGB может продолжать исследовать, в основном связанные с программируемостью.
В настоящее время предложенные шаблоны контрактов (схемы) RGB ориентированы на выпуск активов. Однако, поскольку RGB использует парадигму «проверки на стороне клиента», мы фактически можем добавлять к ней любые характеристики, которые могут быть обеспечены проверкой на стороне клиента — ограничиваясь только структурой UTXO.
Ограничения
На основе UTXO концепция, которая может расширить возможности программирования, называется «заветами». Первоначальная цель ограничительной статьи — ограничить пункт назначения, куда может быть переведена денежная сумма. Благодаря этой способности мы можем программировать множество интересных приложений, таких как:
Пул средств для неинтерактивного вывода средств. Мы можем объединить средства многих людей в одном UTXO и использовать положения об ограничениях, чтобы гарантировать, что любой из них сможет вывести свои собственные средства без помощи других. Это может помочь людям покинуть места повышенного риска с низкими затратами, когда спрос на блочное пространство высок.
Контракт Хранилища. Средства сначала должны быть где-то потрачены и пройти временную блокировку, прежде чем их можно будет потратить свободно; в период временной блокировки владелец сейфа может прервать этот процесс аварийным ключом и немедленно перевести средства в другое место. Это устройство может стать отличным подспорьем для автономного содержания.
Текущий биткойн-скрипт не имеет такой возможности, поэтому для включения ограничений биткойн-скрипта требуется софт-форк.
Однако до тех пор, пока мы готовы пожертвовать некоторыми преимуществами, предоставляемыми «дифференциацией механизмов определения активов и хранения», мы можем экспериментировать с такими функциями на активах RGB. Только не работает для активов RGB, которые его используют (а не Биткойн), но определенно откроет интересное пространство.
Существующие исследования положений об ограничениях показывают, что они могут расширить пространство программирования транзакций на основе UTXO и предоставить множество функций. Но эти исследования в основном основаны на Биткойне, а на таких протоколах, как Биткойн, мы будем более консервативны. Что касается RGB, мы можем смело обобщить основную возможность ограничительных предложений — возможность читать транзакции, которые тратятся на уровне сценария, — чтобы обеспечить более гибкую программируемость: возможность перекрестного доступа к контрактам.
Перекрестный доступ
Минимально ограничительные условия означают, что при расходовании UTXO его сценарий может считывать выходные данные транзакции расходов. Но полностью обобщенное ограничение означает, что оно может читать все части транзакции, на которую оно было потрачено. Это означает, что он также может читать другие входные данные транзакции.Если мы не ограничиваем другие входные данные из одного и того же контракта, это означает, что он может читать статус других контрактов.
В RGB по умолчанию каждый контракт представляет собой независимую вселенную со своим собственным направленным ациклическим графом. Однако пользователь по-прежнему может сохранять статус двух разных контрактов одновременно. Если бы транзакции RGB позволяли одновременно расходовать активы из обоих контрактов, такие возможности перекрестного доступа могли бы найти применение (хотя, возможно, это могло бы усложнить проверку транзакций).
Фактически, уже существуют внутрисетевые контрактные системы, основанные на аналогичных структурах UTXO (например, Nervos Network), которые используют это для достижения возможностей перекрестного доступа к контрактам. Это совершенно новая область, открывающаяся в области, редко затрагиваемые предыдущими исследованиями Биткойна, и там могут быть спрятаны некоторые сюрпризы.
в заключение
В этой статье читатели обнаружат, что существует концепция, которая часто упоминается и проходит через все процессы рассуждений и фантазий: «UTXO». Это именно мое намерение. Если вы не понимаете UTXO, вы не сможете понять отправную точку разработки такого протокола, как RGB, не сможете понять преимущества разработки протокола RGB и не сможете представить, как люди его используют. Характеристики протокола RGB во многом определяются его одноразовой запечатанной формой UTXO. Соответственно, исследования UTXO, накопленные в области исследований Биткойна, также могут быть применены к исследованиям RGB.
Это также объясняет, почему людям, которые не понимают Биткойн, будет трудно понять RGB. Люди, которым нравится Биткойн, узнают дизайн, созданный RGB.