自動化で最も難しいのが実行ではないこともあります。そもそも、どの指示を実行に値するものとして扱うかを決めることです。多くのソフトウェアでは、その判断はアプリケーションのロジックの中に隠されています。ユーザーがボタンをクリックすると、システムはいくつかの条件を確認し、処理は前に進みます。しかし、資産、権限、そして複数のオペレーターが絡むと、デフォルトであらゆる要求を信頼することは安全な前提ではなくなります。
ニュートンは、その問題を別のやり方で扱います。あらゆるアクションは、まずIntent（誰かがやりたいことの説明）として始まります。その段階では、まだオンチェーン上で何も起きていません。Intentは提案にすぎません。それがトランザクションになる前に、ニュートンはそれを一連のポリシーに照らして評価します。これらのルールを満たしたIntentだけが、実行の領域へ進むことを許可されます。
一見すると、これは標準的な認可レイヤーのように聞こえます。たとえば、承認の前に最後の署名を付けるだけだというふうに、取引がすでに組み立てられた後で政策チェックが行われるイメージを簡単に思い描けます。その前提は、より深い直感を反映しています。すなわち、取引がシステムの基本単位であり、ガバナンスはそれでできることを制約するだけだ、という考えです。
Newton は、その関係を逆にします。政策エンジンが、その Intent が許容できると判断するまで、取引は存在しません。評価が先に来ます。実行はその後です。
この順序は、政策（ポリシー）の役割を完全に変えてしまいます。政策は、すでに存在している取引を包む受動的な制約ではなくなります。政策は、そもそも取引が存在するに値するかどうかを決める仕組みになります。意図（Intent）はある行為を提案しますが、政策は、その提案がシステムのルールと両立しているかどうかを判断します。ガバナンスは、実行の端にあるチェックポイントであることをやめ、意図を権限へと翻訳する層になります。
この違いが重要なのは、意図（Intent）が、承認待ちの未完成な取引に過ぎないわけではないからです。Intent はアーキテクチャ上で別の位置を占めます。取引は、すでに特定の実行経路にコミットされています。つまり、特定の calldata、特定の効果、特定の状態変化です。Intent はそれよりも抽象的なものを記述します。つまり、まだ結果を伴っていない可能性としての行為です。政策は、その可能性を事後に検査しません。それを解釈し、システムがそれを現実にすることを受け入れるかどうかを決定します。
この設計は、責務の明確な分離も生み出します。アプリケーションは、ガバナンスのロジックを各ワークフローに埋め込むことなく、ビジネス上の目標を記述します。政策の著者は、それらの目標が実行可能になる条件を定義します。すべての Intent を同じ評価層を通すことで、Newton はガバナンスを、異なるアプリケーションに隠されたバラバラのチェックの集合にしてしまうことを避けます。
そのトレードオフは微妙ですが、非常に根本的です。実行はもはやアーキテクチャの中心に立ちません。システム全体は、意図と結果の間を取り持つ政策層の質と完全性に依存します。弱い政策は危険な行為を許可します。過度に厳格な政策は、正当な意図が決して形にならないようにしてしまいます。Newton は、その依存関係を受け入れています。このモデルでは、ガバナンスは取引を守っているのではなく、取引を生み出しているからです。
私は、その“逆転”に何度も立ち戻ります。ほとんどのシステムでは、取引をプリミティブ（基礎単位）として扱い、ガバナンスを制約として扱います。 @NewtonProtocol t Intent をプリミティブとして扱い、取引は、誰かが最初にやりたいことをガバナンスが解釈し、ふるいにかけ、正当化した後に初めて姿を現す、と考えるわけです。
