スマートコントラクトのツール周りに十分な時間を費やした結果、「ボイラープレートが少なくて済む」と言うものには疑いを持つようになりました。だいたいの場合、それはボイラープレートが別の場所へ移動しただけです。まだ見つけられていないだけ。だから Dusk Forge が目に留まりました。Rust を突然簡単にするからではなく、特定のイライラへの対処をしているからです。ネイティブの Dusk コントラクトを書くには、通常、そのコントラクト自体と WASM のエクスポート、スキーマ、さらにアプリがそれと通信できるようにするデータドライバ層まで扱う必要があります。Forge の #[contract] マクロは、開発者が別々に保守することなく、1つのモジュールからそれらを生成します。
紙の上では小さな話です。でも現実には、小さな摩擦が「何が作られるか」を決めます。実行モデルが洗練されているチェーンでも、日々のワークフローが罰ゲームみたいに感じられてしまい、開発者が離れていくのを見てきました。核となるアイデアは良かった。仕組みがダメだった。
ただ、落とし穴があります。抽象化は複雑さを隠しても、なくしはしません。生成されたスキーマは役に立つのに、いつの間にかズレていきます。データドライバは便利でも、フロントエンド、ウォレット、ノード、そしてコントラクトのバージョンが噛み合わなくなった瞬間に不便になります。Dusk 自身のドキュメントも、ネイティブの DuskVM 開発は依然として Dusk 固有のツールを意味する一方で、EVM はより広い Ethereum のエコシステムを得られると認めています。
だから私は Forge をブレークスルーとして読んでいません。メンテナンス作業として読んでいます。十分なサイクルを経ると、ブレークスルーよりもメンテナンス作業のほうを信じたくなります。
流動性は、マクロ展開がどれだけエレガントに見えるかには関心がありません。ユーザーが気にするのは、アプリが動くかどうか、そして出口が退屈なものになるかどうかです。
見守る価値があるのは、その部分かもしれません。Forge が簡単そうに聞こえるかどうかではなく、Dusk の上で作ることが、目に見えない形でどれだけ安くなるのか。

@Dusk #dusk $DUSK