Taproot близко, или Следующая ступень эволюции биткоина

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

Изначально Taproot спроектировал разработчик Bitcoin Core и бывший CTO компании Blockstream Грегори Максвелл. На данный момент ведущие представители сообщества разработчиков в лице Питера Велле, Энтони Тоунса, Джонсона Лау, Йонаса Ника, Эндрю Поэлстры, Тима Раффинга и Расти Рассела работают над имплементацией подписей Шнорра, которая включает в себя и технологию Taproot.

ForkLog предлагает вашему вниманию адаптированный перевод статьи Аарона ван Вирдума, опубликованной в Bitcoin Magazine, о принципах работы Taproot и почему это решение сделает биткоин сильнее.

P2SH

Все существующие биткоины «заперты» в скриптах; это несколько строчек кода в транзакции, определяющих, каким образом монеты могут быть потрачены в следующей транзакции. Необходимым условием для траты является подпись, подтверждающая право собственности на монеты. Тем не менее не стоит забывать о существовании временных меток [трата только после генерации определенного блока] и мультиподписей [трата только при условии авторизации достаточным числом приватных ключей].

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

С 2012 года только новый держатель биткоинов знает, как можно их потратить, а сторонние наблюдатели не осведомлены об условиях траты до ее реализации. Это стало возможным за счет реализации решения P2SH [pay to script hash], предполагающего включение в блокчейн лишь хешей скриптов. Это, казалось бы, случайное число определяет право собственности на монеты. В момент траты держатель раскрывает скрипт и ключ для расшифровки хеша одновременно. Затем каждый пользователь может использовать изначальный хеш для проверки истинности скрипта и исполнения условий траты.

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

MAST

Потенциальным решением этих недостатков стало абстрактное синтаксическое дерево на базе дерева Меркла [или MAST] для более эффективной обработки массивов данных. MAST предполагает генерацию отдельных хешей для каждого условия траты монет с последующем их включением в дерево Меркла, которое и производит единый хеш или так называемый корень Меркла. Последний и «запирает» монеты.

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

Тем не менее Taproot в комбинации с подписями Шнорра может и вовсе скрыть факт существования такого абстрактного синтаксического дерева.

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

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

Реализация подписей Шнорра в протоколе биткоина позволит агрегировать несколько подписей для одной транзакции в единую за счет заложенной в схеме линейной математики. Такой же подход можно применить для транзакций с мультиподписью: комбинируя публичные ключи и подписи в “пороговые публичные ключи” или “пороговые подписи”, можно сделать такие переводы неотличимыми от обычных.

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

Taproot

Taproot основан на следующем утверждении: любая MAST-конструкция, вне зависимости от уровня сложности, должна включать в себя условие, которое позволит всем участникам согласовать результат и подписать транзакцию вместе. Если Боб знает, что Алиса все равно получит доступ к средствам на следующей неделе, он может работать с ней сообща, чтобы подписать транзакцию вместе.

Таким образом Taproot по своей структуре напоминает MAST, но всегда предполагает наличие условия, позволяющего всем участникам работать сообща для осуществления траты: так называемое «совместное закрытие». Как только в игру вступают подписи Шнорра, концепция становится куда интересней.

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

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

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

Если же «совместное закрытие» оказалось невозможным, тогда можно раскрыть тот факт, что «пороговый публичный ключ» — это видоизмененная версия истинного публичного ключа.

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

Такое развитие событий предполагает слияние «порогового публичного ключа» с корнем Меркла, поскольку дерево Меркла содержит все возможные условия траты. При этом раскрывается лишь то условие, которое было соблюдено.

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

Graftroot

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

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

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

Вернемся к ситуации с Бобом и Алисой, которые могут осуществить трату средств при определенных условиях. У них есть опция «совместного закрытия», то есть Алиса может потратить монеты через неделю или же это может сделать Боб, если он задействует секретное число. В этом случае Боб и Алиса объединяют публичные ключи и создают «пороговый публичный ключ», который позволит им осуществить трату при наличии “пороговой подписи”. Последнюю создадут при непосредственной трате.

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

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

Проблемой решения Graftroot является его интерактивность. Участники должны контактировать друг с другом для подтверждения альтернативных скриптов до траты. Кроме того, они должны хранить «пороговые подписи» для каждого из этих скриптов, и при их потере, они лишатся запасных вариантов для траты в случае провала «совместного закрытия».

Вероятно, подписи Шнорра и Taproot будут активированы в рамках единого апгрейда, а Graftroot станет следующим шагом. При этом Segregated Witness позволяет сделать это в виде софтфорка за счет функции «управления версиями скриптов».

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

Подписывайтесь на новости ForkLog в Telegram: ForkLog Live — вся лента новостей, ForkLog — самые важные новости и опросы.