Автор оригинала: Янош Ник, Blockstream

Оригинальный текст составлен: Бай Дин, Фауст, Geek Web3

Аннотация: В этой статье кратко, но по существу указано, как заставить Биткойн поддерживать функцию проверки ZK. Конкретные затронутые темы включают функциональные дефекты биткойн-UTXO и скриптов, такие концепции, как Taproot и OP_CAT, а также BitVM и доказательство состояния цепочки. общее содержание. В статье выдвигается относительно четкая точка зрения:

Внедрение ZK в протокол Биткойн — неизбежная тенденция. Для этого есть два пути: один — разрешить сценариям Биткойна напрямую поддерживать проверку SNARK, для чего требуется помощь кода операции OP_CAT, и вероятность того, что OP_CAT в конечном итоге пройдет. очень высок; второй маршрут основан на BitVM, необходимо внедрить метод защиты от мошенничества, и команда ZeroSync также предложила Chain State Proofs, чтобы снизить стоимость проверки клиентом узла исторических данных.

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

Это восходит к историческому происхождению Биткойна. Когда Сатоши Накамото опубликовал официальный документ о Биткойне, он сказал: «Я работаю над совершенно новой системой электронных платежей. Эта система полностью P2P и не требует участия какой-либо третьей стороны». Этот отрывок был опубликован в списке рассылки Cypherpunks (группа обсуждения электронной почты, созданная в 1992 году группой криптографов и энтузиастов технологий, занимающихся защитой конфиденциальности и технологиями криптографии).

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

Чтобы решить проблему комиссий за транзакции, люди вложили много ресурсов в развитие сети Lightning. Но согласно статье, опубликованной в 2016 году, на практике Lightning Network могла поддерживать максимум десятки миллионов пользователей, не сумев реализовать свое видение глобальной платежной системы.

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

Хотя существуют некоторые клиенты-кошельки с функциями конфиденциальности, которые в определенной степени решают вышеуказанные проблемы, разработчики этих клиентов-кошельков сталкиваются с угрозами различного масштаба. Например, разработчики кошелька Samourai CoinJoin были арестованы ФБР в апреле 2024 года, а неделю спустя разработчики кошелька Wasabi закрыли свой координационный компонент CoinJoin. Очевидно, что эти так называемые конфиденциальные кошельки не совсем достойны доверия пользователей.

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

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

1. Значительно улучшить конфиденциальность: использовать гомоморфный Peterson для фиксации суммы транзакции и Range Proof, чтобы значительно улучшить конфиденциальность пользователей (как это сделано в боковой цепочке Element от Blockstream), скрыть следы транзакций с помощью связываемых подписей (например, Monero); Зкэш).

2. Повышение пропускной способности транзакций

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

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

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

Здесь следует отметить, что у Биткойна нет глобального состояния, такого как у Эфириума, особенно состояния без учетных записей, а есть только выходные данные транзакций. Вывод каждой транзакции имеет два состояния: потрачено получателем или неизрасходовано. Выход неизрасходованной транзакции — это знакомый UTXO.

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

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

Здесь мы суммируем функциональность Bitcoin Script. Во-первых, что может сделать биткойн-скрипт?

· Стек можно переупорядочить, можно выполнить проверку на равенство (используйте проверку на равенство, чтобы проверить, выполняются ли определенные условия, обеспечивая тем самым безопасность и достоверность транзакций), а также могут выполняться операции ветвления, аналогичные if-else.

· Может выполнять ограниченные арифметические операции с 32-битными числами, а именно сложение и вычитание.

· Данные можно хешировать, а также проверять подписи ECDSA и Шнорра.

Чего не может биткойн-скрипт?

· Здесь нет циклов, переходов и рекурсий, то есть он не является полным по Тьюрингу, и его возможности программирования весьма ограничены.

· Побитовые операции невозможны. Отсутствие опкодов для умножения и деления.

· Невозможно объединить элементы в стеке.

· Небольшая возможность читать и проверять данные транзакций в цепочке.

· Биткойн-скрипты не могут напрямую получить доступ к сумме каждой транзакции, и нет способа передать статус (UTXO используются одноразово, старые уничтожаются, а новые генерируются при каждом переводе).

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

Итак, может ли Bitcoin Script проверять SNARK? Хотя сценарий Биткойна теоретически не является полным по Тьюрингу, его основных операций достаточно для проверки любых вычислений. Однако на практике проверка SNARK по-прежнему недостижима, поскольку размер программы, необходимый для этапа проверки, превышает максимальный размер блока Биткойна в 4 МБ.

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

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

Итак, вернемся к предыдущему вопросу: почему мы не можем просто изменить протокол Биткойна и добавить более мощные коды операций?

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

Конечно, Биткойн не является полностью статичным: последними обновлениями были SegWit в 2017 году и Taproot в 2021 году.

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

Кроме того, улучшения Биткойна от Taproot в основном разделены на следующие три части:

Во-первых, Taproot снижает стоимость проверки скриптов с большим количеством выборочных ветвей, позволяя Биткойну поддерживать более сложные программы;

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

В-третьих, Taproot также добавила другие механические конструкции.

При этом, поскольку у Биткойна есть прецедент добавления более мощных функций, таких как Tarpoot, почему бы не добавить специальный код операции для проверки SNARK? Это связано с тем, что добавление так называемого кода операции OP_SNARK сильно отличается от обновления Taproot.

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

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

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

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

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

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

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

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

А помогает ли OP_CAT проверять SNARK в скриптах? Ответ в том, что это помогает, потому что поддержка проверки доказательств Меркла помогает проверять SNARK на основе FRI, и OP_CAT может это поддерживать. Раньше сценарии, участвующие в проверке SNARK, могли быть слишком большими, чтобы поместиться в блок Биткойн, но с помощью OP_CAT размер программы можно уменьшить.

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

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

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

В настоящее время блок Биткойн может содержать до 4 МБ данных, а поскольку ожидается, что блок будет добываться каждые 10 минут, почти все блоки могут быть заполнены биткойн-скриптами и свидетелями-свидетелями (аналогично цифровым подписям). В преобразованном виде каждый блок в настоящее время может содержать до 80 000 проверок подписей, а в среднем каждый блок поддерживает от 7 000 до 10 000 проверок подписей. Моему процессору Intel 2020 года требуется в среднем 3,2 секунды для проверки блока Биткойна. Конечно, на скорость проверки блоков влияет не только трудоемкая проверка подписи.

Кроме того, если транзакции Биткойн будут поддерживать ZKization в будущем, продление времени генерации транзакций не будет вредным. Аппаратные кошельки, используемые для долгосрочного хранения активов, обычно имеют экраны и невелики. Их функция — хранить ключи и генерировать подписи. Аппаратные кошельки обычно имеют слабый процессор, например двухъядерный процессор с частотой 240 МГц и определенным объемом памяти, который очень быстро реагирует при подписании транзакций биткойнов.

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

Выше мы потратили много времени на обсуждение того, как изменить базовую конструкцию Биткойна, но на самом деле существует множество сценариев применения, которые можно реализовать без изменения Биткойна. Здесь я хотел бы выделить приложение, связанное с BitVM — Chain State Proofs, которое в сочетании с ZK может доказать достоверность хеша блока.

Какие изменения эта технология принесла в Биткойн? Прежде всего, с помощью Chain State Proofs можно сжать рабочую нагрузку по синхронизации и проверке данных биткойн-календаря, что значительно снижает стоимость эксплуатации узлов. В настоящее время синхронизация и проверка последнего блока Биткойн из блока Genesis на устройстве с хорошим оборудованием занимает 5 часов 30 минут, а на устройстве уровня Raspberry Pi это займет несколько дней. Если будет введено государственное подтверждение, на этот раз. -процесс потребления может быть значительно сокращен. Во-вторых, подтверждение состояния цепочки — важная часть, которую можно использовать с BitVM и которая будет способствовать внедрению BitVM.

Команда ZeroSync провела углубленное исследование доказательств состояния цепочки и создала более легкие «доказательства цепочки заголовков». Это решение в сочетании с ZK доказывает только достоверность заголовка блока Биткойн, образуя таким образом «цепочку заголовков», содержащую все 850 000. заголовки блоков в истории биткойнов и генерирует 80-байтовый хэш для каждого заголовка блока.

Эта схема требует двойного расчета SHA-256 каждого заголовка блока Биткойн для проверки соответствующего доказательства PoW. ZeroSync использует STARK для генерации доказательства цепочки заголовков Биткойна. Стоимость создания доказательства составляет около 4000 долларов, а проверка доказательства с помощью моего браузера занимает всего 3 секунды.

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

Однако, несмотря на низкий уровень успеха этого сценария атаки, доказательство цепочки заголовков не может считаться надежным решением, если оно позволяет злоумышленнику украсть огромное количество BTC. Если мы хотим доказать полное состояние цепочки, нам нужно напрямую доказать, что все в блоке Биткойн действительно, включая ECDSA и проверку подписи Шнорра на основе эллиптических кривых secp256k1.

Исторические блоки Биткойна могут содержать 30 миллионов подписей каждый месяц, а история содержит в общей сложности 2,5 миллиарда подписных операций, а также большое количество операций SHA-256. Таким образом, сеть Биткойн генерирует около 7 ГБ блочных данных каждый месяц, а общий объем всех исторических данных превышает 650 ГБ. В действительности это число может быть в 2-3 раза.

Теперь давайте посмотрим на BitVM. BitVM позволяет Биткойну проверять любую вычислительную задачу и является лучшим способом добиться проверки SNARK без изменения протокола. BitVM использует два метода, чтобы обойти ограничение размера блока Биткойн на размер сценария. Во-первых, он использует структуру сценариев Taproot MerkleTree;

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

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

Многие в биткойн-сообществе воодушевлены потенциалом SNARK/STARK. Наиболее реальным методом достижения проверки SNARK в среднесрочной и долгосрочной перспективе, скорее всего, является BitVM, но для его эффективности на практике требуются дополнительные инвестиции в исследования и разработки;

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

Исходная ссылка