Ветка Меркла Taproot

Каждый хеш в ветке является одним соседним узлом из taptree, в порядке от вашего листа вверх до корня. BIP-341 ограничивает ветку 128 хешами, 4096 байтами, а благодаря тому, что дерево отсортировано, ветка вообще не несет битов направления влево или вправо. Длина вашей ветки публична, поэтому более глубокий лист выдает минимальную глубину вашего дерева и дает подсказку о том, какой кошелек построил выход.

Как это работает

Ветка Меркла Taproot передается внутри блока управления, последнего элемента стека свидетеля расхода по пути скрипта после удаления аннекса, если он был.

Блок управления имеет фиксированную форму. Нулевой байт несет версию листа плюс четность координаты Y ключа выхода. Байты с 1 по 32 содержат внутренний публичный ключ. Все, что идет после, является веткой: m последовательных хешей по 32 байта, поэтому блок управления занимает 33 + 32m байт, и m должно быть целым числом от 0 до 128. Любая другая длина приводит к отказу расхода еще до выполнения хотя бы одного опкода.

Проверка начинается снизу. Узел хеширует раскрытый скрипт с тегом TapLeaf, затем по очереди сворачивает каждый хеш ветки с тегом TapBranch, сравнивая на каждом шаге два значения по 32 байта лексикографически и хешируя меньшее из них первым. На выходе получается корень taptree, который хешируется вместе с внутренним ключом под тегом TapTweak, прибавляется к внутренней точке и сверяется с 32 байтами в расходуемом выходе.

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

Предел в 128 хешей является границей безопасности, а не произвольным ограничением. Глубина в оптимально упакованном дереве близка к двоичному логарифму от величины, обратной вероятности листа, поэтому глубина 129 означала бы скрипт с вероятностью использования ниже 1 из 2^128, который, по словам BIP-341, вероятно, можно просто удалить. На другом конце taptree из одного листа имеет m, равное 0, пустую ветку и хеш листа, который уже является корнем.

Где это встречается

Ветки Меркла Taproot встречаются в любой транзакции, которая расходует выход bc1p, раскрывая скрипт вместо подписи ключом.

BIP-341 разбирает один пример на дереве из пяти листов. A, B, C и E являются хешами TapLeaf, а AB является хешем TapBranch над первыми двумя. Чтобы потратить с помощью скрипта D, блок управления несет C, затем E, затем AB: три хеша, 96 байт ветки, блок управления в 129 байт. E хешируется раньше CD при их объединении, потому что E сортируется ниже.

Цена приватности является тем, что стоит учитывать при планировании. Раздел безопасности BIP-341 говорит, что глубина скрипта выдает минимальную глубину дерева, что указывает на кошелек, построивший выход, и помогает анализу цепочки объединять адреса в кластеры, и рекомендует отходить от дерева, которое дали бы вероятности листов. Повторное использование листа является другой ловушкой: расход другого выхода может заново опубликовать те же хеши ветки, поэтому два расхода, имеющие общий соседний хеш размером 32 байта, выглядят связанными.

Ветка Меркла Taproot vs блок Меркла

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