#dusk $DUSK 昨晚、私はDuskのテストネットでシンプルなコントラクトをデプロイしてみて、開発体験がどう感じられるか確かめようとしました。結果はすぐに詰まりました——登録簿のような構造を作って保有分を追跡しつつ、特定のフィールドは秘匿し、特定のフィールドは公開する、証券プラットフォームが求めるような仕組みを作りたかったのです。

最初はSolidityならそのまま使えると思いました。でも、そのような構造を汎用のキー・バリュー型ストレージに無理やり押し込むと、すぐに違和感がありました。まるで四角い杭で丸い穴を叩き割ろうとしているようで、しかも「その形が正しいんだ」と受け入れないといけない感じです。そこで、Duskにはもっと良い方法があるのではないかと考え、ドキュメントを読み始めました。

そのとき見つけたのがMicrokelvinツールキットです。結果は、性能最適化ツールではありません——むしろ逆です。開発者が、自分に必要なデータ構造を組み立てられるようにするもので、チェーン上の汎用的なものに閉じ込められないようにしてくれます。必要な構造——複雑な関係、プライバシー要件、証明生成——それらをすべて内蔵し、そしてRuskの実行レイヤーが、汎用VMのようにあなたのやり方に干渉してくることがありません。

「さっき自分がやろうとしていたこと」との違いが一気に重要になりました。私はこれまで、スマートコントラクトを普通の発想で理解していました。つまり、チェーンはあなたに汎用プリミティブを渡して、それに金融ロジックを詰め込む、という考えです。交換やリワードファームのような用途なら問題ありません。でも、証券の登録簿をモデル化して、数十万件の保有を追跡しつつ保有のプライバシーを守り、詳細を晒さずに制約条件を証明する——このようなことを汎用アプローチでやろうとすると、すぐに破綻します。

イーサリアムやSolanaで独自のデータ構造を使うなら、非効率に保存するか、回りくどく高価なロジックを組むことになります。Duskでは、必要なものをそのまま組み立てさせてくれるのです。

既製のスーツを買うのと、仕立てで作るのの違いに似ています。前者は仕立て側が設計してくれる。後者は仕方なく体に合わせることになります。

規制された証券プラットフォームに必要なのは、「汎用であること」も「何でもかんでも効率的であること」も同時に満たすチェーンではありません。必要なのは、やるべき“その1つのこと”に極めて効率的なチェーン——規制されたツールの保有と移転を扱い、プライバシーは守り、透明性は確保しつつ、公開もできること。汎用の基盤インフラは、ただ邪魔になるだけです。

誤解のないように言っておくと、メインネットでコントラクトが本当にMicrokelvinを使っているところは、まだ見ていません。開発者が、標準的な制約よりもMicrokelvinのほうが使いやすいと気づくかどうかは、実際のアプリが出揃うまで分かりません。

それでも、専用に作られた開発者ツールが、機関レベルのエンジニアを惹きつけるのか、それとも多くの人が、あまり合っていなくても慣れた汎用ツールを使い続けるのか——そのあたりをまだ考えています。

@Dusk $DUSK #dusk