Tapscript y árboles de scripts (MAST)

Curiosidad

1. ¿Por qué el gasto bajo una cláusula de un contrato debería revelar todo el contrato?
2. ¿Qué hace que un gasto cooperativo sea indistinguible de una firma simple?
3. ¿Cómo puede una sola clave comprometer toda una biblioteca de condiciones ocultas de gasto?

Explorar

1. Los árboles de sintaxis abstracta merkelizados (MAST) fueron descritos por primera vez por Russell O’Connor en 2013 y desarrollados en propuestas presentadas en 2016 y 2017. Este concepto consiste en incluir condiciones alternativas de gasto dentro de un árbol Merkle, lo que permite al destinatario del gasto revelar únicamente la rama específica que está utilizando. Mientras que el término “árbol de sintaxis abstracta” se refería a estructuras de compiladores en las cuales cada condición creaba un nuevo nodo, la implementación en Bitcoin evolucionó de manera diferente. Anthony Towns acuñó posteriormente el backronímico “Merklized Alternative Script Tree” para describir la estructura realmente adoptada: un conjunto de scripts completos e independientes entre los cuales solo uno se selecciona en el momento del gasto.
2. Taproot integró esta estructura de árbol en las reglas de consenso a través de BIP341. Cada hoja del árbol Merkle contiene un script, y la raíz de dicho árbol contribuye a la clave de salida final. Cuando se gastan fondos por medio de la «ruta de script», el gastoador revela el script específico de la hoja, sus entradas y la prueba Merkle: los hashes de los nodos hermanos en cada nivel. Las ramas no utilizadas permanecen ocultas en la cadena, preservando la privacidad en arreglos complejos como multisig o timelocks, que anteriormente se veían obligados a utilizar envoltorios P2SH.
3. Tapscript (BIP342) es el dialecto específico utilizado para estos scripts de tipo “leaf”, y difiere del Bitcoin Script tradicional en varios aspectos cruciales. En Tapscript, OP_CHECKMULTISIG está deshabilitado. Su sustituto, OP_CHECKSIGADD, verifica una firma contra una clave y suma 1 a un contador acumulativo; una firma vacía no aporta nada, mientras que una firma inválida y no vacía hace que todo el script falle. El script conecta una firma por cada clave y compara el contador con el umbral establecido. Cada firma está asociada a una clave conocida, por lo que no hay necesidad de probar diferentes combinaciones, y las firmas pueden verificarse en lotes.
4. Tapscript también deja espacio para actualizaciones con códigos de operación OP_SUCCESS: hoy en día, cualquier script que contenga uno tiene éxito incondicionalmente, por lo que nadie los utiliza; además, un futuro soft fork podría asignarles significados restrictivos sin invalidar nada que ya esté en uso. El límite heredado de 10,000 bytes para el tamaño de los scripts se elimina en Tapscript; en su lugar, el tamaño del script está limitado únicamente por el peso del bloque y las restricciones establecidas. Además, el presupuesto para operaciones de firma aumenta según el tamaño del testimonio, lo que evita ataques de denegación de servicio mediante la verificación excesiva de firmas.
5. Considere un ejemplo práctico: un usuario tiene fondos en una ruta de claves 2-de-2 para gastos cotidianos, donde ambas partes firman de forma cooperativa para revelar únicamente una firma Schnorr estándar. Sin embargo, el árbol de scripts incluye una hoja oculta que permite a una sola clave gastar los fondos tras un plazo de espera de un año. Si la parte colaboradora deja de responder, el usuario puede activar esta rama de recuperación. La prueba Merkle revela únicamente ese script de plazo de espera específico, manteniendo completamente privadas a otras ramas potenciales, como las de recuperación social o los hashlocks.
6. Para verificar estas mecánicas, abra un explorador de bloques y localice una transacción Taproot gastada a través de la ruta de script. Examine el witness: las entradas del script, el propio script de hoja y un bloque de control cuyo primer byte combina la versión de la hoja (0xc0 para tapscript) con un bit de paridad, seguido por la clave interna y un hash de 32 bytes por nivel del árbol. Compare esto con un gasto mediante ruta de clave del mismo tipo de dirección; este último solo revela una firma de 64 o 65 bytes y sin datos de script, lo que demuestra cómo los contratos complejos permanecen invisibles cuando no se utilizan.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• BIP341: Taproot: SegWit version 1 spending rules
• BIP342: Validation of Taproot Scripts
• Bitcoin Optech, 'MAST' and 'Tapscript' topics
• Anthony Towns, 'Merklized Alternative Script Trees' proposal discussions