Введение

Эмиссия активов на основе BTC всегда была актуальной темой. Начиная с появления цветных монет в 2011 году и заканчивая недавно популярным Ординарным протоколом, сообщество BTC всегда способно приводить к появлению новых игроков и консенсусу. Однако лишь немногие из них выдержали испытание временем. После того, как амбициозная компания Lightling Labs объявила о своем плане создания стабильной монеты на базе Taproot Assets, а Tether объявила о своем выборе RGB для майнинга USDT на первом уровне Биткойна, стало ясно, что некогда знаменитый OmniLayer (Mastercoin) больше не является крупнейшим игроком в экосистеме BTC. Протоколы активов Client-Side Validation (CSV) начинают привлекать к себе внимание, отличаясь от традиционных протоколов активов BTC тем, что в них также включены функции масштабируемости Биткойна. Но, столкнувшись с таким множеством протоколов активов в экосистеме BTC, следует задаться вопросом: в чем их различия? И как нам выбрать и найти свои собственные возможности среди этих многочисленных протоколов активов?

Цель этой статьи - помочь читателям рассмотреть различные протоколы активов, которые появились в истории Биткойна, и рассмотреть потенциальную траекторию развития протоколов активов на основе Биткойна в обозримом будущем.

Цветные монеты

Идея цветных монет была впервые предложена Йони Ассиа, нынешним генеральным директором eToro, в статье, написанной 27 марта 2012 года и озаглавленной "Биткойн 2.X (он же цветной биткойн)". В статье утверждается, что Биткойн, как базовая технология, совершенен, подобно тому, как HTTP является основой Интернета. Поэтому на основе повторного использования BTC был разработан протокол токенов Colored Coins.

Йони Ассиа стремился создать экономику BTC 2.0 с помощью этого метода - любое сообщество могло бы создать множество валют таким образом. Такой подход к использованию Биткойна в качестве базовой технологии для клиринга транзакций и предотвращения двойных трат, несомненно, был очень смелой идеей в то время.

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

3 июля 2014 года компания ChromaWay разработала усовершенствованный протокол цветных монет на основе технологии Pay-to-Script-Hash (P2SH) (EPOBC), который упростил для разработчиков процесс создания цветных монет. Это был самый ранний протокол, принявший функциональность OP_RETURN в Bitcoin Script.

Окончательная реализация показана на следующем изображении:

)

Эта реализация очень лаконична, но она также порождает множество проблем:

Гомогенизированные токены и минимальное значение привязки

В транзакции генезиса, если цветная монета связана с 1000 сатов, наименьшая дробная единица этой цветной монеты равна 1 сату. Это означает, что актив или токен может быть разделен или распределен максимум на 1000 частей (но это только теоретически, для предотвращения атак пыли, например, раньше sat был установлен на 546 SAT, а позже на ordinal, что выше).

Вопросы верификации

Чтобы установить подлинность и право собственности на цветную монету, необходимо проследить и проверить все этапы от генезиса актива до текущего UTXO. Поэтому необходимо разработать специальный кошелек и сопутствующий ему полный узел, и даже браузер.

Потенциальный риск цензуры в отношении майнеров

Из-за отличительных особенностей ColoredTransaction, которая предполагает запись информации о метаданных в вывод, существует возможность цензуры майнеров.

Цветные монеты - это, по сути, система отслеживания активов, использующая правила верификации Биткойна для отслеживания передачи активов. Однако, чтобы доказать, что какой-либо конкретный выход (txout) представляет собой определенный актив, необходимо проследить всю цепочку передачи от возникновения актива до настоящего момента. Это означает, что для проверки законности транзакции может потребоваться длинная цепочка доказательств. Для решения этой проблемы было предложено ввести OP_CHECKCOLORVERIFY, чтобы помочь в прямой проверке правильности транзакций Цветных монет на BTC, но это предложение не было принято.

Первое ICO в криптовалютной индустрии: Mastercoin

Первоначальная концепция Мастеркойна была предложена Дж.Р. Уиллеттом. В 2012 году он опубликовал документ под названием "The Second Bitcoin Whitepaper", в котором описал концепцию создания новых активов или токенов на существующем блокчейне Биткойна, позже получившем название "MasterCoin". Впоследствии она была переименована в Omni Layer.

Проект Mastercoin провел первичную продажу токенов (то, что мы сегодня называем ICO или Initial Coin Offering) в 2013 году, успешно собрав миллионы долларов. Это считается первым в истории ICO. Наиболее заметным применением Мастеркойна является Tether (USDT), самый известный фиатный стейблкоин, который первоначально был выпущен на Omni Layer.

На самом деле, концепция Мастеркойна возникла еще до появления Цветных Монет. Причина, по которой он рассматривается здесь во вторую очередь, заключается в том, что по сравнению с цветными монетами, Mastercoin - это относительно более сложное решение. Mastercoin создал полноценный уровень нод, предлагая тем самым более сложные функциональные возможности (например, смарт-контракты), в то время как Colored Coins был более простым и прямым, сосредоточившись в основном на "раскрашивании" или маркировке Биткойн UTXO для представления других активов.

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

По сравнению с цветными монетами, Мастеркойн может выполнять более сложную логику. А поскольку он не записывает состояние и не выполняет проверку по цепочке, его транзакции не требуют непрерывности (непрерывного окрашивания).

Однако для реализации сложной логики Mastercoin пользователям необходимо доверять состоянию внецепочечной базы данных узлов или запускать собственные узлы Omni Layer для проверки.

Подведем итоги:

Основное различие между Mastercoin и Colored Coins заключается в том, что Mastercoin решил не хранить все данные, необходимые для протокола, на цепи. Вместо этого она паразитически использовала систему консенсуса BTC для реализации собственной публикации и упорядочивания транзакций, сохраняя их состояние в базе данных вне цепи.

Согласно информации, предоставленной компанией OmniBolt: Omni Layer предлагает новый протокол активов UBA (UTXO Based Asset) для Tether, который будет использовать обновление Taproot для кодирования информации об активах в tapleaf, что позволит реализовать такие функции, как условные платежи. Тем временем OmniBolt внедряет Stark в инфраструктуру Lightning Network компании OmniLayer.

Концепция проверки на стороне клиента

Чтобы понять концепцию проверки на стороне клиента, нам нужно вернуться в год, следующий за появлением цветных монет и Мастеркойна, то есть в 2013 год. В том же году Питер Тодд опубликовал статью: "Распутывая майнинг криптомонет: Timestamping, Proof-of-Publication и Validation". Хотя название статьи, казалось бы, не имеет прямого отношения к валидации на стороне клиента, при внимательном прочтении выясняется, что в ней содержатся самые ранние просветительские мысли о валидации на стороне клиента.

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

Следуя мыслям Питера Тодда, давайте сначала разберемся, какие проблемы на самом деле решил BTC (Биткойн). По мнению Питера Тодда, BTC решил три проблемы:

Доказательство публикации

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

Консенсус по заказу

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

Валидация (необязательно)

Проверка на BTC относится к проверке подписей и сумм переводов BTC. Однако здесь Питер Тодд считает, что эта проверка не является необходимой для создания системы токенов поверх BTC, а скорее является вариантом оптимизации.

В этот момент Вы можете вспомнить об Ominilayer, упомянутом ранее. Сам Ominilayer не делегирует BTC вычисление и проверку состояния, но при этом повторно использует защиту BTC. Цветные монеты, с другой стороны, делегируют отслеживание состояния BTC. Существование обоих вариантов показывает, что проверка не обязательно должна происходить на цепи.

Итак, каким образом проверка на стороне клиента эффективно подтверждает транзакции?

Давайте сначала посмотрим, что нужно подтвердить:

• Состояние (проверка логики транзакции)

• Достоверность входного сигнала TxIn (для предотвращения двойного расходования)

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

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

Питер Тодд предложил следующую структуру дерева обязательств:

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn

Но как хранить такое дерево обязательств в цепочке? Это приводит нас к концепции одноразовой печати.

Одноразовое уплотнение

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

Для SealProtocol есть три элемента и два действия.

Основные элементы:

1. l： печать, то есть уплотнение
2. m： сообщение, сообщение
3. In：свидетель, свидетель

Основные операции: Существует две основные операции:

1. Close(l,m) → w: в закрывающем силе messagemupper создайте свидетеляIn。
2. Verify(l,w,m) → bool: Verify seallВы в новостях? mis closed.

Реализация одноразовой печати с точки зрения безопасностиДва разных сообщения не могут быть найдены атакующимerm1иm2, и заставляет функцию Verify возвращать одно и то же уплотнение.

Прежде всего, Single-Use Seal - это концепция, которая гарантирует, что определенный актив или данные будут использованы или заблокированы только один раз. В контексте Биткойна это обычно означает, что UTXO (выход неизрасходованной транзакции) может быть потрачен только один раз. Поэтому выход транзакции Биткойна можно считать одноразовой печатью, и когда этот выход используется в качестве входа для другой транзакции, печать "ломается" или "используется".

Для CSV-активов на BTC сам Биткойн выступает в качестве одноразового запечатанного "свидетеля". Это связано с тем, что для проверки транзакции Биткойна узел должен убедиться, что каждый вход в транзакцию ссылается на действительный и неизрасходованный UTXO. Если транзакция пытается дважды потратить UTXO, который уже был потрачен, правила консенсуса Биткойна и честные узлы сети отклонят транзакцию.

Может ли она быть проще?

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

Да, это так просто.

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

1. Хранение данных вне цепи: Большая часть истории транзакций, данных о владельцах и других связанных с ними данных активов, проверенных клиентом, хранится вне цепи. Это значительно снижает потребность в хранении данных в цепи и помогает повысить уровень конфиденциальности.
2. Механизм обязательств: Хотя данные об активах хранятся вне цепи, изменения или передачи этих данных будут регистрироваться в цепи с помощью обязательств. Эти обязательства позволяют транзакциям на цепочке ссылаться на состояния вне цепочки, тем самым обеспечивая целостность и неизменность данных вне цепочки.
3. Свидетель на цепи (не обязательно BTC): Хотя большая часть данных и верификации находится вне цепи, активы, верифицированные клиентом, все же могут воспользоваться преимуществами безопасности основной цепи (выдача доказательств, упорядочивание транзакций) с помощью обязательств, встроенных в цепь.
4. Верификация выполняется на стороне клиента: Большая часть работы по проверке выполняется на устройстве пользователя. Это означает, что всем узлам сети не нужно участвовать в проверке каждой транзакции, только вовлеченные участники должны проверять действительность транзакции.

Для тех, кто использует проверку активов на стороне клиента, есть еще один момент, на который следует обратить внимание:

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

Пионер в области валидации на стороне клиента (CSV): RGB

Концепция RGB была предложена Джакомо Зукко (Giacomo Zucco), известной фигурой в сообществе, после 2015 года. В связи с ростом Ethereum и распространением ICO, а также до ICO многие люди пытались делать что-то за пределами Биткойна, например, проекты Mastercoin и Colored Coins. .

Джакомо Зукко выразил разочарование. Он считает, что эти проекты уступают Биткойну, и полагает, что прежние способы внедрения токенов в Биткойн неприемлемы. В процессе работы он познакомился с Питером Тоддом и увлекся его идеей Client-Side-Validation. Затем он началпредлагатьRGBидею.

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

Схемы этих контрактов отвечают за ограничение поведения, которое не выходит за рамки ожидаемого поведения при выполнении vm, например, RGB20 и RGB21, которые, соответственно, отвечают за некоторые ограничения на транзакции со сменными и несменными токенами.

Механизм обязательств RGB: Хэш Педерсена

Что касается механизмов обязательств, то RGB использует хэш Педерсена. Его преимущество заключается в том, что он может заявить о своей ценности, не раскрывая ее. Использование хэша Педерсена для построения дерева Меркле означает, что Вы можете создать дерево Меркле, защищенное от посторонних глаз, которое скрывает значения внутри него. Эта структура может использоваться в некоторых специфических протоколах защиты конфиденциальности, например, в некоторых анонимных криптовалютных проектах. Однако он может не подойти для CSV-активов, о которых будет сказано позже в сравнении с Taproot Assets.

RGB's Virtual Machine Design: От простоты к AluVM

Цель RGB - не только реализовать протокол активов, подтвержденный клиентом, но и расширить его до Тьюринг-полного выполнения виртуальных машин и программирования контрактов. В ранних разработках RGB утверждалось, что он использует язык программирования под названием Simplicity. Этот язык характеризуется тем, что во время выполнения выражений генерируется доказательство выполнения, что облегчает формальную проверку контрактов, написанных на нем (во избежание ошибок). Однако разработка этого языка не была идеальной и в конечном итоге столкнулась с трудностями. Это напрямую привело к сложному рождению протокола RGB в том же году. В конце концов, RGB начала использовать AluVM, разработанный компанией Maxim, с целью избежать неопределенного поведения, подобного первоначальному Simplicity. Новый AluVM, как говорят, будет заменен в будущем языком программирования под названием Contractum, в настоящее время используется Rust.

Направление расширения второго уровня RGB: Lightning Network или Sidechain?

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

RGB и сеть Lightning

Проще говоря, принцип работы Lightning Network заключается в том, что две стороны, участвующие в транзакции, подписывают кучу контрактов (транзакций с обязательствами) вне цепи. Они гарантируют, что если какая-либо сторона нарушит договор, пострадавшая сторона сможет передать договор (транзакцию с обязательствами) в BTC для урегулирования, получить свои средства и наказать другую сторону. Другими словами, Lightning Network обеспечивает безопасность внецепочечных транзакций благодаря разработке протоколов и теории игр.

RGB может создать свою собственную инфраструктуру Lightning Network, разработав подходящие для себя правила заключения договоров о платежных каналах, но сложность Lightning Network чрезвычайно высока, и создание такой системы - непростая задача. Однако, в отличие от них, компания Lightnling Labs уже много лет возделывает эту область, и доля LND на рынке составляет более 90%.

Сайдчейн RGB: Prime

LNP-BP в настоящее время поддерживает протокол RGB, а компания Maxim в июне 2023 года выпустит предложение под названием Prime - схему расширения активов, одобренную клиентами. В нем он раскритиковал существующие схемы расширения сайдчейна и Lightning Network как слишком сложные в разработке. Максим отметил, что, по его мнению, помимо Prime, другие методы расширения включают в себя многоузловые каналы Lightning от NUCLEUS и фабрики каналов Ark/Enigma, оба из которых требуют более двух лет разработки. Однако Прайм может быть завершен всего за один год.

Prime - это не традиционный блокчейн, а модульный слой публикации доказательств, предназначенный для проверки клиентов и состоящий из четырех частей:

1. Сервис временных меток: Определение последовательности транзакций всего за 10 секунд.

2. Доказательство: Хранится в формате PMT, производится и публикуется вместе с заголовком блока.

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

4. Протокол умных контрактов: Осколочные контракты - RGB (заменяемые).

Чтобы решить проблему времени подтверждения транзакций RGB, Prime использует сервис временных меток для быстрого подтверждения транзакций вне цепи и инкапсуляции транзакций и идентификаторов в блоки. Одновременно доказательства транзакций на Prime могут быть дополнительно объединены с помощью PMT и затем привязаны к BTC аналогично контрольным точкам.

Протокол активов CSV на основе Taproot: Taproot Assets

Taproot Assets - это протокол CSV-активов, основанный на Taproot и используемый для выпуска активов, подтвержденных клиентом, на блокчейне Биткойна. Этими активами можно торговать мгновенно, в больших объемах и по низкой цене через сеть Lightning Network. Суть Taproot Assets заключается в использовании безопасности и стабильности сети Биткойн, а также скорости, масштабируемости и низкой стоимости сети Lightning Network. Этот протокол был спроектирован и разработан техническим директором Lightnling Labs roasbeef, который, возможно, является единственным человеком на этой планете, лично руководившим разработкой как клиента Bitcoin (BTCD), так и клиента Lightning Network (LND), и глубоко разбирающимся в BTC.

Транзакции Taproot несут только корневой хэш скрипта актива, поэтому сторонним наблюдателям сложно определить, задействованы ли в них активы Taproot, поскольку сам хэш является общим и может представлять любые данные. С обновлением Taproot Биткойн получил возможность заключения смарт-контрактов (TapScript). Исходя из этого, кодирование активов Taproot Assets сродни созданию определения токена, аналогичного ERC20 или ERC721. Таким образом, Биткойн обладает не только функцией определения активов, но и способностью писать смарт-контракты, закладывая основу для создания инфраструктуры смарт-контрактов с токенами на Биткойне.

Структура кодирования Taproot Assets выглядит следующим образом: [На этом описание заканчивается, указывая на то, что следующая часть статьи, скорее всего, будет посвящена техническим деталям структуры кодирования Taproot Assets].

Изображение с сайта Lightning Labs CTO roasbeef

Как протоколы активов CSV (CoinSwap), Taproot Assets разработаны для более рационального использования по сравнению с RGB. Они максимально используют современные достижения в экосистеме BTC, такие как обновление Taproot и PSBT (Partially Signed Bitcoin Transactions). Наиболее существенное различие между Taproot Assets и RGB в плане расширяемости приложений заключается в исполняющей виртуальной машине (VM). Taproot Assets использует TaprootScriptVM, которая является такой же, как и родная VM, используемая BTC. В последние годы многие инфраструктурные исследования для BTC были основаны на TapScript. Однако из-за медленных темпов обновления BTC эти исследования не были быстро реализованы, что делает Taproot Assets потенциальным полигоном для тестирования этих новых идей.

Чем отличаются Taproot Assets и RGB?

1. Проверка транзакций и удобство работы с легкими узлами

Благодаря реализации дерева сумм, Taproot Assets могут похвастаться высокой эффективностью проверки и безопасностью (проверка и транзакция могут быть выполнены просто с помощью доказательства владения, без просмотра всей истории транзакций). В отличие от этого, использование компанией RGB обязательств Педерсена препятствует эффективной проверке вводимых данных, требуя от RGB отслеживать историю транзакций, что со временем становится значительным бременем. Дизайн дерева сумм Меркеля также облегчает легкую верификацию узлов в Taproot Assets, чего не было в предыдущих протоколах активов, построенных на BTC.

1. ВМ выполнения

Taproot Assets появился после обновления Taproot. Они используют TaprootScriptVM, механизм выполнения скриптов, встроенный в Биткойн после обновления Taproot, и vPSBT, вариант PSBT BTC. Как только механизм молниевого канала Taproot Assets будет завершен, он сможет сразу же повторно использовать всю текущую инфраструктуру LND и прошлые продукты Lightning Labs (в настоящее время LND доминирует более чем в 90% молниевых сетей). Недавнее предложение BitVM, также основанное на TaprootScript, теоретически поддерживает Taproot Assets. Однако виртуальная машина RGB и правила проверки (SCHEMA) являются самодостаточными, образуя относительно замкнутую экосистему. Развитие RGB в значительной степени ограничено рамками его экосистемы, и его интеграция с экосистемой Биткойна не так близка, как можно было бы подумать. Например, единственная связь RGB с обновлением Taproot - это кодирование данных о цепочке обязательств в TapLeaf Свидетеля.

1. Умные контракты

В текущей реализации RGB большое внимание уделяется контрактам и VM. Однако смарт-контракты еще не появились в Taproot Assets. В настоящее время RGB не объясняет, как модификации глобального состояния синхронизируются с отдельными осколками контракта (UTXO), и как обязательства Педерсена, которые гарантируют только общее количество активов, обнаруживают фальсификацию других состояний. В отличие от этого, Taproot Assets с их более простым дизайном в настоящее время хранят только остатки активов и не имеют обширного хранилища состояний, что делает обсуждение смарт-контрактов преждевременным. Однако компания Lightning Labs сообщила, что в следующем году Taproot Assets сосредоточится на разработке смарт-контрактов.

1. Концентратор синхронизации

Как следует из основных принципов проверки активов на стороне клиента, владение Proof так же важно, как и владение закрытым ключом. Но что делать, если доказательство потеряно на стороне клиента пользователя? В Taproot Assets эта проблема может быть решена с помощью "вселенной". Вселенная - это публично проверяемое разреженное дерево Меркле, охватывающее один или несколько активов. В отличие от обычных деревьев активов Taproot, Вселенная не содержит активов Taproot. Вместо этого он берет на себя обязательства по подмножеству одной или нескольких историй активов. В RGB эту роль играет Storm, который синхронизирует данные доказательства вне цепи через P2P. Однако, по историческим причинам, возникшим у команд разработчиков RGB, эти форматы доказательств в настоящее время несовместимы. Команда экосистемы RGB, DIBA, по сообщениям, разрабатывает "карбонадо" для решения этой проблемы, хотя прогресс в этом направлении неясен.

1. Инженерная реализация

Все библиотеки, используемые Taproot Assets, проверены временем, так как у Lightning Labs есть собственный клиент Bitcoin (BTCD), клиент сети Lightning (LND) и многочисленные lib-реализации кошельков. В отличие от этого, большинство библиотек, используемых в RGB, являются самоопределяющимися, и с точки зрения промышленных стандартов, реализация RGB все еще находится на экспериментальной стадии."

Краткое обсуждение будущего расширения BTC

По мере развития дискуссии становится очевидным, что проверка протоколов активов на стороне клиента вышла за рамки спецификаций протоколов и стремится к вычислительному расширению.

Многие считают, что в будущем Биткойн будет существовать как цифровое золото, а другие цепочки создадут экосистему приложений. Однако у меня другое мнение. Как видно из многих обсуждений на форумах, посвященных BTC, они часто вращаются вокруг различных альткоинов и их недолгого существования. Быстрая гибель этих альткоинов превращает капитал и усилия, связанные с ними, в пузыри. Благодаря прочной основе консенсуса Биткойна, нет необходимости создавать новый L1 для протоколов приложений. Что нам нужно сделать, так это использовать эту надежную инфраструктуру Биткойна для построения более долгосрочного децентрализованного мира.

Меньше вычислений в цепочке, больше проверки в цепочке

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

Где происходит валидация? Это очень важно

Для разработчиков протоколов поверх Биткойна вопрос о том, как использовать Биткойн для критических проверок или даже для проведения проверок вне цепи, а также о том, как разрабатывать схемы безопасности, - это вопросы для самих разработчиков протоколов. Они не должны и не обязаны быть связаны с самой цепочкой. Поэтому то, как будет осуществляться валидация, приведет к различным стратегиям расширения для BTC.

Исходя из перспективы внедрения валидации, у нас есть три направления для расширения:

1. 1.Проверка на цепочке (OP-ZKP)
2. Если OP-ZKP будет реализован непосредственно в TaprootScriptVM, это означает интеграцию возможностей проверки ZKP в сам BTC, в сочетании с некоторыми ковенантскими разработками для расчетных протоколов, создавая план расширения Zk-Rollup, который наследует безопасность BTC. Однако, в отличие от развертывания валидационного контракта на Ethereum, медленный процесс обновления BTC в сочетании с таким специализированным и потенциально требующим обновления оп-кодом делает эту задачу сложной.
4. 2.Полуцепочечная валидация (BitVM)
5. Дизайн BitVM не предназначен для обслуживания обычной логики транзакций. Робин Линус также отметил, что будущее BitVM заключается в создании свободного кросс-цепочечного рынка для различных SideChains. Подход BitVM считается полу-цепочечным, поскольку большинство этих вычислений для проверки происходят не на цепочке, а вне ее. Тем не менее, важной причиной для разработки вокруг Taproot BTC является использование TapScriptVM для вычислительной проверки, когда это необходимо, теоретически наследуя безопасность BTC. Этот процесс также генерирует цепочку доверия для проверки. Например, достаточно, чтобы один из 'n' валидаторов был честным, как в Оптимистичных Свертках.
6. Внутрицепочечные расходы BitVM высоки, но может ли он использовать доказательства мошенничества ZK для повышения эффективности? Ответ - нет, потому что реализация доказательств мошенничества ZK основана на возможности выполнить проверку ZKP на цепи, что возвращает нас к дилемме схемы OP-ZKP.
8. 3.Проверка вне цепи (проверка со стороны клиента, Lightning Network)
9. Поскольку проверка происходит полностью вне цепи, мы возвращаемся к ранее рассмотренным протоколам активов CSV и Lightning Network. В предыдущих обсуждениях было отмечено, что при разработке CSV мы не можем полностью предотвратить фальсификацию с помощью сговора. Что мы можем сделать, так это использовать криптографию и дизайн протоколов, чтобы удержать ущерб от злонамеренного сговора в контролируемом диапазоне, сделав такое поведение невыгодным.
10. Плюсы и минусы внецепочечной проверки очевидны. Преимущество заключается в минимальном использовании ресурсов цепочки и огромном потенциале для расширения. Недостатком является то, что практически невозможно полностью использовать безопасность BTC, что значительно ограничивает типы и методы внецепочечных транзакций. Более того, проверка вне цепи также означает, что данные хранятся вне цепи и управляются пользователями, что предъявляет более высокие требования к безопасности среды выполнения программного обеспечения и стабильности программного обеспечения.

Тенденция расширения Эволюция

В настоящее время популярный Layer2 в Ethereum, по сути, использует Layer1 для проверки вычислительной эффективности Layer2. То есть, вычисления состояния переносятся на Уровень2, а проверка остается на Уровне1. В будущем мы сможем аналогичным образом вытеснить вычисления, связанные с проверкой, за пределы цепи, что еще больше увеличит производительность существующей инфраструктуры блокчейна.

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

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