Taproot está llegando a Bitcoin: cómo funciona, su historia e implicaciones

Las firmas de Taproot y Schnorr se lanzarán en Bitcoin en el bloque 709,632. Este será un gran logro fundacional para continuar construyendo en el futuro. Han pasado cuatro años desde que Segregated Witness se puso en marcha en la red, nuestra última actualización importante de protocolo. ¡Eso es tan largo como un ciclo de reducción a la mitad!

Piénsalo. Cuatro años desde la puesta en marcha de SegWit hasta la puesta en marcha de Taproot. Paciencia lenta y metódica, como debe ser. Pero la historia de Taproot / Schnorr se remonta mucho más atrás.

La historia de Taproot

Algunos que han estado aquí por un tiempo pueden encontrar esto irónico, pero la primera mención de las firmas de Schnorr que conozco fue en realidad del ex desarrollador de Bitcoin Core convertido en creador de blockchain empresarial Mike Hearn. En 2012, él trajo la idea de una nueva curva criptográfica en relación con la verificación de firmas por lotes para hacer que la validación de nodos sea menos costosa computacionalmente. En última instancia, el plan que proponía dependía de las firmas de Schnorr.

Adam Back estaba hablando de ingenuo esquemas para hacer direcciones de firmas múltiples que parecieran singlesig en 2014, utilizando firmas de Schnorr. Incluso Gavin Andresen incluido Schnorr en lugar de ECDSA en su lista de deseos de cambios que haría a Bitcoin si pudiera agitar una varita mágica.

Desde muy cerca del comienzo de Bitcoin, la mayoría de los desarrolladores que participan activamente en Bitcoin Core han querido las firmas de Schnorr, y siempre ha habido un consenso bastante sólido sobre su superioridad sobre las firmas ECDSA. De hecho, se podría argumentar que ECDSA se creó específicamente porque el esquema de firma de Schnorr estaba patentado y había una gran necesidad de un esquema de firma criptográfica de código abierto que no estuviera gravado por patentes.

Schnorr es mucho más eficiente y fácilmente manipulable (se pueden agregar, restar cosas, etc. de las firmas, y si se hace correctamente, aún puede dejar a los usuarios firmas válidas cuando deberían tenerlas) que ECDSA. El uso de ECDSA fue una necesidad más que un deseo en la mayoría de las aplicaciones criptográficas a lo largo de los años.

Merkelized Abstract Syntax Trees (MAST), la mitad de Taproot de esta próxima actualización de Taproot, tiene una historia similar de larga data. No puedo encontrar la cita, pero recuerdo claramente haber visto esa frase lanzada por personas como Peter Todd en Bitcointalk.org alrededor de 2013 o 2014.

El original BIP para MAST fue propuesta por Johnson Lau en 2016. Esta propuesta también vio algo de actividad alrededor de 2017 cuando Mark Friedenbach, BTCDrak y Kalle Alm la dividieron en dos BIP separados (116 y 117) y amplió la propuesta original de Lau.

MAST se quedó en el limbo durante el año siguiente hasta que a Greg Maxwell se le ocurrió la idea inicial de Taproot y publicado a la lista de correo de bitcoin-dev. Su idea clave fue que en cualquier caso de contrato entre múltiples participantes que se le ocurriera, había un "resultado óptimo" en el que el contrato podía ser resuelto por todos simplemente firmando el resultado apropiado en lugar de hacer cumplir el resultado con scripts y transacciones más avanzados. Esta es la afirmación fundamental en la que se basa Taproot, es decir, ajustar el árbol MAST a una clave de nivel superior regular que se puede gastar sin revelar si existe un árbol Merkle de otras condiciones de gasto.

El último tramo de esta lección de historia comienza con Pieter Wiulle anunciando borrador de BIP para Schnorr y Taproot junto con la lista de correo el 6 de mayo de 2019. Para enero de 2020, esto se finalizó formalmente en BIP 340, 341 y 342. A partir de este momento, fue solo una gran cantidad de pequeños detalles refinados en el nivel de implementación, un período de revisión y luego el prolongado batalla por los mecanismos de activación. Eso nos lleva al ahora, apenas por debajo de la activación.

La importancia de las firmas Schnorr

Entonces, ¿cuál es el problema con las firmas de Schnorr? Bueno, para empezar, hacen transacciones más pequeñas. Una firma ECDSA suele tener un tamaño de aproximadamente 72 bytes para una sola firma en una transacción. Las firmas de Schnorr registran un máximo de 64 bytes por firma. Eso es aproximadamente un 12% de ahorro en tamaño en comparación con ECDSA para cada firma de Schnorr. Esto es un beneficio directo para la persona que usa Schnorr, que pagará menos en tarifas que un usuario de ECDSA, pero también es un beneficio directo para las personas que no usan Schnorr al requerir que se almacenen un poco menos de datos en la cadena de bloques para procesar y validar el Schnorr de otra persona. firmas.

Almacenar menos datos siempre es bueno, pero lo que es aún mejor es aumentar la eficiencia de la validación de los datos que tiene que almacenar. Una de las buenas propiedades de Schnorr, la linealidad de las matemáticas detrás de él, también permite una buena propiedad que desea en los datos de Bitcoin: la validación por lotes. Cuando su nodo recibe un bloque de la red, analiza cada transacción individual y valida cada firma una por una.

Esta es una gran parte de por qué la validación de bloques consume mucha energía de la CPU. Las firmas de Schnorr se pueden agrupar y validar matemáticamente a la vez, algo así como romperlas juntas y hacer una operación matemática en lugar de un montón de operaciones individuales. Entonces, cuantas más firmas de Schnorr haya, mayores serán los ahorros computacionales. Esta es una ganancia de escala masiva para la red.

Otra gran mejora que aporta Schnorr son los scripts de firma múltiple. Cada dirección multisig tiene que revelar explícitamente todas las claves públicas individuales involucradas en un script multisig al pasar el tiempo, y se debe proporcionar una firma para cada clave involucrada en el proceso de gasto. Con las propiedades matemáticas de Schnorr, se abre la puerta para MuSig, un estándar de múltiples firmas. Puede simplemente agregar claves juntas y terminar con una única clave pública que los recursos compartidos de claves privadas de todos pueden firmar mediante el uso de nuevos protocolos de firma. Jonas Nick de Blockstream comparado MuSig2 en dos minutos para un millón participantes en una dirección multifirma para firmar. La mejora de escala de los scripts de firma múltiple no puede subestimarse.

Este gran avance para los scripts de múltiples firmas también tiene una gran implicación para el perfil de privacidad y el costo de numerosas aplicaciones construidas sobre Bitcoin. Los canales Lightning basados ​​en MuSig ahora pueden combinarse con todo el conjunto de anonimato de Schnorr/Taproot UTXO en cadena porque ya nadie podrá distinguir el hecho de que son una salida multisig de dos de dos.

Se integrarán y se verán como un solo guión de firma. Lo mismo ocurre con cualquier UTXO multisig en general. Esto tendrá muchas implicaciones para las personas que utilizan secuencias de comandos de firma múltiple para proteger mejor su almacenamiento en frío con un modelo de seguridad y recuperación más sólido que una secuencia de comandos de firma única.

En primer lugar, no será obvio que estén usando una configuración multifirma al observar la cadena de bloques, por lo que esto, como en el caso de Lightning, hará que se mezclen con todo lo demás. Sin embargo, una ventaja clave es en lo que respecta a la economía: el uso de firmas múltiples en este momento requiere proporcionar una firma separada para cada clave involucrada en eventualmente gastar un UTXO. Con Schnorr / MuSig, las cosas se comprimirán en una sola firma para la única clave pública combinada, lo que significa que gastar UTXO multisig usando MuSig será mucho más barato ya que está enviando menos datos a la cadena de bloques.

Una última cosa interesante que hacen las firmas de Schnorr es simplificar drásticamente la implementación de firmas de adaptadores. Piense en una firma de adaptador que está "encriptada" por un valor que se ha agregado o restado de una firma válida. No es válido hasta que invierta esa operación matemática, o "la descifre" con la "clave" que se utilizó para manipularla. Esto es posible con ECDSA, pero debido a que las matemáticas no son lineales en comparación con Schnorr, es relativamente complicado y hay muchas preocupaciones de seguridad a considerar al implementarlo.

Sin embargo, debido a las propiedades lineales de Schnorr, una firma de adaptador es tan simple como tomar una sola (digamos, el número 9,300,030) y restarle un valor (digamos 30). Una vez que la parte que tiene la firma del adaptador aprende el valor restado, simplemente puede volver a agregarlo y voilá, tienen una firma válida nuevamente.

Las implicaciones de la raíz principal

Como se discutió un poco anteriormente, Taproot en realidad es esencialmente solo MAST, excepto que en lugar de que funcione como P2SH (donde se aplica un hash al script, o en el caso de MAST, la raíz Merkle de la parte superior del árbol de script), se "ajusta" un Clave pública de Schnorr por la raíz del árbol Merkle.

El ajuste funciona debido a las propiedades lineales de Schnorr: cuando "modifica" una clave pública con una raíz Merkle (agrega esa raíz Merkle a la clave pública), simplemente puede agregar la raíz Merkle a la clave privada original y generar la clave de gasto para la nueva clave pública modificada. Es decir, agrega lo mismo tanto a la clave pública como a la privada, y siguen siendo un par de claves válido. Esto oculta la existencia de un árbol MAST, a menos que se use una rama del mismo, pero fundamentalmente sigue siendo solo un árbol MAST, solo uno comprometido de una manera más eficiente y privada.

La capacidad de comprometerse con diferentes scripts de gastos en un árbol de Merkle y solo revelar el script usado es una ganancia de escalabilidad masiva en términos de complejidad de contrato inteligente que es posible construir en Bitcoin.

Al igual que el tamaño del bloque limita la cantidad de transacciones por bloque, existe un límite de restricción de tamaño de transacción de 100 kilobytes. La única diferencia es que en lugar de ser una regla de consenso, es una regla de política. Eso significa que un minero puede extraer una transacción de más de 100 kilobytes, pero de forma predeterminada, ningún nodo en la red transmitirá una transacción más grande que esa al minero en primer lugar.

Esto limita inherentemente el tamaño del script utilizado para bloquear un UTXO de Bitcoin. Incluso con P2SH, donde la UTXO está bloqueada en un hash del script que no se revela hasta que lo gastas, eventualmente tienes que revelar el script completo en el momento del gasto. Taproot aumenta este límite de escalabilidad de la secuencia de comandos al no requerir que revele la secuencia de comandos completa cuando la usa. En lugar de que el tamaño total de todas las formas en que puede gastar el UTXO esté restringido al límite del tamaño de la transacción, solo debe asegurarse de que cualquier forma en que pueda gastar un Taproot UTXO respete esta limitación.

También hay muchos beneficios de privacidad que vienen junto con Taproot. Uno de los grandes beneficios de un árbol MAST es la capacidad de crear todo tipo de situaciones condicionales en las que otras partes pueden gastar monedas.

Imagínese cosas como esquemas de herencia en los que después de aproximadamente un año sus hijos pueden gastar sus monedas, o en el caso de que usted se niegue a firmar, su esposa y un abogado tienen un camino potencial para recuperar monedas. Nada acerca de estas condiciones de gasto se revela al público a menos que realmente se utilicen. Este proceso doble proporciona una negación plausible para otras partes involucradas en diferentes ramas de gasto que usted construye en cuanto a su participación en ese UTXO, así como también las protege de un ladrón o atacante que las ataca de manera preventiva sabiendo que tienen cierto grado de control sobre sus acciones. UTXO del objetivo.

A nivel técnico, Taproot también ha sido relativamente bien diseñado. Cualquiera que lea y esté familiarizado con Segregated Witness en cualquier nivel profundo debe estar familiarizado con la versión de testigo.

Cuando se implementó Segregated Witness, se creó la nueva sección "testigo" de una transacción a la que se movieron los datos de la firma. Los datos de los testigos tenían una marca de versión para que pudieran actualizarse a una nueva funcionalidad sin tener que utilizar OP_CODE indefinidos en la capa base para nuevas funciones.

Así es como se ha implementado Taproot / Schnorr. Las transacciones de Testigo segregado utilizan la versión cero del testigo. Cuando Taproot / Schnorr se active pronto, usarán la nueva versión de testigo uno para distinguirlos de las transacciones de Testigos segregados más antiguos. De la misma manera que SegWit introdujo versiones de testigos, Taproot introduce la "versión tapleaf" para los tapscripts usados ​​en los árboles MAST para UTXOs que usan Taproot. Esto no solo permite que los scripts enterrados en MAST se actualicen sin usar nuevos OP_CODE en la capa base, ¡sino también sin tener que actualizar las versiones de testigos! Por lo tanto, Taproot fue diseñado para ser lo más eficiente posible para actualizar en el futuro sin limitar otras actualizaciones no relacionadas con el protocolo.

Taproot traerá muchos casos de uso diferentes. Para comenzar, todas las cláusulas no cooperativas en un canal Lightning, como las claves de penalización o los bloqueos de tiempo para permitir su uso, se pueden enterrar bajo un MAST con Taproot. Nadie sabrá nunca que existen a menos que sea necesario usarlos, lo que oscurece aún más qué UTXO son en realidad canales Lightning o no.

Los esquemas de herencia son otro caso de uso. Imagine un árbol de raíz principal estructurado de modo que después de seis meses sin mover su dinero, toda su familia pueda reunirse y gastar los UTXO como quieran. Luego, seis meses después, todos menos una persona pueden gastarlo (así que imagínese si tuviera a su esposa, dos hijos y sus padres como poseedores de llaves, luego imagine que después de los seis meses adicionales, su esposa, un niño y sus padres pueden firmar , o sus dos hijos y sus padres pueden firmar sin su esposa, etc.).

Luego, seis meses después de eso, todos menos dos personas pueden gastarlo. Eventualmente, podría reducirse a que solo una persona con la ayuda de un abogado (para asegurarse de que no ocurran travesuras) pueda gastar el UTXO.

O, ¿qué pasa si usa multisig para asegurar su almacenamiento en frío, pero solo tiene un lugar que considera seguro y predecible a largo plazo? Podría crear un MAST donde eventualmente, después de unos años, la llave en ese lugar seguro pueda gastar esas monedas sola, en caso de que otras llaves se pierdan o se destruyan, pero sin poner sus monedas inmediatamente en riesgo de robo en el presente si eso una clave se vio comprometida.

Esta es una actualización sorprendente y completa de Bitcoin que podría decirse que ha estado en proceso desde casi el nacimiento de Bitcoin en sí, no solo en los últimos años en los que se han elaborado e implementado los detalles de implementación reales.

Realmente es una victoria en muchos sentidos para la escalabilidad y la utilidad del protocolo Bitcoin que es difícil de transmitir debido a lo sutiles y "poco sexys" que son algunos de ellos. Pero eso no resta valor a la victoria. Entonces, abróchense los cinturones y prepárense para jugar con los nuevos juguetes que tendremos que usar pronto, ¡porque Taproot está por llegar!

Esta es una publicación de invitado de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.

Fuente: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer