Основы обновления Taproot

Вообще, обновление taproot это комплекс предложений по улучшению сети bitcoin, собранных вместе в обновлении BIP-341 (bitcoin implementation protocol). Впервые обсуждения этого обновления пошли в email-рассылке разработчиков еще в 2018 году. Сам BIP собран и опубликован в начале 2020.

BIP включает множество дополнений, но главные из них это MAST (Merklized Alternative Script Tree) (BIP114, BIP117) и подписи шнорра (BIP340). Но для того, чтобы понять их смысл – нужно немного теории.

Немного теории

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

Эти правила называются скриптами транзакции и состоят из двух частей – scriptSig (unlocking script) и scriptPubKey (locking script). В попытке потратить монеты – scriptSig + scriptPubKey выполняются как единая программа.

scriptPubKey описывает правила, по которым эти монеты можно получить. Обычно этот скрипт представляет из себя одну из стандартных форм. Ниже представлены самые распространенные:

pay2key (p2k) - самый старый вариант, оплата напрямую на публичный ключ

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

pay 2 public key hash (p2pkh) - оплата на хеш публичного ключа

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

pay 2 script hash (p2sh) - оплата на scriptHash

scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
scriptSig: ..signatures... <serialized script>

Есть еще, менее распространенные, или схожие (например P2WSH, который связан с segwit и является схожей с p2sh версией). Как видите scriptSig так же отличается у каждой версии, так как они работают в паре.

В примере есть фразы, начинающиеся с OP_ - это операторы bitcoin script, полный их список можно посмотреть в документации. Каждый оператор выполняет какое-то действие. Фразы в скобках – места, куда нужно подставить данные. Операции в script выполняются последовательно, результат операций заносится в стек, некоторые операторы могут брать данные из стека и что-то с ними делать. В результате успешного выполнения скрипта – стек будет пуст либо на выходе останется просто true. В противных случаях считается что скрипт завершился с ошибкой.

Возьмем для примера p2pkh. Когда вам поступают монеты на pubkey1, отправителю достаточно знать pubKeyHash, который можно получить из адреса. Получая его – он подставляет его в scriptPubKey и отправляет монеты с данным скриптом:

OP_DUP OP_HASH160 pubKeyHash(pubkey1) OP_EQUALVERIFY OP_CHECKSIG

Когда же вы хотите потратить монеты с pubkey1, вам необходимо выполнить полный скрипт (scriptSig + scriptPubKey)

<sig> <pubKey> OP_DUP OP_HASH160 pubKeyHash(pubkey1) OP_EQUALVERIFY OP_CHECKSIG

Добавить в стек <sig> <pubKey>, т.е. подпись текущей транзакции, и вставить свой pubkey1, тем самым клиент, а позже сеть – получит pubkeyHash(pubkey1), проверит что результат выполнения scriptPubKey входящей транзакции верен и отпустит монеты.

Рассмотрим еще один важный пример:

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
scriptSig: <любые данные>

В данном примере scriptPubkey содержит оператор OP_HASH256, который берет входные данные из стека (в процессе выполнения там будут данные из scriptSig) и хеширует их, далее в стек кладется хеш 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 и производится оператор OP_EQUAL. Не трудно догадаться, что суть этого скрипта сводится к поиску нужного хеша, при этом транзакция и правила отпуска монет содержатся в блокчейне открыто! Т.е. тот, у кого будут нужные данные, а именно – scriptSig транзакции будет содержать нужные данные, хеш которых равен  6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000  – сможет без труда потратить эти монеты. Т.е. нет никакой защиты, это может быть кто угодно. (к слову говоря это хеш от coinbase первой транзакции нулевого блока биткоина).

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

MAST

Эту проблему как раз и решает MAST. Вообще, mast это дерево, основанное на технологии merkle tree.

Придется сделать еще одно техническое отступление, чтобы объяснить принцип работы merkle tree.

Еще одно отступление

В bitcoin (как и в других криптовалютах) уже используется merkle tree. Это параметр merkle root из заголовка каждого блока. Для чего же он нужен?

Merkle root - это хеш дерева транзакций, содержащихся в блоке, в примере ниже у нас есть 4 транзакции, A,B,C,D. Хеш дерева тут обозначается top hash.

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

Во-вторых, дерево меркла позволяет получить подтверждение того, что транзакция действительно содержится в блоке, без необходимости получения всего списка транзакций блока, напомню, что их может быть более 1000 в блоке. Для того, чтобы получить информацию о транзакции A, достаточно будет получить так же транзакцию B, получить их хеши (hash0-0, hash0-1) и общий hash 0.

Т.е. мы храним информацию о транзакциях и их порядке в одном коротком merkle root хеше, и можем подтвердить одну транзакцию имея не полную информацию из блока. Более подробно о merkle root вы можете прочитать в моей старой статье: https://telegra.ph/Merkle-root-02-04

То же самое происходит и в MAST, но вместо транзакций у нас операторы.

Для примера взял картинку из интернета. В данном примере script1 – требует для разблокировки монет подпись Alice и определенное время, script2 – подпись боба и определенное время, а script3 – мультиподпись Alice + Bob.

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

При этом, в scriptPubKey будет записан лишь merkle root hash этого дерева, а не все условия. Тем самым мы, во-первых, перекладываем необходимость тратить комиссию тому, кто тратит монеты, так как он должен будет добавить ветки исполняющихся условий в scriptSig, а также скрываем условия траты монет до момента их траты. Кроме того, это нововведение сильно экономит место в блокчейне, так же, как и следующее нововведение в этом обновлении.

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

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

Одно из главных отличий подписей Шнорра в том, что их можно «стэковать». Т.е. 5 публичных ключей можно объединить в один, так же, как и пять подписей превращаются в одну, которая позволяет проверить все подписи не раскрывая конкретики и содержимого.

Как это применимо к биткоину?

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

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

Но в случае транзакции B – мы имеем 3 входа, в каждом из которых своя подпись и свой публичный ключ. Мы объединяем 3 публичных ключа в единый ключ, а 3 подписи в единую подпись, тем самым экономя множество места, не теряя в функциональности.

Кроме сохранения пространства – Подписи Шнорра позволяют добавить конфиденциальности в блокчейн, потому что по составному ключу, который использует механику сложения нельзя понять из каких ключей он состоит, так же как нельзя понять по числу 12, состоит ли оно из 6+6, или 3+3+4+2 или 7+5 (все же помнят, что публичные ключи это просто очень большие координаты, т.е. цифры, так же как и подписи).

Что эти обновления значат для сети

Читал несколько комментариев, где люди пишут «ура, теперь туземун, у битка наконец-то есть контракты». Не считаю такую точку зрения верной. У биткоина смарт-контракты были с первого блока, но предназначены они для другого. Это больше уклон в сторону мультиподписей и совместного ведения бизнеса\кошельков и каких-то революций в плане контрактов тут не предвидится, так как стек-ориентированный язык не особо удобен, не то строгий и ванильный c++&js-подобный solidity.

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

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

Несколько примеров:

Все описанные ниже примеры взяты «с потолка» на примере новых возможностей:

• Любая биржа теперь может хранить монеты совместно с вами, используя механизмы MUST, и управлять монетами с помощью гибких multisig алгоритмов.
• Возможны различные инвестиционные сервисы, дающие возможность инвестировать в какой-то проект, не отправляя в пустоту свои монеты, а реализовать более продуманный и гибкий механизм отправки монет. Например, после предоставления результата работы, по прошествии какого-то времени или только при согласии всех инвесторов одновременно.
• Возможно подписание документов в блокчейне биткоина. Т.к. MUST дает возможность хранить данные в блокчейне, не храня сами данные, а лишь их слепок.
• Более приватные миксеры монет

И так далее.

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

Цифровое золото fiat Telescr.in