Предисловие

Эмиссия активов на основе BTC всегда была актуальной темой. От самых первых цветных монет в 2011 году до недавно популярного протокола Ordinal, сообщество BTC постоянно придумывало новых игроков и консенсус, но мало кто оставался в нем. Однако компания Lightning Labs обнародовала амбициозные планы по разработке стабильных монеток на основе активов Taproot Assets. Компания Tether также объявила, что будет использовать протокол RGB для майнинга USDT на первом уровне Биткойна.

Это означает, что некогда знаменитый OmniLayer (бывший Mastercoin) больше не является крупнейшим игроком в экосистеме BTC. А протоколы проверки активов на стороне клиента (CSV) начинают входить в поле зрения каждого. Эти протоколы не только поддерживают целостность традиционных протоколов активов Биткойна, но и повышают масштабируемость. Однако множество протоколов активов, входящих в экосистему Биткойна, вызывает соответствующие вопросы: Чем они отличаются друг от друга, и как ориентироваться и использовать возможности в этом ландшафте?

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

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

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

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

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

3 июля 2014 года компания ChromaWay сделала значительный шаг вперед, разработав протокол Enhanced Colored Coins Order-based Protocol (EPOBC), который значительно упростил процесс создания цветных монет для разработчиков. Это был первый протокол, в котором использовалась функция OP_RETURN Биткойн Скрипта.

Результат выглядит следующим образом:

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

1. Вопрос о сгораемости и минимальной стоимости привязки Привязав 1000 сатов в транзакции генезиса за цветную монету, минимальной единицей этой цветной монеты становится 1 сат. Это означает, что теоретически актив или токен может быть разделен максимум на 1000 единиц (но на практике этот показатель ниже, чтобы предотвратить атаки пыли. Например, минимальное значение сатоши когда-то было установлено на уровне 546 SAT, а для ординаров оно еще выше).
2. Проблемы с проверкой Чтобы определить подлинность и принадлежность цветной монеты, необходимо проследить и подтвердить историю транзакций с момента возникновения до текущего UTXO. Поэтому необходимо разрабатывать специальные кошельки, полноценные узлы и даже сканеры.
3. Потенциальный риск цензуры майнеров ColoredTransaction имеет отличительные особенности, такие как запись метаданных на выходе, что создает возможность цензуры майнеров.

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

Первое ICO в криптовалюте: Mastercoin

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

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

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

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

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

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

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

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

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

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

Если мы хотим понять концепцию проверки на стороне клиента (Client Side Validation, CSV), нам нужно вернуться в год, следующий за появлением цветных монет и Мастеркойна, то есть в 2013 год. В том же году Питер Тодд, один из первых исследователей Биткойна и криптографии, опубликовал статью под названием "Разъединение майнинга криптомонет: Timestamping, Proof-of-Publication и Validation". Хотя в названии не содержится прямого упоминания о валидации на стороне клиента, при внимательном прочтении становится ясно, что это одна из самых ранних работ, в которой представлена данная концепция.

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

Чтобы следовать мысли Питера Тодда, нам сначала нужно понять, какую проблему на самом деле решает Биткойн. По словам Питера Тодда, Биткойн решает три проблемы:

1. Доказательство публикации: Суть доказательства публикации заключается в решении проблемы двойного расходования средств. Например, если Алиса хочет перевести несколько биткоинов Бобу, то, хотя она и подписала транзакцию на перевод Бобу, Боб может физически не знать о существовании такой транзакции. Поэтому нам нужно публичное место для публикации транзакций, и все желающие смогут запрашивать транзакции оттуда.
2. Порядок консенсуса: В компьютерных системах физическое время, которое мы обычно ощущаем, не существует. В распределенных системах время часто представляет собой временные метки Lamport, которые не измеряют наше физическое время, а упорядочивают наши транзакции.
3. Проверка (необязательно): Валидация в Bitcoin включает в себя проверку подписей и сумм, переданных в транзакциях BTC. Однако Питер Тодд считает, что эта проверка не является необходимой для создания системы токенов поверх Биткойна; это просто вариант оптимизации.

На этом этапе Вы, возможно, вспомните OmniLayer, о котором мы говорили ранее. Сам OmniLayer не делегирует Bitcoin вычисление состояния и проверку, но он повторно использует безопасность Bitcoin. Colored Coins, с другой стороны, доверяет отслеживание состояния Биткойну. Существование этих двух систем уже продемонстрировало, что подтверждение не обязательно должно происходить на блокчейне.

Так как же проверка на стороне клиента эффективно проверяет транзакции?

Во-первых, давайте посмотрим, что нужно проверить:

1. Состояние (проверка логики транзакции)
2. Убедитесь, что входы (TxIn) действительны, чтобы предотвратить двойное расходование средств.

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

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

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

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

Но как мы можем хранить такое дерево обязательств в блокчейне? Именно здесь мы можем представить концепцию "одноразовой печати".

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

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

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

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

1. l: печать
2. m: сообщение, то есть информация или транзакция
3. w: свидетель, кто-то или что-то, что может подтвердить печать

Основные действия: Есть два основных действия:

1. Close(l, m) → w: Закройте печать l на сообщении m, создав свидетеля w.
2. Verify(l, w, m) → bool: Проверьте, была ли печать l закрыта для сообщения m.

Безопасность реализации одноразовой печати означает, что злоумышленник не сможет найти два разных сообщения m1 и m2, чтобы функция Verify вернула true для одной и той же печати.

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

Для активов на Bitcoin сам Bitcoin выступает в качестве "свидетеля" (w) для одноразовой печати. Это связано с тем, что для проверки транзакции Bitcoin узлы должны убедиться, что каждый вход транзакции ссылается на действительный и неизрасходованный UTXO. Если транзакция пытается дважды потратить UTXO, который уже был использован, правила консенсуса Биткойна и сеть честных узлов отклонят эту транзакцию.

Если говорить еще проще:

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

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

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

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

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

RGB, первопроходец в области CSV

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

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

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

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

Механизм обязательств, используемый в RGB, Pedersen Hash

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

Дизайн виртуальной машины для простоты RGB → AluVM

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

Направление масштабирования RGB layer2: Сеть Lightning или Sidechain?

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

RGB и сеть Lightning

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

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

RGB's Sidechain Prime

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

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. Протокол был спроектирован и разработан roasbeef, техническим директором Lightning Labs. Роасбиф, вероятно, единственный человек на планете, который лично руководил разработкой как клиента Bitcoin (BTCD), так и клиента Lightning Network (LND), демонстрируя глубокое понимание BTC.

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

Структура кодировки Taproot Assets выглядит следующим образом:

roasbeef, технический директор Lighting Labs

Кроме того, протокол активов CSV в Taproot Assets имеет более лаконичный дизайн по сравнению с RGB. Самое большое различие между Taproot Assets и RGB в плане масштабируемости приложений заключается в виртуальной машине выполнения: Taproot Assets использует ту же виртуальную машину TaprootScript, что и BTC по умолчанию. В последние годы многие исследования для BTC В последние годы многие исследования инфраструктуры для BTC были основаны на TapScript, но из-за медленного обновления BTC их невозможно применить за короткий период времени, поэтому можно предсказать, что Taproot Assets станет полигоном для этих свежих идей в будущем.

Различия между Taproot Assets и RGB

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

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

2. Исполняющая виртуальная машина

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

Однако RGB работает несколько иначе. Его виртуальная машина и правила проверки (SCHEMA) являются частью самодостаточной системы, образуя несколько замкнутую экосистему. RGB работает в рамках своей собственной экосистемы, и ее отношения с более широкой экосистемой Биткойна не такие тесные, как некоторые могут подумать. Например, что касается обновления Taproot, то единственное реальное взаимодействие RGB заключается в кодировании данных об обязательствах в блокчейн в Witness TapLeaf. Это показывает, что RGB и обновление Taproot связаны лишь минимально.

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

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

С другой стороны, Taproot Assets имеет более простой дизайн, но в настоящее время хранит только остатки активов и не обрабатывает более сложные состояния, что делает обсуждение смарт-контрактов преждевременным. Однако, по словам представителей Lightning Labs, в следующем году планируется сосредоточиться на разработке смарт-контрактов для Taproot Assets.

4. Центр синхронизации

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

В системе RGB эту роль выполняет Storm, который синхронизирует данные доказательства вне цепи через одноранговую (p2p) сеть. Однако по историческим причинам, связанным с командой разработчиков RGB, эти команды в настоящее время используют несовместимые форматы доказательств. Команда экосистемы RGB, DIBA, сообщила, что она разработает "карбонадо" для решения этой проблемы, но ход ее решения неясен.

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

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

Краткий взгляд на будущее масштабирования BTC

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

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

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

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

Где происходит проверка? Это очень важно.

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

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

1.Верификация на цепи (OP-ZKP)

Реализация OP-ZKP непосредственно в TaprootScriptVM наделит сам Биткойн способностью выполнять проверку ZKP. Это, в сочетании с некоторыми расчетными протоколами, разработанными компанией Covenant, может создать масштабируемое решение Zk-Rollup, которое унаследует безопасность Биткойна. Однако, в отличие от развертывания проверочного контракта в Ethereum, обновление Биткойна по своей природе происходит медленно, и добавление такого специализированного, потенциально требующего обновления оп-кода будет сопряжено с определенными трудностями.

2.Верификация на полуцепочке (BitVM)

Дизайн BitVM гарантирует, что он не предназначен для обычной логики транзакций. Робин Линус также заявил, что будущее BitVM заключается в создании свободного кросс-цепочечного рынка для различных SideChains. Подход BitVM считается полу-цепочечным, поскольку большинство вычислений при проверке будут происходить не на цепи, а вне ее. Основная причина разработки вокруг Taproot Биткойна заключается в том, чтобы использовать TapScriptVM для вычислительной проверки, когда это необходимо, теоретически наследуя безопасность Биткойна. Этот процесс также создает цепочку доверия при проверке, например, требуется только один честный верификатор среди 'n' верификаторов, что известно как Оптимистичные Свертки.

BitVM несет значительные накладные расходы на цепочку, но может ли он использовать доказательства мошенничества ZK для повышения эффективности? Ответ - нет, поскольку реализация доказательств мошенничества ZK зависит от возможности выполнить проверку ZKP на цепи, что возвращает нас к трудностям подхода OP-ZKP.

3.Верификация вне цепи (верификация на стороне клиента, Lightning Network)

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

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

Тенденция эволюции масштабирования

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

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

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