Eine Transaktion, die Dusk erneut abspielen kann, sollte auch im Live-Betrieb zulässig sein.
Diese Grenze ist strenger.
Ich nahm an, das Transaktionsformat sei eine einzige Regel: Es erfolgreich dekodieren, und das Netzwerk ist zufrieden.
Dusk hat diesen Pfad aufgespalten.
Die aktuelle Rusk-Implementierung trennt den Live-Eingang von Transaktionen von den kanonischen Ledger-Daten. Hüllen von Aegis und Boreas können über die Live-Zulassung eintreten und in das aktive Eingangsformat normalisiert werden, dann passieren sie `CanonicalTransaction` und `LedgerTransaction`, bevor die lokal versiegelte Transaktion für die Blockbindung kanonisiert wird. Der Konsens prüft weiterhin, dass die Ledger-Kodierung dem kanonischen Format entspricht, das in dieser Blockhöhe erforderlich ist.
Und das Seltsame ist, was mit älteren Formaten passiert.
Die Mainnet-Aegis-Aktivierung von Dusk hat als Standardblock **3,590,904**. Historische Transaktionsformate bleiben für das Ledger-Replay dekodierbar, aber genau diese historischen Formate werden bei der Live-Mempool-Zulassung abgelehnt, sobald das Format dort nicht mehr erlaubt ist.
Stell dir also vor, eine alte Transaktion aus der Zeit vor dieser Grenze liegt in der Historie der Kette.
Dusk kann sie noch verstehen, während es das Ledger wiedergibt.
Aber versuche, dieses historische Format nach dem Umstieg des Protokolls durch die Live-Zulassung zu drücken, und es wird abgelehnt.
Der Knoten kann die Vergangenheit bewahren, ohne zuzulassen, dass die Vergangenheit definiert, was zu neuen Ledger-Daten wird.
Wie viel von Dusk’ Transaktions-Kompatibilität kommt daher, dass alte Formate für die Kettenhistorie beibehalten werden, und wie viel seiner Konsistenz daraus, dass diese Formate nicht mehr in den Live-Pfad zurückgelassen werden?
@Dusk $DUSK #dusk
Diese Grenze ist strenger.
Ich nahm an, das Transaktionsformat sei eine einzige Regel: Es erfolgreich dekodieren, und das Netzwerk ist zufrieden.
Dusk hat diesen Pfad aufgespalten.
Die aktuelle Rusk-Implementierung trennt den Live-Eingang von Transaktionen von den kanonischen Ledger-Daten. Hüllen von Aegis und Boreas können über die Live-Zulassung eintreten und in das aktive Eingangsformat normalisiert werden, dann passieren sie `CanonicalTransaction` und `LedgerTransaction`, bevor die lokal versiegelte Transaktion für die Blockbindung kanonisiert wird. Der Konsens prüft weiterhin, dass die Ledger-Kodierung dem kanonischen Format entspricht, das in dieser Blockhöhe erforderlich ist.
Und das Seltsame ist, was mit älteren Formaten passiert.
Die Mainnet-Aegis-Aktivierung von Dusk hat als Standardblock **3,590,904**. Historische Transaktionsformate bleiben für das Ledger-Replay dekodierbar, aber genau diese historischen Formate werden bei der Live-Mempool-Zulassung abgelehnt, sobald das Format dort nicht mehr erlaubt ist.
Stell dir also vor, eine alte Transaktion aus der Zeit vor dieser Grenze liegt in der Historie der Kette.
Dusk kann sie noch verstehen, während es das Ledger wiedergibt.
Aber versuche, dieses historische Format nach dem Umstieg des Protokolls durch die Live-Zulassung zu drücken, und es wird abgelehnt.
Der Knoten kann die Vergangenheit bewahren, ohne zuzulassen, dass die Vergangenheit definiert, was zu neuen Ledger-Daten wird.
Wie viel von Dusk’ Transaktions-Kompatibilität kommt daher, dass alte Formate für die Kettenhistorie beibehalten werden, und wie viel seiner Konsistenz daraus, dass diese Formate nicht mehr in den Live-Pfad zurückgelassen werden?
@Dusk $DUSK #dusk