私が @Dusk を見るたびに結局立ち戻ってしまうのは、それが単に、あるアドレスから別のアドレスへと取引が移動するだけの話ではない、という点です。
その裏で起きているのが、送金の下にある仕組みです。
取引は決して、「この資産をAからBへ送ってください」というメッセージだけではありません。ネットワークは、要求されている内容を検証し、関連するルールが満たされているかを確認し、必要なロジックを実行し、場合によっては契約のデプロイや契約との相互作用を行い、結果として生じた状態を更新し、そのプロセス中に使われた計算資源が会計上きちんと計上されていることを保証しなければなりません。
そこで、送金（転送）コントラクトの役割が興味深くなります。
転送コントラクトは、適用されるルールに基づいて取引を検証すること、必要に応じてコントラクトのデプロイまたはコントラクト呼び出しを扱うこと、そして実行に伴う計算作業をカバーするためのガスを差し引くことを担っています。
だからガスは、単に取引に付随する余分な数字なだけではありません。
それは、ネットワークが実際に行わなければならない何かを表しています。
すべてのコントラクト呼び出しには計算が必要です。すべての状態遷移には処理が必要です。取引ロジックに追加の層が加わるたびに、バリデータとネットワークが扱わなければならない、別のリソースコストが発生する可能性があります。
その観点に立てば、計算上の会計は直感的に意味を持ちます。
実行が資源を消費するなら、実行には測定可能なコストがあるべきです。
さもないと、ネットワークは、必要な資源を直接会計処理せずに、ユーザーがますます複雑な計算を要求できる状態を実質的に許してしまうことになります。
それは明白な問題を生みます。
ブロックチェーンには有限の計算能力があります。
もし取引の価格が、処理に必要な作業ではなく「受け渡される価値」だけで決まるなら、理屈の上では、2つの取引はまったく異なる計算フットプリントを持ち得るのに、ユーザーの視点からは似て見えてしまう可能性があります。
単に資産を移動するだけだ、と言えるかもしれません。
別のケースでは、複数の契約との相互作用を引き起こし、複数の状態要素を変更し、処理量も大幅に増やす可能性があります。
両者を同等だと扱うと、実行の本当のコストが隠れてしまいます。
しかし、ここからが面白いトレードオフの始まりです。
取引システムが表現力を増すほど、計算コストを予測可能にするのは難しくなります。
ユーザーは一般に、取引がシンプルに感じられることを望みます。
ユーザーは、何に署名しているのか、いくらかかるのか、その後どうなるのかを知りたいのです。
一方で開発者は、すべてのやり取りを可能な限り単純な操作にまで落とし込むことなく、洗緻なアプリケーションを構築するために十分な柔軟性を求めています。
ネットワークは、この2つの期待のちょうど中間に位置する必要があります。
計算上の会計（コンピュテーショナル・アカウンティング）が少なすぎると、ネットワーク資源の非効率的、あるいは悪用につながるおそれがあります。
価格モデルの複雑さが過剰だと、取引が一般のユーザーにとって理解しにくくなります。
そしてそれは、実行レイヤー設計に関するより大きな問いを生み出します。
複雑さはどこに置くべきでしょうか？
ユーザーは、ますます洗緻になっていく取引の計算コストを理解することを期待されるべきでしょうか？
開発者は、その複雑さの大部分を抽象化すべきでしょうか？
それともプロトコル自体が進化し続け、リソース使用が測定可能なままでありつつ、ユーザー体験を不必要に複雑にしないように会計モデルを維持すべきでしょうか？
私は、Duskで見守るべき面白いポイントのひとつがこれだと思います。
持続可能な実行とは、取引を速くしたり安くしたりすることだけではありません。
また、ネットワークがより表現力を持つようになっていくにつれて、取引によって必要となる計算作業を測定し、価格付けし、管理できる仕組みを作ることでもあります。
課題は、そのバランスを見つけることです。
計算に現実のコストがあるなら、そのコストを無視することは持続可能ではありません。
しかし、そのコストの算出があまりに複雑になってユーザーが「何に対して支払っているのか」を理解できなくなるなら、会計システム自体が使い勝手の問題になり得ます。
そこで私が何度も考え直す疑問は、こうです。
明示的な計算上の会計はDuskの実行モデルをより持続可能にしますか？それとも、価格計算の複雑さが増すことによって、最終的にそれが独自のUX課題になっていくのでしょうか？
