プライバシー関連のコンプライアンス対応チェーンで3週間走らせたところ、Duskはコンセンサスではなくツールチェーンに詰まってしまいました

テストネットに、機密残高付きのコントラクトをデプロイしてみると、@Dusk のPlonK回路のコンパイル時間が想定より約2倍に。致命的というほどではないものの、ツールチェーンの分断感はかなりはっきりしています。ローカルノードからブラウザ側の署名まで、RPCを手動で切り替えることがしばしば必要で、ドキュメントの例も最新バージョンと噛み合っていません。Secret Networkは開発体験がよりスムーズな方ですが、あのTEEの信頼に関する前提は、私はどうしても受け入れにくいです。

Duskはコンプライアンス志向の金融の道を歩もうとしていて、プライバシートランザクションとアイデンティティ検証を同じレイヤーに結びつけようとしています。方向性は間違っていません。実際に走らせてみると、ゼロ知識証明の生成は一般的なハードウェアにはやや重く、検証ノードのメモリ使用量も低くありません。Oasisはプライバシーレイヤーでモジュール化を行っており、開発は柔軟です。ただ、オンチェーンのアイデンティティとコンプライアンスのコンポーネントはDuskほど密に統合されていません。私がテストした資産発行のフローでは、Duskの権限設計がより細かく、発行者、監査ノード、通常の保有者を区別できる点は、単に匿名送金をするチェーンよりも実用的だと感じました。

問題もここにあります。Duskの開発者の参入障壁は、コンプライアンスのパラメータによって引き上げられており、多くの設定には規制の用語を理解する必要があります。エコシステムのコールドスタートは、想定より遅くなる可能性もあります。$DUSK は手数料とガバナンストークンのロジックが明快ですが、現状オンチェーンにデプロイできるアプリケーションの種類はまだ比較的限られています。Aleph Zeroのプライバシーコントラクトはより汎用寄りで、Gasも安定していますが、規制対象の資産シナリオでのネイティブなコンプライアンス枠組みが欠けています。

もしDuskがSDKをもう少し薄くラップし、コンプライアンスのパラメータをプリセットのテンプレートとして用意できれば、開発体験は大きく改善するはずです。そうでなければ、それは普通の開発者が素早く試行錯誤できる場所というより、機関向けにカスタムしたチェーンのように見えます。少なくとも現時点では、コンセンサスは成り立っていて、ボトルネックはツールとドキュメントにあります。

#dusk