Newton Protocols Architectureについて読んでいたとき、ある点が目を引きました。彼らは、ポリシーのロジック、計算、実行を3つの層に分けることにしたのです。

* 最初の層はポリシー層です。ここでは、ポリシーが定義され、設定され、データを提供するオラクルに接続されます。この層は、適用すべきルールが何かを判断します。たとえば、支出上限、制裁チェック、または本人確認（KYC）の要件などです。

次の層が「計算＆コンセンサス」です。ブロックチェーン上でポリシーを確認した後、Newtonはゲートウェイを通じて、オペレーターのネットワークにタスクを送信します。オペレーターはデータを受け取り、ポリシーを評価し、署名を作成します。

* 次に、十分なオペレーターが同意したら、アグリゲータがこれらの署名を1つの証明にまとめます。

* その後、検証 & 実行レイヤーが関与します。

* ここで、PolicyClientはトランザクションが起きる前に、AttestationValidatorを通じて証明を検証します。

* スマートコントラクトは、ポリシー作業をやり直した結果をチェックします。

エンジニアリングの観点から、この分離は役に立ちます。

* 物事を明確に分離したままにできます。

* ポリシーレイヤーはルールだけを定義します。

* Compute & Consensus レイヤーは、評価だけを生成します。

* 検証レイヤーは、実行前に証明だけをチェックします。

この分離のおかげで、検証コントラクトに影響を与えずにポリシールールを変更できます。

* 検証は、オペレーターがポリシーをどう評価するかとは別のままです。

* これにより、ワークフローもできます。

* 開発者はポリシーを一度だけ定義します。

* 演算子はブロックチェーンの外で評価されます。

* スマートコントラクトは、トランザクションを実行する前に証明だけをチェックします。

ニュートンは、ポリシー評価を別のサービスにして、コントラクトのための証明を生成します。

* この分離はドキュメントで興味深いと思いました。

オンチェーンでの認可としてのビルダーは、より複雑になります。認可ロジックをスマートコントラクトに入れるよりも、ポリシーの定義、評価、検証を分離した方がうまくいきますか @NewtonProtocol #Newt $NEWT