Si bien el alcance de las propuestas es bastante amplio, ¿cuál podría ser la razón por la que la “Gran Recuperación de Scripts” de Rusty Russell se considera el camino a seguir para el desarrollo de Bitcoin?

Nota de unicornio de Block: Rusty Russell es un desarrollador activo en la comunidad de Bitcoin y es muy respetado dentro de ella. Ha realizado contribuciones notables al desarrollo del kernel de Linux y ha participado en varios proyectos de desarrollo del núcleo de Bitcoin.

Cuando Bitcoin fue diseñado inicialmente, incluía un lenguaje de secuencias de comandos completo destinado a cubrir y respaldar cualquier caso de uso de seguridad potencial que los usuarios pudieran proponer en el futuro. Como dijo Satoshi Nakamoto 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ó establecido de por vida. Debido a eso, quería diseñarlo para admitir todos los tipos de transacciones que se me ocurrieran, pero en versiones posteriores, eliminamos la capacidad de ejecutar scripts arbitrarios. El problema era que cada función requería códigos de soporte especiales y campos de datos, ya sea que se usaran o no, lo que llevó a demasiados casos especiales. La solución fue el script, que generalizó el problema para que las transacciones puedan describir sus condiciones de una manera específica para ellas, y los nodos de la red puedan evaluar y validar estas condiciones.” - Satoshi Nakamoto, 17 de junio de 2010

El propósito principal era dar a los usuarios un lenguaje lo suficientemente genérico como para permitirles organizar sus tipos de transacciones según sus deseos. En otras palabras, les da a los usuarios el espacio para diseñar y experimentar con la forma en que escriben su propio dinero.

Antes de su desaparición, Satoshi Nakamoto eliminó 15 opcodes, desactivándolos por completo, y agregó un límite estricto en el tamaño de los bloques de datos que podrían operar en la pila del motor de script (520 bytes). Esto se debió a que efectivamente cometió un error, dejando atrás muchas formas en que scripts complejos podrían potencialmente ser utilizados para llevar a cabo ataques DOS en toda la red (enviando grandes cantidades de solicitudes basura, causando parálisis en la red), creando transacciones enormes y costosas que podrían colapsar los nodos.

Estos opcodes no fueron eliminados porque Satoshi Nakamoto considerara estas funcionalidades como peligrosas, o que la gente no debería explotarlas para construir lo que pudieran, sino simplemente (al menos en apariencia) porque representaban un riesgo para toda la red sin limitaciones de recursos, y por lo tanto podrían imponer los peores costos de verificación en la red sin restricciones.

Desde entonces, cada actualización de Bitcoin ha sido en última instancia una optimización de las características restantes, corrigiendo otras fallas menos graves que nos dejó Satoshi Nakamoto, y expandiendo la funcionalidad del subconjunto de scripts que nos ha dejado.

Gran recuperación de guiones

En la conferencia Bitcoin++ en Austin a principios de mayo, el desarrollador principal de Lightning Network, Rusty Russell, hizo una propuesta muy radical en su primera charla en la conferencia, donde básicamente propuso volver a habilitar la mayoría de los opcodes deshabilitados por Satoshi Nakamoto antes de su desaparición en 2010.

Desde la activación de Taproot en 2021 (Taproot es una actualización significativa de Bitcoin destinada a mejorar la privacidad, la seguridad y la escalabilidad), el campo del desarrollo ha estado algo sin rumbo. Es bien sabido que Bitcoin carece de escalabilidad suficiente para proporcionar verdaderamente servicios soberanos a cualquier población significativa en el mundo, o incluso para proporcionar escalabilidad de manera mínimamente confiable o custodia que pueda superar a instituciones custodiales y proveedores de servicios muy grandes, y no puede escapar verdaderamente de las limitaciones de la supervisión gubernamental.

Este artículo destaca una comprensión a nivel técnico de Bitcoin, que no es un tema de debate. El problema discutible es cómo abordar esta deficiencia, que es un tema muy controvertido. Desde la propuesta de Taproot, todos han estado proponiendo propuestas muy estrechas destinadas a resolver problemas que solo se pueden lograr con casos de uso específicos.

Por ejemplo, ANYPREVOUT (APO) es una propuesta que permite reutilizar las firmas en diferentes transacciones siempre y cuando los scripts de entrada y los montos sean los mismos. Esta propuesta está diseñada específicamente para optimizar la Red Lightning y sus versiones multiparte. CHECKTEMPLATEVERIFY (CTV) es una propuesta que requiere que las monedas solo se gasten en transacciones que coincidan exactamente con transacciones predefinidas. Esta propuesta está diseñada para ampliar la funcionalidad de las cadenas de transacciones prefirmadas haciéndolas completamente descentralizadas. OP_VAULT está diseñado específicamente para establecer un "tiempo de espera" para soluciones de almacenamiento en frío para que los usuarios puedan "cancelar" retiros de almacenamiento en frío enviándolos a configuraciones de múltiples firmas más frías para evitar que se filtren sus claves.

Hay muchas otras propuestas, pero creo que has entendido los puntos clave. En los últimos años, cada propuesta ha tenido como objetivo aumentar ligeramente la escalabilidad o mejorar una sola característica pequeña, ya que se consideraba deseable. Por eso estas discusiones no han avanzado. Nadie está satisfecho con otras propuestas porque no han cumplido los casos de uso que desean ver.

Aparte de los proponentes, nadie cree que ninguna propuesta sea lo suficientemente completa como para ser considerada un próximo paso razonable.

Esta es la lógica detrás de la 'Gran Recuperación de Scripts'. Al abogar y analizar la restauración integral de scripts, tal como lo diseñó originalmente Satoshi Nakamoto, podemos intentar explorar realmente todo el espacio funcional que necesitamos, en lugar de debatir y pelear sobre qué pequeña extensión de función es suficiente por ahora.

OPCODES (Códigos de operación)

• OP_CAT: Obtener dos datos de la pila y sumarlos para formar un solo dato.
• OP_SUBSTR: Acepta un parámetro de longitud (en bytes), obtiene un fragmento de datos de la pila, elimina los bytes de esa longitud y los vuelve a colocar en la pila.
• OP_LEFT y OP_RIGHT: Acepta un parámetro de longitud, toma un fragmento de datos de la pila y elimina bytes de la longitud especificada de uno u otro lado.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT y OP_DOWNSHIFT: Acepta un elemento de datos y realiza la operación de bits correspondiente en él.
• OP_2MUL, OP_2DIV, 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 los opcodes enumerados anteriormente para recuperarse, Rusty Russell propuso tres opcodes adicionales diseñados para simplificar la combinación de diferentes opcodes:

OP_CTV (o TXHASH/código de operación equivalente): Permite la aplicación de un cumplimiento detallado de ciertas partes de una transacción, requiriendo que esas partes sean exactamente coherentes con el contenido predefinido.

CSFS: Permite la verificación de firmas, no solo de toda la transacción, por lo que ciertas partes del script o datos utilizados deben estar firmados antes de que puedan ejecutarse.

OP_TWEAKVERIFY: Una validación de operación basada en Schnorr, que implica claves públicas, como agregar o restar claves públicas individuales de una clave pública agregada. Esto se puede utilizar para garantizar que cuando una parte gasta unilateralmente de una salida de transacción no utilizada compartida (UTXO), los fondos de todas las demás partes se envíen a una clave pública agregada que permite el gasto cooperativo sin requerir la firma de la parte que abandona el UTXO compartido.

¿Por qué lo estamos haciendo?

Las redes de capa 2 son básicamente extensiones de la capa base de Bitcoin, y están limitadas por las funcionalidades de la capa base. Antes de que se pudiera implementar la Red Lightning, se necesitaban tres bifurcaciones suaves separadas: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) y Testigo Segregado (SegWit).

Sin una capa base más flexible, es imposible construir redes Layer2 más flexibles. El único atajo es confiar en terceros, lo cual es muy directo, pero espero que todos aspiremos a eliminar la confianza en terceros tanto como sea posible de cada aspecto de interactuar con la escalabilidad de Bitcoin.

Necesitamos poder hacer cosas que actualmente son imposibles, como consolidar de manera segura a dos o más individuos en una única salida de transacción no utilizada (UTXO) y poder ejecutar sin confianza en la capa base. La flexibilidad actual de los scripts de Bitcoin no es suficiente. En el nivel más básico, necesitamos contratos, y necesitamos scripts para hacer cumplir realmente detalles más finos sobre la ejecución de transacciones para asegurar que un usuario que sale de manera segura de su propio UTXO no ponga en riesgo los fondos de otros usuarios.

Desde una perspectiva más elevada, esta es la funcionalidad que necesitamos:

Introspección: Necesitamos poder inspeccionar realmente detalles específicos sobre la transacción de gasto en sí misma en la pila, como “esta porción del dinero fluirá hacia una clave pública particular de una salida”. Esto me permite utilizar mi propia rama específica de Taproot para extraer mis fondos de forma independiente asegurando que no puedo tomar los fondos de nadie más. El script ejecutado garantizará que los fondos de otros propietarios se envíen de vuelta a direcciones compuestas por claves públicas de otros usuarios para evitar la pérdida de fondos causada por otros participantes.

Forward Data Carrying: Suponiendo que desarrollemos aún más el concepto de un único UTXO con un gran número de personas, donde cualquiera puede entrar y salir libremente. En este caso, necesitamos una forma de rastrear quién tiene cuánto dinero, generalmente usando árboles Merkle y sus raíces. Esto significa que cuando alguien sale, debemos asegurarnos de que "registre" quién tiene derecho a recibir qué como parte del cambio UTXO de los fondos de otras personas. Este es esencialmente un uso específico de la introspección.

Modificación de clave pública: Necesitamos asegurarnos de que las modificaciones a las claves públicas agregadas puedan ser verificadas en la pila. En un esquema de salida de transacción no gastada (UTXO) compartida, nuestro objetivo es facilitar la cooperación y el flujo eficiente de fondos a través de una clave pública agregada que contenga a todos los participantes. Cuando alguien sale unilateralmente de la UTXO compartida, necesitamos eliminar su clave pública individual de la clave pública agregada. Si todas las combinaciones posibles no fueron precalculadas, entonces la única opción es verificar si restar una clave pública de la clave pública agregada generaría una clave pública válida compuesta por las claves públicas individuales restantes.

Garantizando la seguridad: Como mencioné anteriormente, la razón para deshabilitar todos estos opcodes fue abordar los ataques DOS (causando bloqueos de red al enviar grandes cantidades de solicitudes basura), lo que podría llevar al bloqueo de los nodos que forman la red. Una forma de abordar este problema es limitar la cantidad de recursos que cualquiera de estos opcodes puede utilizar.

Cuando se trata de la verificación de firmas, la parte más costosa del script de Bitcoin, ya tenemos una solución para esto llamada Presupuesto de Operación de Firma (sigops). Cada uso de un opcode de verificación de firma consume un cierto "presupuesto", es decir, el número de operaciones de firma permitidas por bloque, estableciendo un límite estricto en el costo requerido para validar un bloque para una transacción a un usuario. Taproot cambia la forma en que esto funciona al no usar un límite de bloque global único, sino que cada transacción tiene su propio límite de sigops (operaciones de firma), proporcional al tamaño de la transacción. Esto esencialmente equivale al mismo límite global pero facilita entender cuántos sigops tiene disponible cada transacción.

El cambio en Taproot con respecto al límite de sigops (operaciones de firma) para cada transacción ofrece la posibilidad de un enfoque generalizado, que es también la sugerencia que Rusty Russell propuso con respecto a las limitaciones de varops. La idea es asignar un costo a cada opcode reactivado para tener en cuenta el peor escenario que cada opcode podría crear en términos del costo computacional más caro durante la verificación. Así, cada opcode tendrá su propio límite de "sigops", limitando la cantidad de recursos que puede consumir durante la verificación. Esto también estará basado en el tamaño de cualquier transacción que utilice estos opcodes, lo que facilitará la inferencia al mismo tiempo que se acumula en el límite global implícito de cada bloque. Esto abordará los ataques DOS (causando bloqueos de red al enviar grandes cantidades de solicitudes basura), que también fue la razón por la cual Satoshi Nakamoto inicialmente deshabilitó todos estos opcodes.

La Fuerza Motriz Hacia Adelante

Creo que muchos de ustedes podrían pensar, "Eso es un gran cambio." Entiendo esta perspectiva, pero creo que un aspecto importante para entender acerca de una propuesta es que no tenemos que hacerlo todo de una sola vez. El valor de esta propuesta puede que no resida necesariamente en restaurar completamente todas estas funcionalidades, sino más bien en examinar a fondo una amplia gama de componentes fundamentales y preguntarnos qué funcionalidades deseamos realmente.

Esto marcaría un cambio completo de los últimos tres años de discusiones y debates, donde simplemente debatíamos cambios menores y estrechos, cambios que solo afectaban ciertas funcionalidades. Es como un cuadrado donde todos pueden reunirse y contemplar colectivamente la dirección del futuro. Tal vez, al final, restauraremos todas estas funcionalidades, o tal vez solo activaremos algunas, porque el consenso consiste en ponernos de acuerdo sobre qué funcionalidades todos creemos que deben estar habilitadas.

Independientemente del resultado final, este puede ser un cambio que impacte positivamente en todo el diálogo sobre nuestra dirección futura. En realidad, podemos trazar y comprender completamente la situación, en lugar de avanzar a tientas al debatir el próximo paso en un camino oscuro.

Esta no es de ninguna manera la única forma de avanzar que debemos tomar, pero creo que presenta la mejor oportunidad para que decidamos qué camino tomar. Es hora de volver a trabajar juntos de manera práctica y efectiva.

Declaración:

1. Este artículo originalmente titulado “Great Script Recovery: Bitcoin's Road Ahead” es reproducido de [Bloque unicornio]. Todos los derechos de autor pertenecen al autor original [SHINOBI]. Si tiene alguna objeción a la reimpresión, por favor contacte al Gate Aprenderequipo, el equipo lo manejará tan pronto como sea posible.

2. Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales 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.