#dusk @Dusk $DUSK

証明が遅い工程になると予想していました。Hedgerは、ブラウザ上でクライアントサイドに機密性のあるトランザクションの証明を生成します。2秒未満で、暗号化された値にはECC上のElGamal、正しさのためのZK証明です。2秒は待ち時間のように聞こえたので、エクスプローラで「このチェーンで2秒がどれくらいの価値に相当するか」を見に行きました。

メインネット、ブロック5,021,189。私の前回の読み取りは5,004,022でした。これは、固定の10秒ごとのペースで17,167ブロック:171,670秒、47.7時間です。それらのすべてが、2日以内に19.8574 DUSKを支払い(340,892 DUSKが発行)、そのほとんどはゼロ件のトランザクションを運ぶブロックに入っていました。

つまりHedgerの計算はこうです:2秒未満で証明が完了するのに対して、ブロックは10秒。2つのブロックの間に5つの証明が収まります。ユーザー側の暗号処理は待ち行列ではありません。待ち行列の原因はブロックです。

ただ、意外だったのは、ドキュメント自体がそう書いていることです。DuskEVMのトランザクションは、シーケンサ実行→L2ブロック→バッチャがDuskDSへデータを公開、そしてステートコミットメントとフォールト証明がそれを決済(settlement)にアンカーします。ドキュメントには明確に「包含(inclusion)は速い」が、「包含と決済は別の段階であり、アプリケーションは経過時間から最終性を推測するのではなく、プロトコルの状態を参照すべき」と書かれています。デモ最適化のプロジェクトなら、「2秒未満」がエンドツーエンドを意味すると気軽に解釈してしまうでしょう。こちらは、その修正を自分たちのドキュメントに書き込んでいます。

その下で、決済レイヤーは同じ47.7時間の間に重くなっていました。現在のステークが206.94Mから214.15Mへ、さらに7.21M。保留ステークは7.08M減って1.82Mになりました。したがって、その増加分5.26Mは、待ち行列(queue)がアクティブなセキュリティへ転換したもの、そして約1.95Mが本当に新しい分です。

アクティブのプロビジョナは179から184、保留は15から11。

高速な証明はユーザー体験を買います。決定論的な決済は、規制のある会場が実際にサインオフするものです。これらは別の問題であり、その興味深い点は、それらが1つのスタックとして出荷されていることです。

もしあなたがその会場のコンプライアンス担当者なら、どちらの数字をまず確認しますか?証明時間、それとも決済段階?