28/01/2019 - 12:37

Taproot, la propuesta para mejorar la privacidad de Bitcoin

Autor Por Redacción Cripto247
Taproot, la propuesta para mejorar la privacidad de Bitcoin

La actualización de la red de la criptomoneda ya tiene cuenta con el trabajo de importantes desarrolladores

Por Aaron van Wirdum

Los usuarios de Bitcoin podrán, en poco tiempo, beneficiarse de un truco llamado “Taproot”. Primero propuesto por el colaborador de Bitcoin Core y el ex CTO de Blockstream Gregory Maxwell, Taproot ampliaría la flexibilidad de los contratos inteligentes de Bitcoin y, al mismo tiempo, ofrecería más privacidad al hacerlo. Incluso los contratos inteligentes más complejos serían, en la blockchain, típicamente indistinguibles de las transacciones normales.

Si bien es una gran apuesta ya no es sólo una teoría. Varios de los colaboradores más prolíficos de Bitcoin Core, entre ellos Pieter Wuille, Anthony Towns, Johnson Lau, Jonas Nick, Andrew Poelstra, Tim Ruffing, Rusty Russell y, de hecho, Gregory Maxwell, están trabajando en una propuesta de Schnorr Signature [aumentando la escala y la privacidad de Bitcoin] que incluiría a Taproot, todo junto en una actualización del protocolo.

Qué es y cómo funciona Taproot

P2SH

Todos los bitcoins están esencialmente “bloqueados” en scripts: un par de líneas de código incrustadas en una transacción incluida en la cadena de bloques, que definen cómo pueden gastarse las monedas en la próxima transacción. Las condiciones de gasto generalmente implican proporcionar una firma para demostrar la propiedad de las monedas. Pero otras condiciones bien conocidas, por ejemplo, incluyen “bloqueos de tiempo” (timelocks), que implica que las monedas solo pueden gastarse después de una altura o fecha específica del bloque, o multisig (las monedas solo se pueden gastar si un número de claves privadas de un conjunto de claves privadas proporcionan las firmas necesarias).

Se pueden mezclar y combinar diferentes condiciones para crear tipos complejos de contratos inteligentes. Un ejemplo de tal contrato podría ser que las monedas se pueden gastar si tanto Alicia como Pedro firman, o si Alicia solo firma después de que haya pasado una semana, o si Pedro solo firma al mismo tiempo que proporciona un número secreto. Dependiendo de cuál de estas tres condiciones se cumple primero, es cómo se gastan las monedas.

Desde 2012, los scripts (las condiciones) a menudo no son públicamente visibles al principio; solo el nuevo propietario de las monedas sabe cómo se pueden gastar. Esto se hace con un truco llamado P2SH (pay to script hash), donde inicialmente solo se incluye un hash del script en la cadena de bloques. Este número aparentemente aleatorizado contiene las monedas. Cuando el propietario gasta las monedas, revela el guión completo, así como la “solución” al guión al mismo tiempo. Cualquiera puede usar el hash inicial para verificar que el script suministrado fuera realmente el script original que bloquea las monedas y puede concluir inmediatamente que se cumplieron los requisitos del script.

Aún así, cuando se gastan las monedas, actualmente es necesario revelar todas las condiciones posibles que podrían haberse cumplido, incluidas las condiciones que no se cumplieron. Esto tiene dos desventajas principales. Una, son datos pesados, especialmente si hay muchas condiciones. Y dos, es malo para la privacidad. Todos se enteran las diferentes formas en que se podrían haber gastado los fondos, lo que puede, por ejemplo, revelar qué tipo de billetera se usó y quizás incluso más.

MAST

MAST (Merkelized Abstract Syntax Tree) es una solución propuesta que utiliza árboles Merkle (una estructura de datos compacta de décadas de antigüedad inventada por el criptógrafo Ralph Merkle) para solucionar estos dos inconvenientes. En resumen, todas las diferentes condiciones bajo las cuales se pueden gastar los fondos se dividen individualmente (en lugar de combinarse en un solo hash) y se incluyen en un árbol Merkle, que en última instancia produce un solo hash: la raíz Merkle. Esta raíz de Merkle “encierra” las monedas.

El beneficio único es que si se revela cualquiera de los datos en el árbol de Merkle, la raíz de Merkle y algunos datos adicionales (llamados la ruta de Merkle) se pueden usar para verificar que los datos específicos se incluyeron en el árbol de Merkle. El resto del árbol permanece hasheado y oculto.

Con MAST, esto significa que solo debe revelarse la condición que se cumple. Si, en el ejemplo inicial anterior, solo Alicia gasta los fondos después de una semana, simplemente revela esa condición (y el camino de Merkle). Nadie se entera de que Alicia y Pedro podrían haber gastado el dinero juntos, o solo Pedro si hubiera agregado un número secreto. Esto hace que MAST sea más eficiente y más privado que los complejos contratos inteligentes P2SH.

Sin embargo, con Schnorr, Taproot puede hacerlo aún mejor: una transacción puede ocultar que existió una estructura MAST.

Schnorr

El esquema de firma de Schnorr ha estado durante mucho tiempo en la lista de deseos de muchos desarrolladores de Bitcoin y actualmente está en desarrollo para ser implementado como una actualización del protocolo de bifurcación. Muchos criptógrafos consideran que el esquema de firma de Schnorr es el mejor en el campo, ya que sus propiedades matemáticas ofrecen un alto nivel de corrección, no sufren maleabilidad y su verificación es relativamente rápida.

Como su beneficio más conocido en el contexto de Bitcoin, la “matemática lineal” de Schnorr permite la agregación de firmas: varias firmas en la misma transacción se pueden combinar en una. Un truco similar podría aplicarse a transacciones multisig. Combinando tanto las claves públicas como las firmas en “threshold public keys” y “threshold signatures”, una transacción multisig puede ser indistinguible de cualquier transacción regular.

Y el esquema de firma se puede utilizar de maneras aún más interesantes. Por ejemplo, es posible utilizar datos para “modificar” tanto una clave privada como una pública. Como ejemplo simplificado, una clave privada y su correspondiente clave pública se podrían modificar multiplicando ambas por dos. La “clave privada x 2” y la “clave pública x 2” seguirían correspondiendo, y la “clave privada x 2” todavía podría firmar mensajes que podrían verificarse con la “clave pública x 2”. Cualquiera que no sepa que la clave original fue modificada, ni siquiera vería ninguna diferencia; las claves modificadas se parecen a cualquier otro par de claves.

Esto es lo que permite Taproot.

Taproot (Raíz principal)

Taproot se basa en una realización interesante: no importa lo compleja que sea, casi cualquier construcción MAST podría (o debería) incluir una condición que permita a todos los participantes ponerse de acuerdo sobre el resultado y simplemente firmar una transacción de liquidación juntos.

En el ejemplo anterior, si Pedro sabe que Alicia puede, por sí misma, reclamar todos los fondos la próxima semana, es mejor que coopere con ella ahora para firmar juntos. (En muchas configuraciones típicas de contratos inteligentes, incluso lo penalizarían si no lo hace. La complejidad realmente sirve para mantener a todos honestos).

Taproot se parece a MAST y siempre incluye una condición en la que todos los participantes pueden cooperar para gastar los fondos: el “cierre cooperativo”.

Al utilizar las firmas Schnorr es donde se pone interesante el asunto.

En primer lugar, el cierre cooperativo utilizaría el truco de Schnorr para que pareciera una transacción regular, de una persona a otra. Por lo tanto, las claves públicas de todos los participantes se suman, dando como resultado la “threshold public key”. En correspondencia con esta clave pública, la combinación de las firmas de todos los participantes, la “threshold public key”, les permite gastar los fondos.

Hasta ahora todo bien, pero gastar los fondos como si fuera una transacción normal es lo único que pueden hacer (sin estructuras MAST). Ahí es donde entra en juego el otro truco de Schnorr.

Todas las formas alternativas en que pueden gastarse los fondos (los resultados no cooperativos) se combinan en un script diferente. Esta secuencia de comandos, entonces, está codificada y se utiliza para modificar la “threshold public key”. En lugar de “public key x 2”, como se usó en el ejemplo anterior, esto da como resultado un “threshold public key x script”. (Todavía estamos simplificando). Este “threshold public key x script”corresponde, por supuesto, a un “threshold signature x script”.

Ahora, si el dinero se gasta de forma cooperativa, todos los participantes combinan sus firmas en la “threshold signature” y lo ajustan con el script. El  “threshold signature x script”  resultante les permite gastar los fondos. Sin embargo, y lo que es más importante, para el mundo exterior, todo esto parecería una clave pública regular y una firma regular, una transacción regular.

Solo si resulta imposible un cierre cooperativo se puede mostrar la threshold public key por lo que realmente está: adaptada.

En este caso, se revelan tanto la threshold public key original como el script. Esto prueba que el “threshold public key x script” se ha modificado con este script específico. Entonces, al igual que el hash en P2SH, el cambio demuestra al mundo que los fondos deberían poder gastarse si se cumplen las condiciones alternativas, como se especifica en este script. (Y, al igual que con P2SH, se deben cumplir estas condiciones para gastar los fondos).

Alternativamente, en lugar de ajustar la threshold public key con el script, la threshold public key se puede modificar con una raíz Merkle de un árbol Merkle que incluya todas las diferentes condiciones en las que se pueden gastar los fondos: una estructura MAST. Para gastar los fondos, entonces, solo debe revelarse la condición de gasto que se ha cumplido.

Como tal, Taproot ofrece todos los beneficios de MAST, mientras que en circunstancias normales, nadie sabrá nunca que una transacción regular estaba ocultando un contrato inteligente tan complejo.

Este es un resumen general del concepto de Taproot; Los detalles de la implementación pueden variar. Para más detalles, lea la propuesta original de Taproot de Gregory Maxwell o vea esta presentación de Pieter Wuille.

Este artículo fue originalmente publicado en Bitcoin Magazine.

Traducción realizada por Cripto247.

Compartilo en las redesFacebookTwitterWhatsAppMessengerE-mail

Comentarios

Recibí las últimas noticias
del cripto-ecosistema en
tu casilla de E-mail


Su email ha sido ingresado.
Cargando