#dusk $DUSK Duskの開発ドキュメントを、環境構築から簡単なコントラクトのデプロイまで一通り試してみました。結論として、ドキュメントの「網羅性」と「実用性」の間には、かなりの隔たりがあります。
DuskEVMはSolidityと互換性があるため、理論上はEthereumの開発者がシームレスに移行できます。しかし、ドキュメントに沿って作業する中で最初につまずいたのは、ローカルテスト環境でした。DuskEVM TestnetのRPCエンドポイントは安定性がいまひとつで、ときどきタイムアウトします。Faucetも応答しないことがあり、テスト用トークンを受け取るまで数時間待たされることもあります。Ethereumに慣れた開発者にとって、これらは致命的ではありませんが、「ちょっと試してみよう」という人を遠ざけてしまいます。
2つ目のハードルは、Dusk特有の概念を理解することです。Ethereumの開発者が慣れ親しんでいるアカウントモデル、Gasの見積もり、トランザクションのライフサイクルは、Duskでは改めて理解し直す必要があります。たとえば、L1とEVM間の退出処理には3つのステップがあり、各ステップの状態や待機条件はEthereumのL2とは異なります。ドキュメントには確かに説明がありますが、トラブルシューティングのガイドが不足しています。どこかのステップで処理が止まった場合、開発者は自分でソースコードを調べるか、Discordで質問するしかありません。
3つ目のハードルは、ツールチェーンの成熟度です。ブロックエクスプローラーのEVM側への対応はまだ整備中で、一部のコントラクト検証機能は利用できません。イベント監視やログ検索のAPIも、成熟したチェーンほど安定していません。こうした基盤の不足により、開発者はデバッグの際、ビジネスロジックではなくツールの問題を切り分けるために、より多くの時間を費やすことになります。
Duskの開発体験が悪いと言いたいわけではありません。急速に進化しているチェーンであれば、こうしたことはどれも自然な段階です。しかし問題は、エコシステムの成長が開発者の参入にかかっていることです。そして、開発者がどのチェーンを選ぶかは、たいていホワイトペーパーではなく、初めてデモを動かすまでにどれくらい時間がかかるかで決まります。環境構築だけで午後がつぶれてしまうなら、多くの人はそのまま画面を閉じてしまうでしょう。@Dusk
だから私は、Duskのエコシステムの進展を、提携先のロゴが並ぶ壁ではなく、開発者向けドキュメントの更新頻度、Discordで技術的な質問に返答があるまでの速さ、そして「非公式のインセンティブ」によって生まれたサードパーティ製ツールやチュートリアルが登場しているかどうかで見ています。本当の開発者エコシステムは、技術ブログを積み上げて作るものではなく、実際につまずいた経験を積み重ねて築かれるものです。