#dusk $DUSK @Dusk
DUSKの2つのアクティベーションレコードを並べて開いていたのですが、そのギャップがほとんどタイプミスのように見えました。Nocturneは10:53 UTC、メインネットは11:06で、13分です。

本物のリハーサルとしては短すぎます。アップグレードされたノードがフォーク境界をまたいで動作し、PLONK V3を受け入れてブロックを生成し続けることは確認できます。しかし、数時間に及ぶバリデータのチャーン、トランザクション末尾の失敗、ガスの外れ値、あるいは資本リスク下でのユーザー行動までは明らかにできません。まさに13分では、です。

Rusk 1.6.0はメインネットのアクティベーション前に約91h 53m公開されていたので、より深いテストは、おそらくフォーク後の最後の試験というより、テストネットがまたがりきる前のオペレーター間の連携だったのでしょう。

DUSKでは、この違いが重要です。テストネットの成功はプロトコル互換性を示しますが、メインネットでのレジリエンスは、互換性のあるソフトウェアが現実の経済状況の中で生き残るか、さらにノードの準備がばらつくことや、敵対的なインセンティブがある中で持ちこたえられるかを示します。同じコードでも、かかる圧力はまったく別物です。

多くの人は、アクティベーションとバリデーションを混同します。重要なのは「テストネットで先にフォークされたか」だけではなく、ブロック2,773,727の前に何台のDUSKノードがアップグレードされたか、次のブロックで何が失敗したか、そしてそのシグナルがブロック3,590,904の前にメインネットのオペレーターへ届いたかどうかです。

それでも気になる、1つだけ不快な疑問があります。もしDUSKがフォーク後10:58に微細な不具合を検知していたなら、13分で何かを止めるには十分だったのでしょうか？