Bitcoin fue diseñado inicialmente con un lenguaje de scripting completamente desarrollado, destinado a abarcar y soportar cualquier caso de uso seguro potencial que los usuarios pudieran encontrar en el futuro. Como dijo el propio Satoshi antes de desaparecer:

"La naturaleza de Bitcoin es tal que una vez que se lanzó la versión 0.1, el diseño central quedó grabado en piedra por el resto de su vida útil. Por eso, quise diseñarlo para que soporte todos los tipos de transacciones posibles que se me ocurrieran. El problema era que cada cosa requería un código de soporte especial y campos de datos, ya sea que se usara o no, y solo cubría un caso especial a la vez. Habría sido una explosión de casos especiales. La solución fue un script, que generaliza el problema para que las partes que realizan la transacción puedan describir su transacción como un predicado que la red de nodos evalúa." - Satoshi, 17 de junio de 2010.

Toda la intención era dar a los usuarios un lenguaje lo suficientemente general como para que pudieran componer sus propios tipos de transacciones como mejor les pareciera, es decir, dar a los usuarios espacio para diseñar y experimentar con la forma en que programaron su propio dinero.

Antes de desaparecer, Satoshi arrancó 15 de estos códigos de operación, deshabilitándolos por completo y agregando un límite estricto a qué tan grande de un dato podría manipularse en la pila del motor de scripting (520 bytes). Esto se hizo porque, francamente, metió la pata y dejó abiertas una gran cantidad de formas en que los scripts complicados podrían usarse para atacar la denegación de servicio a toda la red, creando transacciones enormes y costosas de validar que bloquearían los nodos.

Estos códigos de operación no se eliminaron porque Satoshi pensara que la funcionalidad era peligrosa, o porque las personas no deberían poder construir las cosas que podían con ellos, sino únicamente (al menos aparentemente) debido al riesgo para la red en general de que se utilicen sin restricciones de recursos para limitar el costo de validación en el peor de los casos que podrían imponer a la red.

Cada actualización a Bitcoin desde entonces ha estado optimizando la funcionalidad dejada, corrigiendo otros defectos menos graves que Satoshi nos dejó y extendiendo la funcionalidad de ese subconjunto de script con el que nos quedamos.

THE GREAT SCRIPT RESTORATION

En Bitcoin++ en Austin a principios de mayo, el desarrollador de Core Lightning, Rusty Russell, hizo una propuesta bastante radical durante la primera presentación de la conferencia. Básicamente, lanzó la idea de revertir la mayoría de los códigos de operación que Satoshi desactivados en 2010 antes de que desapareciera.

Durante los últimos años, desde que Taproot se activó en 2021, el espacio de desarrollo ha estado francamente sin rumbo. Todos sabemos que Bitcoin no es lo suficientemente escalable como para servir realmente a una parte considerable de la población mundial de una manera autosoberana, y probablemente ni siquiera de una manera de confianza minimizada o custodia que pueda escalar más allá de custodios y proveedores de servicios muy grandes incapaces de escapar realmente del brazo largo del gobierno.

Cualquiera que entienda Bitcoin a nivel tecnológico entiende esto, no es un tema de debate. Lo que es objeto de debate, y muy polémico, es cómo abordar esta deficiencia. Desde Taproot, todos han estado presentando propuestas muy limitadas destinadas a abordar solo casos de uso muy particulares que podrían habilitarse.

ANYPREVOUT (APO), una propuesta para permitir que las firmas sean reutilizables en diferentes transacciones tan largas como el script y la cantidad de la entrada era la misma, se adaptó específicamente para optimizar Lightning y las versiones multipartitas de la misma. CHECKTEMPLATEVERIFY (CTV), una propuesta para hacer cumplir que las monedas solo se pueden gastar en una transacción que coincida exactamente con una transacción predefinida, fue diseñada específicamente para ampliar la funcionalidad de las cadenas de transacciones prefirmadas haciéndolas completamente inconfiables. OP_VAULT fue diseñado específicamente para habilitar un "período de tiempo de espera" para los esquemas de almacenamiento en frío, de modo que un usuario pueda "cancelar" un retiro del almacenamiento en frío enviándolo a una configuración multifirma aún más fría si sus claves se ven comprometidas.

Hay un montón de otras propuestas, pero creo que entiendes el punto. En lugar de intentar abordar de manera integral la expresividad y la programabilidad necesarias para escalar Bitcoin de una manera fundamental, cada una de las propuestas de los últimos años fue diseñada para dar un pequeño aumento en la escalabilidad o mejorar una sola funcionalidad estrecha considerada deseable. Creo que esta es la fuente de por qué ninguna de estas conversaciones va a ninguna parte. Nadie está contento con ninguna otra propuesta porque no se adapta al caso de uso que quieren que se construya.

Nada es lo suficientemente completo como para que alguien piense, fuera del creador de la propuesta, que es el siguiente paso sensato.

Esa es la lógica detrás de la Gran Restauración de la Escritura. Al impulsar y analizar una restauración integral del script tal como Satoshi lo diseñó inicialmente, podemos intentar explorar todo el espacio de la funcionalidad que necesitamos, en lugar de discutir y pelear sobre qué pequeña extensión de funcionalidad es lo suficientemente buena por ahora.

THE OPCODES

• OP_CAT: toma dos datos de la pila y los suma para formar uno.
• OP_SUBSTR: Toma un argumento de longitud en bytes y toma un fragmento de datos de la pila eliminando esa cantidad de bytes y volviéndolo a colocar.
• OP_LEFT & OP_RIGHT: Toma un argumento de longitud y elimina esa cantidad de bytes de un lado u otro de un dato en la pila.
• OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFT: Toma un elemento de datos de la pila y realiza la operación correspondiente < href="https://en.wikipedia.org/wiki/Bitwise_operation">bit en él.
• OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MOD: Operadores matemáticos para operaciones de multiplicación, división y módulo (devolviendo el resto de la división).

Los anteriores son los códigos de operación que se pretenden restaurar. Además de estos, Rusty propone tres más para simplificar la composición de diferentes códigos de operación.

• OP_CTV (O TXHASH/equivalente): Algo para permitir la aplicación granular que requiere que ciertas partes de una transacción sean exactamente como se definen de antemano.
• CSFS: Permite verificar las firmas con datos arbitrarios, en lugar de solo con toda la transacción. Esto le permite requerir que partes de un script, o los datos que utilizan, se firmen en orden para que se ejecuten.
• OP_TWEAKVERIFY: Verifica las operaciones basadas en Schnorr que involucran claves públicas, como agregar o restar claves públicas individuales de las agregadas. Esto se puede utilizar para garantizar que, en caso de que una de las partes abandone unilateralmente un UTXO compartido, los fondos de todos los demás se envíen a una clave pública agregada que no requiera que la parte que se fue firme en el orden para gastar de manera cooperativa.

POR QUÉ QUEREMOS HACER ESTO

Las capas 2 son inherentemente una extensión de la capa base de Bitcoin, están limitadas por su naturaleza en términos de funcionalidad por la funcionalidad de la capa base. Lightning requirió tres bifurcaciones de software separadas, CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) y Segregated Witness antes de que fuera posible implementarlo realmente.

Simplemente no se pueden construir capas 2 más flexibles sin una capa base más flexible. El único atajo que existe son los terceros de confianza, simple y llanamente. Eso es algo que espero que todos aspiremos a eliminar de todos los aspectos de la interacción con Bitcoin a escala que podamos.

Hay cosas que necesitamos poder hacer que simplemente no podemos hacer en este momento en orden para empaquetar de manera segura a más de dos personas en un solo UTXO de una manera que se pueda aplicar sin confianza en la capa base, el script de Bitcoin simplemente no es lo suficientemente flexible. En el nivel más básico, necesitamos convenios, necesitamos la capacidad de que el script realmente aplique detalles más granulares sobre la transacción que los ejecuta para garantizar cosas como que un usuario salga de manera segura de un UTXO por su cuenta no ponga en riesgo los fondos de otros usuarios.

A grandes vistas, este es el tipo de funcionalidad que necesitamos:

Introspección: Necesitamos ser capaces de inspeccionar detalles específicos sobre una transacción de gasto en sí misma en la pila, como "esta cantidad de dinero va a esta clave pública en alguna salida". Eso me permite retirar mi dinero por mí mismo utilizando una rama específica de Taproot propia, mientras me aseguro de que no puedo tomar el dinero de nadie más. El script que se ejecuta impondría por consenso que la cantidad correcta que todos los demás poseen se envíe de vuelta a una dirección compuesta por las claves públicas de los otros usuarios si me fuera.

Transporte de datos hacia adelante: Digamos que vamos aún más allá de la idea de un canal Lightning con más de dos personas en él, construimos un solo UTXO con una gran cantidad de personas donde cualquiera puede entrar y salir a su antojo. De alguna manera, casi siempre con un árbol de merkle y su raíz, necesitamos alguna forma de rastrear quién tiene cuánto dinero. Eso significa que cuando alguien se va, tenemos que ser capaces de garantizar que el "registro" de quién tiene derecho a qué es parte del cambio UTXO del dinero de todos los demás. Este es esencialmente un uso específico para la introspección.

Modificación de llave pública: Necesitamos la capacidad de garantizar que las modificaciones a las claves públicas agregadas se puedan verificar en la pila. El objetivo a apuntar en los esquemas de intercambio de UTXO es que haya una clave agregada con todos los involucrados que permita un movimiento cooperativo y más eficiente de fondos. Cada vez que alguien abandona un UTXO compartido unilateralmente, debemos eliminar su clave individual del agregado. Sin calcular previamente todas las combinaciones posibles de antemano, la única opción es poder verificar que al restar una clave del agregado se crea una clave válida compuesta por el resto de las claves individuales.

CÓMO HACER QUE ESTO SEA SEGURO: VAROPS

Como dije anteriormente, la razón por la que se deshabilitaron todos estos códigos de operación fue para eliminar los riesgos de ataques de denegación de servicio que podrían literalmente bloquear los nodos que componen la red. Hay una manera de resolver esto, restringir la cantidad de recursos que cualquiera de estos códigos de operación puede usar.

Ya tenemos una solución de este tipo cuando se trata de verificación de firmas, la parte más costosa de la verificación de scripts de Bitcoin. Se llama presupuesto sigops. Cada uso de un código de operación de verificación de firma consume un cierto "presupuesto" de operaciones de firma permitidas por bloque. Esto pone un límite estricto al costo que las transacciones pueden imponer a los usuarios para verificar un bloque individual.

Taproot cambió la forma en que esto funciona, en lugar de usar un solo límite de bloque global, cada transacción tiene su propio límite de sigops proporcional al tamaño de la transacción. Esto funciona esencialmente con el mismo límite global, pero hace que sea más fácil razonar en términos de cuántos sigops tiene disponibles una transacción individual.

El cambio en la forma en que Taproot maneja los límites de sigops en relación con cada transacción ofrece una forma de generalizar esto, que es lo que Rusty propone con un límite de varops. La idea es asignar un costo para cada uno de los códigos de operación reactivados para tener en cuenta el peor caso, es decir, el costo computacional más caro de validar, que cada código de cuenta podría crear. Con esto, cada uno de estos códigos de operación tendría su propio límite "sigops" para restringir la cantidad de recursos que podría consumir en la verificación. También se basaría en el tamaño de cualquier transacción que los utilice, por lo que hay que mantener la facilidad de razonamiento al respecto, sin dejar de sumar un límite global implícito por bloque.

Esto resolvería los riesgos de denegación de servicio que causaron que Satoshi deshabilitara todos estos códigos de operación en primer lugar.

FORWARD MOMENTUM

Estoy seguro de que muchos de ustedes están pensando "ese es un cambio demasiado grande". Puedo empatizar con eso, pero creo que un aspecto importante de este proyecto como propuesta a entender es que no tenemos que hacerlo todo. El valor de esta propuesta no es necesariamente volver a activar todo esto como un todo, es el hecho de que en realidad estaríamos mirando exhaustivamente un conjunto masivo de primitivas y preguntándonos qué es lo que realmente queremos de esto en términos de funcionalidad.

Sería un cambio completo de cara de los últimos tres años de disputas y discusiones sobre pequeños cambios estrechos que solo ayudan a ciertas funcionalidades. Es una carpa que podría reunir a todos bajo un mismo techo para evaluar de manera integral hacia dónde ir a partir de aquí. Tal vez terminemos volviendo a activar todo esto, tal vez terminemos activando solo algunas cosas porque el consenso es que eso es todo lo que necesitamos para habilitar la funcionalidad que todos están de acuerdo en que necesitamos.

Independientemente de cuál sea el resultado final, puede ser un cambio productivo en toda la conversación sobre hacia dónde vamos a partir de aquí. De hecho, podemos trazar un mapa y obtener una visión completa del terreno, en lugar de andar discutiendo sobre qué camino turbio y medio iluminado seguir a continuación.

Este no tiene por qué ser el camino que tomemos, pero creo que es nuestra mejor oportunidad para decidir cuál hacemos. Es hora de empezar a trabajar juntos de forma productiva de nuevo.

Disclaimer:

1. Este artículo es una reimpresión de [bitcoinmagazine], Todos los derechos de autor pertenecen al autor original [SHINOBI]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos lo gestionarán con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.