なぜポリシーエンジンは、取引に対して「はい」か「いいえ」を言うだけのために、5つもの別々のステップを必要とするのでしょうか？
これは、ニュートンの評価ライフサイクルの背後にある本当の問いです。

そもそもポリシーはどうやって作られるのでしょうか？

開発者がRegoでロジックを書き、Newtonのレジストリに公開し、CIDとして参照されるIPFSに保存します。つまり、すべてのポリシーは検証可能で再利用でき、契約の中に埋もれたブラックボックスではありません。

どのポリシーが取引に適用されるかを決めるのは誰ですか？

ユーザーです。PolicyClientコントラクトをデプロイし、ポリシーを選び、自分のしきい値や有効期限のルールを設定します。私の見解では、ここが過小評価されているポイントです。集中管理のゲートキーパーではなく、制御をユーザーに取り戻します。

タスクが提出されたときはどうなりますか？

IntentがPolicyClientと組み合わさり、SDKまたはRPCを通じて#Newt Gatewayに到達します。表面上はシンプルですが、これが下流すべての起点です。

実際に取引が有効かどうかをチェックするのは誰ですか？

AVSオペレーターが独立してポリシーを評価し、BLS署名を生成します。クォーラムに到達すると、Aggregatorがそれらを1つのアテステーションにまとめます。私の見解では、これはフロー全体で最も強い設計判断です。単一のオペレーターが、何かを一方的に承認したりブロックしたりすることはできません。$NEWT

では、要点は何でしょうか？

@NewtonProtocol は、取引に別の承認ステップを追加するだけではありません。判断そのものを分散化しているのです。これこそが、注目に値する本当の転換点です。
$ARX $LAB #NewtonProtocol #NEWTtoken #NEWTUSDT
📊 取引が実行される前に、最も重要なのは何でしょうか？