БиткойнУровень 2扩展Технический анализ：доказательство действительности与доказательство мошенничества

1 Введение

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

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

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

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

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

Кроме того, необходимо особенно обратить внимание на:

• Ключ к различению доказательства мошенничества и доказательства действительности не заключается в использовании систем доказательства ZK, таких как SNARK или STARK. Система доказательства ZK лишь выражает метод доказательства, в то время как мошенничество или действительность представляют собой содержание доказательства. Таким образом, сценарий 1 в таблице 1 называется доказательством действительности.
• доказательство действительности的时效性更好，但в блокчейне验证的复杂性较高；而доказательство мошенничества的в блокчейне验证复杂性较低，但时效性较差。
• Для случаев 2 и 4 в таблице 1 с помощью рекурсивных и комбинаторных методов ZK можно вычислить и сжать несколько fs, что приводит к значительным затратам на валидацию для вычислений в блокчейне.

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

Ограничения и прорывы в парадигме 2 BTC

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

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

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

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

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

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

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

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

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Это hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Это hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Значение Бит, на которое сейчас совершается обязательство, находится в стеке. Оно может быть “0” или “1”.

В настоящее время существует два способа реализации промиса Бит:

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

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

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

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

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

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

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

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

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

Рисунок 1: схема выхода разъема

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

2.5 Смарт-контракт: преодоление ограничений предварительной подписи

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

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

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

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

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

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

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

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

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

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

表 3：одиночный и многоразовый обмен

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

Для большинства вычислительных задач сети BTC signet, testnet и mainnet не могут полностью поддерживать скрипты размером 4 МБ, поэтому требуется использование технологии разделения скриптов. Это означает разделение полного вычислительного скрипта на блоки размером менее 4 МБ и их распределение по различным Tapleaf.

3.1 Биткойн多轮доказательство мошенничества

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

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

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

3.2 BTC的一轮доказательство мошенничества

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

Рис. 3: Одноколесное доказательство мошенничества

15 августа 2024 года Robin Linus опубликовал технический Вайтпейпер “BitVM2: Подключение BTC ко второму уровню”, в котором реализован кроссчейн мост, использующий метод обнаружения мошенничества в одном раунде, аналогичный показанному на рисунке 3.

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

OP_CAT является частью языка сценариев BTC при его выпуске, но был отключен из-за уязвимости в 2010 году. Тем не менее, сообщество BTC уже много лет обсуждает возможность повторного включения OP_CAT. В настоящее время OP_CAT имеет номер 347 и включен в сеть signet BTC.

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

• Контракт: Andrew Poelstra предложил CAT и Schnorr Tricks I, использование технологий OP_CAT и Schnorr для реализации контрактов на BTC. Алгоритм Schnorr - это цифровая подпись, применимая к типам P2TR-выходов; для других типов выходов можно использовать аналогичную технологию ECDSA, как показано в контракте, использующем CAT и ECDSA. С помощью контракта OP_CAT, алгоритм STARK-проверки можно разбить на несколько транзакций и последовательно проверить всё STARK-доказательство.
• Валидатор STARK: Основная функция валидатора STARK - связывание данных и хеширование. В отличие от алгебраических операций, хеш является встроенной операцией в BTC-скрипте, которая существенно снижает затраты. Например, OPSHA256 в оригинальной форме является отдельным операционным кодом, в то время как в симуляционной версии требуется сотни операционных кодов. Основные хеш-операции в STARK включают проверку Merkle-пути и преобразование Фиата-Шамира. Таким образом, операция OP_CAT очень дружественна к алгоритму валидатора STARK.

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

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

При наличии контракта OP_CAT верификатор STARK может быть разбит на несколько стандартных транзакций размером менее 400 КБ, что позволяет проверить всё доказательство действительности STARK без необходимости сотрудничать с Майнерами.

В этом разделе будет основное внимание уделено технике разделения BTC скрипта без введения или активации новых операционных кодов.

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

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

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

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

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

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

• Найти Алгоритм, который может оптимизировать локальность памяти, даже если это может увеличить некоторую вычислительную нагрузку, чтобы уменьшить количество ввода/вывода между блоками и, таким образом, Падение количество данных, необходимых для обязательства в assertTx транзакционном дизайне BitVM2, до 01928374656574839201.
• Используйте коммутативность соответствующих операций (например, логических операций), таких как x&y = y&x, чтобы сэкономить примерно половину пространства таблицы поиска.
• В настоящее время скрипт, оперирующий Fq12, имеет большой размер; можно рассмотреть использование схемы Фиата-Шамира, Шварца-Циппеля и схемы обязательства многочленов для значительного увеличения вычислительной сложности операций с Падение Fq12.

4 Сводка

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

Заявление:

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