Duskにおける、見た目以上の意味を持つ小さな設計上のディテールに注目しています。Transfer Contractは、互いに時折やり取りする別々の2つのシステムを動かすのではなく、パブリックなDUSKとシールドされたDUSKの両方に対する唯一の入口として機能します。パブリックかシールドかを問わず、すべての送金と、両者間のすべての変換が、同じコントラクトのロジックを経由します。これは偶然そうなったのではなく、意図的な設計上の選択です。これが重要な理由は、少し分かりにくいところにあります。システムが分断されていると、プライバシーの保証や残高の計算に、気付かないうちに食い違いが生じる境界事例が発生しがちです。入口を一つに絞ることで攻撃対象領域が狭まり、少なくとも理論上は、ロジックの監査もより容易になります。まだ分からないのは、実際の高負荷下でこれがどう機能するのか、あるいは利用が増えるにつれて、経路を統一したこと自体が新たなボトルネックを生むのかという点です。文書だけで判断するのではなく、実際の取引量で検証されるのを見たいと思います。問われるのは、さらに多くの種類のコントラクトがその上に構築されても、この設計がすっきりと保たれるかどうかです。実際の処理量が増えたときにどう機能するのか、注目しています。
@Dusk #dusk $DUSK
@Dusk #dusk $DUSK