1 Введение

Для алгоритма f два взаимно недоверяющих участника, Алиса и Боб, могут установить доверие следующими способами:

1. Алиса вводит x, запускает алгоритм f и получает результат y. Боб также запускает алгоритм f с тем же входным значением x и получает y′. Если y = y′, то Боб подтверждает предоставленные Алисой данные x и вывод y. Это особый механизм доказательства действительности, широко используемый в консенсусе блокчейна, где Алиса является узлом, упаковывающим блок, а Боб - узлом, участвующим в консенсусе.
2. Алиса вводит x, запускает программу zk.prove на алгоритме f и получает результат y и доказательство proof. Боб запускает программу zk.verify на основе f, y и proof. Если результат истинный, то Боб подтверждает результат Алисы y; если результат ложный, то Боб не подтверждает результат Алисы y. Это доказательство действительности, где Боб может быть контрактом в сети.
3. Алиса вводит x, запускает алгоритм f и получает результат y. Боб также запускает алгоритм f с тем же вводом x, что приводит к y′. Если y = y′, то ничего не происходит; если y ≠ y′, то Боб бросает вызов Алисе, при этом вызванным программным обеспечением является f. Количество взаимодействий между Алисой и Бобом может быть одним или несколькими. Арбитраж достигается через процесс вызова-ответа. Это доказательство мошенничества, где Боб является вызывающим, слушая внецепочно и вызывая в цепочке.
4. Алиса вводит x, запускает программу zk.prove на алгоритме f и получает результат y и доказательство proof. Боб запускает программу zk.verify на основе f, y и proof. Если результат истинный, то ничего не происходит; если результат ложный, то Боб вызывает Алису, причем вызываемая программа - zk.verify. Количество взаимодействий между Алисой и Бобом может быть одним или несколькими. Арбитраж достигается через процесс вызова и ответа. Это доказательство мошенничества, где Боб является вызывающим, слушая оффчейн и вызывая на чейне.

Для вышеперечисленных 2, 3 и 4 пусть x будет транзакциями Уровня 2 и начальным состоянием, пусть f будет программой консенсуса Уровня 2, а y - конечным состоянием транзакции, соответствующей масштабируемому решению Уровня 2 для блокчейна. Среди них:

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

Таблица 1: Способы установления доверия

Кроме того, важно отметить:

• Ключ к различению между доказательствами мошенничества и доказательствами действительности заключается не в том, используются ли системы ZK proof, такие как SNARK/STARK. Система доказательства ZK выражает используемый метод доказательства, в то время как мошенничество или действительность представляют собой доказываемое содержание. Вот почему сценарий 1 в Таблице 1 считается доказательством действительности.
• Доказательства действительности имеют лучшую своевременность, но сложность проверки на цепи относительно высока; доказательства мошенничества имеют более низкую сложность проверки на цепи, но их своевременность относительно низкая.
• Для случаев 2 и 4 в Таблице 1, с использованием рекурсии и комбинаторных техник ZK, можно вычислить и сжать несколько f, что значительно снизит стоимость проверки вычислений вне цепи внутри цепи.

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

2 Ограничения и Прорывы в Парадигме Биткойна

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

2.1 Модель UTXO и ограничения сценария

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

1. Скрипты Bitcoin являются безсостоятельными;
2. Для типов выходных данных P2TR максимальное количество операционных кодов, которые можно разместить в одной транзакции, составляет около 4 миллионов, заполняя весь блок, в то время как для других типов выходных данных доступно только 10 000 операционных кодов;
3. Методы расходования одного UTXO ограничены, отсутствует исследование комбинированных методов расходования;
4. Гибкие функции контракта не поддерживаются;
5. Размер стека ограничен максимум до 1000 элементов (altstack + stack), а максимальный размер одного элемента составляет 520 байт;
6. Арифметические операции (такие как сложение и вычитание) ограничены 4-байтовыми элементами. Они не могут быть изменены на длинные элементы, такие как 20 байт или больше, которые необходимы для криптографических операций;
7. Опкоды типа OPMUL и OPCAT были отключены, и их моделирование с использованием существующих опкодов несет в себе чрезвычайно высокие издержки, например, моделирование хэша BLAKE3 с одним раундом при размере скрипта около 75K.

2.2 Битовое обязательство: преодоление ограничений состояния UTXO

В настоящее время сценарии Биткойна полностью не имеют состояния. При выполнении сценария Биткойна его среда выполнения сбрасывается после каждого сценария. Это приводит к невозможности нативной поддержки сценариев Bitcoin constraint 1 и 2 с одним и тем же значением x. Однако эту проблему можно обойти различными способами, основная идея которых заключается в подписи значения. Если для значения может быть создана подпись, можно достичь состояний сценариев Биткойна. То есть, проверяя подпись значения x в сценариях 1 и 2, можно обеспечить использование одного и того же значения x в обоих сценариях. Если есть конфликтующая подпись, что означает, что для одной и той же переменной x подписаны два разных значения, может быть применена штрафная мера. Это решение известно как бит-коммитмент.

Принцип фиксации бита относительно прост. Бит означает установку двух различных хэш-значений, hash0 и hash1, для каждого бита в сообщении, которое должно быть подписано. Если значение подписываемого бита равно 0, раскрывается преобразование preimage0 от hash0; если значение подписываемого бита равно 1, раскрывается preimage1 от hash1.

Если взять в качестве примера однобитовое сообщение m ∈{0,1}, то соответствующий сценарий разблокировки битовых обязательств представляет собой всего лишь некоторые прообразы: если значение бита равно 0, соответствующий сценарий разблокировки — preimage0—"0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"; Если значение бита равно 1, соответствующий сценарий разблокировки — preimage1—"0x47c31e611a3bd2f3a7a42207613046703fa27496". Таким образом, с помощью битового обязательства можно преодолеть ограничение UTXO без сохранения состояния и получить скрипты Биткойна с отслеживанием состояния, что делает возможными различные интересные новые функции.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Это hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Это hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Теперь значение битового коммитмента находится в стеке. Либо «0», либо «1».

В настоящее время существует 2 реализации обязательства бита:

• Одноразовая подпись Лампорта: Принцип относительно простой и требует только использования хэш-функций, что делает его подходящим для Биткойна. Для каждого бита в сообщении необходимо подтвердить два значения хэшей, что приводит к относительно большим данным подписи. Другими словами, для сообщения длиной v бит длина открытого ключа составляет 2v бит, а длина подписи — v бит.
• Одноразовая подпись Винтерница: По сравнению с подписями Лампорта значительно сокращает длину подписей и открытых ключей, но увеличивает сложность подписи и верификации. Эта схема позволяет гибко устанавливать различные длины цепочек хэшей d, тем самым балансируя длину и сложность. Например, установка d = 15 приводит к сокращению длины как открытого ключа, так и подписи примерно в 4 раза, но сложность верификации увеличится в 4 раза. Это, по сути, компромисс между стековым пространством Bitcoin и размером скрипта. Подписи Лампорта можно рассматривать как частный случай подписей Винтерница при d = 1.

В настоящее время в библиотеке BitVM2 реализованы подписи Winternitz на основе хеш-функции Blake3. Длина подписи, соответствующей одному биту, составляет около 26 байт. Таким образом, можно видеть, что введение состояния через битовое подтверждение затратно. Таким образом, в реализации BitVM2 сначала сообщение хешируется для получения 256-битного хеш-значения, а затем выполняется битовое подтверждение хеш-значения для экономии накладных расходов, вместо подтверждения каждого бита исходного более длинного сообщения напрямую.

2.3 Taproot: Преодоление ограничений пространства скриптов

Апгрейд Bitcoin Taproot soft fork, активированный в ноябре 2021 года, включает три предложения: подписи Schnorr (BIP 340), Taproot (BIP 341) и TapScript (BIP 342). Он вводит новый тип транзакции - транзакции Pay-to-Taproot (P2TR). Транзакции P2TR могут создавать более приватный, гибкий и масштабируемый формат транзакции, объединяя преимущества Taproot, MAST (Merkel Abstract Syntax Tree) и подписей Schnorr.

P2TR поддерживает два метода расходов: расходы в соответствии с ключевым путем или путем скрипта.

В соответствии с положениями Taproot (BIP 341), при расходовании средств через путь скрипта соответствующий путь Меркла не может превышать максимальную длину 128. Это означает, что количество створок в стержневом дереве не может превышать 2^128. С момента обновления SegWit в 2017 году сеть Биткойн измеряет размер блока в единицах веса, с максимальной поддержкой 4 миллиона единиц веса (примерно 4 МБ). Когда вывод P2TR осуществляется по пути к сценарию, он должен показать только один сценарий tapleaf, что означает, что блок упакован одним скриптом tapleaf. Это означает, что для транзакций P2TR размер скрипта, соответствующего каждому ответвлению, может составлять максимум около 4 МБ. Тем не менее, в соответствии с политикой Биткойна по умолчанию, многие узлы пересылают только транзакции размером менее 400 тысяч; Более крупные транзакции должны сотрудничать с майнерами, чтобы быть упакованными.

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

При создании проверяемых вычислений на основе P2TR размер соответствующего скрипта больше не ограничивается 4 МБ, а может быть разделен на несколько подфункций, распределенных по нескольким tapleafs, таким образом, преодолевая ограничение пространства скрипта в 4 МБ. Фактически, алгоритм проверки Groth16, реализованный в текущей версии BitVM2, имеет размер до 2 ГБ. Однако его можно разделить и распределить по примерно 1000 tapleafs, и путем комбинирования его с фиксацией бита можно ограничить согласованность между входами и выходами каждой подфункции, обеспечивая целостность и правильность всего вычисления.

2.4 Выход коннектора: преодоление ограничений метода расходования UTXO

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

Тем не менее, Бурак, основатель протокола Ark, умело использовал флаг SIGHASH для достижения вывода коннектора. В частности, Алиса может создать подпись для отправки своих BTC Бобу. Однако, поскольку подпись может фиксироваться для нескольких входов, Алиса может установить свою подпись условной: подпись действительна для транзакции Taketx тогда и только тогда, когда эта транзакция потребляет второй вход. Второй вход называется разъемом, соединяющим UTXO A и UTXO B. Другими словами, транзакция Taketx действительна тогда и только тогда, когда UTXO B не были потрачены Challengetx. Поэтому, уничтожив выход коннектора, эффективность транзакции Taketx может быть заблокирована.

Рисунок 1: Иллюстрация выходного разъема

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

2.5 Контракты: преодоление ограничений предварительного подписания

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

Текущие реализации контрактов могут быть разделены на две категории:

• Предварительное подписание: Основываясь на существующих возможностях скриптов Биткойна, заранее определенные контракты с ограниченной функциональностью создаются путем предварительного подписания. Это означает разработку и подписание всех возможных будущих транзакций заранее, привязку участников к определенным закрытым ключам и ставкам комиссии. Некоторые схемы даже требуют, чтобы участники генерировали краткосрочные закрытые ключи для всех предварительно подписанных транзакций. После завершения предварительного подписания эти краткосрочные закрытые ключи надежно удаляются, что не позволяет злоумышленникам получить их и украсть средства. Однако каждый раз, когда добавляется новый участник или обновляется операция, описанный выше процесс необходимо повторять, что приводит к высоким затратам на обслуживание. Например, Lightning Network достигает двухсторонних контрактов путем предварительного подписания и использует технологию Hash Time-Locked Contracts (HTLC) для реализации функций маршрутизации для нескольких двухсторонних контрактов, тем самым достигая стратегии масштабирования с минимальным доверием. Однако Lightning Network требует предварительного подписания нескольких транзакций и ограничена двумя сторонами, что делает ее несколько громоздкой; в BitVM1 сотни транзакций должны быть предварительно подписаны при каждой инициализации, в то время как в оптимизированном BitVM2 количество транзакций, которые необходимо предварительно подписать при каждой инициализации, также достигает десятков. Как в BitVM1, так и в BitVM2 только операторы, участвующие в предварительном подписании, имеют право на возмещение. Если в предварительном подписании участвуют n участников, и каждому участнику необходимо предварительно подписать m транзакций, то сложность предварительного подписания для каждого участника составит n*m.
• Введение опкодов контрактов: Введение новых опкодов функций контракта может значительно снизить сложность коммуникации и затраты на обслуживание между участниками контракта, тем самым вводя более гибкий метод реализации контракта для Биткойна. Например, OPCAT: используется для конкатенации байтовых строк. Хотя его функция очень проста, он очень мощный и может значительно снизить сложность BitVM; OPTXHASH: позволяет лучше детализировать действия в рамках контракта. При использовании в BitVM он может поддерживать больший набор операторов, тем самым значительно улучшая предположения о безопасности BitVM и сводя к минимуму доверие. Кроме того, метод предварительного подписания по своей сути означает, что операторы в BitVM могут принять только процесс возмещения, что приводит к снижению эффективности использования капитала; В то время как с помощью новых кодов контрактов можно напрямую выплачивать средства из пула фонда привязки выходным пользователям, что еще больше повышает эффективность капитала. Таким образом, гибкая контрактная модель позволит эффективно преодолеть традиционные ограничения предварительного подписания.

3 Биткойн Layer2 масштабирование: доказательства действительности и доказательства мошенничества

Как доказательство действительности, так и доказательство мошенничества могут использоваться для масштабирования Bitcoin на уровне 2, основные различия показаны в таблице 2.

Таблица 2: Доказательства действительности против доказательств мошенничества

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

Согласно количеству взаимодействий challenge-response между Алисой и Бобом, доказательства мошенничества можно разделить на однокруговые доказательства мошенничества и многоходовые доказательства мошенничества, как показано на рисунке 2.

Рисунок 2: Доказательства мошенничества за один раунд против доказательств мошенничества за несколько раундов

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

Таблица 3: Взаимодействие за один раунд против многоступенчатого взаимодействия

В парадигме масштабирования Bitcoin Layer2 BitVM1 принимает механизм многоходового доказательства мошенничества, в то время как BitVM2 использует механизм однократного доказательства мошенничества, а bitcoin-circle stark использует доказательства действительности. Из них BitVM1 и BitVM2 могут быть реализованы без внесения каких-либо изменений в протокол Bitcoin, в то время как bitcoin-circle stark требует введения новой операции OP_CAT.

Для большинства вычислительных задач сигнет Bitcoin, тестнет и главная сеть не могут полностью представлять 4МБ скрипта, что требует использования технологии разделения скриптов - т. е. разделения полного вычислительного скрипта на части меньше 4МБ, распределенные по различным tapleafs.

3.1 Многоходовые доказательства мошенничества на Биткойн

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

Ранняя белая бумага BitVM Робина Линуса (обычно называемая BitVM1) использовала многоступенчатые доказательства мошенничества. Предполагая, что каждый период вызова длится неделю и применяя метод бинарного поиска для нахождения проблемных участков вычислений, период ответа на вызов в цепи для проверяющего Groth16 может продлиться до 30 недель, что приводит к плохой своевременности. Хотя в настоящее время существуют команды, исследующие более эффективные методы n-ичного поиска, чем бинарный поиск, их своевременность все равно значительно ниже по сравнению с 2-недельным циклом в одноступенчатых доказательствах мошенничества.

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

3.2 Доказательства мошенничества в один раунд на Биткойне

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

Рисунок 3: Доказательство мошенничества одного раунда

15 августа 2024 года Робин Линус выпустил техническую белую книгу BitVM2: Bridging Bitcoin to Second Layers, в которой был реализован кросс-цепной мост с использованием метода доказательства мошенничества в один раунд, аналогичного показанному на рисунке 3.

3.3 Доказательства действительности на Биткойне с OP_CAT

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

Основная функция OP_CAT - объединить два элемента в стеке и поместить объединенный результат обратно в стек. Эта функциональность открывает возможность для контрактов и STARK-проверителей на Bitcoin:

• Контракты: Эндрю Пуэлстра предложил CAT и Schnorr Tricks I, используя техники OPCAT и Schnorr для реализации контрактов на Bitcoin. Алгоритм Schnorr является цифровой подписью для типов выходных данных P2TR; для других типов выходных данных можно использовать аналогичные техники ECDSA, как это видно в Covenants with CAT и ECDSA. С помощью контрактов OPCAT алгоритм проверки STARK Verifier можно разделить на несколько транзакций, постепенно проверяя всё доказательство STARK.
• STARK Verifier: STARK Verifier в основном соединяет данные вместе и хэширует их. В отличие от алгебраических операций, хэширование - это нативная операция сценария Bitcoin, которая может сэкономить значительное количество накладных расходов. Например, OPSHA256 - это один ОР-код в своей исходной форме, в то время как в имитированной версии требуется сотни тысяч ОР-кодов. Основные операции хэширования в STARK включают проверку Merkle-путей и преобразования Fiat-Shamir. Поэтому OPCAT очень дружелюбен к алгоритму STARK Verifier.

3.4 Технология разделения биткоин-скриптов

Несмотря на то, что вычислительная нагрузка, необходимая для запуска соответствующего алгоритма верификатора для проверки доказательства после доказательства SNARK/STARK, намного меньше, чем та, которая требуется для непосредственного выполнения исходного вычисления f, количество скрипта, необходимого при его преобразовании для реализации алгоритма верификатора в сценарии Биткойна, по-прежнему огромно. В настоящее время, основываясь на существующих опкодах Биткойна, оптимизированный размер скрипта верификатора Groth16 и размер скрипта верификатора Fflonk по-прежнему превышают 2 ГБ. Однако размер одного блока биткоина составляет всего 4 МБ, что делает невозможным запуск всего скрипта верификатора в рамках одного блока. Однако после обновления Taproot Биткойн поддерживает выполнение скриптов с помощью tapleaf, что позволяет разбивать сценарий верификатора на несколько частей, каждый из которых служит в качестве ответвления для создания дерева ответвления. Согласованность значений между блоками может быть обеспечена за счет выделения битов.

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

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

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

• Размер одиночного сценария куска не должен превышать 4 МБ и должен включать в себя скрипты обязательства битов ввода, подписи транзакций и другое пространство.
• Максимальный размер стека одного блока не должен превышать 1000. Таким образом, стек каждого блока должен сохранять только необходимые элементы, чтобы зарезервировать достаточно места для оптимизации размера скрипта, поскольку комиссии за транзакции Bitcoin не зависят от размера используемого стека.
• Сохранение бита в Bitcoin дорогостоящее. Поэтому количество битов ввода и вывода между двумя смежными фрагментами должно быть минимизировано, так как в настоящее время 1 бит соответствует 26 байтам.
• Для удобства аудита функциональность каждого блока должна быть максимально ясной.

В настоящее время методы разделения сценария можно разделить на следующие три основные категории:

• Автоматическое разделение: Этот метод использует подход к разделению, при котором размер скрипта составляет около 3 МБ, а размер стека сведен к минимуму в зависимости от размера стека и размера скрипта. Преимущества этого метода заключаются в том, что он не зависит от конкретных алгоритмов верификатора и может быть расширен до разбиения скриптов для любых вычислений. Недостатками являются: (1) весь логический блок должен быть помечен отдельно, например, OP_IF блоки кода, которые не могут быть разделены; в противном случае результат выполнения скрипта split будет некорректным; (2) результат выполнения блока может соответствовать нескольким элементам в стеке, что требует маркировки количества элементов стека, которые должны применить битовую фиксацию на основе фактической вычислительной логики; (3) удобочитаемость логической функциональности, реализованной каждым скриптом блока, оставляет желать лучшего, что затрудняет аудит; (4) Стек может содержать элементы, не нужные для следующего блока, что приводит к пустой трате места в стеке.
• Разделение функций: Этот метод разделяет на основе различных функциональных подфункций в вычислении, с ясными входными и выходными значениями для подфункций. При разделении скрипта также реализуются необходимые скрипты фиксации битов для каждого фрагмента, обеспечивая, что общий размер скрипта конечных фрагментов составляет менее 4 МБ, а размер стека составляет менее 1000. Преимущества: четкая функциональность, четкая логика для каждого фрагмента, хорошая читаемость и легкость аудита. Недостатки: выражение исходной логики вычислений может не соответствовать логике на уровне скрипта, а исходные функции подвычислений могут быть оптимальными, но не представлять оптимальность на уровне скрипта.
• Ручное разделение: В этом методе точки разделения не основаны на функциональных подфункциях, а задаются вручную. Это особенно подходит для случаев, когда размер одной подфункции превышает 4 МБ. Преимущества: он позволяет вручную разделять подфункции большого размера скрипта, например, связанные с вычислениями Fq12; Четкая логика для каждого блока, хорошая читабельность и простота аудита. Недостатки: ограниченные возможности ручной настройки, когда весь скрипт был оптимизирован, ранее заданные вручную точки разделения могут быть неоптимальными и их нужно будет перенастраивать.

Например, после нескольких раундов оптимизации размер скрипта проверяющего Groth16 был сокращен с примерно 7 ГБ до примерно 1,26 ГБ. Кроме этой общей оптимизации вычислений, каждый фрагмент также может быть оптимизирован индивидуально для полного использования места в стеке. Например, путем введения лучших алгоритмов на основе таблицы поиска и динамической загрузки и выгрузки таблицы поиска размер каждого фрагмента скрипта может быть дополнительно уменьшен.

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

• Ищите алгоритмы, которые оптимизируют локальность памяти, даже за счет некоторой вычислительной нагрузки, чтобы уменьшить количество ввода/вывода битов между фрагментами, тем самым уменьшив объем данных, необходимых для фиксации в конструкции assertTx транзакции BitVM2.
• Используйте коммутативность связанных операций (например, логических операций), таких как x&y = y&x, чтобы сэкономить почти половину таблицы поиска.
• В настоящее время размер скрипта, соответствующего операциям Fq12, большой; рассмотрите возможность использования схем Fiat-Shamir, Schwartz-Zipple и полиномиальных обязательств для значительного снижения вычислительной сложности операций расширения Fq12.

4 Основные сведения

Эта статья сначала представляет ограничения скриптов биткойна и обсуждает использование обязательств биткойна для преодоления ограничений состояния UTXO, использование Taproot для преодоления ограничений пространства скрипта, использование выходов коннектора для обхода ограничений метода потраты UTXO и использование контрактов для преодоления ограничений предварительного подписания. Затем она предоставляет всесторонний обзор и краткое изложение характеристик доказательств мошенничества и доказательств действительности, особенностей разрешенных и неразрешенных доказательств мошенничества, различий между однораундовыми и многораундовыми доказательствами мошенничества и технологии разделения скриптов биткойна.

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

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