La cuestión central: por qué Bitcoin necesitaba una remodelación con Segwit y Taproot
Testigo segregado (BIP de Pieter Wuile, Eric Lombrozo y Johnson Lau) y Taproot(BIP de Pieter Wuille, Jonas Nick, Tim Ruffing y Anthony Towns) son los dos cambios más importantes jamás realizados en el protocolo Bitcoin.
El primero cambió fundamentalmente la estructura de las transacciones de Bitcoin, y en el proceso de los bloques de Bitcoin, para abordar las limitaciones inherentes de la estructura de transacciones anterior. Este último rediseñó algunos aspectos del lenguaje de secuencias de comandos de Bitcoin, cómo se estructuran y validan las secuencias de comandos complejas, e introdujo un nuevo esquema para crear firmas criptográficas.
esos son ambos masivo cambios en comparación con, por ejemplo, agregar un código de operación único como CHECKTIMELOCKVERIFY (CLTV) que no hace más que permitir que el receptor opte por evitar que sus monedas se muevan durante un cierto período de tiempo.
Estos cambios se realizaron para abordar deficiencias y limitaciones muy reales de Bitcoin como sistema. Como capa fundamental para mantener un consenso global sobre el estado general de Bitcoin, es decir, todas las monedas no gastadas, Bitcoin es una innovación brillante e invaluable. Como medio para permitir directamente que todos realicen transacciones con esas monedas, es lamentablemente inadecuado para la tarea.
En los años transcurridos desde que se activaron Segregated Witness y Taproot, muchas de las deficiencias que abordaron se han olvidado. Las razones y los fundamentos detrás de las decisiones de diseño también se han distorsionado en un juego de teléfono con el paso del tiempo.
Ambos cambios al protocolo Bitcoin fueron soluciones a grandes problemas por derecho propio, pero también sentaron las bases para resolver otros problemas o realizar otras mejoras en el futuro.
En un momento en el que muchas personas nuevas se han unido a la red desde que se activaron estos cambios, vale la pena volver atrás y contextualizar las opciones de diseño.
Testigo Segregado (BIP 1411)
Cuando una transacción de Bitcoin gasta monedas, hace referencia a ellas mediante el índice de salida y el ID de transacción (TXID) de la transacción que las creó. Esto garantiza que las entradas de una transacción puedan identificarse de forma única y verificarse con absoluta certeza que nunca antes se han gastado.
Antes de Segregated Witness, la estructura de una transacción tenía este aspecto:
(Versión) (Entradas) (Salidas) (Tiempo de bloqueo)
El TXID es un hash de estos datos. El problema es que el ScriptSig (las firmas, preimágenes hash, etc.) que prueban que la transacción es válida son parte de las entradas. Puedes cambiar las pequeñas instrucciones del programa en un ScriptSig, o incluso cambiar las propias firmas criptográficas sin invalidarlas.
Estas “malaizaciones” cambian los TXID. Este es un gran problema para las transacciones prefirmadas.
Lightning Network, Ark, Spark, BitVM, Discreet Log Contracts (DLC), todas estas herramientas de escalamiento dependen de transacciones prefirmadas. Requieren crear una transacción de financiación sin firmar y prefirmar todas las transacciones que garanticen la correcta ejecución y seguridad de los fondos. antes firmar y confirmar la transacción de financiación. Todos estos sistemas utilizan autenticación multifirma para garantizar la seguridad frente al doble gasto (esto será importante más adelante).
Si esa transacción de financiación es maltratada y su ID de traducción cambia antes de que se confirme en un bloque, entonces todas las transacciones prefirmadas que aseguran los fondos de la segunda capa se invalidan. Ninguna de estas herramientas funciona en un entorno en el que cualquiera pueda alterar su TXID de financiación a medida que se propaga por la red.
Segregated Witness utiliza un código de operación indefinido como una especie de cortina ciega donde anteriormente estaba ScriptSig en las entradas, y mueve todos esos datos a un nuevo campo de transacción llamado “testigo”. La nueva estructura de transacciones se ve así:
(Versión) (Marcador/Bandera) (Entradas) (Salidas) (Testigo) (Tiempo de bloqueo)
La “cortina ciega” en las entradas permite a los nodos antiguos simplemente marcar todo lo que hay detrás como válido de forma predeterminada, y a los nodos más nuevos aplicar la lógica de validación adecuada. Un TXID tradicional ahora ya no cambiará debido a la alteración de los datos de ScriptSig en el testigo. Esto resolvió el problema de las transacciones prefirmadas y abrió la puerta a todas las soluciones de escalamiento que se construyen hoy en día y que las utilizan.
Pero el árbol merkle de transacciones en un encabezado de bloque solo se compromete con el TXID tradicional de una transacción, lo que crea un problema. No hay compromiso con ningún dato de testigo en un bloque. Esto requiere el compromiso del testigo y el ID de la transacción del testigo (WTXID). De la misma manera que se construye el árbol merkle normal de TXID, se construye y confirma un árbol del WTXID de cada transacción en el testigo de la transacción de coinbase.
La única diferencia es que la raíz del árbol tiene un valor de reserva, y eso es lo que se incluye en el testigo de coinbase. Esto permite que ese valor se utilice en el futuro para comprometerse con otros campos de datos nuevos en las reglas de consenso. Antes de la invención de este compromiso de árbol de testigos (que fue ideado por Luke Dashjr), se suponía que Segregated Witness requeriría una bifurcación debido al cambio en la estructura de la transacción y la necesidad de un compromiso de testigo separado en el encabezado del bloque.
El diseño de “cortina ciega” también permite actualizaciones arbitrarias del sistema de secuencias de comandos porque todos los datos nuevos son ignorados y no validados por los nodos que no los admiten. Esto permite que un nuevo sistema de secuencias de comandos evite todas las restricciones del sistema de secuencias de comandos heredado. La flexibilidad en las rutas de actualización aquí es lo que permitió que se integraran las firmas de Schnorr y permitirá firmas de resistencia cuántica si es necesario (las claves públicas de resistencia cuántica son generalmente más grandes que el límite de elementos de datos heredados de 520 bytes, al igual que las firmas).
Segregated Witness resolvió el problema fundamental de la maleabilidad de la identificación de transacciones que estaba frenando el desarrollo de segundas capas escalables que pueden llevar Bitcoin a más usuarios, pero también sentó las bases para cualquier mejora de secuencias de comandos que fuera necesaria para respaldar y mejorar esas segundas capas.
Firmas Schnorr2
Las firmas Schnorr fueron inventadas en 1991 por Claus Schnorr y rápidamente patentadas. De hecho, el esquema de firma ECDSA se inventó gracias a la patente de las firmas Schnorr. La patente de las firmas Schnorr expiró en febrero de 2010, poco más de un año después del lanzamiento de la red Bitcoin.
Si no fuera por la patente, es probable que Satoshi (y el resto del mundo) hubieran utilizado las firmas Schnorr desde el principio.
Hay algunos beneficios importantes que las firmas Schnorr tienen sobre ECDSA:
- Las firmas de Schnorr son demostrablemente seguras. La prueba matemática de que las firmas de Schnorr son infalsificables/irrompibles es mucho más sólida y hace menos suposiciones que la de ECDSA. Tener garantías de seguridad más sólidas para la criptografía que se encuentra en el corazón de Bitcoin es obviamente algo muy positivo.
- Las firmas Schnorr son inherentemente no maleables, lo que significa que los tipos de problemas con ECDSA que permitieron alterar una firma sin invalidarla simplemente no son posibles con las firmas Schnorr.
- Las firmas Schnorr tienen una linealidad que permite una construcción de claves aditiva, una generación de claves distribuidas y una generación de firmas distribuidas simples y eficientes. Esto permite a los usuarios simplemente “agregar” claves públicas individuales de Schnorr y producir firmas para esas claves públicas agregadas como un grupo.
Son más seguros, no maleables por terceros y abren la puerta a todo tipo de esquemas criptográficos eficientes y flexibles para mejorar la autenticación multifirma.
Anteriormente, cuando hablé de la maleabilidad de las transacciones, mencioné que todo lo que se creaba fuera de la cadena utilizando transacciones prefirmadas dependía de la autenticación de firmas múltiples para proteger los fondos de los usuarios. Esto creó un límite de escala implícito en lo que respecta al control compartido de los fondos. La multifirma heredada solo puede tener un tamaño limitado. Existen límites de tamaño de transacción y, para los testigos de la versión 0 (testigo segregado), existe un límite de tamaño de testigo. Sólo un número determinado de participantes podían unirse a una dirección de firmas múltiples, por lo que implícitamente sólo un número determinado de participantes podían compartir el control de los fondos.
Los esquemas de firmas múltiples basados en Schnorr escapan a este límite al agregar claves públicas en una única clave pública de grupo en lugar de construir un script con cada clave miembro incluida explícitamente de forma individual. Antes de Segregated Witness, una dirección con múltiples firmas solo podía tener 15 participantes; después de Segregated Witness, el tamaño máximo posible era de 20 participantes.
Con esquemas multifirma basados en Schnorr como MuSig5 y HELADA6 Estas limitaciones no existen, al menos a nivel de consenso. Los scripts de firmas múltiples pueden ser tan grandes como los usuarios deseen, siempre que sea práctico coordinar el proceso de firma dentro de un grupo del tamaño elegido sin interrupciones o negativas a participar.
Las mismas propiedades que permiten una agregación de claves como esta también permiten firmas de adaptadores eficientes, un esquema que permite a alguien producir una firma que permanece inválida hasta que se revela una información secreta. Esas propiedades también permiten un esquema basado en prueba de conocimiento cero para que un firmante produzca una firma sobre un mensaje que no puede ver.
Raíz principal3,4
Taproot es una evolución de un antiguo concepto llamado árboles de sintaxis abstracta merkelizada (MAST).7que es en sí mismo una especie de extensión de Pay-to-script-hash (P2SH)8. P2SH se creó originalmente para abordar dos problemas principales:
- Cuando se utilizan scripts personalizados de gran tamaño, la salida resultante no utilizada es mayor, lo que requiere más espacio para almacenar en el conjunto UTXO.
- Cuando se utilizan scripts personalizados de gran tamaño, el remitente paga una tarifa más alta, ya que el resultado del pago en su transacción es mayor, lo que desincentiva a las personas a pagar scripts personalizados potencialmente más seguros.
En lugar de incluir explícitamente todo el script en la salida, se incluye un hash de ese script y, al pasar el tiempo, el destinatario debe proporcionar el script completo en la entrada que se utiliza para verificarlo con el hash. Esto resolvió el problema del espacio de almacenamiento de salida no utilizado y hace que el costo de usar scripts más grandes recaiga en la persona que los usa en lugar de en quienes les envían fondos.
Esto todavía deja un problema. Los scripts personalizados pueden incluir múltiples formas de gastarlos, pero al dedicar tiempo, el usuario aún debe revelar la totalidad del script, incluidas las ramas del script que no son necesarias para verificar la condición bajo la cual se gasta realmente la moneda. Esto es increíblemente ineficiente en términos de espacio y deja al usuario que gasta con un costo más alto de lo necesario.
La idea detrás de MAST es tomar cada condición de gasto individual en un script de múltiples ramas y separarlas, construyendo un árbol merkle de cada ruta de gasto individual. Luego, se aplica un hash a cada ruta y la raíz de ese árbol merkle es la dirección del usuario. Al gastar tiempo, el usuario simplemente proporciona la ruta de gasto que está utilizando junto con la prueba merkle de que es una hoja en el árbol, junto con los datos necesarios para satisfacer ese script.
Esta estructura de árbol merkle resuelve los mismos problemas que P2SH, además de optimizar los costos de gasto del usuario de MAST (¡y también mejora su privacidad!).
Taproot toma este concepto y lo integra de una manera que preserva más la privacidad aprovechando las propiedades lineales de las firmas Schnorr. La mayoría de los tipos de contratos que la gente quiere celebrar tendrán un resultado optimista, en el que ambos usuarios simplemente acuerdan cómo distribuir los fondos. En tales casos, pueden simplemente firmar una transacción. Taproot toma la raíz MAST y “modifica” una clave pública de Schnorr, lo que da como resultado una nueva clave pública. Al “modificar” la clave privada con la misma raíz MAST, se llega a la clave privada correspondiente a la nueva clave pública.
Los usuarios ahora pueden simplemente gastar una salida usando esa clave modificada, sin dejar rastro de la presencia de un árbol MAST, o revelar la clave pública original y la raíz MAST junto con la ruta de gasto que realmente están usando. Además, si no desea incluir una ruta de clave, se puede usar un valor especial NUMS (Nothing Up My Sleeve) que probablemente no se pueda usar en lugar de una clave pública normal, dejando solo los scripts MAST como rutas de gasto válidas.
Aprovechando las opciones de diseño de Segregated Witness, Taproot también presentó tapscript, un nuevo sistema de secuencias de comandos. Los cambios principales aquí son desactivar OP_CHECKMULTISIG y OP_CHECKMULTISIGVERIFY. Se reemplazan por OP_CHECKSIGADD, que permite una forma más eficiente de verificar múltiples firmas. Esto, en combinación con la agregación de claves de Schnorr, permite la misma funcionalidad de firma múltiple que el script heredado.
Tapscript modifica adicionalmente OP_CHECKSIG y OP_CHECKSIGVERIFY para que solo funcionen con firmas Schnorr e introduce OP_SUCESS como reemplazo de OP_NOP (códigos de operación no definidos en scripts heredados). OP_SUCCESS está diseñado para permitir actualizaciones de código de operación más limpias y seguras que OP_NOP.
Límites de testigos
Dos aspectos han quedado sin discutir hasta ahora. El límite de peso de bloque introducido en Segregated Witness y el límite de tamaño de testigo aumentan en Taproot.
Ambas decisiones se han convertido en un punto de discordia entre una minoría muy activa de usuarios avanzados del ecosistema. No discutiré el aumento del tamaño de los bloques que fue parte de la introducción del límite de peso de los bloques, esto fue un compromiso en ese momento con los usuarios disidentes presionando por un aumento del tamaño de los bloques y considerado seguro por los participantes de la red en ese momento; pero la dinámica del descuento del testigo en sí es importante.
Las tarifas de transacción de Bitcoin se basan en la cantidad de datos de una transacción. Esto no tiene relación con la cantidad de valor que se transfiere. Es únicamente la cantidad de entradas y salidas (y testigos) y cuántos bytes de datos son. Recuerde que antes mencioné el hecho de que ScriptSig, o firmas y otros datos, se incluían en las entradas de la transacción antes de Segregated Witness. Se trata de una gran cantidad de datos incluidos en las entradas que no se incluyen en las salidas.
Eso significa Los insumos son más caros que los productos. en una transacción, y por un amplio margen. Esto crea un incentivo a largo plazo para que los usuarios también prefieran gastar grandes productos y crear nuevos cambios en lugar de recolectar y gastar muchos productos más pequeños. Este es un incentivo económico a largo plazo que alienta a los usuarios a hacer crecer perpetuamente el conjunto UTXO que es necesario para todos los nodos con validación completa.
El descuento de testigo está destinado a corregir ese margen de precio, haciéndolo minúsculo en lugar de enorme. Esto es increíblemente importante para incentivar económicamente la gestión responsable de UTXO, al menos en el vacío para los usuarios económicamente racionales que simplemente realizan transacciones.
Taproot eliminó los límites de tamaño existentes en el campo testigo de una transacción. En Segregated Witness ese límite era de 10.000 bytes. Esto se hizo porque el diseño de Taproot mitigó la posible construcción de transacciones costosas de verificar, y tratar de introducir tales límites en tapscript introdujo un gran grado de complejidad en Miniscript. El problema que tales límites debían evitar no afectó a Taproot e introdujo complejidad para una herramienta destinada a hacer que los scripts personalizados sean más seguros y accesibles tanto para los desarrolladores como para los usuarios.
El panorama general
Se eliminaron ambos cambios en Bitcoin masivo obstáculos para ampliarlo para que más personas puedan usarlo de forma autónoma, pero requirieron cambios igualmente masivos en partes fundamentales del protocolo.
Espero que ahora los lectores que antes no estaban familiarizados con todas estas opciones de diseño, y la lógica detrás de ellas, puedan apreciar el cuidado y la visión de futuro con la que fueron diseñadas. Bitcoin es una innovación asombrosa, realmente lo es, pero no puede brindar sus beneficios a nada que se acerque remotamente a un porcentaje considerable de la población.
Segregated Witness y Taproot sentaron dos piedras angulares que eran absolutamente necesarias para intentar abordar las deficiencias de escalabilidad de Bitcoin. Sin estas dos propuestas, o algunos cambios de protocolo alternativos que abordaran los mismos problemas, todas estas crecientes capas y sistemas de escalabilidad que tenemos hoy no estarían aquí.
Lightning, Ark, Spark, BitVM, DLC: ninguno de ellos sería posible de construir.
Ése es el panorama general. El Bitcoin de hoy no es perfecto, pero en realidad tiene una buena posibilidad de escalar a un grupo de personas lo suficientemente significativo como para tener un impacto real en el mundo, para ofrecer una verdadera alternativa a las personas que buscan optar por no participar. Esto se debe a estas dos actualizaciones de protocolo y a las barreras fundamentales que eliminaron.
¡Obtenga su copia de The Core Issue hoy!
No pierdas la oportunidad de ser propietario La cuestión central – ¡Con artículos escritos por muchos desarrolladores principales que explican los proyectos en los que trabajan ellos mismos!
Este artículo es la carta del editor que aparece en la última edición impresa de la revista Bitcoin, The Core Issue. Lo compartimos aquí como un vistazo temprano a las ideas exploradas a lo largo de todo el número.
(1) https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
(2) https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
(3) https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
(4) https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
(5) https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki
(6) https://github.com/siv2r/bip-frost-signing
(7) https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
(8) https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
Esta publicación El problema central: por qué Bitcoin necesitaba una remodelación con Segwit y Taproot apareció por primera vez en la revista Bitcoin y está escrita por Shinobi.
