1. Введение

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

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

В декабре 2023 года Робин Линус, руководитель проекта ZeroSync, опубликовал белую книгу под названием " БитVM: Вычислить что угодно на биткоине», который вызвал серьезные размышления об улучшении программируемости Биткойна. В статье предлагается полное по Тьюрингу решение для контрактов Биткойна, которое может выполнять любые сложные вычисления на Биткойне, не изменяя правила консенсуса сети или фундаментальные принципы Биткойна. BitVM использует скрипты Bitcoin и Taproot для реализации оптимистичных роллапов. Он использует подписи Lamport (также известные как битовая фиксация) для установления соединений между двумя биткойн-UTXO, что позволяет создавать биткойн-скрипты с отслеживанием состояния. Большая программа фиксируется в пределах адреса Taproot, а операторы и валидаторы участвуют в обширных взаимодействиях вне сети, оставляя минимальный след в блокчейне. Если обе стороны сотрудничают, любые сложные, отслеживающие состояние вычисления вне цепочки могут быть выполнены, не оставляя никаких следов в блокчейне. Однако, если стороны не сотрудничают, в случае возникновения спора требуется ончейн-исполнение. Таким образом, BitVM значительно расширяет потенциальные варианты использования биткоина, позволяя ему служить не только валютой, но и платформой верификации для различных децентрализованных приложений и сложных вычислительных задач.

Однако, несмотря на преимущества технологии БитVM в масштабировании биткоина, она все еще находится в начальной стадии и сталкивается с некоторыми проблемами эффективности и безопасности, такими как: (1) Вызовы и ответы требуют множества взаимодействий, что приводит к высоким транзакционным сборам и длительным периодам вызова; (2) Одноразовые подписи Лампорта имеют большую длину данных, что требует уменьшения размера данных; (3) Сложность хэш-функции требует использования хэш-функций, дружественных к биткоину, для снижения затрат; (4) Существующие контракты БитVM имеют большой объем, а ёмкость блока биткоина ограничена, поэтому использование безскриптовых сценариев могло бы помочь достичь безскриптовых сценариев БитVM, экономя место в блоке биткоина и улучшая эффективность БитVM; (5) Текущий БитVM работает по модели разрешений, вызовы инициируются только членами консорциума и ограничены двумя сторонами, что нужно расширить до модели вызова многих сторон без разрешения, чтобы еще больше снизить доверие к предположениям. Для решения этих проблем в статье предлагается несколько идей оптимизации для улучшения эффективности и безопасности БитVM.

2. Принцип BitVM

BitVM позиционируется как внеланцевая система контрактов для Bitcoin, направленная на расширение функциональности контрактов Bitcoin. В настоящее время скрипты Bitcoin полностью бессостоятельны, что означает, что окружение выполнения сбрасывается после каждого скрипта. В Bitcoin scripting нет способа гарантировать, что у скриптов 1 и 2 одинаковое значение x. Однако возможно сделать Bitcoin scripting состояний, используя существующие операции и одноразовые подписи Лампорта, обеспечивая, что x в script1 и script2 одинаковы. Если участники подписывают противоречивые значения x, их можно наказать.

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

Подобно Оптимистическому Rollup и предложению MATT (Merkelize All The Things), система BitVM основана на доказательствах мошенничества и протоколах вызова-ответа, но не требует изменений в правилах консенсуса Bitcoin. Основные примитивы BitVM просты, в основном основаны на хеш-блокировках, временных блокировках и крупных деревьях Taproot.

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

Основные компоненты BitVM включают:

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

3. БитVM Оптимизации

3.1 Уменьшить количество взаимодействий ОР на основе ZK

Существует два основных типа Rollups: ZK Rollups и Оптимистичные Rollups (OP Rollups). ZK Rollups полагаются на проверку допустимости доказательств нулевого знания (ZK), которые являются криптографическими доказательствами правильного выполнения. Их безопасность зависит от предположений о вычислительной сложности. Оптимистичные Rollups полагаются на Доказательства Мошенничества, предполагая, что все представленные состояния правильны и обычно устанавливают период испытания около семи дней. Их безопасность предполагает, что по крайней мере одна честная сторона в системе может обнаружить неправильное состояние и представить доказательство мошенничества.

Предполагая, что максимальное количество шагов для программы-вызова BitVM составляет 2^{32}, ей потребуется около 17 ГБ памяти (2^{32}×4 байта). В худшем случае примерно 40 раундов вызовов и ответов могут занять около шести месяцев, с общим размером скрипта около 150 КБ. Такой сценарий предоставил бы недостаточные стимулы, но это редко встречается на практике.

Использование доказательств с нулевым разглашением для уменьшения количества вызовов в BitVM может повысить его эффективность. Согласно теории доказательства с нулевым разглашением, если данные удовлетворяют алгоритму F, то доказательство удовлетворяет алгоритму верификации Verify, выдавая True. Напротив, если данные не удовлетворяют F, то доказательство не удовлетворит Verify, выдавая False. В системе BitVM, если вызывающая сторона не принимает данные доказывающего, инициируется вызов.

Для алгоритма F, используя метод двоичного поиска, предполагается, что для нахождения точки ошибки требуется 2^n итераций. Если сложность алгоритма слишком высока, n велико, и завершение занимает длительное время. Однако сложность алгоритма подтверждения доказательства Зеро-Знания Verify фиксирована. Публичное раскрытие доказательства и процесса подтверждения Verify позволяет увидеть вывод False. Преимущество доказательств Зеро-Знания заключается в меньшей вычислительной сложности, необходимой для открытия алгоритма подтверждения Verify по сравнению с открытием исходного алгоритма F с использованием двоичного поиска. Таким образом, с доказательствами Зеро-Знания, BitVM больше не представляет вызов для исходного алгоритма F, а скорее для алгоритма подтверждения Verify, сокращая количество раундов вызова и сокращая период вызова.

Хотя действительность доказательств о нулевом знании и доказательств о мошенничестве зависит от различных предположений о безопасности, их можно объединить для создания доказательства о мошенничестве ZK и реализации доказательства ZK по требованию. В отличие от полного ZK Rollup, модель по требованию требует доказательства ZK только при обжаловании, сохраняя оптимистичное проектирование, при котором считается, что сгенерированное состояние действительно, пока его не обжалуют. Если состояние не обжалуется, доказательство ZK не требуется. Однако если возникает оспаривание, необходимо сгенерировать доказательство ZK для правильности всех транзакций в оспариваемом блоке. В будущем возможно создание доказательств о мошенничестве ZK для отдельных оспариваемых инструкций, что позволит избежать вычислительных затрат на постоянное генерирование доказательств ZK.

3.2 Биткоин-дружелюбные одноразовые подписи

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

Согласно правилам консенсуса, максимальный размер транзакций для устаревших (нетехнологичных) (non-Segwit) составляет 1МБ, что может заполнить весь блок. Однако предельный лимит стандарта для устаревших транзакций установлен на уровне 100КБ. Для транзакций Segwit максимальный размер, разрешенный правилами консенсуса, составляет 4МБ, известный как предельный вес, но их предельный лимит стандарта - 400КБ.

Подписи Лампорта являются основополагающим компонентом BitVM, и уменьшение длины подписей и открытых ключей помогает уменьшить размер данных транзакции, тем самым уменьшая комиссии за транзакцию. Одноразовые подписи Лампорта требуют хэш-функции (как функции односторонней перестановки f). В схеме одноразовой подписи Лампорта длина сообщения составляет v бит, а длины как открытого ключа, так и подписи составляют 2v бит. Эти длинные подписи и открытые ключи потребляют значительное количество газа для хранения. Поэтому необходимо исследовать схемы подписей, которые могут уменьшить длину подписей и открытых ключей. По сравнению с одноразовыми подписями Лампорта, одноразовые подписи Винтерниц значительно уменьшают длины подписей и открытых ключей, но увеличивают вычислительную сложность подписания и проверки.

В схеме одноразовой подписи Уинтерниц, особая функция P отображает сообщение длиной v бит в вектор s длиной n, при этом каждый элемент s принимает значение в {0,…,d}. Схема одноразовой подписи Лампорта является особым случаем схемы Уинтерниц, где d=1. В схеме Уинтерниц, отношение между n, d и v приблизительно равно n≈v/log2(d+1). При d=15, n≈(v/4)+1. Для подписи Уинтерниц с n элементами, длина открытого ключа и подписи в четыре раза короче, чем в схеме одноразовой подписи Лампорта, но сложность проверки в четыре раза выше. Использование d=15, v=160, f=ripemd160(x) в BitVM для одноразовых подписей Уинтерниц может уменьшить размер битового обязательства на 50%, тем самым уменьшив комиссии за транзакции BitVM как минимум на 50%. В будущем, при оптимизации существующей реализации скрипта Биткойн для схемы Уинтерниц, можно исследовать более компактные схемы одноразовой подписи, представимые в скрипте Биткойн.

3.3 Биткойн-дружественные хеш-функции

Согласно правилам консенсуса, максимальный размер сценария P2TR составляет 10 кБ, а максимальный размер свидетельства сценария P2TR такой же, как максимальный размер транзакции Segwit, который составляет 4 МБ. Однако стандартный предел для свидетельства сценария P2TR составляет 400 кБ.

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

BLAKE3 - это оптимизированная версия хеш-функции BLAKE2 и вводит режим дерева Bao. По сравнению с BLAKE2s, количество раундов сжатия было сокращено с 10 до 7. Хеш-функция BLAKE3 разбивает входные данные на части по 1024 байта, причем последняя часть может быть короче, но не пустой. Когда есть только одна часть, она служит корневым узлом и единственным узлом дерева. Эти части упорядочены как листовые узлы бинарного дерева, и каждая часть сжимается независимо.

Когда используется BitVM для проверки доказательств включения Merkle, входные данные для хеширования состоят из двух конкатенированных 256-битных хеш-значений, общим объемом 64 байта. С хеш-функцией BLAKE3 эти 64 байта могут уместиться в одном чанке, что означает, что для выполнения хеш-операции BLAKE3 нужно применить функцию сжатия только один раз к этому одному чанку. Для функции сжатия BLAKE3 требуется семь раундовых функций и шесть перестановочных функций.

БитVM уже реализовал базовые операции, такие как XOR, модульное сложение и сдвиг вправо на основе значений u32, что облегчает сборку хэш-функции BLAKE3 с использованием сценария Bitcoin. Стек использует четыре отдельных байта для представления слов u32, облегчая сложение u32, побитовое исключающее ИЛИ u32 и побитовые вращения, необходимые для BLAKE3. Хэш-функция BLAKE3 в сценарии Bitcoin в настоящее время составляет около 100 КБ, что достаточно для создания игрушечной версии БитVM.

Кроме того, разделяя эти коды BLAKE3, Проверяющий и Доказывающий могут значительно сократить требования к данным on-chain, разделив выполнение на игру вызова и ответа вместо выполнения его полностью. Наконец, реализация хэш-функций, таких как Keccak-256 и Grøstl, в сценарии Bitcoin определит наиболее дружественную к Bitcoin хэш-функцию и исследует другие новые дружественные к Bitcoin хэш-функции.

3.4 Scriptless Scripts БитVM

Scriptless Scripts - это метод выполнения смарт-контрактов вне цепи блоков с использованием подписей Шнорра. Концепция Scriptless Scripts возникла из Mimblewimble, где кроме ядра и его подписи не хранится никаких постоянных данных.

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

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

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

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

3.5 Пермиссионлесс Мульти-парти Челленджес

Текущее вызов BitVM требует разрешения, потому что Bitcoin UTXO может быть выполнен только один раз, что приводит к ситуации, когда злоумышленный верификатор может «потратить» контракт, оспаривая честного доказателя. BitVM в настоящее время ограничен моделью вызова для двух сторон. Злоумышленный доказатель может использовать верификатора под своим контролем для инициирования вызова и «потратить» контракт, обеспечивая тем самым успешное осуществление своего злонамеренного действия, в то время как другие верификаторы не могут предотвратить это поведение. Поэтому, на основе Bitcoin, необходимо исследовать протокол вызова без разрешения для многопользовательского OP вызова, который может расширить существующую модель доверия 1-из-n BitVM до 1-из-N, где N намного больше, чем n. Кроме того, важно решить проблемы сговора между вызывающими лицами и доказателями или злонамеренными вызовами, которые «потребляют» контракты, чтобы добиться более децентрализованного протокола BitVM.

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

Расширение BitVM до модели безразрешения многопартийного вызова включает в себя решение следующих атак:

• Атаки Сибила: даже если злоумышленник создает несколько личностей, чтобы участвовать в вызове на спор, один честный участник все равно должен иметь возможность выиграть спор. Если стоимость для честного участника защищать правильный результат растет линейно с числом атакующих, стоимость для честного участника победить в споре становится непрактичной и уязвимой для атак Сибила при участии большого числа атакующих. Статья "BIT"Турниры без разрешения с судейским участиемпредлагает алгоритм разрешения споров, который меняет правила игры, где стоимость для одного честного участника, чтобы выиграть спор, растет логарифмически, а не линейно, с числом противников.
• Задержка атак: отдельное лицо или группа злонамеренных действующих лиц следуют стратегии, чтобы предотвратить или задержать подтверждение правильного результата (например, вывод активов на L1) на L1, заставляя честных доказателей тратить комиссию за транзакцию L1. Чтобы смягчить эту проблему, участникам может потребоваться внести авансовый залог. Если участник запускает атаку задержки, его залог будет конфискован. Однако, если злоумышленники готовы частично пожертвовать свой залог в целях осуществления задержки атак, должны быть стратегии по снижению воздействия этих атак. В предложенном в статье алгоритме “BoLD: Ограниченная задержка ликвидности в протоколе вызова Rollupгарантирует, что максимальная задержка, вызванная злоумышленником, ограничена, независимо от того, сколько стейк злоумышленник готов потерять.

В будущем будет исследование модели вызова BitVM с множеством сторон без разрешения, устойчивой к этим атакам и подходящей для характеристик биткоина.

4. Заключение

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

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

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