チェーン上でしばらく待っていると、人をだましやすい細部に気づきます。つまり、取引の承認が速いほど、人は「すでにブロックに入った」を「お金はすでに手に入った」と思い込みやすいのです。私はこれを「最終性パラドックス」と呼んでいます。
DuskEVM の取引フローは、この点をかなり明確に説明しています。取引はまず sequencer に渡され、次に L2 のブロックに入り、その後 batcher がデータを DuskDS に公開します。そして、状態コミットメントと fault proofs によって結果が決済レイヤーに固定されます。言い換えると、ブロックに現れることは第一段階にすぎません。ネットワークがこの結果に責任を持つのは、その後の数ステップです。@Dusk のこの順番は配送に似ています。伝票番号が発行されたからといって受領したことにはならず、荷物が倉庫に入っただけでもあなたが梱包を開けて確認したことにはなりません。資料でも、特に DuskEVM と L1 の間で価値を運ぶときは、「どれくらい経ったか」で最終性を推測しないよう直接注意しています。
$DUSK はここで二つの役割を同時に担っています。つまり、実行レイヤーでガスを支払うための燃料であり、同時に運ばれていく価値そのものでもあるのです。ユーザーがチェーン上で DUSK 残高が変わったのを見ても、それは単に実行レイヤー側が先に台帳を更新しただけで、ブリッジと決済はまだ完了していない可能性があります。だから、取引を行う人や資金を集約する人にとって見るべきなのは、秒時計ではなくプロトコルの状態、あるいはウォレットの状態です。
私は、こうしたプライバシーやコンプライアンス基盤が本当に難しいのはここだと思います。#dusk は「速い」を提供するだけでは不十分で、「いま起きていること」と「すでに確定したこと」をユーザーが見分けられるようにしなければなりません。プロダクト側がこの境界を曖昧にしてしまうと、ユーザーはミリ秒単位のUIの中で、分単位のリスクを負うことになります。下調べは自分でしてください。私のこの一言だけを信じないでください。
DuskEVM の取引フローは、この点をかなり明確に説明しています。取引はまず sequencer に渡され、次に L2 のブロックに入り、その後 batcher がデータを DuskDS に公開します。そして、状態コミットメントと fault proofs によって結果が決済レイヤーに固定されます。言い換えると、ブロックに現れることは第一段階にすぎません。ネットワークがこの結果に責任を持つのは、その後の数ステップです。@Dusk のこの順番は配送に似ています。伝票番号が発行されたからといって受領したことにはならず、荷物が倉庫に入っただけでもあなたが梱包を開けて確認したことにはなりません。資料でも、特に DuskEVM と L1 の間で価値を運ぶときは、「どれくらい経ったか」で最終性を推測しないよう直接注意しています。
$DUSK はここで二つの役割を同時に担っています。つまり、実行レイヤーでガスを支払うための燃料であり、同時に運ばれていく価値そのものでもあるのです。ユーザーがチェーン上で DUSK 残高が変わったのを見ても、それは単に実行レイヤー側が先に台帳を更新しただけで、ブリッジと決済はまだ完了していない可能性があります。だから、取引を行う人や資金を集約する人にとって見るべきなのは、秒時計ではなくプロトコルの状態、あるいはウォレットの状態です。
私は、こうしたプライバシーやコンプライアンス基盤が本当に難しいのはここだと思います。#dusk は「速い」を提供するだけでは不十分で、「いま起きていること」と「すでに確定したこと」をユーザーが見分けられるようにしなければなりません。プロダクト側がこの境界を曖昧にしてしまうと、ユーザーはミリ秒単位のUIの中で、分単位のリスクを負うことになります。下調べは自分でしてください。私のこの一言だけを信じないでください。


