開発者側の立場でDuskEVMのローンチを見てきましたが、面白いのはSolidityがいまDuskで動くようになったことそのものではありません。
大事なのは、どれだけ早く摩擦(導入の障壁)を下げられるかです。
Solidity開発者なら、まったく別の開発ワークフローを最初から学び直すのではなく、Hardhatのような馴染みのあるツールをそのままプロセスに持ち込めます。これは重要です。ですが、それは同時にDuskにとって難しい問いも生みます。
もし障壁がツール面にあるだけなら、実験がもっと速く進むのが見えてくるはずです。
もし本当の障壁が「作る価値のあるものを見つけること」だとしたら、開発者のアクセスが良くなっても大して解決にはなりません。
私が今見ているのは、その指標です。
最初の数日間にデプロイされたコントラクトの数でもありません。ウォレットを接続する開発者の数でもありません。
最初のテスト段階の後も使い続けられているアプリケーションを見たいのです。
本当に稼働しているアプリが10〜20件でもあれば、短命なデプロイが数百件あるよりも私には多くを語ります。
それに、少しだけ不満もあります。EVM互換性により参入は容易になりますが、そのせいでDuskが「Solidityコードをデプロイするだけの、ただの別の場所」に感じられてしまうこともあります。
難しいのは、Duskが提供する“そのもの”を開発者に使ってもらうことです。
だから私は、「DuskEVMが稼働した」というマイルストーンにはあまり関心がありません。
新鮮味が薄れてから開発者が何を作るのか、そのほうが本当のシグナルが現れ始める場所だからです。
#dusk $DUSK @Dusk
大事なのは、どれだけ早く摩擦(導入の障壁)を下げられるかです。
Solidity開発者なら、まったく別の開発ワークフローを最初から学び直すのではなく、Hardhatのような馴染みのあるツールをそのままプロセスに持ち込めます。これは重要です。ですが、それは同時にDuskにとって難しい問いも生みます。
もし障壁がツール面にあるだけなら、実験がもっと速く進むのが見えてくるはずです。
もし本当の障壁が「作る価値のあるものを見つけること」だとしたら、開発者のアクセスが良くなっても大して解決にはなりません。
私が今見ているのは、その指標です。
最初の数日間にデプロイされたコントラクトの数でもありません。ウォレットを接続する開発者の数でもありません。
最初のテスト段階の後も使い続けられているアプリケーションを見たいのです。
本当に稼働しているアプリが10〜20件でもあれば、短命なデプロイが数百件あるよりも私には多くを語ります。
それに、少しだけ不満もあります。EVM互換性により参入は容易になりますが、そのせいでDuskが「Solidityコードをデプロイするだけの、ただの別の場所」に感じられてしまうこともあります。
難しいのは、Duskが提供する“そのもの”を開発者に使ってもらうことです。
だから私は、「DuskEVMが稼働した」というマイルストーンにはあまり関心がありません。
新鮮味が薄れてから開発者が何を作るのか、そのほうが本当のシグナルが現れ始める場所だからです。
#dusk $DUSK @Dusk