Je voulais poster ma répons en espagnol sur le forum espagnol mais je n’ai pas le droit de le faire, donc je la poste ici:
El mensaje que aparece a continuación fue traducido automáticamente por GPT‑6.1 Sol en el mismo hilo en el que preparé la respuesta original en francés, por lo que la traducción se realizó con mucho más contexto que una traducción automática basada únicamente en el texto final. El original en francés está disponible aquí: Respuesta detallada al documento «Comparativa técnica: Duniter v1 vs. Duniter v2».
Hola a todas y a todos:
Acabo de descubrir hoy este documento comparativo entre Duniter v1 y Duniter v2.
La respuesta de @kapis es correcta en términos generales, pero contiene algunos errores y no responde a todos los argumentos planteados. Puedo entenderlo: Duniter es un sistema complejo y algunos puntos requieren conocer al mismo tiempo la historia del proyecto, el funcionamiento de v1 y las decisiones arquitectónicas de v2.
Me habría gustado que me consultaran en su momento para ayudar a elaborar una respuesta más completa y precisa. Más vale tarde que nunca: esta es mi respuesta detallada.
Intentaré distinguir tres cosas:
- las observaciones factuales del documento que son correctas;
- los errores u omisiones técnicas;
- las decisiones de diseño de v2 que pueden cuestionarse legítimamente.
El documento representa un verdadero trabajo de investigación. Mi intención no es rechazarlo en bloque, sino corregir lo que me parece inexacto y situar las diferencias en su contexto.
Duniter v1 y Duniter v2 no son técnicamente idénticos
En este punto general, el documento tiene razón: Duniter v1 y Duniter v2 no utilizan el mismo código, el mismo motor de consenso ni el mismo modelo de cuentas.
V1 utilizaba una prueba de trabajo personalizada, un modelo UTXO y un protocolo propio de Duniter. V2 utiliza BABE y GRANDPA, un modelo de cuentas y el framework Polkadot SDK.
Por tanto, sería incorrecto afirmar que nada ha cambiado.
Sin embargo, constatar que los mecanismos técnicos han cambiado no basta para demostrar que hemos creado una nueva moneda o abandonado los principios fundamentales de la Ğ1.
El estado monetario de v1 —los saldos, las identidades, las membresías y las certificaciones— se utilizó como estado inicial de v2. El Dividendo Universal continuó con la misma periodicidad y la misma lógica de reevaluación. También se conservaron los parámetros fundamentales de la red de confianza: cinco certificaciones, periodo de validez, intervalo entre dos certificaciones y regla de distancia.
El motor cambió, pero el estado de la moneda y sus mecanismos económicos fundamentales continuaron.
Eso no significa que todos los demás cambios sean menores o incuestionables. Algunos modifican realmente la gobernanza o las hipótesis de confianza y deben analizarse como tales.
El comité técnico constituye efectivamente un punto de centralización
En este punto, comparto una parte importante de la crítica formulada en el documento.
En v2, una mayoría de dos tercios del comité técnico puede autorizar una actualización del runtime y hacer que se ejecute con un origen Root. Por tanto, no se trata únicamente de una función de mantenimiento del software: este mecanismo permite modificar las reglas ejecutadas por la blockchain sin pedir a cada operador de nodo que instale manualmente un nuevo binario.
En su momento propuse la creación de este comité porque me parecía la solución más sencilla para permitir las actualizaciones del runtime con los recursos humanos de los que disponíamos. Éramos muy pocas las personas que dominábamos suficientemente el código y todavía no disponíamos de las herramientas de asistencia al desarrollo y a la auditoría de las que podemos beneficiarnos hoy.
Este contexto explica la decisión, pero no basta para justificarla indefinidamente.
Este nuevo punto de centralización nunca me satisfizo plenamente. Antes incluso de conocer la existencia del fork y de este documento, ya había empezado a cuestionar esta organización.
Desde entonces he propuesto públicamente eliminar el comité técnico y confiar la autorización de las actualizaciones del runtime a una supermayoría de los forjadores activos: Propuesta: eliminar el comité técnico.
Ya se está desarrollando una implementación de este mecanismo. Para dejar tiempo al debate y a la experimentación, propuse conservar provisionalmente el comité para el runtime 1200, añadiendo al mismo tiempo la vía de autorización por parte de los forjadores, y volver a debatir su eliminación para el runtime siguiente.
Por tanto, reconozco claramente el problema planteado por el documento. Mi desacuerdo se refiere sobre todo a la idea de que esta situación sea una característica definitiva de v2 o una voluntad de abandonar la descentralización.
En v1, los forjadores ya validaban las evoluciones del protocolo
Es incorrecto afirmar que las reglas de Duniter v1 eran absolutamente inmutables después del bloque génesis o que una evolución requería necesariamente el acuerdo individual de todos los operadores de nodos.
Duniter v1 ya disponía de un mecanismo que permitía a los forjadores aprobar colectivamente la activación de una nueva versión del protocolo.
Primero se integraban las nuevas reglas en una nueva versión del software. A continuación, los forjadores que instalaban esa versión indicaban su disponibilidad en los bloques que producían. Esta señal consistía en un marcador concreto, el patrón 999, integrado en el nonce del bloque.
Duniter examinaba el último bloque producido por cada forjador presente en la ventana actual. Cuando la proporción requerida de forjadores había publicado el marcador, la blockchain autorizaba automáticamente el paso a la siguiente versión del protocolo.
En la última implementación de este mecanismo en v1, el umbral se fijó en más del 70 % de los forjadores de la ventana actual: código del mecanismo en Duniter v1.7.21.
Este mecanismo se utilizó realmente, en particular en enero de 2019 para el paso de la Ğ1 al protocolo v11.
En el tema Lanzamiento de Duniter 1.7, cgeek invitaba a los forjadores a instalar la nueva versión, indicaba que solo faltaban unas pocas personas «para que todo bascule» y HugoTrentesaux hablaba explícitamente de «participar en la votación de la 1.7».
El principio de este mecanismo ya se había debatido anteriormente en Evoluciones del protocolo hacia v11, v12, etc.. Allí se proponía que los bloques contuvieran una señal que permitiera medir si había suficientes forjadores preparados para activar las nuevas reglas.
No obstante, este mecanismo debe distinguirse del poder Root de Duniter v2.
En Duniter v1, los forjadores no podían inventar una regla arbitraria directamente desde la blockchain ni ejecutar una operación administrativa genérica. Las nuevas reglas tenían que haber sido escritas, publicadas y distribuidas en una nueva versión del software. Después, cada forjador expresaba su acuerdo al decidir instalar esa versión.
En Duniter v2, el runtime permite sustituir la lógica on-chain sin actualizar el binario de cada nodo. Actualmente, el comité técnico puede autorizar esta operación con una mayoría de dos tercios y un origen Root.
Por tanto, estos mecanismos no son técnicamente idénticos, pero se basan en una idea común: las personas responsables de producir los bloques validan colectivamente una evolución del protocolo.
La verdadera diferencia no es que las reglas fueran inmutables en v1 y modificables en v2. Ya eran modificables en v1.
La diferencia reside en la manera de autorizar y desplegar el cambio:
- en v1, los forjadores instalaban un software que contenía las nuevas reglas e indicaban su aprobación en los bloques;
- en v2, el comité técnico puede autorizar actualmente la sustitución del runtime on-chain;
- con el mecanismo que propongo para v2, los forjadores instalarían una versión que incluyera el nuevo runtime, su nodo indicaría automáticamente su aprobación y el runtime solo se actualizaría tras el acuerdo de una supermayoría.
Por tanto, mi propuesta de eliminar el comité técnico no pretende inventar una gobernanza completamente nueva. Más bien pretende recuperar el espíritu del mecanismo de v1 —la adopción de las nuevas reglas por parte de los forjadores—, conservando al mismo tiempo la ventaja técnica de las actualizaciones on-chain, que evitan provocar un hard fork y obligar a todos los nodos RPC a coordinarse en el mismo momento.
Por tanto, el documento tiene razón al señalar que el comité técnico dispone actualmente de un poder que no existía de esta forma en v1. Sin embargo, se equivoca cuando presenta los parámetros y las reglas de v1 como definitivamente inmutables después del génesis.
La subred de forjadores responde a una vulnerabilidad de seguridad de v1
El documento tiene razón al señalar que en v1 cualquier miembro podía participar en la producción de bloques, mientras que en v2 es necesario entrar en la subred de forjadores. Pero no presenta la principal razón de este cambio: corregir una vulnerabilidad importante del modelo de seguridad de v1.
En Duniter v1, poseer las credenciales secretas de cualquier cuenta de miembro era suficiente para poder forjar bloques utilizando esa identidad. No era necesario comprometer las cuentas de los forjadores que ya estaban activos.
Un atacante podía obtener las credenciales de unos quince miembros ordinarios que nunca hubieran forjado, iniciar otros tantos nodos forjadores bajo sus identidades y hacer aparecer estos nuevos forjadores en la red.
Con unos treinta forjadores activos en condiciones normales, añadir unas quince identidades controladas por un mismo atacante le habría permitido controlar aproximadamente un tercio del conjunto de forjadores. Unas pocas identidades adicionales habrían bastado para superar ese umbral.
La prueba de trabajo personalizada de v1 intentaba impedir que un número reducido de forjadores produjera demasiados bloques. Los forjadores que habían producido más bloques veían aumentar considerablemente su dificultad personal, lo que en la práctica excluía aproximadamente a un tercio de los forjadores más productivos.
Pero esta protección podía eludirse si un atacante controlaba suficientes identidades de miembros.
El atacante podía compartir su potencia de cálculo entre todas las identidades comprometidas y concentrarla sucesivamente en la que todavía no estuviera penalizada por la dificultad personalizada. Cuando una identidad quedaba temporalmente excluida o demasiado penalizada por haber producido demasiados bloques, la potencia de cálculo podía trasladarse a otra identidad controlada.
Por tanto, no era necesario hackear a unos quince forjadores existentes ni disponer de quince máquinas potentes independientes. Bastaba con obtener las credenciales de unos quince miembros ordinarios y utilizar una potencia de cálculo común, rotando la identidad utilizada para forjar.
El riesgo no era meramente teórico, porque las cuentas de los miembros no se habían concebido ni se utilizaban como cuentas de infraestructura crítica.
Muchos miembros conservan sus credenciales en papel o las introducen en presencia de la persona que los acompaña. A lo largo de los encuentros Ğ1 en los que he participado, yo mismo he visto las credenciales de varias decenas de miembros. Si hubiera actuado de mala fe, habría podido copiar algunas sin dificultad y esperar al momento oportuno para intentar un ataque.
No digo esto para acusar a las personas afectadas. Su comportamiento era comprensible para una cuenta utilizada como monedero personal. El problema procedía del protocolo: hacía depender la seguridad del consenso de secretos que sus titulares no tenían ningún motivo para considerar claves de validación de una blockchain.
Además, este ataque habría sido muy difícil de detectar por parte de las víctimas. El uso de sus credenciales para forjar no habría provocado ningún movimiento visible en su cuenta.
Las aplicaciones de uso general tampoco mostraban ninguna alerta que indicara que una identidad estaba produciendo bloques. En Cesium era necesario abrir la vista técnica de la red y reconocer la propia clave entre los productores de bloques, algo que la gran mayoría de los usuarios nunca hacía.
Por tanto, un atacante habría podido copiar las credenciales de miembros ordinarios, utilizarlas mucho tiempo después y forjar bajo sus identidades sin que se dieran cuenta.
La subred de forjadores se creó principalmente para separar dos niveles de responsabilidad:
- ser miembro y utilizar la moneda;
- participar en el consenso y en la seguridad de la blockchain.
Para convertirse en forjador en v2 ya no basta con poseer las credenciales de una cuenta de miembro. Es necesario recibir una invitación, obtener certificaciones específicas de otros forjadores y respetar una licencia dedicada a las responsabilidades y prácticas de seguridad asociadas a esta actividad.
Los certificadores deben comprobar, en particular, que el candidato comprende los riesgos, sabe administrar su nodo y aplica una higiene de seguridad adecuada. Además, el funcionamiento del validador se basa en claves de sesión propias del nodo: comprometer las credenciales ordinarias de un miembro ya no basta para transformar inmediatamente su cuenta en productora de bloques.
Evidentemente, este mecanismo no garantiza que ningún forjador pueda ser comprometido. Sin embargo, aumenta considerablemente el coste de un ataque y evita que la escasa protección de las cuentas de miembros ordinarios ponga directamente en peligro el consenso.
Por tanto, la subred de forjadores no se creó para reservar la producción de bloques a un círculo privilegiado. Responde a una debilidad concreta de v1: la posibilidad de transformar secretamente cualquier cuenta de miembro comprometida en una identidad de forja.
Esto no impide debatir las modalidades adoptadas en v2. El sistema de invitaciones, el número de certificaciones requeridas y el límite de 32 autoridades son decisiones de protocolo que pueden revisarse.
Sin embargo, es necesario distinguir este debate legítimo del objetivo de seguridad al que responde la subred.
Permitir de nuevo que cualquier cuenta de miembro pueda forjar reintroduciría la vulnerabilidad de v1. Por tanto, cualquier solución alternativa debería impedir que un atacante pudiera constituir secretamente un grupo de forjadores utilizando credenciales copiadas de cuentas de miembros ordinarios.
No existe una cuenta sudo activa en la Ğ1
El documento indica que pallet_sudo está presente en el runtime. Es correcto en el sentido de que el código de esta pallet está compilado.
Sin embargo, no se definió ninguna cuenta sudo en el génesis de la Ğ1: la clave proporcionada a la configuración de producción es None. Por tanto, no existe una persona que posea una clave secreta con la que pueda utilizar sudo.
El poder Root actualmente relevante procede del mecanismo de actualización autorizado por dos tercios del comité técnico, no de una cuenta sudo oculta.
La presencia de esta pallet puede criticarse como una superficie de código innecesaria y podríamos eliminarla. Pero presentar su existencia como la de un superusuario activo induce a error sobre el funcionamiento real de la red.
Los mecanismos necesarios para los HTLC ya existían en v1
Este es uno de los errores factuales más importantes del documento.
La tabla afirma que Duniter v1 no disponía de ningún mecanismo nativo de intercambio con otras criptomonedas y que los intercambios atómicos serían una novedad introducida por pallet_atomic_swap en v2.
Sin embargo, Duniter v1 ya disponía de las primitivas necesarias para construir un HTLC:
XHXpara el bloqueo mediante un secreto;CLTV,CSVylocktimepara las restricciones temporales;SIG,&&y||para combinar firmas y distintas ramas de desbloqueo.
Y no se trataba únicamente de una posibilidad teórica.
El repositorio de Duniter v1 contiene un test de integración llamado Crosschain transactions. Este test crea dos cadenas, bloquea fondos con el mismo secreto, comprueba que las transacciones de reembolso no puedan utilizarse antes de que transcurra el plazo, revela después el secreto en una cadena y lo utiliza para desbloquear los fondos en la otra.
El test todavía puede consultarse aquí: test de integración transaction-crosschain.ts.
El commit de febrero de 2016 que introdujo este funcionamiento lleva explícitamente el título «Crosschain transactions are now working».
Varios desarrolladores también lo confirmaron públicamente:
- en 2020 expliqué que el protocolo se había diseñado intencionadamente para permitir los swaps y que faltaba principalmente el software destinado a los usuarios: GNU Taler + Duniter?;
- en el mismo debate, Vit confirmó que Duniter ya admitía estos mecanismos y que todavía era necesario integrarlos en los clientes: mensaje de Vit;
- en 2021, cgeek recordó que había implementado
CSVyCLTVen v1 para permitir los atomic swaps: Las transacciones; - en 2022, tuxmain volvió a indicar que los atomic swaps ya estaban implementados en Duniter v1, aunque todavía faltaba una plataforma que hiciera práctico su uso: Can a Ğ1 transaction be anonymous?.
Por tanto, la conclusión correcta es la siguiente: Duniter v1 disponía de las primitivas del protocolo y de pruebas funcionales de intercambio atómico, pero ninguna aplicación de uso general las ofrecía de forma sencilla.
La pallet de v2 no inventó esta posibilidad. Traslada al modelo de cuentas de Substrate una funcionalidad que queríamos conservar durante la transición desde el modelo UTXO.
Personalmente, no estoy especialmente apegado a esta pallet. Si nadie la utiliza y la comunidad considera que no tiene cabida en la Ğ1, estoy a favor de eliminarla.
Pero este debate debe partir de una constatación histórica correcta: los intercambios atómicos no fueron introducidos por v2.
La DHT era una posibilidad, no una solución demostrada
En los debates sobre v1, el uso de una DHT para distribuir las certificaciones se presentó en ocasiones como una posible solución para las dificultades de sincronización.
Era una posibilidad arquitectónica interesante. Sin embargo, hasta donde sé, nadie se comprometió a realizar el estudio completo, la implementación, las pruebas de carga y el mantenimiento necesarios para demostrar que respondía a todas las limitaciones de una red monetaria en producción.
Entre proponer una arquitectura y disponer de una solución probada, segura y utilizable existe una cantidad de trabajo considerable.
Una DHT podría haber mejorado la propagación o la sincronización de determinados documentos. Por sí sola, no habría resuelto la cuestión de su validación ni el problema del spam. Una red de difusión descentralizada también debe determinar qué acepta, conserva y retransmite.
No afirmo que una arquitectura basada en mayor medida en una DHT fuera imposible o negativa. Simplemente digo que no existía en un estado suficientemente desarrollado como para constituir una alternativa disponible de forma inmediata.
Las protecciones antispam de v1 eran insuficientes
El documento indica que las transacciones de v1 siempre eran gratuitas. Esto es correcto desde el punto de vista del usuario.
Sin embargo, la ausencia de comisiones no significa que v1 dispusiera de una protección suficiente contra la saturación intencionada. Las pruebas de carga que habíamos realizado habían puesto de manifiesto varias limitaciones. Decidimos no publicar esos puntos débiles con detalle mientras la red seguía funcionando, para no proporcionar instrucciones a un posible atacante.
Después del cierre de v1, un desarrollador publicó además una herramienta llamada explícitamente g1-killer: mensaje y publicación de la herramienta.
Esto no significa que un ataque exitoso fuera inevitable. Sin embargo, demuestra que la posibilidad de explotar los límites de v1 se tomaba en serio, incluso entre personas que conocían bien su funcionamiento.
Una red monetaria debe prever el comportamiento de actores que intenten saturar deliberadamente sus recursos.
Las comisiones son actualmente el mecanismo robusto mejor establecido que conozco para imponer un coste económico a este tipo de saturación. Eso no significa que considere deseables las comisiones en sí mismas. Si otra solución ofrece las mismas garantías sin hacer pagar a los usuarios, estoy totalmente dispuesto a estudiarla.
El compromiso adoptado en v2 consiste en mantener gratuitas las transacciones ordinarias cuando la carga es reducida y activar progresivamente las comisiones cuando la demanda supera el umbral previsto. Además, los miembros disponen de una cuota de reembolso.
El funcionamiento exacto es algo más matizado que el resumen del PDF: algunas transacciones especialmente largas pueden pagar comisiones relacionadas con su tamaño incluso por debajo del umbral de carga. Esta excepción pretende evitar que una sola operación masiva ocupe gratuitamente una parte importante de un bloque.
El diseño y sus compromisos se debatieron, entre otros lugares, aquí: Reembolso de las comisiones de transacción cuando el bloque no está lleno.
La neutralidad monetaria es una preocupación legítima. Pero una red que unos pocos actores pueden saturar gratuitamente también deja de ser neutral y accesible.
Por tanto, la cuestión no es simplemente «comisiones o ausencia de comisiones», sino: ¿cómo compartir un recurso limitado sin permitir que un actor prive de él a todos los demás?
Esta decisión puede mejorarse. Estoy a favor de cualquier propuesta alternativa lo bastante precisa como para poder implementarse y probarse.
Es necesario precisar el papel de la tesorería
La palabra «tesorería» puede dar a entender que se trata de una caja de la que el comité técnico puede disponer libremente. Este no es el funcionamiento ordinario configurado en la actualidad.
Esta cuenta recibe, entre otras cosas, las posibles comisiones de transacción y los pequeños saldos residuales eliminados cuando desaparece una cuenta. Las comisiones deben ir a algún lugar: destruirlas modificaría la masa monetaria, algo que queríamos evitar para mantener la coherencia con la lógica monetaria de la Ğ1.
El mecanismo normal de gasto de pallet_treasury está actualmente desactivado: su SpendOrigin está configurado como Never. Por tanto, no existe un procedimiento ordinario que permita al comité presentar gastos y atribuirse los fondos.
Sin embargo, es necesario introducir una precisión importante: como el comité puede autorizar actualmente una operación Root, dispone teóricamente de un poder lo bastante amplio como para modificar el runtime o desplazar fondos mediante otro mecanismo. Por tanto, sería excesivo afirmar que la tesorería se encuentra completamente fuera de su alcance.
La formulación más exacta es que la tesorería no dispone actualmente de ningún mecanismo ordinario de gasto, pero se encuentra dentro de un sistema en el que el comité todavía posee un poder Root. Esta es otra razón para revisar dicha gobernanza.
En el futuro, una posibilidad sería redistribuir automáticamente los fondos entre los forjadores siguiendo una regla inscrita en el protocolo. Esto permitiría sustituir Remuniter, que dependía de una caja administrada fuera de la blockchain, por un mecanismo transparente y verificable on-chain.
La cuestión de sustituir o adaptar Remuniter ya se había planteado públicamente: Herramientas que deben trasladarse de v1 a v2 o volver a desarrollarse para v2.
Por ahora, esta es solo una posible orientación. Las modalidades de una eventual remuneración de los forjadores deben debatirse colectivamente. Otra posibilidad sería utilizar estos fondos únicamente para reembolsar las cuotas o modificar por completo el mecanismo.
El cálculo de distancia introduce una nueva hipótesis de confianza
El documento describe correctamente una diferencia importante.
En v1, cada nodo recalculaba por sí mismo la regla de distancia durante la validación. En v2, este cálculo se realiza fuera de la cadena por varios oráculos y sus resultados se agregan posteriormente on-chain.
Esta decisión se tomó porque recalcular la distancia dentro del runtime para cada evaluación tendría un coste considerable y difícil de limitar. El uso de varios resultados y de su mediana reduce la influencia de un oráculo aislado.
No obstante, sigue siendo un cambio en las hipótesis de confianza: el runtime no reproduce por sí mismo el cálculo completo. Esta diferencia merece explicarse y supervisarse.
En cuanto a las 10 Ğ1, el documento era correcto en la fecha de su publicación: una evaluación negativa provocaba entonces la pérdida de la cantidad reservada.
Desde entonces, esta regla se ha modificado en el código. El depósito ahora se devuelve cuando el resultado es negativo y la sanción se ha sustituido por un periodo de espera de 48 horas antes de poder solicitar una nueva evaluación.
Esta modificación se integró el 6 de octubre de 2026: sustitución de la sanción por un periodo de espera.
Naturalmente, es necesario distinguir entre el código integrado en el próximo runtime y el runtime que se encuentre efectivamente activo cuando se lea este mensaje. Por tanto, no reprocho al documento que describiera correctamente la situación de abril de 2026. Simplemente aclaro que esta crítica ha sido escuchada y que el mecanismo está evolucionando.
El paso a v2 conservó el estado de v1, pero no su blockchain
El documento es correcto en este punto.
Los saldos, las identidades, las membresías y las certificaciones se transfirieron al estado inicial de v2. En cambio, los bloques y las transacciones anteriores de v1 no se integraron en el consenso de v2.
El historial de v1 es importado por el indexador y se presenta junto al historial de v2 en las aplicaciones. Por tanto, sigue siendo consultable, pero no forma parte de la blockchain v2 en el sentido de que los nodos v2 no reproducen por sí mismos todos los bloques de v1.
Deben evitarse dos formulaciones igualmente engañosas:
- afirmar que todo el historial se integró en la blockchain v2;
- afirmar que v2 abandonó o borró todo el historial.
La constatación correcta es que existe continuidad del estado monetario y de la red de confianza, con una conservación externa del historial anterior.
Continuidad monetaria no significa identidad técnica
Entiendo que la magnitud de los cambios pueda llevar a algunas personas a considerar v2 como una moneda nueva.
Desde mi punto de vista, la continuidad de la Ğ1 se basa ante todo en la continuidad de su estado monetario, sus miembros, su Dividendo Universal y las reglas fundamentales derivadas de la TRM. En estos aspectos, v2 continúa v1.
Pero esta continuidad no convierte en insignificantes los cambios de gobernanza. El comité técnico, las condiciones de acceso a la forja y el uso de oráculos modifican realmente determinadas distribuciones de poder y algunas hipótesis de confianza.
Por tanto, se pueden defender simultáneamente estas dos afirmaciones:
- v2 conserva el núcleo monetario y el estado de la Ğ1;
- algunos mecanismos institucionales y técnicos de v2 deben debatirse y, en ciertos casos, corregirse.
No creo que llamar «Ğ2» a v2 baste para resolver esta cuestión. Ese término expresa un desacuerdo político comprensible, pero no sustituye al análisis detallado de lo que se ha conservado, modificado o añadido.
A la inversa, la ausencia inicial de un fork no demuestra que todo el mundo aprobara cada una de las decisiones. Mantener una blockchain competidora requiere muchas competencias, infraestructura y coordinación. No puede deducirse el consentimiento de quienes no disponían de los medios prácticos para organizar una alternativa.
Estas decisiones no son perfectas ni definitivas
Comprendo las objeciones éticas expresadas en el documento y en este debate. No intento reducirlas a una incomprensión técnica.
Sin embargo, me parece importante distinguir:
- los cambios necesarios para sustituir un software que se había vuelto muy difícil de mantener;
- los compromisos relacionados con la seguridad y el rendimiento;
- las decisiones de gobernanza que pueden y deben seguir siendo cuestionables;
- los errores factuales, como la afirmación de que los mecanismos necesarios para los HTLC no existían en v1.
Desarrollamos v2 con las competencias, el tiempo y los recursos de los que disponíamos. Algunas decisiones nos parecían entonces las soluciones más realistas. Eso no significa que todas fueran óptimas ni que deban convertirse en intocables.
El comité técnico es un ejemplo concreto de una decisión que defendí inicialmente y que hoy deseo cuestionar. El mecanismo de sanción en caso de evaluación negativa de la distancia es otro ejemplo de una regla que ha sido corregida.
Por tanto, no pido que v2 sea aceptada sin críticas. Pido que las críticas se basen en una descripción exacta del funcionamiento de v1 y v2, y que tengan en cuenta que el protocolo sigue evolucionando.
Me gustaría mucho poder conversar directamente con Victor sobre estos puntos. Su documento plantea preguntas reales, pero algunas de sus conclusiones se basan en información incompleta, especialmente en lo relativo a las evoluciones del protocolo v1, los HTLC, sudo, la tesorería y la razón de ser de la subred de forjadores.
Aunque no lleguemos a estar de acuerdo en todo, nos interesa confrontar nuestros argumentos con precisión y evitar que los errores factuales mantengan una separación innecesaria entre las comunidades.
La crítica es útil cuando nos ayuda a identificar los puntos de centralización, revisar nuestras decisiones y construir mecanismos mejores. Espero que esta respuesta pueda servir como base para un diálogo más directo y sereno.
Eloïs