Aspectos destacados del nuevo taller técnico de Jimmy Music, Programming Taproot.
El mes pasado asistí al viaje inaugural de Programming Taproot, un nuevo taller que el desarrollador de Bitcoin Jimmy Music acaba de lanzar. Celebró el taller de un día en Bitcoin Commons en el centro de Austin. Es un seguimiento de su exitoso taller de dos días Programming Blockchain que dirige en todo el mundo, que finalmente se convirtió en la base para su excelente libro Programming Bitcoin. Hablaré sobre los aspectos más destacados del taller y las ideas principales.
[Esta publicación es más técnica que otras. No tengas miedo. Incluso si no entiendes todo, guarda esta publicación y vuelve a ella a medida que se desarrolla tu educación sobre Bitcoin. Estoy en proceso de desarrollar una clase en línea que permitirá a una audiencia educada pero no técnica comprender completamente el contenido de una publicación como esta.]
El gran concepto en Taproot es que permite una mayor complejidad y privacidad en los scripts de Bitcoin. Las transacciones utilizando Taproot no se verán en la cadena de bloques diferentes a las transacciones de Bitcoin más básicas, donde Alice envía dinero a Bob. Las transacciones avanzadas eran posibles utilizando scripts de Bitcoin antes de Taproot, pero revelan muchos detalles sobre la transacción y hinchan la cadena. Taproot utiliza estructuras inteligentes de árboles de Merkle y nuevas firmas para ocultar toda esta información de la cadena de bloques, y en su lugar opera en el nivel de la billetera y del nodo. Es una evolución natural del software, empujando el procesamiento del backend fuera de la vista de la capa pública.
Firmas Schnorr
El primer paso de Taproot es la firma Schnorr. En este momento, Bitcoin utiliza firmas de algoritmo de firma digital de curva elíptica (ECDSA), que requiere una operación computacional costosa, división de campo finito. Schnorr tiene un algoritmo de firma y verificación más simple utilizando funciones hash. Como podrías imaginar, la función hash favorita de Satoshi es SHA-256. Y eso es lo que Schnorr utiliza. De hecho, Schnorr fue inventado cuando Satoshi escribió Bitcoin, pero estaba bajo protección de patente. La simplicidad de Schnorr es atractiva, y cumple la misma función que la firma ECDSA original de Bitcoin: demuestra que un propietario de bitcoins conoce su clave privada sin revelar esa clave privada. Los nodos completos realizan esa verificación cada vez que ese 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 bajo las firmas Schnorr.
Taproot
Taproot permite scripts ahora llamados scripts de Faucet, en un árbol de Merkle con hojas de Faucet y ramas de Faucet. Un árbol de Merkle es una estructura de datos ya utilizada en Bitcoin, diseñada para que los clientes ligeros verifiquen transacciones sin tener 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 de Merkle. En resumen, los árboles de Merkle son estructuras de datos útiles para demostrar fácilmente que algunos datos están almacenados en el árbol. Debido a que los árboles de Merkle son árboles de búsqueda binarios, pueden contener grandes cantidades de datos de manera eficiente: pueden tener 2128 niveles de profundidad, lo que permite muchos scripts diferentes en el árbol. Esto permite scripts complejos en transacciones financieras mucho más sofisticadas, con cálculos que ocurren fuera de la cadena.
MuSig
Una transacción multisig 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 los dolores de cabeza de administrar una sola clave, que podría impedir permanentemente el acceso a bitcoins si se pierde esa clave. Michael Flaxman tiene excelentes entrevistas en el podcast de Stephen Livera sobre los beneficios de multisig, y varias empresas de Bitcoin como Unchained y Casa han construido su negocio en torno a la custodia de multisig de terceros, donde un custodio tiene algunas de las claves.
El problema con multisig antes de Taproot es que es engorroso. Muestra todas las condiciones de gasto en la cadena, y también hincha la cadena ya que todas esas firmas y claves ahora deben formar parte de cada transacción.
MuSig permite que el multisig se realice todo 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 enviar los fondos en una transacción. Por ejemplo, grandes transferencias de fondos de empresa a empresa podrían requerir que tanto el CEO como el CFO firmen, o transferencias de un patrimonio familiar podrían requerir las firmas de todos los miembros de la familia. MuSig genera una clave pública de grupo a partir de las claves públicas individuales, luego genera firmas individuales a partir de la clave pública del grupo, y finalmente una firma de grupo a partir de las firmas individuales. Al final, una sola firma de grupo puede firmar la transacción de grupo para desbloquear la clave pública del grupo. La innovación principal es que la firma y verificación ocurren dentro de una sola transacción de Taproot.
¿Por qué es esto importante? Pre-Taproot, el multisig requería dos tipos de verificación. La primera era la verificación de las firmas individuales, que ocurría en la capa de firmas. La segunda era la verificación de las condiciones de gasto, que ocurría en la capa de script. Con Taproot, todo puede ocurrir en la capa de firmas, y esto conceptualmente es mejor. Una transacción multisig es simplemente una versión más compleja de una transacción de una sola firma y, por lo tanto, conceptualmente debe tratarse de la misma manera: en la capa de firmas. MuSig evita la necesidad de invocar scripts complicados para una transacción multisig. Y luego está el beneficio de privacidad, ya que estas transacciones MuSig no se ven diferentes a transacciones de igual a igual entre personas en la red de Bitcoin.
FROST
Las Firmas de Umbral Flexibles Optimizadas para Rondas (FROST) fueron el tema final, una estrategia para implementar firmas de umbral. Esta es la implementación completa de multisig en Taproot. La novedad aquí es que utiliza el intercambio de secretos de Shamir, una estrategia inteligente para compartir una clave privada entre un grupo utilizando tecnología de umbral. Shamir, quien es la S en RSA, desarrolló un método inteligente para permitir que cualquier grupo de personas recupere un secreto entre 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 matemáticas elegantes en el fondo, utilizando Interpolación de Lagrange para ajustar un polinomio a un conjunto de puntos discretos. Me encantó esta parte del taller porque 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 cualquier dos puntos en un plano, puedes encontrar la línea que conecta los dos puntos resolviendo la pendiente y la intercepción. Con cualquier tres puntos, puedes encontrar una ecuación cuadrática. Con cualquier cuatro puntos, 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 lo 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 de Taproot tiene varios años, pero nunca la entendí realmente hasta ahora. Es un tour de force de matemáticas aplicadas. Soy optimista de que esto desatará nuevas aplicaciones financieras, mayor privacidad y mejores billeteras. Para mí, ha inspirado un camino para repensar las transacciones de banco a banco utilizando este nuevo conjunto de herramientas que exploraré este año.
Jimmy es un gran educador. Ha hecho el trabajo duro de procesar toda la información en las Propuestas de Mejora de Bitcoin (BIPs) y las ha digerido para ti en sus diapositivas. Si estás considerando este taller, definitivamente te recomiendo que tomes su taller de dos días, Programming Blockchain, pases más de 100 horas leyendo y absorbiendo su libro Programming Bitcoin, o tomes mi futura clase en línea sobre Fundamentos de Bitcoin. Jimmy orientó su clase a desarrolladores, y pasamos la mitad del tiempo codificando Taproot en Python entre cada una de las mini-ponencias. Si te sientes cómodo programando y estás abierto a aprender toda la infraestructura específica de Bitcoin, te recomiendo la clase. Si aún quieres saber qué está sucediendo bajo el capó sin programar tú mismo, mantente en contacto con este artículo ya que transmitiré estas ideas a una audiencia más amplia y no técnica. Concluiré con algunas notas técnicas.
Notas Técnicas
- Uno de los principios fundamentales de Taproot es minimizar la huella en la cadena de bloques. Hay un ejemplo que creo que se llevó demasiado lejos, especialmente las claves públicas solo x. Las claves públicas en Bitcoin son puntos de una curva elíptica, por lo que tienen una coordenada x y una coordenada y. Hay una forma 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 lejos al usar como línea base que la coordenada y es par. Si alguna vez la coordenada y es impar, el desarrollador puede cambiar el signo de la clave privada para que la coordenada y resultante de la clave pública se convierta en par. Esto requiere probar constantemente el signo de la coordenada y en el backend, lo que termina siendo molesto. Siento que esto cuesta una mayor sobrecarga de desarrollo con un beneficio mínimo, especialmente, ahorrando solo un byte en la cadena de bloques.
- El árbol de Merkle de Taproot ahora está ordenado. Pre-taproot, los árboles de Merkle utilizados para la verificación del cliente ligero no estaban ordenados y requerían un mensaje bastante elaborado enviado entre el nodo completo y el cliente ligero, algo llamado bits de bandera. Todo esto es más sencillo si el árbol está ordenado en la concepción. Hace que la prueba de inclusión sea mucho más fácil. ¡Ojalá los árboles de Merkle anteriores también hubieran sido ordenados!
- La diferencia principal entre MuSig y FROST es la generación de las claves individuales. Con MuSig, las personas llegan al coordinador de MuSig con las claves, mientras que en FROST el vendedor distribuye las claves. Esta necesidad de un vendedor de confianza en FROST no es trivial y podría ser el único problema que veo en este momento. Con el tiempo, habrá formas de enviar las claves de manera distribuida, pero eso aún está en investigación.
- Los ordinales y las inscripciones son el uso principal de Taproot en la actualidad, pero espero/deseo que esto cambie a medida que crece Bitcoin.
Responderé preguntas sobre Bitcoin en la versión de pago de este artículo, así que envíalas a korok@tamu.edu
