El desarrollo de Bitcoin es lento, porque prevalece una cultura que impide que se implementen cambios en el protocolo que no hayan sido ampliamente probados. Con el tiempo, se han levantado críticas contra Bitcoin Core, el principal grupo de mantenimiento del protocolo, por este método de trabajo. Ahora, un grupo de desarrolladores tiene la intención de establecer nuevos procesos que cambien el estado actual del consenso de desarrollo del protocolo Bitcoin.

A través de la lista de correo de desarrolladores de Bitcoin Core, Antoine Riard, un científico informático que se especializa en diseñar mejoras para Bitcoin y Lightning, público un mensaje “para reanudar el experimento iniciado y marcar oficialmente el mantenimiento de procesos como ‘disponible’«. Esto supone la consolidación de un proceso alternativo para llegar a un consenso que permita integrar cambios en el protocolo de Bitcoin, específicamente todo lo relacionado con una propuesta que permita la ejecución de convenios (acuerdos o pactos).

Como indicó el informático, el año pasado un repositorio en GitHub que se enfoca en el desarrollo comunitario de propuestas de convenio, un tipo de contrato inteligente que podría ser el próximo cambio significativo en el protocolo Bitcoin.

Algunos de los objetivos anunciados en ese momento fueron construir un marco coherente para evaluar las propuestas de pacto, ver los puntos en común entre las propuestas si sus autores pudieran combinarlas, abrir el proceso de desarrollo de cambio de consenso más allá de los límites históricos de Bitcoin Core y mantener un archivo técnico de alta calidad de discusiones de consenso que han generado más de media década, desde la concepción intelectual hasta la activación promedio (al menos para segwit, schnorr, taproot).

Antoine Riard, desarrollador de Bitcoin y Lightning.

En concreto, la propuesta de Riard se llama Grupo de Trabajo de Primitivas de Contratos de Bitcoin. Surge como una respuesta práctica para abordar los obstáculos que Jeremy Rubin, exdesarrollador de Bitcoin Core, señaló cuando lanzó la campaña para activar la propuesta BIP-119, a través del cual se integraría en el protocolo un marco para crear transacciones más flexibles y contratos inteligentes con menos esfuerzo. Este cambio solo requiere un tenedor suave o horquilla blanda.

Según Riard, para llevar a cabo cambios en el desarrollo del consenso, que él y otros creen necesarios, basta con considerar tres premisas expuesto por Jeremy Rubin cuando describió los pasos para activar la propuesta BIP-119: se necesita una “lista de verificación codificada” para los cambios de consenso, que “el consenso no tiene memoria” y que “Bitcoin Core no es Bitcoin”.

Además, recordó en su mensaje que en el mismo lapso de tiempo AJ Townsend, desarrollador de Bitcoin, emprendió una iniciativa similar con el fork Bitcoin-inquisición.

Esta bifurcación es un procedimiento destinado a probar los cambios de política de consenso de Bitcoin Core en una red de prueba, donde la comunidad de investigadores de primitivos contratados puede ejecutar el código propuesto y medir su alcance y posibles fallas. También reconoció el trabajo de David Harding, investigador y escritor técnico, quien “cuidadosamente” reúne todas las propuestas en el periódico Bitcoin Optech.

Hasta ahora, el repositorio tiene varios problemas (asuntos). Entre estos, uno relacionado con la arquitectura delbóveda (o bóveda) y un esquema de pago para un grupo de minería de Bitcoin sin custodia.

Primitivas comerciales de Bitcoin

En programación, una primitiva es una función o procedimiento que está integrado en el lenguaje de programación. Suelen ser funciones básicas como entrada y salida de datos. Las primitivas de contrato se refieren a los componentes básicos de los nuevos esquemas de contrato inteligente para Bitcoin. Las primitivas se utilizan para crear contratos más complejos en Bitcoin. Por aquí el repositorio de GitHub se utiliza para archivar y documentar todas las primitivas.

Entre más de una docena de primitivas que se están desarrollando actualmente, podemos nombrar OP_CTV o OP_CHECKTEMPLATEVERIFY, propuesto por Jeremy Rubin en BIP-119; él anexo raíz principal, propuesta desarrollada por el propio Riard y reenfocada por el desarrollador de Bitcoin Joost Jager, tal como informamos en CriptoNoticias. Riard comenta que en este momento se está enfocando en su desarrollo.

También existe SIGHASH_ANYPREVOUT, un tipo de firma que se utiliza en el protocolo eltoo de Rayo; SIGHASH_GROUP, introducido en la bifurcación Taproot para combinar múltiples firmas en un solo grupo de firmas; OP-BÓVEDApropuesto por el programador James O’Beirne, que permite crear bóvedas con múltiples depósitos.

En el repositorio del proyecto Grupo de Trabajo de Primitivas de Contratos de Bitcoin se lee:

El objetivo de este proyecto es albergar la producción de I+D [investigación y desarrollo] de la comunidad de desarrollo de protocolos de Bitcoin en torno a las primitivas de contratación que impulsan una nueva clase de casos de uso de Bitcoin (bóvedas, cadenas de estado, grupos de pago, etc.).

Grupo de Trabajo de Primitivas de Contratos de Bitcoin, repositorio de GitHub

El espíritu colaborativo en el desarrollo de Bitcoin

En definitiva, la propuesta de Antoine Riard no parece ir tras una reivindicación de un proyecto que fracasó el año pasado. Por el contrario, de alguna manera la bandera del grupo de trabajo parece ser un acuerdo que respete las críticas que surgieron cuando Jeremy Rubin presionó a la comunidad de investigadores y desarrolladores para activar la bifurcación BIP-119.

En otras palabras, Riard propone que se llega a un acuerdo que exige exhaustividad en la investigación de los convenios de Bitcoin y otros proyectos de contratación de primitivas. En este punto, recordó que en la primera etapa del grupo de trabajo se realizaron 6 reuniones mensuales con más de 20 participantes “representando a la mayor parte de la comunidad”, indicó.

“Creo que se han llevado a cabo suficientes sesiones de grupos de trabajo y se han recopilado suficientes marcas de interés técnico para demostrar el valor mínimo de tal proceso”, enfatizó.

No creo que Bitcoin carezca fundamentalmente de propuestas técnicas convincentes para mejorar las capacidades de Bitcoin Script hoy en día, ni de la multitud de desarrolladores de protocolos experimentados e inteligentes para evaluar propuestas maduras de principio a fin y en múltiples dimensiones con un espíritu de independencia. Más bien, creo que lo que le falta a Bitcoin es una pequeña multitud de historiadores técnicos y archivistas para hacer el trabajo de evaluar, recopilar y preservar las propuestas de cambio de consenso y los desarrolladores de control de calidad para garantizar que cualquier propuesta de cambio de consenso tenga pruebas de campo de batalla de clase mundial antes de ser considerada para su implementación, idealmente con la mejor descentralización de Bitcoin y estándares de neutralidad de FOSS. [desarrollo de código abierto].

Antoine Riard, desarrollador de Bitcoin y Lightning.

Como hemos informado en CriptoNoticiasno hay unanimidad ni en contra ni a favor de la integración de los convenios en Bitcoin. Por un lado, desarrolladores como Matt Corallo, Gregory Maxwell, David Harding e incluso Russell O’Connor creen que antes de implementar un cambio como BIP-119 es necesario determinar el valor de esta propuesta para los usuarios y la compatibilidad con el código Bitcoin actual.

Por otro lado, otros investigadores, como Jameson Lopp, creen que los pactos tienen potencial. Por ejemplo, la protección de los fondos mediante la creación de condiciones de gasto específicas (como la inclusión de bloques de tiempo) o directamente a través de bóvedas (o bóvedas), que permite establecer retiros fraccionarios y que evitaría que un atacante se lleve todos los fondos si tiene acceso a las contraseñas de alguien.

Todo indica que solo el tiempo, como suele ocurrir en Bitcoin, y el trabajo colaborativo darán paso a las soluciones que buscan los desarrolladores de Bitcoin.