Asumí que el significado de una transacción quedaba fijado en el momento en que existían sus bytes: la decodifico una vez y obtengo la misma respuesta en todas partes. El changelog propio de Rusk para la actualización Boreas trata eso como algo que hay que diseñar, no como algo que pueda darse por sentado.
Boreas incorporó una decodificación de transacciones dependiente de la versión, vinculada a un hardfork específico, además de una selección de formato gobernada por hardfork para cómo se vuelven a reproducir los bloques antiguos. El código ahora tiene dos tipos explícitamente separados, CanonicalTransaction y LedgerTransaction, separando la representación en memoria de una transacción del formato en el que realmente se persiste en el ledger. Incluso hay una prueba de regresión dedicada únicamente para decodificar correctamente transacciones anteriores a la era Aegis durante la serialización de bloques.
Eso solo se vuelve necesario una vez que la decodificación de transacciones tiene que tener en cuenta diferentes eras de protocolo y etapas de procesamiento: recién recibidas del cable desde un cliente, almacenadas en memoria como un objeto canónico, y reproducidas de un bloque que es anterior a las reglas actuales.
Lo que significa que una actualización de protocolo no es segura solo porque las nuevas transacciones funcionen bajo las nuevas reglas. Solo es segura si esas nuevas reglas no rompen en silencio la capacidad de reproducir correctamente el estado histórico del ledger bajo las reglas que lo produjeron. Esta es la clase de fallo por desajuste de versión que la compatibilidad de reproducción histórica y la decodificación condicionada por hardfork están diseñadas para evitar.
"Una transacción solo es fiable si cada etapa que la toca está de acuerdo en lo que significa".
Lo que realmente me gustaría ver: una reproducción real de un bloque pre-Aegis en un nodo actual sin cambiar cómo se decodifican sus transacciones históricas bajo las reglas aplicables, no solo una prueba de regresión que pase de forma aislada.
#dusk $DUSK @Dusk
Boreas incorporó una decodificación de transacciones dependiente de la versión, vinculada a un hardfork específico, además de una selección de formato gobernada por hardfork para cómo se vuelven a reproducir los bloques antiguos. El código ahora tiene dos tipos explícitamente separados, CanonicalTransaction y LedgerTransaction, separando la representación en memoria de una transacción del formato en el que realmente se persiste en el ledger. Incluso hay una prueba de regresión dedicada únicamente para decodificar correctamente transacciones anteriores a la era Aegis durante la serialización de bloques.
Eso solo se vuelve necesario una vez que la decodificación de transacciones tiene que tener en cuenta diferentes eras de protocolo y etapas de procesamiento: recién recibidas del cable desde un cliente, almacenadas en memoria como un objeto canónico, y reproducidas de un bloque que es anterior a las reglas actuales.
Lo que significa que una actualización de protocolo no es segura solo porque las nuevas transacciones funcionen bajo las nuevas reglas. Solo es segura si esas nuevas reglas no rompen en silencio la capacidad de reproducir correctamente el estado histórico del ledger bajo las reglas que lo produjeron. Esta es la clase de fallo por desajuste de versión que la compatibilidad de reproducción histórica y la decodificación condicionada por hardfork están diseñadas para evitar.
"Una transacción solo es fiable si cada etapa que la toca está de acuerdo en lo que significa".
Lo que realmente me gustaría ver: una reproducción real de un bloque pre-Aegis en un nodo actual sin cambiar cómo se decodifican sus transacciones históricas bajo las reglas aplicables, no solo una prueba de regresión que pase de forma aislada.
#dusk $DUSK @Dusk
