私は、DuskがRuskに導入した2つの取引タイプ――CanonicalTransaction と LedgerTransaction――のことをずっと考えている。
これらは同じ取引の異なる層を表している。CanonicalTransactionは、Ruskが論理的に扱う形であり、一方LedgerTransactionは、特定のプロトコルバージョンで必要とされる台帳表現として、その取引を包み込むものである。ポイントは、Duskが取引の意味をそれらのストレージ形式の進化に“連動させずに”、それらのストレージ形式を進化させたいという緊張関係にある。これは、EUライセンスを持つ機関とともにオンチェーンで金融市場を実現しようとする際に重要な性質だ。まだ分からないのは、この分離が実際にバージョン変更をRuskの中に閉じ込め続けられるのか、それともフォーマット変更がそれでもウォレット、アプリケーション、そして過去データのリプレイにまで波及するのか、という点だ。
注目すべき詳細は、Duskがどのように受信した取引を正規化するのか、正しい台帳表現をどのように選択するのか、そしてプロトコルのアップグレード後に古い取引をどう解釈するのかである。
アップグレード後もウォレットが取引を送信し続けることは、互換性の有力な証拠になる。より強い試験は、Duskが、その下側の表現を変更しつつ、それより上の層にある同じ取引セマンティクスを保持できるかどうかだ。私は、その抽象化がどれだけ“バージョン管理の複雑さ”をアプリケーションが知る必要を減らしているかで判断する。
問題は、Duskが本当に「取引が意味するもの」と「台帳がそれをどう保存するか」を切り離したのか、それとも単に、バージョン取り扱いの負担を別の場所へ移しただけなのか、という点だ。
私は、その境界が今後のフォーマット変更や歴史的リプレイを通じてどれだけ保たれるかを見守っている。
#dusk $DUSK @Dusk