Аннотация

Эта статья рассматривает практические методы включения ZK-верификации в Bitcoin, охватывая темы, такие как модель UTXO Bitcoin, ограничения скриптов, Taproot, OP_CAT, BitVM и Chain State Proofs. Она представляет четкий аргумент о том, что интеграция ZK в протокол Bitcoin неизбежна. Выделяются два потенциальных пути: один заключается в повторном введении операции OP_CAT для непосредственной поддержки верификации SNARK в сценариях Bitcoin — изменение, которое имеет высокую вероятность окончательного утверждения. Второй подход связан с BitVM, который включает доказательства мошенничества. Кроме того, предложение команды ZeroSync о Chain State Proofs направлено на снижение затрат на верификацию исторических данных для узловых клиентов.

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

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

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

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

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

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

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

1. Существенно улучшенная конфиденциальность: использование гомоморфного обязательства Петерсона к сумме транзакции и доказательства диапазона для значительного улучшения конфиденциальности пользователя (как это делается в сайдчейне Element от Blockstream); использование связываемых подписей (как в Monero) для скрытия следов транзакций; достижение действительно конфиденциальных транзакций (как в Zcash).

2. Улучшить пропускную способность транзакций

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

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

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

Важно отметить, что у Биткойна нет глобального состояния, как у Эфириума, особенно отсутствует состояние учетной записи; у него есть только данные о выходных транзакциях. У каждого выхода транзакции есть два состояния: либо он был потрачен получателем, либо остается неизрасходованным. Неизрасходованные выходы транзакций (UTXO) - это то, с чем мы знакомы. Помимо связанной суммы BTC, у каждого выхода транзакции также есть прикрепленный сценарий, написанный на языке Bitcoin Script. Кто может предоставить правильное доказательство (свидетельство) этому сценарию, может потратить UTXO.

Bitcoin Script — это стековый язык программирования с серией опкодов. Программы, подключенные к UTXO, часто состоят из нескольких кодов операций, выполняющих вычисления на основе стека и возвращающих ему результаты. Многие распространенные скрипты Биткойна существовали с момента его создания. Например, самый распространенный скрипт состоит из открытого ключа и опкода, который проверяет цифровую подпись. Этот опкод требует, чтобы для траты или разблокировки UTXO необходимо предоставить цифровую подпись, соответствующую открытому ключу.

Рекомендуемая литература: [Подход к BTC: Основные знания для понимания BitVM (1)]

Возможности Bitcoin Script

Что может сделать Bitcoin Script:

• Переставьте стек и выполните проверку на равенство (для проверки определенных условий и обеспечения безопасности и правильности транзакции).
• Выполняйте условные операции, аналогичные операторам if-else.
• Выполнять ограниченные арифметические операции над 32-битными числами, такие как сложение и вычитание.
• Хешировать данные и проверять подписи ECDSA и Schnorr.

Что не может делать скрипт биткойна:

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

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

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

Так почему бы просто не изменить протокол Bitcoin, чтобы добавить более мощные операции? Как уже упоминалось ранее, достижение мажоритарного согласия по новым правилам протокола является крайне сложной задачей. У Bitcoin отсутствует централизованный принимающий решения орган, и любое предложение по улучшению Bitcoin Script сталкивается с существенным сопротивлением со стороны заинтересованных сторон с разными взглядами. Нет эффективного способа определить консенсус сообщества в сети Bitcoin, и принудительное обновление без него может привести к разделению цепочки. Конечно, Bitcoin не является полностью неизменным. Самые последние обновления были SegWit в 2017 году и Taproot в 2021 году.

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

Кроме того, улучшения Taproot для Bitcoin могут быть классифицированы по следующим трем аспектам:

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

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

Третье, Taproot также добавил другие механизмы проектирования.

Учитывая предшествующий опыт Bitcoin с Taproot для интеграции более продвинутых функций, можно задаться вопросом, почему не был введен выделенный opcode для проверки SNARK. Основное отличие заключается в сложности и консенсусе, необходимых для OP_SNARK. В отличие от Taproot, у которого было четкое, простое проектирование, получившее широкую поддержку, предложения по OP_SNARK значительно отличаются друг от друга, что затрудняет объединение сообщества вокруг одного подхода. Если бы это было реализовано, каждый узел Bitcoin должен был бы поддерживать этот конкретный метод проверки SNARK, что значительно увеличило бы технические требования. Кроме того, встроенная сложность OP_SNARK является серьезным препятствием - Taproot добавил около 1600 строк кода, что управляемо для стандартов сообщества, тогда как OP_SNARK потребовал бы гораздо более сложного кодирования. Кроме того, определение того, кто будет оценивать активацию OP_SNARK и достижение консенсуса, когда немногие полностью понимают его тонкости, добавляет сложности. Учитывая эти проблемы, обновление OP_SNARK не вероятно в ближайшем будущем.

Однако, есть и другие способы проверки SNARKs в Bitcoin Script. Мы можем сделать Bitcoin скрипты более функциональными, добавив более простые операции, позволяющие людям реализовывать программы проверки SNARK в скриптах. Но на самом деле, написание программы проверки SNARK в языке Bitcoin script очень сложно. Поэтому исследовательская команда Blockstream разрабатывает язык программирования Simplicity, предназначенный для замены Bitcoin Script. Simplicity специально разработан для систем консенсуса блокчейна и не является полным по Тьюрингу, что облегчает статический анализ и формальную верификацию.

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

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

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

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

В кратце, Биткойн может сделать шаг к возможности проверки SNARK в сценариях, повторно введя простые операции, такие как OP_CAT. Дополнительно стоит упомянуть о недавнем предложении под названием "Great Script Restoration", которое повторно вводит операцию умножения и позволяет выполнять все арифметические операции с произвольной точностью.

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

В настоящее время блок Bitcoin может содержать до 4 МБ данных, при этом новые блоки добываются примерно каждые 10 минут. Большинство блоков заполнены скриптами Bitcoin и данными свидетелей (аналогично цифровым подписям). В среднем каждый блок может вместить от 7 000 до 10 000 подтверждений подписей, с максимумом около 80 000 подтверждений на блок. Для сравнения мой процессор Intel 2020 года занимает примерно 3.2 секунды на верификацию блока Bitcoin. Естественно, скорость верификации блока зависит от факторов, выходящих за пределы времени подтверждения подписи.

Кроме того, если транзакции Bitcoin в конечном итоге поддерживают доказательства нулевого разглашения (ZK), любое увеличение времени генерации транзакций может не вызвать серьезной озабоченности. Аппаратные кошельки, которые используются для долгосрочного хранения активов, обычно имеют экраны и компактные конструкции, сосредоточенные на хранении ключей и создании подписей. Эти кошельки обычно оснащены относительно низкопроизводительными ЦП, такими как двухъядерный процессор с тактовой частотой 240 МГц, но они эффективно обрабатывают транзакции Bitcoin.

Я провел небольшой опрос, в котором спросил у пользователей, какое максимальное время они готовы ждать, чтобы устройство подписи сгенерировало доказательство, и многие были готовы ждать дольше, особенно если были значительные выгоды. Так что если мы внедрим ZK в транзакции Bitcoin, то не должно быть больших проблем. Мы потратили много времени на обсуждение потенциальных изменений базового дизайна Bitcoin, но есть много приложений, которые могут быть разработаны без изменения самого Bitcoin. Одно из таких приложений, которое стоит упомянуть, это Chain State Proofs, которое связано с BitVM. Данный подход использует доказательства нулевого знания для проверки правильности хешей блоков.

Какое влияние оказывает эта технология на Биткойн? Во-первых, доказательства состояния цепи могут значительно сократить объем работы, связанной с синхронизацией и проверкой исторических данных Биткойна, что в свою очередь снижает затраты на обслуживание узла. В настоящее время синхронизация и проверка данных от блока генезиса до последнего блока занимает около 5 часов и 30 минут на устройстве высокого уровня и несколько дней на устройстве уровня Raspberry Pi. Доказательства состояния цепи могут значительно сократить этот процесс.

Во-вторых, доказательства состояния цепи играют ключевую роль в продвижении BitVM. Команда ZeroSync тщательно изучила доказательства состояния цепи и разработала упрощенную версию под названием "доказательства цепи заголовков". В этом подходе используются доказательства нулевого знания для проверки заголовков блоков Bitcoin, создавая "цепочку заголовков", охватывающую все 850 000 заголовков блоков в истории Bitcoin. Каждый заголовок блока хешируется для создания 80-байтового доказательства. Для проверки связанного доказательства работы этот метод требует двойных вычислений SHA-256 для каждого заголовка. ZeroSync использует STARKs для генерации этих доказательств цепи заголовков, что стоит около 4000 долларов для производства, в то время как проверка занимает всего около 3 секунд в моем браузере.

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

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

Теперь давайте посмотрим на BitVM. BitVM позволяет Биткойну верифицировать любую вычислительную задачу, обеспечивая оптимальный способ выполнения проверки SNARK без изменения протокола. BitVM преодолевает ограничения по размеру скриптов Биткойна с помощью двух методов. Во-первых, он использует структуру скрипта Taproot MerkleTree. Во-вторых, он использует схему хранения KV, к которой можно получить доступ из отдельных скриптов, что облегчает подключение к большому количеству скриптовых программ. Тем не менее, протокол Bitcoin не обеспечивает целостность этой схемы хранения KV. BitVM решает эту проблему, используя доказательства мошенничества для обнаружения вредоносных доказательств. Если Проверяющий делает недействительные заявления или использует неисправное хранилище KV, другие могут инициировать транзакцию в блокчейне Биткойна, чтобы сообщить о неправомерных действиях Доказывающего и конфисковать активы Доказывающего.

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

Читайте оригинальный контент здесь: https://www.youtube.com/watch?v=GrSCZmFuy7U

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

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