私はルーターのことを考えずに毎日Wi-Fiを使っています。何かが読み込みを止めたときだけ、それが存在していることを思い出すのです。すると突然、照明を確認したり、設定を見たり、ケーブルを触ったり……さっきまで見えていなかったあらゆるものが気になり始めます。

それが私のDuskEVMの考え方の始まりです。開発者はSolidity、ウォレット、通常のEVMツールのような馴染みのある領域に留まっていられる一方で、<c-1/>@Dusk は裏側で DuskDS を使って決済とデータ可用性を処理してくれます。すべてがうまく動いているとき、その抽象化こそがまさに欲しいものです。頭の中に余計なインフラを持ちたがる人はいません。

しかし、抽象化は依存も生みます。DuskEVMの活動はバッチ化され、実行レイヤーの下にアンカーされます。$DUSK はさらに、ブリッジを通じて L1 と DuskEVMの間を行き来します。だから、決済が想定外の挙動を示したり、ブリッジが複雑になったり、状態が開発者の期待どおりに見えなかったりすると、基盤レイヤーが急に重要になってきます。

そして私は、@dusk がいずれその部分を証明しなければならないと思っています。開発者は DuskDS の専門家にならずに、それらの境界をトラブルシュートできるのでしょうか？隠れたレイヤーの理解が必要になる頻度が高すぎると、EVM互換が提供するシンプルさの一部が失われていきます。

たぶん、良いアーキテクチャとは、基盤レイヤーを無関係にすることではありません。

むしろ、多くの日は開発者がそれを無視できて――そしてそれが無理な日でもすぐに理解できるようにすることです。$DUSK

#dusk