Биткойн — это децентрализованный, безопасный и заслуживающий доверия цифровой актив. Однако у нее есть существенные ограничения, которые не позволяют ей стать масштабируемой сетью для платежей и других приложений. Проблема масштабирования Биткойна вызывала беспокойство с момента его создания. Модель Bitcoin UTXO рассматривает каждую транзакцию как независимое событие, в результате чего получается система без состояния, в которой отсутствует способность выполнять сложные, зависящие от состояния вычисления. Таким образом, хотя Биткойн может выполнять простые сценарии и транзакции с несколькими подписями, ему трудно обеспечить сложные и динамические взаимодействия с контрактами, характерные для платформ блокчейнов с отслеживанием состояния. Эта проблема существенно ограничивает сферу применения децентрализованных приложений (dApps) и сложных финансовых инструментов, которые могут быть построены на основе Биткойна, в то время как платформы государственных моделей предоставляют более разнообразную среду для развертывания и выполнения многофункциональных смарт-контрактов.
Для расширения Биткойна в основном используются такие технологии, как каналы состояния, сайдчейны и проверка клиентов. Среди них государственные каналы предоставляют безопасные и разнообразные платежные решения, но они ограничены в своих возможностях проверять сколь угодно сложные расчеты. Это ограничение сокращает его использование в различных сценариях, требующих сложной условной логики и взаимодействий. Сайдчейны, хотя и поддерживают широкий спектр приложений и предоставляют разнообразные функциональные возможности помимо Биткойна, имеют более низкую безопасность. Эта разница в безопасности связана с тем, что сайдчейны используют независимые механизмы консенсуса, которые гораздо менее надежны, чем механизм консенсуса Биткойн. Проверка на стороне клиента с использованием модели Bitcoin UTXO может обрабатывать более сложные транзакции, но она не имеет возможности двустороннего ограничения контрольной суммы с Биткойном, что делает его безопасность ниже, чем у Биткойна. Офчейн-дизайн протоколов проверки клиентов опирается на серверную или облачную инфраструктуру, что может привести к централизации или потенциальной цензуре через скомпрометированные серверы. Офчейн-дизайн проверки на стороне клиента также усложняет инфраструктуру блокчейна, что потенциально может привести к проблемам масштабируемости.
В декабре 2023 года руководитель проекта ZeroSync Робин Линус опубликовал официальный документ под названием «BitVM: вычислить что-либо на биткойне», который заставил всех задуматься об улучшении программируемости биткойна. В этой статье предлагается решение контракта Биткойн, которое может достичь полноты по Тьюрингу без изменения консенсуса сети Биткойн, так что любые сложные вычисления могут быть проверены в Биткойне без изменения основных правил Биткойна. BitVM в полной мере использует Bitcoin Script и Taproot для достижения оптимистичного объединения. На основе подписи Лэмпорта (также известной как принятие битов) между двумя биткойн-UTXO устанавливается соединение для реализации биткойн-скриптов с сохранением состояния. Принимая участие в большой программе по адресу Taproot, операторы и валидаторы участвуют в обширных взаимодействиях вне цепочки, что приводит к небольшому объему работы в цепочке. Если обе стороны сотрудничают, можно выполнять произвольно сложные вычисления вне цепочки с сохранением состояния, не оставляя никаких следов в цепочке. Если обе стороны не сотрудничают, при возникновении спора требуется выполнение в цепочке. В результате BitVM значительно расширяет потенциальные варианты использования Биткойна, позволяя Биткойну служить не только валютой, но и платформой проверки для различных децентрализованных приложений и сложных вычислительных задач.
Однако, хотя технология BitVM имеет большие преимущества в расширении Биткойна, она все еще находится на ранней стадии, и все еще существуют некоторые проблемы с точки зрения эффективности и безопасности. Например: (1) Запросы и ответы требуют множественных взаимодействий, что приводит к дорогостоящим затратам на обработку и длительным циклам запроса; (2) Данные одноразовой подписи Лампорта имеют большую длину, и длину данных необходимо уменьшить; (3) Хеш-функция сложный и требует дружественной к Биткойну хеш-функции для снижения затрат; (4) Существующий контракт BitVM огромен, а емкость блока Биткойн ограничена. Меньше s можно использовать для реализации меньшего количества биткойнов BitVM, экономя пространство блоков Биткойн и повышая эффективность BitVM; (5 ) Существующая BitVM использует модель разрешения. Только члены альянса могут инициировать вызовы, и она ограничена только двумя сторонами. Ее следует расширить до модели многостороннего вызова без разрешений, чтобы еще больше уменьшить предположение о доверии. С этой целью в этой статье предлагаются некоторые идеи по оптимизации для дальнейшего повышения эффективности и безопасности BitVM.
2.Принцип BitVM
BitVM позиционируется как внесетевой контракт Биткойна и стремится продвигать функции контракта Биткойн. В настоящее время сценарии Биткойн полностью не сохраняют состояние, поэтому при выполнении сценария Биткойн его среда выполнения сбрасывается после каждого сценария. Не существует встроенного способа для сценария 1 и сценария 2 иметь одинаковое значение x, и Bitcoin Script не поддерживает это изначально. Тем не менее, вы все равно можете использовать существующие коды операций, чтобы сделать биткойн-скрипт сохраняющим состояние с помощью одноразовой подписи Лэмпорта.Например, вы можете заставить x в 1 и 2 иметь одно и то же значение. Участники могут быть оштрафованы, если подпишут противоречивые значения x. Вычисления программы BitVM происходят вне цепочки, а проверка результатов вычислений происходит внутри цепочки. Текущий блок Биткойн имеет ограничение в 1 МБ. Когда расчет проверки слишком сложен, технология OP может использоваться для принятия режима ответа на вызов для поддержки проверки расчета более высокой сложности.
Подобно Optimistic Rollup и предложению MATT (Merkelize All The Things), система BitVM основана на протоколах защиты от мошенничества и запрос-ответ, но не требует изменения консенсусных правил Биткойна. Базовые примитивы BitVM просты и в основном основаны на хэш-блокировках, временных блокировках и больших деревьях Taproot.
Доказывающее устройство фиксирует побайтно, но проверка всех вычислений в цепочке будет слишком дорогой. Итак, проверяющий выполняет ряд тщательно продуманных задач, чтобы лаконично опровергнуть ложные утверждения проверяющего. Доказывающие и валидаторы совместно предварительно подписывают серию транзакций запроса и ответа, которые используются для разрешения споров, обеспечивая универсальную вычислительную проверку Биткойна.
Ключевыми компонентами BitVM являются:
Обязательства по схемам: Испытатели и верификаторы компилируют программы в большие двоичные схемы. Доказывающее устройство фиксирует схему по адресу Taproot, и каждый листовой сценарий по этому адресу соответствует каждому логическому элементу в схеме. Ядро основано на фиксации битов для реализации фиксации логических вентилей и фиксации схемы.
Запрос и ответ: Доказывающие и проверяющие предварительно подписывают серию транзакций для реализации игры «вызов-ответ». В идеале это взаимодействие осуществляется вне блокчейна, но может также осуществляться и внутри блокчейна, когда проверяющий отказывается сотрудничать.
Неоднозначное наказание: Если доказывающий делает какое-либо неверное утверждение, он может забрать депозит доказывающего после успешного оспаривания его, чтобы предотвратить злонамеренное поведение доказывающего.
3.Оптимизация BitVM
###3.1 Уменьшить количество взаимодействий ОП на основе ЗК
В настоящее время существует два основных накопительных пакета: ZK Rollup и OP Rollup. Среди них ZK Rollups полагается на проверку действительности ZK Proof, то есть криптографическое доказательство правильного выполнения, а его безопасность зависит от предположения о вычислительной сложности; OP Rollups полагается на Fraud Proof, предполагая, что представленные состояния верны, устанавливая Период проверки обычно составляет 7 дней, и его безопасность предполагает, что хотя бы одна честная сторона в системе может обнаружить неправильное состояние и предоставить доказательства мошенничества. Предположим, что максимальное количество шагов программы вызова BitVM равно 2 ^{ 32 }, а требуемая память — 2 ^{ 32 }* 4 байта, что составляет около 17 ГБ. В худшем случае потребуется около 40 раундов вызова и ответа, около полугода, а общий размер скрипта составит около 150 КБ. В этой ситуации наблюдается серьезная нехватка стимулов, но на практике этого почти никогда не происходит.
Рассмотрите возможность использования доказательств с нулевым разглашением, чтобы уменьшить количество проблем с BitVM и тем самым повысить эффективность BitVM. Согласно теории доказательства с нулевым разглашением, если данные Data удовлетворяют алгоритму F, доказывается, что доказательство удовлетворяет алгоритму проверки Verify, то есть алгоритм проверки выдает True; если данные Data не удовлетворяют алгоритму F, доказано, что доказательство не удовлетворяет алгоритму проверки Verify, то есть алгоритм проверки выдает False. В системе BitVM, если претендент не распознает данные, представленные проверяющим, инициируется запрос.
Для алгоритма F используйте метод дихотомии, чтобы разбить его. Предположим, что для поиска точки ошибки требуется 2^n раз; если сложность алгоритма слишком высока, n будет большим, и его завершение займет много времени. Однако сложность алгоритма проверки Verify доказательства с нулевым разглашением фиксирована. Весь процесс доказательства и алгоритм проверки Verify является общедоступным, а выходные данные оказываются ложными. Преимущество доказательства с нулевым разглашением состоит в том, что вычислительная сложность, необходимая для открытия алгоритма проверки Verify, намного ниже, чем бинарный метод для открытия исходного алгоритма F. Таким образом, с помощью доказательства с нулевым разглашением BitVM больше не бросает вызов исходному алгоритму F, а алгоритму проверки Verify, сокращая количество раундов проверки и сокращая цикл проверки.
Наконец, хотя эффективность доказательства с нулевым разглашением и доказательства мошенничества зависит от разных предположений безопасности, их можно объединить для создания ZK Fraud Proof и реализации ZK Proof по требованию. В отличие от полного накопительного пакета ZK, для которого больше не требуется генерировать подтверждение ZK для каждого отдельного перехода состояний, модель по требованию делает подтверждение ZK необходимым только при наличии проблем, в то время как весь дизайн накопительного пакета по-прежнему оптимистичен. Таким образом, полученное состояние по-прежнему действительно по умолчанию, пока кто-нибудь его не оспорит. Если в определенном состоянии нет проблем, нет необходимости создавать какое-либо доказательство ZK. Однако если участник инициирует запрос, необходимо сгенерировать ZK Proof для корректности всех транзакций в блоке вызова. В будущем мы можем изучить создание ZK Fraud Proof для одной спорной инструкции, чтобы избежать постоянных вычислительных затрат на создание ZK Proof.
3.2 Одноразовая подпись, совместимая с биткойнами
В сети Биткойн транзакции, которые следуют правилам консенсуса, являются действительными транзакциями, но в дополнение к правилам консенсуса также вводятся правила стандартности. Биткойн-узлы пересылают только широковещательные стандартные транзакции, единственный способ упаковать действительные, но нестандартные транзакции — напрямую работать с майнерами.
Согласно правилам консенсуса, максимальный размер устаревших (не Segwit) транзакций составляет 1 МБ, что занимает весь блок. Но предел стандартности для устаревших транзакций составляет 100 КБ. Согласно правилам консенсуса, максимальный размер транзакции Segwit составляет 4 МБ, что является пределом веса. Однако предел стандартности транзакций Segwit составляет 400 КБ.
Подпись Лампорта является базовым компонентом BitVM. Она уменьшает длину подписи и открытого ключа, что помогает уменьшить объем данных транзакций и тем самым снизить комиссию за обработку. Одноразовая подпись Лэмпорта требует использования хеш-функции (например, функции односторонней перестановки f). В схеме одноразовой подписи Лэмпорта длина сообщения равна v бит, длина открытого ключа равна 2 v битам, а длина подписи также равна 2 v битам. Подпись и открытый ключ длинные и требуют большого количества газа для хранения. Следовательно, существует необходимость найти схемы подписи с аналогичными функциями для уменьшения длины подписи и открытого ключа. По сравнению с одноразовой подписью Лампорта, одноразовая подпись Винтерница значительно уменьшает длину подписи и открытого ключа, но увеличивает вычислительную сложность подписи и проверки подписи.
В схеме одноразовой подписи Винтерница специальная функция P используется для отображения v-битного сообщения в вектор s длины n. Значение каждого элемента в s равно {0,..., d}. Схема одноразовой подписи Лэмпорта представляет собой схему одноразовой подписи Винтерница в частном случае d = 1. В схеме одноразовой подписи Винтерница соотношение между n, d, v удовлетворяет условию: n≈v/log 2(d+ 1). Когда d= 15, существует n≈(v/4)+1. Для подписи Винтерница, содержащей n элементов, длина открытого ключа и длина подписи в 4 раза короче, чем в схеме одноразовой подписи Лэмпорта. Однако сложность проверки подписи возрастает в 4 раза. Использование d= 15, v= 160, f=ripemd 160(x) в BitVM для реализации одноразовой подписи Winternitz может уменьшить размер фиксации битов на 50 %, тем самым снижая комиссию за транзакцию BitVM как минимум на 50 %. В будущем, оптимизируя существующую реализацию биткойн-скрипта Winternitz, можно изучить более компактные схемы одноразовой подписи, выраженные в биткойн-скрипте.
3.3 Хэш-функции, дружественные к биткойнам
Согласно правилам консенсуса, максимальный размер P 2 TR составляет 10 КБ, а максимальный размер свидетеля P 2 TR равен максимальному размеру транзакции Segwit, который составляет 4 МБ. Однако верхний предел стандартности свидетеля P 2 TR составляет 400 КБ.
В настоящее время сеть Биткойн не поддерживает OP_CAT, а строковые строки не могут быть склеены для проверки пути Меркла. Следовательно, необходимо использовать существующие биткойн-скрипты для реализации биткойн-дружественной хэш-функции с оптимальным размером и размером свидетеля для поддержки функции проверки доказательства включения Меркла.
BLAKE 3 — это оптимизированная версия хеш-функции BLAKE 2, в которой представлен режим дерева Бао. По сравнению с BLAKE 2 на базе s количество этапов функции сжатия уменьшено с 10 до 7. Хэш-функция BLAKE 3 разделит входные данные на последовательные фрагменты размером 1024 байта, причем последний фрагмент может быть короче, но не пустым. Если имеется только один фрагмент, этот фрагмент является корневым узлом и единственным узлом дерева. Расположите эти фрагменты как конечные узлы двоичного дерева, а затем сжимайте каждый фрагмент независимо.
Когда BitVM используется для проверки сценария доказательства включения Меркла, входные данные хэш-операции состоят из двух 256-битных хеш-значений, то есть входные данные хеш-операции составляют 64 байта. При использовании хеш-функции BLAKE 3 эти 64 байта могут быть выделены в пределах одного фрагмента, и для всей хеш-операции BLAKE 3 необходимо только один раз применить функцию сжатия к одному фрагменту. В функции сжатия BLAKE 3 необходимо выполнить функцию округления 7 раз и функцию перестановки 6 раз.
В настоящее время в BitVM выполнены базовые операции, такие как XOR, модульное сложение и битовый сдвиг вправо на основе значений u 32, а хеш-функция BLAKE 3, реализованная с помощью биткойн-скрипта, может быть легко собрана. Используйте 4 отдельных байта в стеке для представления 32 слов для реализации 32 сложения, 32 побитовых операций XOR и 32 побитовых операций вращения, необходимых для BLAKE 3. Текущий биткойн-скрипт хеш-функции BLAKE 3 занимает около 100 КБ, чего достаточно для создания игрушечной версии BitVM.
Кроме того, эти коды BLAKE 3 можно разделить, что позволяет Verifier и Prover значительно сократить объем необходимых данных в цепочке, разделив выполнение игры «вызов-ответ» пополам, а не полностью. Наконец, используйте сценарий Биткойн для реализации хэш-функций, таких как Keccak-256 и Grøstl, выберите наиболее дружественную к Биткойну хеш-функцию и изучите другие новые хэш-функции, дружественные к Биткойну.
на 3,4 меньше с BitVM
less s — это метод выполнения смарт-контрактов вне сети с использованием подписей Шнорра. Концепция Scripless родилась из Mimblewimble, который не хранит постоянных данных, кроме ядра и его подписи.
Преимущества less — функциональность, конфиденциальность и эффективность.
**Особенности: **меньше s может увеличить объем и сложность смарт-контрактов. Возможности сценариев Биткойн ограничены количеством OP_CODES, включенных в сети, и меньше s перемещает спецификацию и выполнение смарт-контрактов из цепочки на обсуждение только среди участников контракта на проектирование, не дожидаясь включения разветвления сети Биткойн. Новый код операции.
**Конфиденциальность:**Перенос спецификации и исполнения смарт-контрактов из ончейн в офчейн повышает конфиденциальность. В цепочке многие детали контракта будут доступны всей сети, включая количество и адреса участников, а также сумму перевода. Перемещая смарт-контракты за пределы цепочки, сеть знает только то, что участники согласны с тем, что условия их контрактов соблюдены и базовые транзакции действительны.
**Эффективность: **less s минимизирует объем данных, проверенных и хранящихся в цепочке. За счет перемещения смарт-контрактов за пределы цепочки будут снижены комиссии за управление полными узлами, а также снизятся комиссии за транзакции для пользователей.
less s — это подход к разработке криптографических протоколов в Биткойне, который позволяет избежать необходимости выполнять явные смарт-контракты. Основная идея состоит в том, чтобы использовать криптографические алгоритмы для достижения желаемой функциональности, а не использовать сценарии для достижения этой функциональности. Сигнатуры адаптеров и мультиподписи являются исходными строительными блоками less s. Используя less s, вы можете совершать транзакции меньшего размера, чем обычные транзакции, и снижать комиссию за транзакцию.
С помощью less s можно использовать мультиподпись Шнорра и подпись адаптера, которая больше не предоставляет хеш-значения и хеш-прообразы, как решение BitVM, а также может реализовать фиксацию логического вентиля в схеме BitVM, тем самым экономя BitVM. пространство сценариев и повышение эффективности BitVM. Хотя существующая схема less s может уменьшить пространство сценария BitVM, она требует большого количества взаимодействия между проверяющей и проверяющей стороной для объединения открытого ключа. В будущем мы улучшим это решение и постараемся внедрить Scripless в конкретные функциональные модули BitVM.
3.5 Несанкционированный многосторонний вызов
Причина, по которой текущие вызовы BitVM требуют разрешения по умолчанию, заключается в том, что UTXO Биткойна может быть выполнен только один раз, что позволяет злонамеренному проверяющему «тратить» контракт, бросая вызов честному проверяющему. BitVM в настоящее время ограничен режимом двустороннего вызова. Доказывающий, который пытается совершить зло, может одновременно запустить вызов верификатору, которым он управляет, тем самым «растрачивая» контракт, делая злое действие успешным, а другие верификаторы не могут предотвратить такое поведение. Следовательно, на основе Биткойна необходимо изучить не требующий разрешения многосторонний протокол вызова OP, который может расширить существующую модель доверия BitVM «1 из n» до «1 из N». Среди них N намного больше, чем n. Кроме того, существует необходимость изучить и решить проблему претендентов, вступающих в сговор с доказывающими или злонамеренно оспаривающих «растраченные» контракты. В конечном итоге реализация протокола BitVM с меньшим доверием.
Несанкционированные многосторонние испытания, позволяющие любому участвовать без списка разрешений. Это означает, что пользователи могут выводить монеты из L2 без участия какой-либо доверенной третьей стороны. Кроме того, любой пользователь, желающий принять участие в протоколе проверки OP, может оспорить и удалить недействительные выводы средств.
Расширение BitVM до модели многостороннего вызова без разрешения требует решения следующих атак:
Атака Сивиллы: даже если злоумышленник подделывает несколько личных данных для участия в споре, одна честная сторона все равно может выиграть спор. Если затраты честной стороны на защиту правильного результата линейно связаны с количеством нападавших, то, когда в споре участвует большое количество нападающих, цена победы в споре становится нереальной и уязвимой для атак ведьм. В статье «Турниры без разрешения судей» предлагается революционный алгоритм разрешения споров: стоимость победы одного честного участника в споре увеличивается логарифмически с количеством противников, а не линейно.
Атака с задержкой: Злоумышленник или группа злоумышленников следуют определенной стратегии, чтобы предотвратить или задержать подтверждение правильных результатов (например, вывод активов на L1) на L1 и заставить честных проверяющих потратить комиссию L1. Эту проблему можно решить, потребовав от претендентов сделать ставку заранее. Если претендент начинает отложенную атаку, его ставка теряется. Однако если злоумышленник готов пожертвовать ставкой в определенных пределах ради проведения атаки с задержкой, должны быть приняты контрмеры для уменьшения воздействия атаки с задержкой. Алгоритм, предложенный в статье BoLD: Ограниченная задержка ликвидности в протоколе Rollup Challenge, делает так, что независимо от того, сколько залога готов потерять злоумышленник, атака в худшем случае может вызвать только определенный верхний предел задержки.
В будущем мы будем изучать модель многостороннего вызова BitVM без разрешения, которая соответствует характеристикам Биткойна и может противостоять вышеупомянутым проблемам атак.
4. Вывод
Исследование технологии BitVM только началось. В будущем будут изучены и реализованы дополнительные направления оптимизации для достижения расширения Биткойн и процветания экосистемы Биткойн.
Рекомендации
BitVM: вычисляйте что угодно на биткойнах
BitVM: Биткойн-контракты вне сети
Робин Лайнус на BitVM
[bitcoin-dev] BitVM: вычисляйте что угодно на биткойнах
Странная парочка: ZK и оптимистичные накопительные пакеты на дату масштабируемости
Каковы транзакции и лимиты Биткойна?
BIP-342: Проверка Taproot s
_linus/status/1765337186222686347
Аспирантура по прикладной криптографии.
BLAKE 3: одна функция, быстро везде
[bitcoin-dev] Реализация Blake 3 в Биткойне
Знакомство с less s
BitVM использует меньше s
Решения для задержки атак на накопительные пакеты
Представляем ДЭЙВА. Безопасная защита от ошибок Cartesi.
Атаки с задержкой на накопительные пакеты
Решения для задержки атак на накопительные пакеты - Arbitrum Research
Примечания к многопользовательским интерактивным вычислительным играм.
BoLD: ограниченная задержка ликвидности в протоколе Rollup Challenge
Турниры без разрешения судей
Исходная ссылка
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Анализ принципов BitVM и соображения по оптимизации
Первоисточник: Исследовательская группа Bitlayer.
Автор оригинала: Линнделл, Мутуренд.
1. Введение
Биткойн — это децентрализованный, безопасный и заслуживающий доверия цифровой актив. Однако у нее есть существенные ограничения, которые не позволяют ей стать масштабируемой сетью для платежей и других приложений. Проблема масштабирования Биткойна вызывала беспокойство с момента его создания. Модель Bitcoin UTXO рассматривает каждую транзакцию как независимое событие, в результате чего получается система без состояния, в которой отсутствует способность выполнять сложные, зависящие от состояния вычисления. Таким образом, хотя Биткойн может выполнять простые сценарии и транзакции с несколькими подписями, ему трудно обеспечить сложные и динамические взаимодействия с контрактами, характерные для платформ блокчейнов с отслеживанием состояния. Эта проблема существенно ограничивает сферу применения децентрализованных приложений (dApps) и сложных финансовых инструментов, которые могут быть построены на основе Биткойна, в то время как платформы государственных моделей предоставляют более разнообразную среду для развертывания и выполнения многофункциональных смарт-контрактов.
Для расширения Биткойна в основном используются такие технологии, как каналы состояния, сайдчейны и проверка клиентов. Среди них государственные каналы предоставляют безопасные и разнообразные платежные решения, но они ограничены в своих возможностях проверять сколь угодно сложные расчеты. Это ограничение сокращает его использование в различных сценариях, требующих сложной условной логики и взаимодействий. Сайдчейны, хотя и поддерживают широкий спектр приложений и предоставляют разнообразные функциональные возможности помимо Биткойна, имеют более низкую безопасность. Эта разница в безопасности связана с тем, что сайдчейны используют независимые механизмы консенсуса, которые гораздо менее надежны, чем механизм консенсуса Биткойн. Проверка на стороне клиента с использованием модели Bitcoin UTXO может обрабатывать более сложные транзакции, но она не имеет возможности двустороннего ограничения контрольной суммы с Биткойном, что делает его безопасность ниже, чем у Биткойна. Офчейн-дизайн протоколов проверки клиентов опирается на серверную или облачную инфраструктуру, что может привести к централизации или потенциальной цензуре через скомпрометированные серверы. Офчейн-дизайн проверки на стороне клиента также усложняет инфраструктуру блокчейна, что потенциально может привести к проблемам масштабируемости.
В декабре 2023 года руководитель проекта ZeroSync Робин Линус опубликовал официальный документ под названием «BitVM: вычислить что-либо на биткойне», который заставил всех задуматься об улучшении программируемости биткойна. В этой статье предлагается решение контракта Биткойн, которое может достичь полноты по Тьюрингу без изменения консенсуса сети Биткойн, так что любые сложные вычисления могут быть проверены в Биткойне без изменения основных правил Биткойна. BitVM в полной мере использует Bitcoin Script и Taproot для достижения оптимистичного объединения. На основе подписи Лэмпорта (также известной как принятие битов) между двумя биткойн-UTXO устанавливается соединение для реализации биткойн-скриптов с сохранением состояния. Принимая участие в большой программе по адресу Taproot, операторы и валидаторы участвуют в обширных взаимодействиях вне цепочки, что приводит к небольшому объему работы в цепочке. Если обе стороны сотрудничают, можно выполнять произвольно сложные вычисления вне цепочки с сохранением состояния, не оставляя никаких следов в цепочке. Если обе стороны не сотрудничают, при возникновении спора требуется выполнение в цепочке. В результате BitVM значительно расширяет потенциальные варианты использования Биткойна, позволяя Биткойну служить не только валютой, но и платформой проверки для различных децентрализованных приложений и сложных вычислительных задач.
Однако, хотя технология BitVM имеет большие преимущества в расширении Биткойна, она все еще находится на ранней стадии, и все еще существуют некоторые проблемы с точки зрения эффективности и безопасности. Например: (1) Запросы и ответы требуют множественных взаимодействий, что приводит к дорогостоящим затратам на обработку и длительным циклам запроса; (2) Данные одноразовой подписи Лампорта имеют большую длину, и длину данных необходимо уменьшить; (3) Хеш-функция сложный и требует дружественной к Биткойну хеш-функции для снижения затрат; (4) Существующий контракт BitVM огромен, а емкость блока Биткойн ограничена. Меньше s можно использовать для реализации меньшего количества биткойнов BitVM, экономя пространство блоков Биткойн и повышая эффективность BitVM; (5 ) Существующая BitVM использует модель разрешения. Только члены альянса могут инициировать вызовы, и она ограничена только двумя сторонами. Ее следует расширить до модели многостороннего вызова без разрешений, чтобы еще больше уменьшить предположение о доверии. С этой целью в этой статье предлагаются некоторые идеи по оптимизации для дальнейшего повышения эффективности и безопасности BitVM.
2.Принцип BitVM
BitVM позиционируется как внесетевой контракт Биткойна и стремится продвигать функции контракта Биткойн. В настоящее время сценарии Биткойн полностью не сохраняют состояние, поэтому при выполнении сценария Биткойн его среда выполнения сбрасывается после каждого сценария. Не существует встроенного способа для сценария 1 и сценария 2 иметь одинаковое значение x, и Bitcoin Script не поддерживает это изначально. Тем не менее, вы все равно можете использовать существующие коды операций, чтобы сделать биткойн-скрипт сохраняющим состояние с помощью одноразовой подписи Лэмпорта.Например, вы можете заставить x в 1 и 2 иметь одно и то же значение. Участники могут быть оштрафованы, если подпишут противоречивые значения x. Вычисления программы BitVM происходят вне цепочки, а проверка результатов вычислений происходит внутри цепочки. Текущий блок Биткойн имеет ограничение в 1 МБ. Когда расчет проверки слишком сложен, технология OP может использоваться для принятия режима ответа на вызов для поддержки проверки расчета более высокой сложности.
Подобно Optimistic Rollup и предложению MATT (Merkelize All The Things), система BitVM основана на протоколах защиты от мошенничества и запрос-ответ, но не требует изменения консенсусных правил Биткойна. Базовые примитивы BitVM просты и в основном основаны на хэш-блокировках, временных блокировках и больших деревьях Taproot.
Доказывающее устройство фиксирует побайтно, но проверка всех вычислений в цепочке будет слишком дорогой. Итак, проверяющий выполняет ряд тщательно продуманных задач, чтобы лаконично опровергнуть ложные утверждения проверяющего. Доказывающие и валидаторы совместно предварительно подписывают серию транзакций запроса и ответа, которые используются для разрешения споров, обеспечивая универсальную вычислительную проверку Биткойна.
Ключевыми компонентами BitVM являются:
3.Оптимизация BitVM
###3.1 Уменьшить количество взаимодействий ОП на основе ЗК
В настоящее время существует два основных накопительных пакета: ZK Rollup и OP Rollup. Среди них ZK Rollups полагается на проверку действительности ZK Proof, то есть криптографическое доказательство правильного выполнения, а его безопасность зависит от предположения о вычислительной сложности; OP Rollups полагается на Fraud Proof, предполагая, что представленные состояния верны, устанавливая Период проверки обычно составляет 7 дней, и его безопасность предполагает, что хотя бы одна честная сторона в системе может обнаружить неправильное состояние и предоставить доказательства мошенничества. Предположим, что максимальное количество шагов программы вызова BitVM равно 2 ^{ 32 }, а требуемая память — 2 ^{ 32 }* 4 байта, что составляет около 17 ГБ. В худшем случае потребуется около 40 раундов вызова и ответа, около полугода, а общий размер скрипта составит около 150 КБ. В этой ситуации наблюдается серьезная нехватка стимулов, но на практике этого почти никогда не происходит.
Рассмотрите возможность использования доказательств с нулевым разглашением, чтобы уменьшить количество проблем с BitVM и тем самым повысить эффективность BitVM. Согласно теории доказательства с нулевым разглашением, если данные Data удовлетворяют алгоритму F, доказывается, что доказательство удовлетворяет алгоритму проверки Verify, то есть алгоритм проверки выдает True; если данные Data не удовлетворяют алгоритму F, доказано, что доказательство не удовлетворяет алгоритму проверки Verify, то есть алгоритм проверки выдает False. В системе BitVM, если претендент не распознает данные, представленные проверяющим, инициируется запрос.
Для алгоритма F используйте метод дихотомии, чтобы разбить его. Предположим, что для поиска точки ошибки требуется 2^n раз; если сложность алгоритма слишком высока, n будет большим, и его завершение займет много времени. Однако сложность алгоритма проверки Verify доказательства с нулевым разглашением фиксирована. Весь процесс доказательства и алгоритм проверки Verify является общедоступным, а выходные данные оказываются ложными. Преимущество доказательства с нулевым разглашением состоит в том, что вычислительная сложность, необходимая для открытия алгоритма проверки Verify, намного ниже, чем бинарный метод для открытия исходного алгоритма F. Таким образом, с помощью доказательства с нулевым разглашением BitVM больше не бросает вызов исходному алгоритму F, а алгоритму проверки Verify, сокращая количество раундов проверки и сокращая цикл проверки.
Наконец, хотя эффективность доказательства с нулевым разглашением и доказательства мошенничества зависит от разных предположений безопасности, их можно объединить для создания ZK Fraud Proof и реализации ZK Proof по требованию. В отличие от полного накопительного пакета ZK, для которого больше не требуется генерировать подтверждение ZK для каждого отдельного перехода состояний, модель по требованию делает подтверждение ZK необходимым только при наличии проблем, в то время как весь дизайн накопительного пакета по-прежнему оптимистичен. Таким образом, полученное состояние по-прежнему действительно по умолчанию, пока кто-нибудь его не оспорит. Если в определенном состоянии нет проблем, нет необходимости создавать какое-либо доказательство ZK. Однако если участник инициирует запрос, необходимо сгенерировать ZK Proof для корректности всех транзакций в блоке вызова. В будущем мы можем изучить создание ZK Fraud Proof для одной спорной инструкции, чтобы избежать постоянных вычислительных затрат на создание ZK Proof.
3.2 Одноразовая подпись, совместимая с биткойнами
В сети Биткойн транзакции, которые следуют правилам консенсуса, являются действительными транзакциями, но в дополнение к правилам консенсуса также вводятся правила стандартности. Биткойн-узлы пересылают только широковещательные стандартные транзакции, единственный способ упаковать действительные, но нестандартные транзакции — напрямую работать с майнерами.
Согласно правилам консенсуса, максимальный размер устаревших (не Segwit) транзакций составляет 1 МБ, что занимает весь блок. Но предел стандартности для устаревших транзакций составляет 100 КБ. Согласно правилам консенсуса, максимальный размер транзакции Segwit составляет 4 МБ, что является пределом веса. Однако предел стандартности транзакций Segwit составляет 400 КБ.
Подпись Лампорта является базовым компонентом BitVM. Она уменьшает длину подписи и открытого ключа, что помогает уменьшить объем данных транзакций и тем самым снизить комиссию за обработку. Одноразовая подпись Лэмпорта требует использования хеш-функции (например, функции односторонней перестановки f). В схеме одноразовой подписи Лэмпорта длина сообщения равна v бит, длина открытого ключа равна 2 v битам, а длина подписи также равна 2 v битам. Подпись и открытый ключ длинные и требуют большого количества газа для хранения. Следовательно, существует необходимость найти схемы подписи с аналогичными функциями для уменьшения длины подписи и открытого ключа. По сравнению с одноразовой подписью Лампорта, одноразовая подпись Винтерница значительно уменьшает длину подписи и открытого ключа, но увеличивает вычислительную сложность подписи и проверки подписи.
В схеме одноразовой подписи Винтерница специальная функция P используется для отображения v-битного сообщения в вектор s длины n. Значение каждого элемента в s равно {0,..., d}. Схема одноразовой подписи Лэмпорта представляет собой схему одноразовой подписи Винтерница в частном случае d = 1. В схеме одноразовой подписи Винтерница соотношение между n, d, v удовлетворяет условию: n≈v/log 2(d+ 1). Когда d= 15, существует n≈(v/4)+1. Для подписи Винтерница, содержащей n элементов, длина открытого ключа и длина подписи в 4 раза короче, чем в схеме одноразовой подписи Лэмпорта. Однако сложность проверки подписи возрастает в 4 раза. Использование d= 15, v= 160, f=ripemd 160(x) в BitVM для реализации одноразовой подписи Winternitz может уменьшить размер фиксации битов на 50 %, тем самым снижая комиссию за транзакцию BitVM как минимум на 50 %. В будущем, оптимизируя существующую реализацию биткойн-скрипта Winternitz, можно изучить более компактные схемы одноразовой подписи, выраженные в биткойн-скрипте.
3.3 Хэш-функции, дружественные к биткойнам
Согласно правилам консенсуса, максимальный размер P 2 TR составляет 10 КБ, а максимальный размер свидетеля P 2 TR равен максимальному размеру транзакции Segwit, который составляет 4 МБ. Однако верхний предел стандартности свидетеля P 2 TR составляет 400 КБ.
В настоящее время сеть Биткойн не поддерживает OP_CAT, а строковые строки не могут быть склеены для проверки пути Меркла. Следовательно, необходимо использовать существующие биткойн-скрипты для реализации биткойн-дружественной хэш-функции с оптимальным размером и размером свидетеля для поддержки функции проверки доказательства включения Меркла.
BLAKE 3 — это оптимизированная версия хеш-функции BLAKE 2, в которой представлен режим дерева Бао. По сравнению с BLAKE 2 на базе s количество этапов функции сжатия уменьшено с 10 до 7. Хэш-функция BLAKE 3 разделит входные данные на последовательные фрагменты размером 1024 байта, причем последний фрагмент может быть короче, но не пустым. Если имеется только один фрагмент, этот фрагмент является корневым узлом и единственным узлом дерева. Расположите эти фрагменты как конечные узлы двоичного дерева, а затем сжимайте каждый фрагмент независимо.
Когда BitVM используется для проверки сценария доказательства включения Меркла, входные данные хэш-операции состоят из двух 256-битных хеш-значений, то есть входные данные хеш-операции составляют 64 байта. При использовании хеш-функции BLAKE 3 эти 64 байта могут быть выделены в пределах одного фрагмента, и для всей хеш-операции BLAKE 3 необходимо только один раз применить функцию сжатия к одному фрагменту. В функции сжатия BLAKE 3 необходимо выполнить функцию округления 7 раз и функцию перестановки 6 раз.
В настоящее время в BitVM выполнены базовые операции, такие как XOR, модульное сложение и битовый сдвиг вправо на основе значений u 32, а хеш-функция BLAKE 3, реализованная с помощью биткойн-скрипта, может быть легко собрана. Используйте 4 отдельных байта в стеке для представления 32 слов для реализации 32 сложения, 32 побитовых операций XOR и 32 побитовых операций вращения, необходимых для BLAKE 3. Текущий биткойн-скрипт хеш-функции BLAKE 3 занимает около 100 КБ, чего достаточно для создания игрушечной версии BitVM.
Кроме того, эти коды BLAKE 3 можно разделить, что позволяет Verifier и Prover значительно сократить объем необходимых данных в цепочке, разделив выполнение игры «вызов-ответ» пополам, а не полностью. Наконец, используйте сценарий Биткойн для реализации хэш-функций, таких как Keccak-256 и Grøstl, выберите наиболее дружественную к Биткойну хеш-функцию и изучите другие новые хэш-функции, дружественные к Биткойну.
на 3,4 меньше с BitVM
less s — это метод выполнения смарт-контрактов вне сети с использованием подписей Шнорра. Концепция Scripless родилась из Mimblewimble, который не хранит постоянных данных, кроме ядра и его подписи.
Преимущества less — функциональность, конфиденциальность и эффективность.
less s — это подход к разработке криптографических протоколов в Биткойне, который позволяет избежать необходимости выполнять явные смарт-контракты. Основная идея состоит в том, чтобы использовать криптографические алгоритмы для достижения желаемой функциональности, а не использовать сценарии для достижения этой функциональности. Сигнатуры адаптеров и мультиподписи являются исходными строительными блоками less s. Используя less s, вы можете совершать транзакции меньшего размера, чем обычные транзакции, и снижать комиссию за транзакцию.
С помощью less s можно использовать мультиподпись Шнорра и подпись адаптера, которая больше не предоставляет хеш-значения и хеш-прообразы, как решение BitVM, а также может реализовать фиксацию логического вентиля в схеме BitVM, тем самым экономя BitVM. пространство сценариев и повышение эффективности BitVM. Хотя существующая схема less s может уменьшить пространство сценария BitVM, она требует большого количества взаимодействия между проверяющей и проверяющей стороной для объединения открытого ключа. В будущем мы улучшим это решение и постараемся внедрить Scripless в конкретные функциональные модули BitVM.
3.5 Несанкционированный многосторонний вызов
Причина, по которой текущие вызовы BitVM требуют разрешения по умолчанию, заключается в том, что UTXO Биткойна может быть выполнен только один раз, что позволяет злонамеренному проверяющему «тратить» контракт, бросая вызов честному проверяющему. BitVM в настоящее время ограничен режимом двустороннего вызова. Доказывающий, который пытается совершить зло, может одновременно запустить вызов верификатору, которым он управляет, тем самым «растрачивая» контракт, делая злое действие успешным, а другие верификаторы не могут предотвратить такое поведение. Следовательно, на основе Биткойна необходимо изучить не требующий разрешения многосторонний протокол вызова OP, который может расширить существующую модель доверия BitVM «1 из n» до «1 из N». Среди них N намного больше, чем n. Кроме того, существует необходимость изучить и решить проблему претендентов, вступающих в сговор с доказывающими или злонамеренно оспаривающих «растраченные» контракты. В конечном итоге реализация протокола BitVM с меньшим доверием.
Несанкционированные многосторонние испытания, позволяющие любому участвовать без списка разрешений. Это означает, что пользователи могут выводить монеты из L2 без участия какой-либо доверенной третьей стороны. Кроме того, любой пользователь, желающий принять участие в протоколе проверки OP, может оспорить и удалить недействительные выводы средств.
Расширение BitVM до модели многостороннего вызова без разрешения требует решения следующих атак:
В будущем мы будем изучать модель многостороннего вызова BitVM без разрешения, которая соответствует характеристикам Биткойна и может противостоять вышеупомянутым проблемам атак.
4. Вывод
Исследование технологии BitVM только началось. В будущем будут изучены и реализованы дополнительные направления оптимизации для достижения расширения Биткойн и процветания экосистемы Биткойн.
Рекомендации
Исходная ссылка