Duskがリプレイできる取引は、ライブでも受理可能であるべきです。

その境界はより厳格です。

取引フォーマットは1つのルールで、正しくデコードできればネットワークは満足するものだと私は思っていました。

Duskはその経路を分岐させました。

現在のRusk実装では、ライブ取引の流入と、正準（canonical）台帳データが分離されています。AegisとBoreasのエンベロープはライブの受け付け（live admission）から入ってきて、アクティブな流入フォーマットへ正規化され、その後ローカルで封印された取引がブロックコミット用に正準化される前に、`CanonicalTransaction` と `LedgerTransaction` を通過します。コンセンサスは、台帳のエンコードが、そのブロック高で要求される正準フォーマットと一致しているかどうかを依然として検証します。

そして不思議なのは、古いフォーマットに何が起きるかです。

DuskのメインネットにおけるAegisの有効化デフォルトは、ブロック **3,590,904** です。歴史的な取引フォーマットは台帳のリプレイのためにデコード可能なままですが、それらの同じ歴史的フォーマットは、そのフォーマットがライブ側で許可されなくなった時点で、ライブのメンプール受け付けでは拒否されます。

つまり、その境界より前の古い取引が、チェーンの履歴に残っていると想像してください。

Duskは台帳をリプレイしている間はそれをまだ理解できます。

しかし、プロトコルが先へ進んだ後に、その歴史的フォーマットをライブの受け付けへ押し込もうとすると、拒否されます。

ノードは過去を保持できますが、過去が新しい台帳データになるものを規定することは許しません。

Duskの取引互換性のうち、チェーンの履歴のために古いフォーマットを保持することでどれだけが実現されていて、整合性のうち、そうしたフォーマットをライブ経路へ戻さないことでどれだけが実現されているのでしょうか？

@Dusk $DUSK #dusk