私は、データ・アーキテクチャという観点からDuskのXSC契約を見つめてしまっていた。自動化というよりも、データの設計の問題として考えていたのだ。
従来の企業アクションは、奇妙な重複の問題を生み出す。同じ配当、分割、または議決イベントが、複数の仲介業者によってそれぞれ独立に処理され、それぞれが自分の記録を保持し、その後お互いの記録を照合する必要がある。
ネイティブ発行なら、XSCは企業アクションのロジックをアセット構造そのものに埋め込める。イベントとその実行は同じ基盤となる状態を共有するため、ネットワークは単に別々の台帳間で命令を受け渡しているだけではない。
それは、実際に運用上のリスクがどこに位置するのかを変えうる。
「不一致はアーキテクチャに組み込まれているので、リコンシリエーションは高コストになる。」
私にとって投資の観点は、会計の信頼性だ。すべての参加者が同じ実行結果を参照できるなら、イベントが起きた後に残高、権利、所有権を確認するために必要なリソースは減るかもしれない。それは、企業アクションを単に速くすることよりも価値がある可能性がある。
市場はまだ、既存のワークフローをトークン化することと、ネイティブなアセットに合わせてワークフローを再設計することの違いを過小評価していると思う。
弱点も同様に重要だ。実行をスマートコントラクトに集中させることは、ミスの結果も集中させるということでもある。コードのエラーや、設計の不十分なアップグレード手順は、その同じ真実のソースを参照するすべての参加者に影響を及ぼしうる。
本当の試験は、Duskが共有された実行を、それが効率的であるのと同じくらい説明責任のあるものにできるかどうかだ。
#dusk $DUSK @Dusk