#dusk $DUSK 最近、週末を使って @Dusk の開発者ドキュメントを手順どおりに読んで、ローカル環境をゼロから組み立ててみました。正直に言うと、想像していたよりもかなり手こずりました。
ドキュメントは概念レベルではしっかりしています。アーキテクチャ図は分かりやすく、コアモジュールの役割分担も明確ですし、Rusk仮想マシンの設計思想にも専用の章が用意されています。ですが、実際に手を動かす段階に入ると、問題が次々と出てきます。サンプルコードの依存バージョンが最新版のリポジトリと一致していなかったり、いくつかのAPIの入力パラメータの説明がドキュメントにそのまま欠けていて、ソースを掘って探さないとパラメータ形式が分からなかったりします。致命的ではないものの、開発者の忍耐と信頼をかなり消耗させます。
特に気になったのはテストネットの安定性です。ローカルからテストネットに接続して簡単なトランザクションのデバッグをしていた際、何度かRPCノードが応答しないことがありました。リトライすれば復旧するものの、ドキュメントにはテストネットのサービスグレードやメンテナンスの時間枠が書かれていません。「状況を見に来ただけ」の開発者にとって、この不確実性はそのまま撤退につながりかねませんし、離れる理由を彼らに説明してくれるわけでもありません。
もう一つの所感として、Duskの開発ツールチェーンはイーサリアムのエコシステムと明確に違っていて、これは両刃の剣だと感じます。良い点は、Duskが自社のプライバシーやコンプライアンスの特性に合わせて深くカスタマイズでき、EVMの歴史的な制約に縛られないこと。悪い点は、Solidityのスキルや既存のツールをそのまま転用できないことです。ドキュメントにはRust SDKやコントラクト例も用意されていますが、ゼロからRustを学び、その上でDuskの開発パラダイムを学ぶのは、「ERC-20をフォークする」よりも学習曲線がはるかに急です。
ドキュメントやツールチェーン作りには時間がかかること、チームがリソースをメインネットやコアプロトコルに優先配分していることも理解できます。しかし、開発者エコシステムのコールドスタートは、プロトコル性能ではなく、初日から動く「Hello World」です。#dusk が、より安定したテストネット、バージョン固定された入門チュートリアル、そしてサードパーティーの開発者が成功裏にデプロイできた事例の数を提供してくれるまで、エコシステムが正の循環に入っているかは判断を保留したいと思います。$DUSK にとって、開発者の数とはコミュニティの人数ではなく、チェーン上で実際にデプロイされたコントラクト数です。@Dusk