#dusk $DUSK 私はDuskの取引手数料の検証プロセスを、ユーザー視点で一通り見直してみたところ、ウォレットに表示される「予想手数料」は単なる最外層の情報にすぎないことが分かりました。実際にネットワークで検証が進むとき、システムが関心を持つのはgas limitとgas priceがそれぞれいくらかだけではなく、両者を掛け合わせて得られる最大費用が、取引中ですでに証明されているmax feeと完全に一致しているかどうかです。このいずれかの項目が対応できなければ、取引パラメータ自体に矛盾が存在します。

ここで注目すべきは、同一の費用制約がmempoolの受け入れとVM実行の段階で、それぞれ別にチェックされる点です。最初の層の役割は、取引がさらにネットワークに拡散される前に、早い段階で不一致な入力をふるい落として、有効でないデータがノードのリソースを占有するのを減らすことです。ただしmempoolは、プロトコル実行の最終境界ではありません。ブロックに含まれる内容のすべてが、ある普通のノードで馴染みの受け取り経路を経ているとは限らないからです。

そのためVMは、もう一度検証する必要があります。これは単なる反復ではなく、取引がどの入口から現れても、オンチェーン上の状態を変更しようとする以上、同じ一連の費用の等式を必ず守ることを保証するためです。mempoolは入口でのふるい分け、VMのチェックは取引に実行資格があるかどうかを決めるもの、と考えると分かりやすいでしょう。前者はネットワークの処理効率を高め、後者はプロトコル結果の整合性を担保します。

ETHユーザーがgas limitとgas priceを見ると、まず「手数料が高いかどうか」「見積もりが正確かどうか」といった議論に進みがちです。しかしDuskが解決する安全上の制約の焦点は、費用の証明、署名内容、実際の実行、そして払い戻し計算が一貫して保たれるかどうかにあります。仮にウォレットが提示する見積もりが一見妥当に見えても、項目同士が厳密に結び付けられていなければ、異常処理の余地が残る可能性があります。

これはつまり、安全上の修正が必ずしも一般ユーザーに「手数料が下がった」とすぐに感じさせるとは限らない、ということでもあります。より直接的な価値は、費用データ同士が矛盾した取引が、実行プロセスに入り込むのを減らすことです。その後、私は特に@Dusk ウォレットが、最大で確保した費用、実際に消費された費用、そして最終的な払い戻しをそれぞれ別々に表示できるかに注目しています。DUSKでネットワーク手数料を支払う人にとって、単なる漠然としたgasの数字では、取引のどの段階で失敗したのかを説明しにくく、さらに異なるクライアントが同じルールで実行したかどうかも判断できません。@Dusk $BTC