Rama de Merkle de Taproot

Cada hash de la rama es un hash hermano del taptree (árbol de scripts de Taproot), en orden desde su hoja hacia arriba hasta la raíz. BIP-341 limita la rama a 128 hash, 4.096 bytes, y, como su árbol está ordenado, la rama no lleva ningún bit que indique izquierda o derecha. La longitud de su rama es pública, así que una hoja más profunda revela la profundidad mínima de su árbol y da pistas sobre qué billetera construyó la salida.

Cómo funciona

Una rama de Merkle de Taproot viaja dentro del bloque de control, el último elemento de la pila del testigo de un gasto por ruta de script una vez eliminado el anexo, si lo hay.

El bloque de control tiene una forma fija. El byte cero lleva la versión de hoja más la paridad de la coordenada Y de la clave de salida. Los bytes 1 a 32 contienen la clave pública interna. Todo lo que sigue es la rama: m hash consecutivos de 32 bytes, así que el bloque de control mide 33 + 32m bytes, y m debe ser un entero de 0 a 128. Cualquier otra longitud hace fallar el gasto antes de que se ejecute un solo opcode (código de operación).

La verificación empieza por abajo. Un nodo calcula el hash del script revelado con la etiqueta TapLeaf y después incorpora uno a uno los hash de la rama con la etiqueta TapBranch, comparando en cada paso los dos valores de 32 bytes en orden lexicográfico y colocando primero el menor al calcular el hash. Lo que se obtiene es la raíz del taptree, cuyo hash se calcula junto con la clave interna con la etiqueta TapTweak; ese valor se suma al punto interno y se compara con los 32 bytes de la salida que se gasta.

Esa comparación es todo el truco. Como BIP-341 ordena los dos hijos antes de calcular su hash, una rama nunca dice en qué lado estaba un hermano: el verificador lo deduce. La justificación del BIP es tajante sobre el motivo: dice que al diseño no le importa la posición de scripts concretos en el árbol, solo que el árbol realmente los fije.

El techo de 128 es un límite de seguridad y no un tope arbitrario. En un árbol empaquetado de forma óptima, la profundidad se acerca al logaritmo en base dos del inverso de la probabilidad de una hoja, así que una profundidad de 129 supondría un script con una probabilidad de uso inferior a 1 entre 2^128, que, según BIP-341, probablemente se puede eliminar sin más. En el otro extremo, un taptree de una sola hoja tiene un m de 0, una rama vacía y un hash de hoja que ya es la raíz.

Dónde aparece

Las ramas de Merkle de Taproot aparecen en cualquier transacción que gasta una salida bc1p revelando un script en lugar de firmar con la clave.

BIP-341 desarrolla un ejemplo con un árbol de cinco hojas. A, B, C y E son hash con la etiqueta TapLeaf, y AB es un hash con la etiqueta TapBranch calculado sobre los dos primeros. Para gastar con el script D, el bloque de control lleva C, luego E y luego AB: tres hash, 96 bytes de rama, un bloque de control de 129 bytes. Cuando E y CD se combinan, E entra primero en el hash porque es el menor en orden lexicográfico.

El costo en privacidad es lo que hay que tener en cuenta al planificar. La sección de seguridad de BIP-341 dice que la profundidad de un script revela la profundidad mínima del árbol, lo que sugiere qué software de billetera construyó la salida y ayuda al análisis de cadena a agrupar direcciones, y recomienda apartarse del árbol que darían las probabilidades de las hojas. La reutilización de hojas es el otro escollo: gastar una salida distinta puede volver a publicar los mismos hash de la rama, así que dos gastos que comparten un hash hermano de 32 bytes parecen relacionados.

Rama de Merkle de Taproot frente a bloque de Merkle

Una rama de Merkle de Taproot demuestra que un script pertenece a una dirección; un bloque de Merkle demuestra que una transacción pertenece a un bloque. La rama del taptree es crítica para el consenso, la recalcula todo nodo completo que valida el gasto y no depende de la posición, porque la ordenación eliminó la necesidad de decir izquierda o derecha. Una prueba sobre el árbol de transacciones de un bloque no puede tomar prestado ese truco, ya que el orden de las transacciones bajo la raíz de Merkle de un bloque es fijo y tiene significado, así que tiene que llevar el recorrido además de los hash.