Биткоин: работа продолжается. Глава 11

Технические инновации из окопов

Перевод NADO Book by Sjors Provoost.

Проект перевода организован HypeCoinNews.

Taproot

Обзор

Эта часть посвящена Taproot: что это такое, чем интересно и как появилось.

Taproot — это обновление Биткоина, которое было предложено в 2018 году и развернуто в ноябре 2021 года. Этот софтфорк повышает конфиденциальность «смартконтрактов» и снижает комиссию за транзакции. Это достигается путем скрытия всех различных условий траты в дереве Меркла и отображения только того условия, которое в конечном итоге используется. Оно также внедряет подписи Шнорра, которые значительно упрощают сжатие подписей нескольких участников в одну. Оба этих нововведения приводят к меньшему использованию драгоценного пространства в блоке, снижению комиссий и повышению конфиденциальности.

Глава 11 Taproot (см. также) разъясняет и раскладывает его по полочкам — показывая все составные части, которые делают возможным использование Taproot - и обрисовывает в общих чертах, что он позволяет делать в Биткоине.

В главе 12 рассказывается о том, как был активирован софтфорк Taproot, и о дискуссиях вокруг него.

Taproot и подписи Шнорра

В этой главе мы впервые познакомимся с деревом Меркла, которое скрывает все различные условия расходования монет до тех пор, пока они не будут использованы. Это называется MAST (Merklized Abstract Syntax Trees). Далее мы объясним, как подписи Шнорра позволяют нам скрыть сам MAST, что еще больше повышает конфиденциальность. Мы рассмотрим более ранние предложения по MAST, в которых не было преимуществ подписей Шнорра, что, в свою очередь, хорошо иллюстрирует всю мощь Taproot. Наконец, мы отмечаем некоторые интересные вещи, которые позволяет Taproot.

Абстрактные синтаксические деревья Меркла

В главе 10 рассказывается, как программный форк Pay-to-Script-Hash (P2SH) 2012 года позволил скрыть содержимое скрипта до тех пор, пока монеты не будут израсходованы. С точки зрения приватности это намного лучше, чем сразу выкладывать скрипт в блокчейн. Однако, что прискорбно, когда вы тратите монеты, все ограничения, которые были наложены на транзакцию, становятся видны всем.

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

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

Именно здесь на помощь приходят абстрактные синтаксические деревья Меркла (Merklized Abstract Syntax Trees или MAST).

Дерево Меркла — это дерево хэшей скриптов, и оно определяет различные способы потратить биткоин. Представьте его вверх ногами, с корнем вверху и листьями внизу. Итак, если у вас есть список из четырех условий, вы строите дерево, начиная с этих четырех условий (или хэшей) внизу. Затем вы объединяете их в пары, в результате чего получается две группы хэшей. Далее они опять хэшируются вверх по дереву, пока не останется один хэш наверху, корень, который вы и публикуете: он используется для генерации адреса, на который отправляются монеты.

Позже, когда вы захотите их потратить, вы говорите: «Вот часть дерева, которую я хочу потратить», а затем используете этот скрипт. Вы также передаете хэш скрипта соседа, потому что скрипты идут парами; также вы даете хэш каждой другой точки дерева. Раскрывая скрипт и хэш соседнего листа, вы доказываете, что не изменяли скрипт. Это называется доказательством Меркла, которое мы более подробно объясняли в главе 6.

В нашем примере с четырьмя условиями дерево имеет три уровня в высоту. Поскольку вы уже раскрываете используемый скрипт, нет необходимости раскрывать его хэш. Остается открыть только два хэша: соседний лист вашего скрипта внизу и сосед его родителя (где дерево имеет ширину в два хэша). Сам родительский хэш не нужно раскрывать, потому что любой может вычислить его из двух предоставленных вами хэшей. В зависимости от скриптов для этого обычно требуется меньше данных, чем для исходных четырех скриптов, а все остальное вы держите в секрете. Имея 1024 скрипта, вам нужно поместить в блокчейн только тот, который вы использовали, плюс девять хэшей.

Деревья Меркла сейчас широко распространены: они используются в блоках, для обмена файлами, в BitTorrent и т.д. Их использование позволяет вам делиться только теми частями записанной в виде дерева сущности, которые вам нужны. В контексте Биткоина это может быть скрипт, который вы используете, чтобы потратить монеты, тогда как в контексте BitTorrent это может быть конкретное двухсекундное видео; ваш компьютер может принимать множество коротких фрагментов и уверенно хранить их на жестком диске, зная, что вы скачиваете действительно кусок фильма, а не какие-то мусорные данные. В обоих сценариях остальное остается хэшированным, и вы просто добавляете дополнительные данные, чтобы доказать, что они — скрипт или фрагмент видеофайла — находятся где-то в этом дереве.

Помимо сохранения секретности, использование MAST также менее затратно, потому что вам не нужно включать все возможные скрипты в блокчейн. Это особенно актуально для больших деревьев с большим количеством скриптов, которые могут понадобиться для «смарт-контракта». Блокчейн — дефицитный ресурс, а включение всего стоит дорого. Потратив монеты, вы должны раскрыть скрипт, который требует комиссий. С момента появления P2SH скрипт открывает именно тот, кто тратит. Без MAST тот, кто тратит монеты, должен был бы раскрыть все возможные скрипты, но с MAST ему нужно раскрыть только тот скрипт, который фактически использовался.

Скрытие MAST

Хотя деревья Меркла — хорошее решение, было бы еще лучше, если бы вы могли скрыть сам MAST. В идеале никто не должен знать даже то, что вы используете MAST.

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

Было бы неплохо иметь способ выразить это, используя только подпись — без скриптов или всего дерева. Это можно сделать, подправив ваш открытый ключ, как описано в BIP 341 (Taproot SegWit v1) Вместо того, чтобы сказать: «Отправьте эти монеты на мой открытый ключ», вы бы сказали: «Отправьте их на мой открытый ключ, плюс на открытый ключ моей мамы, плюс на этот MAST-ключ».

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

Шнорр

В главе 4 рассказывается о библиотеке libsecp256k1, а в мае 2021 года в нее добавилась поддержка BIP 340 (Шнорр). Это добавило в Bitcoin Core подписи Шнорра.

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

Поэтому множество юристов, инженеров и криптографов объединили усилия и попытались выяснить, есть ли способ покалечить алгоритм Шнорра настолько, чтобы он юридически не подпадал под действие патента, но все же работал. Результатом стал алгоритм подписи под названием Алгоритм цифровой подписи на эллиптических кривых (Elliptic Curve Digital Signature Algorithm или ECDSA), который представляет собой алгоритм для той эллиптической кривой, которую сейчас использует Биткоин и который реализуется в библиотеке libsecp. Хотя оба алгоритма - и Шнорра, и ECSDA - используют открытые и закрытые ключи для создания цифровых подписей, последний подразумевает несколько более сложный процесс.

Хотя ECDSA представляет собой изрядно запутанную версию подписей Шнорра, он был стандартизирован в 2005 году, и внедрен не менее чем в дюжину криптографических библиотек, включая OpenSSL. Итак, когда Сатоши нужно было выбрать криптографическую кривую для Биткоина, он выбрал ECDSA именно потому, что она не была запатентована и уже присутствовала в OpenSSL.

В целом, алгоритм Шнорра проще, чем ECDSA. Они используют одну и ту же эллиптическую кривую, но для создания подписи с ней приходится производить несколько иные вычисления. Так что это также означает, что правки для алгоритма Шнорра не так сложны, как, скажем, для первоначальной версии libsecp.

Первоначальная версия libsecp должна была представлять эллиптическую кривую, включая все операции, которые вы можете выполнять с кривой, такие как сложение и умножение, а затем реализовать алгоритм подписи ECDSA. Но для новой библиотеки вам просто нужно выполнить алгоритм подписи Шнорра, после чего можно пропустить или удалить всю ненужную математику.

Переход от ECDSA к алгоритму Шнорра это не очень большое изменение; при этом не меняется и не вводится совершенно новая эллиптическая кривая. Скорее, это переход к другому — и более простому — способу подписи.

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

Вдобавок ко всему, поскольку алгоритм Шнорра добавляется как софтфорк, его использование полностью добровольно. ECDSA никуда не денется.

Но почему Шнорр?

Простота — это здорово, но вся тяжелая работа по более сложной ECDSA уже сделана. Зачем утруждаться, что-то меняя? Еще до Taproot люди хотели добавить алгоритм Шнорра ради всех его возможностей. Но однажды участник Bitcoin Core и бывший технический директор Blockstream Грегори Максвелл придумал умный способ использования подписей Шнорра в сочетании с MAST.

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

public_key(private key + hash) == public_key(private_key) + public_key(hash)

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

Резервный ключ — это то, что входит в MAST. Если вы никогда его не используете, ничто в блокчейне не выдаст, что у вас есть резервный ключ. В обычных обстоятельствах вы бы использовали только первичный ключ, не раскрывая MAST или резервный ключ в нем.

Но как работает это сокрытие MAST? А вот тут-то и появляется алгоритм Шнорра. Шнорр позволяет вам взять этот MAST и спрятать его внутри вашего открытого ключа. Ваш кошелек добавляет корневой хэш MAST к вашему закрытому ключу, а затем вычисляет соответствующий измененный открытый ключ (в Taproot это называется tweaking, прим ред.). Этот измененный ключ — вы как раз и помещаете в блокчейн. Для внешнего мира это выглядит как самый обычный открытый ключ.

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

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

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

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

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

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

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

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

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

Предшествующие предложения MAST

Чтобы еще больше оценить Taproot, давайте совершим короткую экскурсию в прошлое.

Первое предложение MAST, BIP 114 представило новую версию SegWit. Оно было призвано обеспечить преимущества конфиденциальности, аналогичные предложению Taproot, и раскрывало только использованное условие расходов или скрипт.

Вместо введения новой версии SegWit второе предложение MAST, BIP 116, (MERKLEBRANCHVERIFY) добавило новый опкод MERKLEBRANCHVERIFY к существующей системе скриптов. Хотя конфиденциальность получалась одинаковой, реализация менялась.

Однако у обоих этих более ранних предложений MAST есть недостатки:

1. Как только вы потратите монеты, все поймут, что MAST существовало, даже если и не могут увидеть полное содержимое дерева.
2. В случае, когда все согласны, вы не можете просто игнорировать скрипт и поместить подписи в блокчейн: вам все равно нужно выбрать скрипт «мы все согласны» из дерева MAST и выполнить это условие, что тратит драгоценные байты блокчейна.

Прикрепляя корень MAST к открытому ключу Шнорра, вы, как было показано выше, решаете эти проблемы.

Погодите, есть кое-что еще…

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

Например, подписи M-из-N, так называемые мультиподписи, теперь можно реализовывать без скрипта, поскольку Taproot обеспечивает протоколы их объединения. При помощи пороговых подписей в ECDSA это было возможно и раньше, но, как и все до Шнорра, было очень сложно, а теперь стало несколько проще.

Для внешнего мира пороговая подпись выглядит как один открытый ключ и одна подпись. Для подписей M-из-M, например. 2-из-2, можно использовать алгоритм MuSig2. Для более общего M-из-N рекомендуемого алгоритма пока нет. Это не проблема, потому что алгоритм объединения ключей и подписей не нужно встраивать в протокол; протокол Биткоина просто должен поддерживать алгоритм Шнорра. Когда кто-то решит объединить подписи как-то иначе, результат будет выглядеть как единая подпись — не только для людей, но и для узлов. При этом могут быть проверены и отдельные подписи.

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

Кроме того, Lightning использует каналы, которые представляют собой монеты, защищенные двумя подписями, а с помощью Taproot:

1. Эти две подписи можно объединить в одну (например, с помощью MuSig2).
2. Скрипты, которые Lightning использует для обеспечения кооперативного поведения, могут быть скрыты в MAST, чтобы быть раскрытыми только в случае конфликта.

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

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

Поддержите проект(ы) на цепочке

HCN имеет две активные краудфандинговые компании на TallyCoin, которые собирают средства ончейн:

https://tallycoin.app/@hypecoinnews/

/send 100 [email protected]