#dusk $DUSK
Hoy continúo viendo la actualización de Boreas para @Dusk . Lo que más me preocupa no es que Phoenix se jubile, ni tampoco que se hayan añadido algunas reglas adicionales de fork.
Más bien, es un problema más de fondo:
Después de la actualización del protocolo, ¿por qué una transacción de un momento anterior puede seguir conservando continuamente el mismo significado?
Esto suena como una tontería.
Pero después de un hard fork, los nodos ya están ejecutando con las nuevas reglas, mientras que en los bloques históricos todavía yacen la transacción de la versión anterior, el verificador anterior y las semánticas de ejecución anteriores.
Si hoy un nodo vuelve a interpretar esos bytes antiguos con el juego de reglas actual, la reejecución (replay) histórica podría fallar.
Así que en esta ocasión Boreas hace más claras las fronteras de versión del manejo de transacciones.
El ingreso en vivo (live ingress) sigue las reglas del protocolo actual.
El “sobre” (envelope) antiguo puede ser identificado y normalizado en la entrada.
Antes de entrar al ledger, se convierte en la transacción canónica.
Y los bloques históricos, continúan decodificándose y reejecutándose según las reglas de aquel entonces.
Creo que aquí lo realmente importante no es la “unificación del formato”.
Sino esto:
Las transacciones no solo tienen contenido, sino también la era del protocolo a la que pertenecen.
Aegis tiene las reglas de Aegis.
Boreas tiene las reglas de Boreas.
Un hard fork puede cambiar el futuro, pero no debería, por añadidura, reexplicar el pasado.
Por eso, cuando ahora miro una actualización de la cadena, no solo me fijo en “qué se añadió”.
Me importa más:
Después del despliegue de la nueva versión, ¿los nodos de hoy aún pueden entender con precisión qué pasó en esa cadena hace varios años?
Para una red que pretende ser una infraestructura de mercado regulado, esta continuidad histórica es realmente básica.
Se puede actualizar la cuenta.
Pero el pasado dentro de la cuenta no debe actualizarse con ella.
Hoy continúo viendo la actualización de Boreas para @Dusk . Lo que más me preocupa no es que Phoenix se jubile, ni tampoco que se hayan añadido algunas reglas adicionales de fork.
Más bien, es un problema más de fondo:
Después de la actualización del protocolo, ¿por qué una transacción de un momento anterior puede seguir conservando continuamente el mismo significado?
Esto suena como una tontería.
Pero después de un hard fork, los nodos ya están ejecutando con las nuevas reglas, mientras que en los bloques históricos todavía yacen la transacción de la versión anterior, el verificador anterior y las semánticas de ejecución anteriores.
Si hoy un nodo vuelve a interpretar esos bytes antiguos con el juego de reglas actual, la reejecución (replay) histórica podría fallar.
Así que en esta ocasión Boreas hace más claras las fronteras de versión del manejo de transacciones.
El ingreso en vivo (live ingress) sigue las reglas del protocolo actual.
El “sobre” (envelope) antiguo puede ser identificado y normalizado en la entrada.
Antes de entrar al ledger, se convierte en la transacción canónica.
Y los bloques históricos, continúan decodificándose y reejecutándose según las reglas de aquel entonces.
Creo que aquí lo realmente importante no es la “unificación del formato”.
Sino esto:
Las transacciones no solo tienen contenido, sino también la era del protocolo a la que pertenecen.
Aegis tiene las reglas de Aegis.
Boreas tiene las reglas de Boreas.
Un hard fork puede cambiar el futuro, pero no debería, por añadidura, reexplicar el pasado.
Por eso, cuando ahora miro una actualización de la cadena, no solo me fijo en “qué se añadió”.
Me importa más:
Después del despliegue de la nueva versión, ¿los nodos de hoy aún pueden entender con precisión qué pasó en esa cadena hace varios años?
Para una red que pretende ser una infraestructura de mercado regulado, esta continuidad histórica es realmente básica.
Se puede actualizar la cuenta.
Pero el pasado dentro de la cuenta no debe actualizarse con ella.
