Raíz principal de programación

Lo más destacado del nuevo taller técnico de Jimmy Song, Programming Taproot.

El mes pasado asistí al viaje inaugural de Programming Taproot, un nuevo taller que acaba de lanzar el desarrollador de Bitcoin Jimmy Song. Realizó el taller de un día en Bitcoin Commons en el centro de Austin. Es una continuación de su exitoso taller de programación Blockchain de dos días que imparte en todo el mundo y que finalmente se convirtió en la base de su excelente libro Programación de Bitcoin. Discutiré los aspectos más destacados del taller y las ideas principales.

[This post is more technical than others. Don’t be scared. Even if you don’t understand everything, save this post and come back to it as your Bitcoin education develops. I’m in the process of developing an online class that will allow an educated but non-technical audience to fully understand the content of a post like this.]

La gran idea de Taproot es que permite una complejidad y privacidad mucho mayores en los scripts de Bitcoin. Las transacciones que utilizan Taproot no se verán diferentes en la cadena de las transacciones de Bitcoin más básicas, donde Alice envía dinero a Bob. Eran posibles transacciones complejas utilizando el script de Bitcoin anterior a Taproot, pero revelan mucha información sobre la transacción e inflan la cadena. Taproot utiliza estructuras de árbol Merkle inteligentes y nuevas firmas para ocultar toda esta información de la cadena de bloques y, en cambio, opera a nivel de billetera y nodo. Esta es una evolución natural del software, que hace que el procesamiento back-end quede fuera de la vista de la capa pública.

Firmas de Schnorr

El primer paso de Taproot es la firma Schnorr. En este momento, Bitcoin utiliza firmas del algoritmo de firma digital de curva elíptica (ECDSA), que requiere una operación computacional costosa, división de campo finita. Schnorr tiene un algoritmo de firma y verificación más simple que utiliza funciones hash. Como puedes imaginar, la función hash favorita de Satoshi es SHA-256. Y eso es lo que usa Schnorr. De hecho, Schnorr se inventó cuando Satoshi escribió Bitcoin, pero estaba bajo protección de patente. La simplicidad de Schnorr es atractiva y realiza la misma función que la firma ECDSA de Bitcoin original: demuestra que un propietario de bitcoins conoce su clave privada sin revelarla. Los nodos completos realizan esa verificación cada vez que el propietario envía bitcoins a través de la red, y estas verificaciones (operaciones de firma o SigOps) ahora son mucho más rápidas con las firmas Schnorr.

Raíz principal

Taproot permite scripts ahora llamados scripts Tap, en un árbol Merkle con hojas Tap y ramas Tap. Un árbol Merkle es una estructura de datos que ya se utiliza en Bitcoin, diseñada para que clientes ligeros verifiquen transacciones sin tener que mantener toda la cadena de bloques en el disco. En mi clase, muestro exactamente cómo un cliente ligero puede realizar una prueba de inclusión utilizando este árbol Merkle. En resumen, los árboles Merkle son estructuras de datos útiles para demostrar fácilmente que algunos datos están almacenados en el árbol. Debido a que los árboles Merkle son árboles de búsqueda binarios, pueden contener grandes cantidades de datos de manera eficiente: puede ejecutar 2¹²⁸ niveles de profundidad, lo que permite muchos scripts diferentes en el árbol. Esto permite secuencias de comandos complejas en transacciones financieras mucho más sofisticadas, con cálculos que se realizan fuera de la cadena.

MuSig

Una transacción multifirma en Bitcoin permite gastar bitcoins si varias firmas desbloquean varias claves públicas. Multisig es una gran innovación que mejora enormemente la usabilidad y la experiencia del usuario, ya que evita el estrés y el dolor de cabeza de administrar una única clave, lo que puede impedir para siempre el acceso a bitcoin si se pierde esa clave. Michael Flaxman tiene excelentes entrevistas en el podcast de Stephen Livera sobre los beneficios de la multifirma, y ​​varias empresas de Bitcoin como Unchained y Casa han construido su negocio en torno a la custodia multifirma de terceros, donde un custodio posee una cierta cantidad de claves.

El problema con multisig pre-Taproot es que es torpe. Revela todas las condiciones de gasto en la cadena y también la infla, ya que todas esas firmas y claves ahora deben ser parte de cada transacción.

MuSig permite la multifirma y todo se realiza en segundo plano. Supongamos que un grupo de personas genera sus propias claves públicas y desea recibir un pago para el grupo, que luego requerirá firmas de todas las personas para poder enviar los fondos en una transacción. Por ejemplo, las grandes transferencias de fondos de una empresa a otra pueden requerir la firma tanto del director ejecutivo como del director financiero, o las transferencias desde un patrimonio familiar pueden requerir la firma de todos los miembros de la familia. MuSig genera una clave pública grupal a partir de las claves públicas individuales, luego genera firmas individuales a partir de la clave pública grupal y finalmente una firma grupal a partir de las firmas individuales. Al final, una única firma de grupo puede firmar la transacción grupal para desbloquear la clave pública del grupo. La principal innovación es que la firma y la verificación se realizan dentro de una única transacción Taproot.

¿Por qué es esto tan importante? Antes de Taproot, multisig requería dos tipos de verificación. La primera fue la verificación de firmas individuales, que se realizó en la capa de firma. El segundo fue la verificación de las condiciones de gasto, que ocurrió en la capa del guión. Con Taproot, todo puede suceder en la capa de firma, y ​​esto es conceptualmente mejor. Una transacción multifirma es simplemente una versión más compleja de una transacción de firma única y, por lo tanto, conceptualmente debe tratarse de la misma manera: en la capa de firma. MuSig evita la necesidad de invocar scripts complejos para una transacción multifirma. Y luego está el beneficio de la privacidad, ya que estas transacciones de MuSig no se diferencian de las transacciones entre pares entre individuos en la red Bitcoin.

ESCARCHA

Las firmas de umbral Schnorr optimizadas por rondas flexibles (FROST) fueron el tema final, una forma de implementar firmas de umbral. Este es el desarrollo completo de multisig en Taproot. La novedad aquí es que utiliza el intercambio secreto de Shamir, una forma inteligente de compartir una clave privada entre un grupo utilizando tecnología de umbral. Shamir, que es la S en RSA, desarrolló un enfoque inteligente para permitir que cualquier grupo de personas recupere un secreto entre las acciones que se han distribuido, con la condición de que cualquier grupo más pequeño no pueda recuperar la clave privada (de ahí la condición de umbral). ). Hay algunas matemáticas elegantes de fondo, que utilizan la interpolación de Lagrange para ajustar un polinomio a un conjunto de puntos discretos. Me encantó esta parte del taller, ya que me recordó cómo Bitcoin utiliza matemáticas geniales para llegar a nuevas aplicaciones financieras.

Hay una geometría muy simple que transmite la idea básica. Con dos puntos cualesquiera en un plano, puedes encontrar la línea que conecta los dos puntos resolviendo la pendiente y la intersección. Con tres puntos cualesquiera, puedes encontrar una ecuación cuadrática. Con cuatro puntos cualesquiera, puedes encontrar una ecuación cúbica, y así sucesivamente. La interpolación de Lagrange generaliza esta intuición y el intercambio de secretos de Shamir la aplica para recuperar una clave privada. FROST implementa esto, para mostrar que cualquier número fijo de acciones de una clave privada puede revelar esa clave privada, pero no menos.

Pensamientos finales

La actualización Taproot tiene algunos años, pero nunca la entendí realmente hasta ahora. Es un tour de force de las matemáticas aplicadas. Soy optimista en cuanto a que esto desencadenará nuevas aplicaciones financieras, mayor privacidad y mejores billeteras. Para mí, ha inspirado un camino para repensar las transacciones entre bancos utilizando este nuevo conjunto de herramientas que exploraré este año.

Jimmy es un excelente educador. Ha hecho el arduo trabajo de procesar toda la información dentro de las Propuestas de mejora de Bitcoin (BIP) y las ha digerido en sus diapositivas. Si está considerando este taller, definitivamente le recomiendo que tome su taller de dos días de Programación Blockchain, pase más de 100 horas leyendo y absorbiendo su libro Programación de Bitcoin, o tome mi futura clase en línea sobre Fundamentos de Bitcoin. Jimmy dirigió su clase a los desarrolladores y pasamos la mitad del tiempo codificando Taproot en Python entre cada una de las miniconferencias. Si se siente cómodo con la codificación y está dispuesto a aprender toda la infraestructura específica de Bitcoin, le recomiendo la clase. Si aún desea saber qué sucede bajo el capó sin codificarse, manténgase en contacto con este boletín mientras comunico estas ideas a una audiencia más amplia y no técnica. Concluiré con algunas notas técnicas a pie de página.

Notas técnicas

1. Uno de los principios principales de Taproot es minimizar la huella en la cadena. Hay un ejemplo que creo que fue demasiado lejos: las claves públicas exclusivas para x. Las claves públicas en Bitcoin son puntos de una curva elíptica, por lo que tienen una coordenada x y ay. Existe una manera inteligente de representar una clave pública en forma comprimida con solo la coordenada x y el signo de la coordenada y. Esto utiliza el pequeño teorema de Fermat y la simetría única de la curva elíptica sobre el eje x. Taproot lo llevó más allá al utilizar como punto de partida que la coordenada y es par. Si alguna vez la coordenada y es impar, el desarrollador puede invertir el signo de la clave privada para que la coordenada y resultante de la clave pública resulte par. Esto requiere probar constantemente el signo de la coordenada y en la parte posterior, lo que termina siendo molesto. Siento que esto cuesta más gastos generales al desarrollador con un beneficio mínimo, es decir, ahorrar solo un byte en la cadena de bloques.
2. El árbol Taproot Merkle ahora está ordenado. Antes de la raíz, los árboles Merkle utilizados para la verificación del cliente ligero no estaban ordenados y requerían el envío de un mensaje bastante elaborado entre el nodo completo y el cliente ligero, algo llamado bits de bandera. Todo esto es más sencillo si el árbol se ordena desde el inicio. Hace que la prueba de inclusión sea mucho más fácil. ¡Ojalá se hubieran clasificado también los árboles Merkle anteriores!
3. La principal distinción entre MuSig y FROST es la generación de claves individuales. En MuSig, los individuos llegan al coordinador de MuSig con las llaves, mientras que en FROST el distribuidor distribuye las llaves. Esta necesidad de un distribuidor confiable de FROST no es trivial y es probablemente el único inconveniente que veo en este momento. Con el tiempo habrá formas de entregar las claves de forma distribuida, pero eso aún está bajo investigación.
4. Los ordinales y las inscripciones son el uso principal de Taproot hoy en día, pero espero que esto cambie a medida que Bitcoin crezca.

Respondo preguntas sobre Bitcoin en la versión paga de este boletín, así que envíelas a korok@tamu.edu.