-
Los nodos podrían validar transacciones con JavaScript sin tocar el código base.
-
Advierten que esta propuesta conduciría a nodos más lentos y complejos.
En medio de un torbellino de debates cada vez más encendidos dentro del ecosistema Bitcoin, avivado por el enfrentamiento entre los defensores y los detractores de los clientes Bitcoin Core y Bitcoin Knots, surge una propuesta intrigante, cargada de una intención innovadora.
Y es que esa propuesta de mejora de Bitcoin (BIP) sugiere que los operadores de nodos de esa red puedan personalizar la política de aceptación de transacciones en sus mempools (donde se almacenan las operaciones aún no confirmadas) sin modificar el software base, a través de scripts externos.
Un script es un archivo de instrucciones que un programa ejecuta de forma automática; en este caso, describe reglas de aceptación de transacciones.
El lenguaje propuesto para ejecutar el software es JavaScript, un lenguaje de programación ampliamente usado en aplicaciones web, particularmente la versión ES2020, que facilitaría escribir reglas complejas de manera más segura y reutilizable.
En términos prácticos, este BIP permitiría a operadores de nodos eliminar o extender políticas del mempool sin depender de los desarrolladores del software, compartir scripts entre distintas implementaciones y probar políticas de manera modular y segura.
Sin embargo, también plantea interrogantes sobre los efectos de políticas muy diversas en la propagación y confirmación de transacciones.
La iniciativa fue presentada el 23 de septiembre por el desarrollador Aiden McClelland, quien denominó el esquema como «Validación y retransmisión de mempool mediante políticas definidas por el usuario».
¿Cómo funcionaría esta nueva propuesta para Bitcoin?
Hoy, las políticas de aceptación están fijadas por el propio software de los nodos y sus configuraciones predeterminadas. Entre esos softwares, se destacan Core y Knots, entre otros.
El BIP aquí descripto plantea un cambio al permitir que cada nodo cargue un directorio de archivos «.js» que definen reglas de aceptación personalizadas. La extensión «.js» es la terminación que identifica a los archivos que contienen código JavaScript.
El documento describe que, al recibir una transacción o un paquete de transacciones, el nodo ejecutará estos scripts en orden numérico. Si todos devuelven un resultado exitoso y la validación de consenso se cumple, la transacción será aceptada en el mempool y retransmitida a la red.
En cambio, si algún script produce un error, la transacción será rechazada con el código «script-policy-validation-failed» (validación de política de script fallida), junto a un mensaje que identifique el script fallido.
Primeras conjeturas de la comunidad de Bitcoin
Las reacciones a la propuesta también muestran matices técnicos.
El desarrollador Chris Guida advirtió que implementar reglas personalizadas en JavaScript exigiría incluir gran cantidad de código para analizar transacciones (“transaction parsing”) dentro de los scripts, algo que podría volverlos lentos o complejos.
En su opinión, deberían ser rápidos y minimalistas. Además, recordó que los nodos ya disponen de la información de las transacciones preprocesada y que, si se expone mediante las funciones de acceso disponibles (“getters”, en inglés) se evitarían cálculos costosos cuando los scripts no necesiten ciertos datos.
Otros desarrolladores destacan aspectos positivos y dudas de fondo. Martin Mutonga considera que se trata de un avance importante para reducir la fricción en torno a las políticas de retransmisión del mempool.
Según expresó, un esquema modular, con una implementación de referencia en QuickJS (un motor de JavaScript ligero y eficiente) y C++ (un lenguaje de programación de alto rendimiento), facilitaría experimentos sin afectar el consenso de Bitcoin y pondría fin a años de desacuerdos sobre políticas inflexibles.
Sin embargo, otro desarrollador expresó escepticismo sobre la motivación de base del BIP y pidió que se aclare por qué permitir a los usuarios eliminar o ampliar políticas del mempool sería un objetivo valioso por sí mismo.
Finalmente, el autor de este BIP aclara que la propuesta no modifica las reglas de consenso de Bitcoin.
Es decir, los nodos que no adopten este sistema seguirán funcionando sin cambios. Además, las transacciones que un nodo rechace localmente por sus políticas personalizadas podrían igualmente ser aceptadas y propagadas por otros nodos de la red, lo que limita el alcance de las decisiones individuales al ámbito local sin afectar la validez global de las operaciones.
