Taproot подходит к биткойнам: как это работает, его история и последствия

Подписи Taproot и Schnorr будут опубликованы в Биткойне в блоке 709,632. Это будет огромное фундаментальное достижение, которое будет продолжаться и в будущем. Прошло четыре года с тех пор, как в сети появился Segregated Witness, наше последнее крупное обновление протокола. Это столько же, сколько цикл сокращения в два раза!

Подумай об этом. Четыре года с момента запуска SegWit до запуска Taproot. Медленное, методичное терпение, как и должно быть. Но история Taproot / Schnorr уходит намного дальше этого.

История Taproot

Некоторым, кто был здесь какое-то время, это может показаться иронией, но первое упоминание о подписях Шнорра, о которых я знаю, было на самом деле от бывшего разработчика Bitcoin Core, ставшего разработчиком корпоративного блокчейна Майка Хирна. В 2012 году он воспитанный идея новой криптографической кривой в отношении пакетной проверки подписей, чтобы сделать проверку узла менее затратной в вычислительном отношении. В конечном итоге предлагаемая им схема зависела от подписей Шнорра.

Адам Бэк говорил о наивности схемы для создания адресов с несколькими подписями, которые в 2014 году выглядели как однопользовательские, с использованием подписей Шнорра. Даже Гэвин Андресен включил Шнорр вместо ECDSA в своем списке желаний, которые он внес бы в Биткойн, если бы мог взмахнуть волшебной палочкой.

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

Schnorr намного более эффективен и прост в обращении (из подписей можно добавлять, вычитать и т. Д., И, если все сделано правильно, они могут оставить пользователей с действительными подписями, когда они должны быть у них), чем ECDSA. Использование ECDSA было вопросом необходимости, а не желания в большинстве криптографических приложений на протяжении многих лет.

Меркелизированные абстрактные синтаксические деревья (MAST), Taproot-часть предстоящего обновления Taproot, имеют аналогичную давнюю историю. Я не могу найти цитату, но я совершенно отчетливо помню, как видел эту фразу, брошенную такими людьми, как Питер Тодд, на Bitcointalk.org примерно в 2013 или 2014 году.

Оригинальный BIP для МАЧТ было предложено Джонсоном Лау в 2016 году. Это предложение также вызвало некоторую активность примерно в 2017 году, когда Марк Фриденбах, BTCDrak и Калле Альм разделили его на два отдельных BIP (116 и 117) и расширил первоначальное предложение Лау.

MAST сидела в подвешенном состоянии в течение следующего года, пока Грег Максвелл не придумал первоначальную идею Taproot и опубликованный его в список рассылки bitcoin-dev. Его ключевая идея заключалась в том, что в любом случае контракта между несколькими участниками, который он мог придумать, существовал «оптимальный результат», при котором контракт мог быть урегулирован путем того, что каждый просто подписал соответствующий результат, вместо того, чтобы обеспечивать его исполнение с помощью более сложных сценариев и транзакций. Это основополагающее утверждение, на котором основан Taproot, то есть настройка дерева MAST на обычный ключ верхнего уровня, который можно потратить, не раскрывая, существует ли вообще дерево Меркла других условий расходов.

Последний небольшой отрезок этого урока истории начинается с того, что Питер Вюлле объявляет проект BIP для Schnorr и Taproot в тандеме со списком рассылки 6 мая 2019 г. К январю 2020 г. он был официально оформлен в БИПы 340, 341 и 342. С этого момента это было просто доработка мелких деталей на уровне реализации, некоторый период проверки, а затем долгая работа. битва за механизмы активации. Это приводит нас к моменту, который просто не может быть активирован.

Важность подписей Шнорра

Итак, что такого особенного в подписях Шнорра? Ну, для начала они делают транзакции меньше. Подпись ECDSA обычно имеет размер около 72 байтов для одной подписи в транзакции. Синхронизация подписей Шнорра составляет максимум 64 байта на подпись. Это примерно 12% -ная экономия в размере по сравнению с ECDSA для каждой подписи Шнорра. Это и прямая выгода для человека, использующего Schnorr, который будет платить меньше комиссионных, чем пользователь ECDSA, но это также прямая выгода для людей, не использующих Schnorr, поскольку для обработки и проверки чужого Schnorr требуется хранить немного меньше данных в блокчейне. подписи.

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

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

Еще одно значительное улучшение, которое вносит Шнорр, - это скрипты с несколькими подписями. Каждый адрес с несколькими подписями должен явно раскрывать все индивидуальные открытые ключи, задействованные в сценарии с несколькими подписями, во время расходования времени, и для каждого ключа, участвующего в процессе расходования, должна быть предоставлена ​​подпись. С математическими свойствами Шнорра открывается дверь для MuSig, стандарта с множественной подписью. Вы можете просто сложить ключи вместе и получить единый открытый ключ, который может быть подписан всеми частными ключами с использованием новых протоколов подписи. Джонас Ник из Blockstream протестированные MuSig2 занимает две минуты для один миллион участники многоподписного адреса должны подписать. Нельзя недооценивать улучшение масштабирования сценариев с несколькими подписями.

Этот огромный шаг вперед в области сценариев с мультиподписями также имеет огромное значение для профиля конфиденциальности и стоимости многочисленных приложений, созданных на базе Биткойна. Каналы Lightning на основе MuSig теперь могут сливаться со всем набором анонимных UTXO Schnorr/Taproot в цепочке, поскольку никто больше не сможет отличить тот факт, что они представляют собой выход с мультиподписью «два из двух».

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

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

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

Однако из-за линейных свойств Шнорра сигнатура адаптера так же проста, как взять единицу (скажем, число 9,300,030 30) и вычесть из нее значение (скажем, XNUMX). Как только сторона, имеющая подпись адаптера, узнает вычитаемое значение, они могут просто добавить его обратно и Вуаля, они снова имеют действительную подпись.

Последствия Taproot

Как уже говорилось выше, Taproot на самом деле, по сути, просто MAST, за исключением того, что он работает как P2SH (где вы хешируете скрипт или, в случае MAST, корень Меркла на вершине дерева скриптов), вы «настраиваете» Открытый ключ Шнорра у корня дерева Меркла.

Настройка работает из-за линейных свойств Шнорра - когда вы «настраиваете» открытый ключ с помощью корня Меркла (добавляете этот корень Меркла к общему ключу), вы можете просто добавить корень Меркла к исходному закрытому ключу и сгенерировать ключ расходов для новый измененный открытый ключ. То есть вы добавляете одно и то же как к общему, так и к закрытому ключу, и они по-прежнему являются действующей парой ключей. Это скрывает существование MAST-дерева, если только его ветвь не используется, но по сути это все еще просто MAST-дерево, только одно, предназначенное для более эффективного и конфиденциального использования.

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

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

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

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

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

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

Когда был реализован Segregated Witness, был создан новый раздел «свидетель» транзакции, в который были перемещены данные подписи. У данных-свидетелей был флаг версии, чтобы их можно было обновить до новых функций без использования неопределенных OP_CODE на базовом уровне для новых функций.

Именно так были реализованы Taproot / Schnorr. Транзакции с изолированным свидетелем используют нулевую версию свидетеля. Когда Taproot / Schnorr скоро выйдет в эфир, они будут использовать новую версию свидетеля, чтобы отличать их от старых транзакций Segregated Witness. Точно так же, как SegWit представил версии свидетелей, Taproot представляет «версию tapleaf» для сценариев, используемых в деревьях MAST для UTXO, использующих Taproot. Это не только позволяет скриптам, скрытым в MAST, обновляться без использования новых OP_CODE на базовом уровне, но также без необходимости обновлять версии свидетелей! Таким образом, Taproot был разработан, чтобы быть максимально эффективным для обновления в будущем без ограничения других несвязанных обновлений протокола.

Taproot предоставит множество различных вариантов использования. Для начала, все некооперативные пункты в канале Lightning, такие как штрафные ключи или временные рамки, позволяющие их использовать, могут быть похоронены под MAST с Taproot. Никто никогда не узнает, что они существуют, если их не нужно использовать, что еще больше скрывает, какие UTXO на самом деле являются каналами Lightning или нет.

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

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

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

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

Это действительно выигрыш во многих отношениях масштабируемости и полезности протокола Биткойн, который трудно передать из-за того, насколько тонкими и «несексуальными» являются некоторые из них. Но это не умаляет победы. Итак, все пристегиваются и готовы играть с новыми игрушками, которые нам скоро придется использовать, потому что Taproot уже близко!

Это гостевой пост Шиноби. Выраженные мнения являются полностью их собственными и не обязательно отражают мнение BTC Inc или Биткойн-журнал.

Источник: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer.