AUTOR ORIGINAL: SHINOBI

Compilación original: Bloquear unicornio

A pesar del alcance de la propuesta, ¿cuál es la razón por la cual la "gran recuperación de scripts" de Rusty Russell podría ser el camino a seguir para el desarrollo de Bitcoin?

Bloquear unicornio Nota: Rusty Russell es un desarrollador activo en la comunidad Bitcoin y es muy respetado en la comunidad. Ha trabajado extensamente en el desarrollo del kernel de Linux y ha estado involucrado en muchos proyectos de desarrollo largo Bitcoin centrales.

Bitcoin fue diseñado originalmente para tener un lenguaje de scripting completo diseñado para cubrir y soportar cualquier caso de uso de seguridad potencial que los usuarios puedan encontrar en el futuro. Como dijo Satoshi Nakamoto antes de desaparecer:

"La esencia de Bitcoin es que una vez que se lanza la versión 0.1, el diseño central se determina para el resto del ciclo de vida. Por lo tanto, quería diseñarlo para soportar todos los tipos de comercio posibles que se me ocurrieran. El problema es que todo requiere códigos de soporte especiales y campos de datos, ya sea que se usen o no, lo que lleva a casos especiales más largos. La solución es un script que generalice el problema para que ambas partes puedan describir sus transacciones con condiciones específicas que la red de nodos evalúa o valida en función de esas condiciones". - Satoshi Nakamoto, 17 de junio de 2010

Su propósito es dar a los usuarios un lenguaje que sea lo suficientemente común como para que puedan organizar sus tipos de transacciones como deseen. Es decir, shorts para que los usuarios diseñen y experimenten con cómo escribir sus propias monedas.

Antes de desaparecer, Satoshi Nakamoto eliminó 15 de estos códigos de operación, los deshabilitó por completo y agregó un límite estricto en la pila del motor de secuencias de comandos que limitaba el tamaño de los bloques de datos que podían manipularse (520 bytes). Esto se debe a que en realidad metió la pata, dejando atrás muchas formas en que los scripts complejos podrían usarse para llevar a cabo ataques DOS en toda la red (enviando una gran cantidad de solicitudes de spam, haciendo que la red se cayera), creando transacciones enormes y costosas que colapsarían los nodos.

Estos códigos de operación no se eliminaron porque Satoshi Nakamoto pensara que las características eran peligrosas o que la gente no debería usarlas para construir algo que pudiera lograrse, sino simplemente (al menos en la superficie) debido al riesgo que representan para toda la red sin limitaciones de recursos, como los peores costos de validación que podrían imponer a la red sin limitaciones.

Desde entonces, cada actualización de Bitcoin ha terminado siendo una optimización funcional de las características restantes, corrigiendo otros defectos menos graves que nos dejó Satoshi Nakamoto y ampliando la funcionalidad de nuestro subconjunto de script restante.

Gran recuperación de script

En la conferencia Bitcoin ++ de Austin a principios de mayo, el desarrollador principal de Lighting Network, Rusty Russell, hizo una propuesta muy radical en su primer discurso en la conferencia, donde básicamente se le ocurrió la idea de volver a habilitar el gran anhelante Código de Operación que Satoshi Nakamoto había desactivado antes de que desapareciera en 2010.

En los años transcurridos desde la activación de Taproot en 2021 (Taproot es una actualización importante de Bitcoin que tiene como objetivo mejorar la privacidad, la seguridad y la escalabilidad), el espacio de desarrollo en realidad ha estado un poco sin rumbo. Todos sabemos que Bitcoin no es lo suficientemente escalable como para proporcionar realmente servicios autosoberanos a cualquier tamaño considerable de la población mundial, y es posible que ni siquiera pueda proporcionar escalabilidad a los proveedores de servicios que pueden superar a los custodios y proveedores de servicios muy grandes, y no pueden liberarse realmente de las restricciones de brazo largo de los gobiernos, de una manera que minimice la confianza o la custodia.

Este artículo apunta al nivel técnico de Bitcoin, que no es un tema a debatir. La pregunta sobre la que vale la pena discutir es cómo corregir esta falla, que es un tema muy controvertido. Desde que se introdujo Taproot, todos han presentado propuestas muy limitadas que apuntan a resolver problemas que solo se pueden lograr para casos de uso específicos.

Por ejemplo, ANYPREVOUT (APO) es una propuesta que permite reutilizar firmas en diferentes transacciones, tan largas como el script y la cantidad ingresada sean las mismas, y esta propuesta está diseñada específicamente para optimizar la Lighting Network y sus versiones más largas. CHECKTEMPLATEVERIFY (CTV) es una propuesta que requiere que las monedas duras solo se gasten en transacciones que coincidan exactamente con transacciones predefinidas, y esta propuesta está diseñada para ampliar la funcionalidad de las cadenas de transacciones prefirmadas haciéndolas completamente confiables. OP_VAULT está diseñado específicamente para establecer un "tiempo de espera" para una solución de almacenamiento en frío, de modo que los usuarios puedan "recuperar" del almacenamiento en frío enviándolo a una configuración de largo más fría para evitar que su Llave secreta se vea comprometido.

Hay otras propuestas más largas, pero creo que ya entiendes la esencia. En los últimos años, cada propuesta se ha diseñado para aumentar ligeramente la escalabilidad o mejorar una sola característica pequeña, ya que esto se considera deseable. Esa es la causa fundamental de por qué estas discusiones no han progresado. Nadie estaba contento con las otras propuestas porque no cumplían con los casos de uso que querían ver.

Nadie más que el patrocinador de la propuesta cree que cualquier propuesta sea lo suficientemente completa como para ser considerada un próximo paso razonable.

Esta es la lógica detrás de "Great Script Recovery". Al impulsar y analizar una recuperación completa de los scripts, como Satoshi Nakamoto diseñó originalmente, podemos intentar explorar todos los cortos que necesitamos, en lugar de discutir y pelear sobre qué pequeñas extensiones de funciones son lo suficientemente buenas en este momento.

OPCODES (código de operación)

• OP_CAT: Toma dos datos de la pila y los suma para formar un solo dato.
• OP_SUBSTR: Acepta un parámetro de longitud (en bytes), obtiene un dato de la pila, elimina los bytes de esa longitud y vuelve a colocarlo en la pila.
• OP_LEFT y OP_RIGHT: Acepta un parámetro de longitud que toma un fragmento de datos de la pila y elimina bytes de la longitud especificada de un lado u otro.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT y OP_DOWNSHIFT: Acepta un elemento de datos y realiza las operaciones de bits correspondientes en él.
• OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV y OP_MOD: Operadores matemáticos para operaciones de multiplicación, división y módulo (devolviendo el resto de la división).

Además de la lista anterior de Códigos de Operación para recuperar, Rusty Russell propone tres Códigos de Operación más diseñados para simplificar la combinación de diferentes Códigos de Operación:

OP_CTV (o TXHASH/equivalente Código de operación): Permite la aplicación detallada de ciertas partes de una transacción que deben ser exactamente como están predefinidas.

CSFS: Permite verificar las firmas, no solo para toda la transacción, lo que requiere que ciertas partes del script o los datos utilizados deben firmarse en orden para ser ejecutados.

OP_TWEAKVERIFY: valida las operaciones basadas en Schnorr que implican Llave pública, como sumar o restar Llave pública individuales del agregado Llave pública. Esto se puede utilizar para garantizar que cuando una parte deja unilateralmente una salida de transacción compartida no utilizada (UTXO), los fondos de todos los demás participantes se envían a una clave pública agregada que no requiere la firma de la parte saliente para realizar gastos cooperativos.

¿Por qué estamos haciendo esto?

Capa 2 redes son esencialmente extensiones de la capa base de Bitcoin y están limitadas funcionalmente por las funciones de la capa base. Lighting Network requiere tres bifurcaciones suaves separadas antes de que puedan implementarse: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) y SegWit (Segregated Witness).

Sin una capa base más flexible, no se puede crear una red de capa 2 más flexible. El único atajo es confiar en terceros, lo cual es muy simple y directo, y espero que todos aspiremos a eliminar a terceros confiables de todos los aspectos de la interacción con Bitcoin a escala tanto como sea posible.

Necesitamos poder hacer algo que actualmente no es posible en orden para fusionar de forma segura a más de dos personas en una sola salida de transacción no utilizada (UTXO) y poder actuar sin confianza en la capa base. La flexibilidad actual de Bitcoin Script no es suficiente. En el nivel más básico, necesitamos contratos, y necesitamos scripts que realmente puedan hacer cumplir detalles más finos sobre la ejecución de transacciones para garantizar que un usuario que salga de forma segura de su propio UTXO no ponga en riesgo los fondos de otros usuarios.

En una perspectiva más elevada, esto es lo que necesitamos:

Introspección: Necesitamos ser capaces de verificar detalles específicos en la pila sobre la transacción de gasto en sí, como "esta cantidad de dinero irá a esta clave pública de alguna salida". Esto me permite retirar mis fondos por mi cuenta utilizando mi propia sucursal específica de Taproot, al tiempo que me aseguro de que no puedo retirar los fondos de nadie más. El script ejecutado asegurará que los fondos de otros propietarios se envíen de vuelta a la DIRECCIÓN que consiste en la llave pública de otros usuarios, en caso de que otros participantes causen pérdida de fondos.

Forward Data Carrying: Digamos que tomamos el concepto de un solo UTXO, por ejemplo, con un gran número de personas, que cualquiera puede entrar y salir a su antojo. En este caso, necesitamos una forma de rastrear quién tiene más o menos dinero, generalmente usando el Árbol Merkle y sus raíces. Esto significa que cuando alguien se va, tenemos que asegurarnos de "registrar" quién tiene derecho a qué como parte del cambio UTXO para los fondos de todos los demás. Este es básicamente un uso específico de la introspección.

Modificación de llave pública: Necesitamos asegurarnos de que las modificaciones a la llave pública agregada se puedan verificar en la pila. En el esquema de intercambio de salida de transacciones no utilizadas (UTXO), nuestro objetivo es facilitar la cooperación y el flujo eficiente de fondos a través de una llave pública agregada que incluya a todos los participantes. Cuando alguien abandona unilateralmente un UTXO compartido, debemos eliminar su llave pública personal de la llave pública agregada. Si todas las combinaciones posibles no se calculan de antemano, la única opción es verificar que al restar una clave pública de la clave pública agregada se producirá una clave pública válida que consta de las claves públicas individuales restantes.

Cómo estar seguro: VAROPS Como dije anteriormente, la razón para deshabilitar todos estos códigos de operación es para abordar los ataques DOS (que hacen que la red se bloquee al enviar una gran cantidad de solicitudes de spam), que pueden hacer que los Nodos que componen la red se bloqueen. Una forma de resolver este problema es limitar la cantidad de recursos que puede utilizar cualquiera de estos códigos de operación.

Cuando se trata de verificación de firma, la parte más cara del script de Bitcoin, ya tenemos una solución de este tipo, que se llama presupuesto de operación de firma (sigops). Cada uso del código de operación de comprobación de firma consume un determinado "presupuesto", es decir, el número de operaciones de firma permitidas por bloque, que establece un límite estricto en el coste que puede generar una transacción para validar un bloque.

Taproot cambia esta forma de trabajar, no más largo usando un único límite global de bloqueo, sino que cada transacción tiene su propio límite de sigops (operación de firma), proporcional al tamaño de la transacción. Esto básicamente equivale al mismo límite global, pero es más fácil entender que cada transacción tiene menos sigops largos disponibles.

El cambio en el límite de sigops (operación de firma) de Taproot para procesar cada transacción abre la posibilidad de un enfoque de generalización, que es lo que sugirió Rusty Russell en términos de límites de varops. La idea es asignar un costo a cada Código de operación reactivado para cuenta el peor de los casos que cada Código de operación pueda crear, es decir, el costo computacional más caro incurrido en el momento de la validación. De esta manera, cada código de operación tendrá su propio límite de "sigops", limitando la cantidad de recursos que puede consumir durante el proceso de validación. Esto también se basará en el tamaño de cualquier transacción que use estos códigos de operación, por lo que se puede facilitar la inferencia mientras se bloquea hasta el límite global implícito por bloqueo.

Esto resolvería el ataque DOS (enviando muchas solicitudes de spam, haciendo que la red se bloquee) debido a estas transacciones de spam, y lo que causó que Satoshi Nakamoto deshabilitara inicialmente todos esos códigos de operación.

Impulso para avanzar

Estoy seguro de que la mayoría de ustedes pensará: "Esto es demasiado cambio". Puedo entenderlo, pero creo que un aspecto importante que hay que entender como propuesta es que no tenemos que hacerlo todo. El valor de esta propuesta no es necesariamente que todas estas características estén completamente restauradas, sino que vamos a echar un vistazo holístico a un vasto conjunto de componentes fundamentales y preguntarnos qué es lo que realmente queremos en términos de funcionalidad.

Sería un cambio completo con respecto a los últimos tres años de disputas y debates que solo hemos estado discutiendo sobre cambios pequeños y estrechos que solo tienen ciertas funciones. Es como una plaza donde todos pueden reunirse y mirar hacia el futuro. Tal vez eventualmente restauremos todas estas características, o tal vez terminemos activando solo algunas de ellas, porque el consenso es que estas son las que todos estamos de acuerdo en que deben activarse.

Independientemente del resultado final, este puede ser un cambio que impacte positivamente en toda la conversación sobre nuestra dirección futura. De hecho, podemos trazar un mapa y obtener una imagen completa de la situación, en lugar de andar a tientas debatiendo qué ruta turbia tomar a continuación.

De ninguna manera es el camino que tenemos que tomar, pero creo que es la mejor oportunidad para que decidamos qué camino queremos tomar. Es hora de empezar a trabajar juntos de nuevo de una manera práctica y productiva.