Tras un hard fork, los formatos históricos de transacciones están muertos.
Dusk no les deja desaparecer tan fácilmente.

Boreas se activó en el bloque de reinicio de la red principal 4,414,095, introduciendo un manejo de transacciones consciente de la versión y separando los datos canónicos de transacción del sobre del libro contable, preservados en el historial.

Supongamos que un nodo está reproduciendo un bloque registrado antes de la transición. Esa transacción histórica todavía necesita su ruta de decodificación original para reconstruir correctamente el libro contable. Envía ese mismo formato histórico mediante la admisión al mempool en vivo después de la transición, y Dusk lo rechaza.

La parte extraña es que se requieren ambos resultados.

La reproducción pregunta qué es realmente lo que la cadena registró. La admisión en vivo pregunta qué formato acepta la cadena ahora. Dusk no puede usar una sola regla para ambos sin romper uno de esos trabajos.

Así que un formato histórico puede ser necesario para reconstruir el pasado mientras sea inaceptable para entrar a la red hoy. Su significado no desapareció. Su papel cambió en el límite.

¿Cuánto de la validez de una transacción realmente depende de lo que la red acepta en la altura actual, y cuánto depende de preservar exactamente lo que la cadena ya comprometió?

@Dusk $DUSK #dusk