一つの楕円曲線ライブラリ移行が「利用可能」かどうかは、「すでに移行した」という一文だけでは判断できない。Duskの現在公開されている資料は、次の3層に分けて考えるのがより適切だ。Citadelの曲線スタックを現在のDusk curve stackへ移行すること、Citadel APIもそれに合わせて修正すること、そしてDusk CurvesがBLS12-381対応を含めてDusk曲線ライブラリへ移行すること。この3つは関連しているが、同じ納品物ではない。

製品の利用者にとって、第一層は依存関係だ。旧曲線スタックの呼び出し元が、新しいライブラリをすでに指しているか。第二層はインターフェース関係だ。APIの修正後に、元の呼び出し方法が引き続き成立するか。第三層になって初めて、具体的な曲線能力が、目的のライブラリで使えるかどうかが問題になる。この3層を「移行完了」に圧縮してしまうと、最もミスが起きやすい接続部分を見落としがちだ。

そして、それが「本当に利用可能な状態か」を判断するための鍵でもある。確認できるのは、移行対象・インターフェース修正・曲線対応がそれぞれ列挙されているかどうかだ。これらの資料だけで、すべての業務がすでに切り替わり、すべての下流呼び出しが検証され、あるいはメインネットが全面的に有効化されたとまでは確認できない。@Dusk と$DUSK に関心のある読者にとって、最も確実な見方は、移行に「成功」や「失敗」というラベルを貼ることではなく、まず次を尋ねることだ。誰がライブラリ移行を担当しているのか、誰がAPIの適応を担当しているのか、どの層に直接的な証拠があるのか。これは「インフラのアップグレード」と一言で片付けるより、実際の意思決定にずっと近い。

したがって、移行判断は責任と証拠に落とし込む必要がある。ライブラリが切り替わったか、インターフェースが適応されたか、曲線対応が検証されたか——この3つに明確な境界があり、初めて「利用可能」と言える。

ゆえに、プロダクトチームは導入前に移行範囲と検証責任を確認すべきであり、ライブラリ名の変更をそのままユーザーに見える能力の変化だと見なすべきではない。

移行作業の価値は、すべての人に「より先進的になった」と信じてもらうことではなく、導入者が、自分が依存しているライブラリ・インターフェース・曲線能力が、それぞれどの状態にあるのかを把握できるようにすることにある。#dusk