Estaba revisando los cambios de protocolo realizados por #Dusk y un detalle en Boreas captó mi atención.
Boreas no era una característica.
Boreas trataba de asegurar que la red interprete las transacciones de la manera.
Boreas introdujo límites entre cómo las transacciones aceptadas de clientes representados dentro de Rusk y almacenadas en el libro mayor.
Eso suena a ingeniería.
Creo que Boreas es más importante de lo que parece.
Una transacción pasa por etapas antes de convertirse en parte de los datos históricos de la cadena: ingreso, gestión del mempool, producción de bloques, validación de consenso y, finalmente, reejecución.
Si partes diferentes del nodo interpretan los bytes de manera distinta, el problema no es solo una transacción fallida.
Puede convertirse en un problema de consistencia.
Boreas lo aborda mediante una decodificación consciente de la versión en el límite de la red y canonizando las transacciones antes de que se confirmen en los bloques.
Lo interesante es que Dusk también conserva decodificadores para que los bloques antiguos aún puedan reejecutarse correctamente.
Así que el diseño no es simplemente: "cambiar el formato de la transacción".
Está más cerca de: "cambiar las reglas sin dejar la historia antigua en ambigüedad".
Esa es una exigencia para una red que se espera que gestione infraestructura financiera de larga duración.
Me hace mirar las actualizaciones de protocolo de otra manera.
Una hard fork exitosa no consiste en agregar nuevas capacidades.
También consiste en asegurarse de que cada capa esté de acuerdo sobre lo que significa la transacción.
Lo que estoy observando ahora es si este tipo de disciplina de protocolo se mantiene sólida a medida que Dusk agrega rutas de ejecución y aplicaciones financieras.
Porque la complejidad no desaparece cuando modularizas una blockchain.
Solo se desplaza a los límites, entre los módulos.
#dusk $DUSK @Dusk
Boreas no era una característica.
Boreas trataba de asegurar que la red interprete las transacciones de la manera.
Boreas introdujo límites entre cómo las transacciones aceptadas de clientes representados dentro de Rusk y almacenadas en el libro mayor.
Eso suena a ingeniería.
Creo que Boreas es más importante de lo que parece.
Una transacción pasa por etapas antes de convertirse en parte de los datos históricos de la cadena: ingreso, gestión del mempool, producción de bloques, validación de consenso y, finalmente, reejecución.
Si partes diferentes del nodo interpretan los bytes de manera distinta, el problema no es solo una transacción fallida.
Puede convertirse en un problema de consistencia.
Boreas lo aborda mediante una decodificación consciente de la versión en el límite de la red y canonizando las transacciones antes de que se confirmen en los bloques.
Lo interesante es que Dusk también conserva decodificadores para que los bloques antiguos aún puedan reejecutarse correctamente.
Así que el diseño no es simplemente: "cambiar el formato de la transacción".
Está más cerca de: "cambiar las reglas sin dejar la historia antigua en ambigüedad".
Esa es una exigencia para una red que se espera que gestione infraestructura financiera de larga duración.
Me hace mirar las actualizaciones de protocolo de otra manera.
Una hard fork exitosa no consiste en agregar nuevas capacidades.
También consiste en asegurarse de que cada capa esté de acuerdo sobre lo que significa la transacción.
Lo que estoy observando ahora es si este tipo de disciplina de protocolo se mantiene sólida a medida que Dusk agrega rutas de ejecución y aplicaciones financieras.
Porque la complejidad no desaparece cuando modularizas una blockchain.
Solo se desplaza a los límites, entre los módulos.
#dusk $DUSK @Dusk
