#dusk $DUSK

今日は引き続き、@Dusk の Boreas のアップデートを見ています。私が一番気になっているのは、Phoenix の退役でも、fork rule が増えたことでもありません。

それよりも、もっと根本的な問題です：

プロトコルのアップグレード後、過去のある取引が、なぜずっと同じ意味を保てるのか？

これは馬鹿げた話に聞こえるかもしれません。

しかしハードフォークの後、ノードは新しいルールで動いているのに、歴史のブロックの中には旧バージョンの transaction、旧 verifier、旧 execution semantics がそのまま残っています。

もし今日のノードが今のルールで以前の bytes を改めて解釈すれば、歴史のリプレイに問題が起き得ます。

だからこそ Boreas は、今回 transaction handling のバージョン境界をより明確にしました。

Live ingress は現在のプロトコルルールに従う。

古い envelope は入口で識別され、normalize される。

ledger に入る直前で canonical transaction に変換される。

一方で、過去のブロックは当時のルールのままデコードし、リプレイし続ける。

私はここで本当に重要なのは「フォーマットの統一」ではないと思います。

重要なのは：

取引には、内容だけでなく、それが属するプロトコルの時代があること。

Aegis は Aegis のルール。

Boreas は Boreas のルール。

ハードフォークは未来を変えられても、ついでに過去を再解釈してしまうわけにはいかない。

だからこそ今、私はチェーンのアップグレードを見るとき、「何が追加されたか」だけを重視していません。

むしろ気にしているのは、

新バージョンが公開された後、今日のノードが何年も前のその取引が、実際に何を起こしていたのかを正確に理解できるのか。

regulated market infrastructure を提供するネットワークにとって、このような歴史の連続性は実はとても基礎的です。

台帳はアップグレードできる。

でも台帳の中の過去は、アップグレードに一緒に引きずられてはならない。