Duskのアーキテクチャを読み進めるときに私が立ち止まったのは、見出しの特徴やロードマップの約束ではありませんでした。それは、決済は後で議論すべきものではないという、システムに深く埋め込まれた静かな仮定でした。
金融システムにおいて、実行は示すのが簡単です。決済は擁護するのが難しいです。その区別は、システムが監査、紛争、運用ストレスに直面するのに十分な時間が経過した後にのみ明らかになります。Duskは、その瞬間を念頭に置いて設計されているようです。デモフェーズではありません。
スタックの基礎にはDuskDSがあります。この層は、真剣なインフラがしばしば持つような退屈さを故意に持っています。アプリケーションをホストすることはありません。実験を奨励することもありません。その責任は狭く、厳格です。DuskDSは、状態が交渉可能でなくなる場所です。
もし状態遷移がこの層に到達する場合、それはすでに適格性ルール、権限、プロトコルの制約を満たすことが期待されます。正確性を後で再構築できるという仮定はありません。ソフト解釈フェーズもありません。Duskでの決済は、曖昧さがすでに取り除かれたときにのみ越えるラインとして扱われます。
その選択は、私がこれまで見てきた多くのシステムからDuskを即座に分離します。それは、これらのシステムが不良設計だったからではなく、異なるトレードオフを受け入れたからです。彼らは実行を迅速に進め、強制を下流に押しやりました。何かが壊れたとき、彼らはガバナンス、調整、または人間のプロセスに頼って一貫性を回復しました。
DuskDSはそのトレードオフを拒否します。
決済を制限することで、Duskはコストを運用からプロトコルの論理に移します。台帳に入らないあらゆる曖昧な結果は、行われない監査です。除外された無効な遷移は、数ヶ月後に説明する必要のない和解です。これは目に見える進展ではありませんが、累積的なリスク削減です。
これはDuskEVMが適合する場所でもあり、その権限が意図的に制限されている理由です。DuskEVMは実行をアクセス可能にするために存在します。それは開発者に慣れ親しんだツールを提供し、統合の摩擦を低減します。しかし、それは自らの現実を定義することはできません。
DuskEVMでの実行は候補となる結果を生み出します。それらの結果は、DuskDSの境界で強制される制約を通過した後にのみ状態になります。その分離は偶然ではありません。実行が進化することを可能にし、複雑性が直接的に決済に漏れ出ることを許しません。
私は、アプリケーションのバグが静かに台帳の問題に変わるのを見たことが十分にあります。それは、実行と決済があまりにも密接に結びついていたからです。Duskは、そのパターンを繰り返さないように決意しているようです。複雑さは存在を許されていますが、無制限に硬化することは許可されていません。
この設計は、Duskがしばしば静かに見える理由も説明しています。目に見える修正が少ないのです。リバージョンが少ないのです。システムが公に自らを説明する必要がある瞬間が少ないのです。何も起こらないからではなく、少ないミスが長く生き残ることがないからです。
外部から見ると、これは制限的に見えることがあります。内部から見ると、これは規律があるように見えます。
金融インフラは、実行が遅かったから失敗することはほとんどありません。失敗するのは、後の精査の下で決済が擁護できなかったからです。DuskDSはその現実を中心に構築されています。決済はエンドポイントではなく、その下にあるすべてを守る境界として扱われます。
多くのシステムは、どれだけの実行をサポートできるかを尋ねます。Duskは、決済層がどれだけの曖昧さを吸収する意志があるかを尋ねます。
それは興味深い質問ではありません。それはノイズを生み出しません。しかし、それはインフラが圧力、監査、時間に耐えられるかどうかを決定する種類の質問です。
その境界が明確になると、Duskのアーキテクチャの他の部分は保守的に見えなくなり、意図的に見え始めます。