Una transacción que Dusk pueda reproducir debería ser admisible también en vivo.
Ese límite es más estricto.
Asumí que el formato de la transacción era una sola regla: decodificarla correctamente y la red queda satisfecha.
Dusk tomó ese camino y lo dividió.
La implementación actual de Rusk separa la entrada de transacciones en vivo de los datos canónicos del libro mayor. Los envoltorios de Aegis y Boreas pueden entrar a través de la admisión en vivo y normalizarse al formato de entrada activo, luego pasan por `CanonicalTransaction` y `LedgerTransaction` antes de que la transacción sellada localmente se canonicalice para el compromiso del bloque. El consenso aún verifica que la codificación del libro mayor coincide con el formato canónico requerido en esa altura del bloque.
Y la parte extraña es lo que ocurre con formatos más antiguos.
El valor predeterminado de activación en mainnet de Dusk para Aegis es el bloque **3,590,904**. Los formatos históricos de transacciones siguen siendo decodificables para la reproducción del libro mayor, pero esos mismos formatos históricos se rechazan durante la admisión en el mempool en vivo una vez que el formato ya no está permitido allí.
Así que imagina una transacción antigua de antes de ese límite que está sentada en el historial de la cadena.
Dusk todavía puede entenderla mientras reproduce el libro mayor.
Pero intenta hacer pasar ese formato histórico por la admisión en vivo después de que el protocolo haya avanzado, y se rechaza.
El nodo puede preservar el pasado sin dejar que el pasado defina lo que se convierte en nuevos datos del libro mayor.
¿Cuánto de la compatibilidad de transacciones de Dusk proviene de preservar formatos antiguos para el historial de la cadena, y cuánto de su consistencia proviene de negarse a permitir que esos formatos regresen a la ruta en vivo?
@Dusk $DUSK #dusk
Ese límite es más estricto.
Asumí que el formato de la transacción era una sola regla: decodificarla correctamente y la red queda satisfecha.
Dusk tomó ese camino y lo dividió.
La implementación actual de Rusk separa la entrada de transacciones en vivo de los datos canónicos del libro mayor. Los envoltorios de Aegis y Boreas pueden entrar a través de la admisión en vivo y normalizarse al formato de entrada activo, luego pasan por `CanonicalTransaction` y `LedgerTransaction` antes de que la transacción sellada localmente se canonicalice para el compromiso del bloque. El consenso aún verifica que la codificación del libro mayor coincide con el formato canónico requerido en esa altura del bloque.
Y la parte extraña es lo que ocurre con formatos más antiguos.
El valor predeterminado de activación en mainnet de Dusk para Aegis es el bloque **3,590,904**. Los formatos históricos de transacciones siguen siendo decodificables para la reproducción del libro mayor, pero esos mismos formatos históricos se rechazan durante la admisión en el mempool en vivo una vez que el formato ya no está permitido allí.
Así que imagina una transacción antigua de antes de ese límite que está sentada en el historial de la cadena.
Dusk todavía puede entenderla mientras reproduce el libro mayor.
Pero intenta hacer pasar ese formato histórico por la admisión en vivo después de que el protocolo haya avanzado, y se rechaza.
El nodo puede preservar el pasado sin dejar que el pasado defina lo que se convierte en nuevos datos del libro mayor.
¿Cuánto de la compatibilidad de transacciones de Dusk proviene de preservar formatos antiguos para el historial de la cadena, y cuánto de su consistencia proviene de negarse a permitir que esos formatos regresen a la ruta en vivo?
@Dusk $DUSK #dusk