私はDuskのアカウント抽象レイヤーを真剣に確認しましたが、Ethereum $ETH のようにアプリ層でパッチを当てるのではなく、最初からコンセンサス層で直接サポートされていることが分かりました。
DuskのWASMスマートコントラクトでは、ユーザーが検証ロジックを自由にカスタマイズできます。システムは、ユーザー自身のロジックで「有効な取引」と見なされる条件を定義できるようにしています。検証ロジックをWASMコントラクトとしてチェーン上にデプロイし、その後はアカウントが従来の楕円曲線署名に依存しなくなります。ソーシャルリカバリー、多要素認証、ハードウェアキーの組み合わせ、さらには時間ベースの条件付き承認など、こうしたものもすべてコントラクト内でカスタマイズ可能です。
これは機関ユーザーにとってとても実用的です。たとえば資産運用会社なら、次のようなアカウントルールを設定できます。単発の送金が一定額を超える場合は取締役3名の署名が必要、さらに高額の場合は5名の署名に加えて48時間のタイムロックが必要、という具合です。こうしたロジックはアカウントコントラクト内に直接固定され、中間コントラクトやマルチシグ用ウォレットを経由する必要はありません。
もう一つの細部は、取引の原子性です。Duskのアカウントコントラクトでは、1つの取引の中で複数の操作を連結できます。まず本人確認を検証し、次に残高を確認し、その後に送金を実行し、最後に状態を更新する——この一連の流れは原子的な単位の中で完結し、すべて成功するか、またはすべてロールバックされます。これは、Ethereumでの「承認→送金」の二段階操作よりもずっと簡潔で、オンチェーンのやり取りを1回分節約できます。
もちろん、検証ロジックを自由にカスタマイズできるということは、攻撃面もより大きくなるということでもあります。もしアカウントコントラクトに脆弱性があれば、攻撃者は検証ルールを回避して資産を直接奪える可能性があります。Duskの対策は、重要なコントラクトに対して厳密な監査や形式的検証を行うことを推奨し、ユーザー資産の安全を確保することです。このような事前のセキュリティのハードルは、開発者にとっては負担ですが、ユーザーにとっては保障になります。$DUSK @Dusk #dusk
DuskのWASMスマートコントラクトでは、ユーザーが検証ロジックを自由にカスタマイズできます。システムは、ユーザー自身のロジックで「有効な取引」と見なされる条件を定義できるようにしています。検証ロジックをWASMコントラクトとしてチェーン上にデプロイし、その後はアカウントが従来の楕円曲線署名に依存しなくなります。ソーシャルリカバリー、多要素認証、ハードウェアキーの組み合わせ、さらには時間ベースの条件付き承認など、こうしたものもすべてコントラクト内でカスタマイズ可能です。
これは機関ユーザーにとってとても実用的です。たとえば資産運用会社なら、次のようなアカウントルールを設定できます。単発の送金が一定額を超える場合は取締役3名の署名が必要、さらに高額の場合は5名の署名に加えて48時間のタイムロックが必要、という具合です。こうしたロジックはアカウントコントラクト内に直接固定され、中間コントラクトやマルチシグ用ウォレットを経由する必要はありません。
もう一つの細部は、取引の原子性です。Duskのアカウントコントラクトでは、1つの取引の中で複数の操作を連結できます。まず本人確認を検証し、次に残高を確認し、その後に送金を実行し、最後に状態を更新する——この一連の流れは原子的な単位の中で完結し、すべて成功するか、またはすべてロールバックされます。これは、Ethereumでの「承認→送金」の二段階操作よりもずっと簡潔で、オンチェーンのやり取りを1回分節約できます。
もちろん、検証ロジックを自由にカスタマイズできるということは、攻撃面もより大きくなるということでもあります。もしアカウントコントラクトに脆弱性があれば、攻撃者は検証ルールを回避して資産を直接奪える可能性があります。Duskの対策は、重要なコントラクトに対して厳密な監査や形式的検証を行うことを推奨し、ユーザー資産の安全を確保することです。このような事前のセキュリティのハードルは、開発者にとっては負担ですが、ユーザーにとっては保障になります。$DUSK @Dusk #dusk