当初、@NewtonProtocolは主にプログラマブルなコンプライアンスを目的としていると思っていました。アーキテクチャについてもう少し時間をかけて調べるうちに、個々のポリシーに注意を向けることが減り、それらのポリシーが実際にどこに存在しているのかにもっと注目するようになりました。この変化が、私のプロトコルの見方を変えました。

この設計では、すべてのスマートコントラクトの中に業務ルールを直接埋め込む代わりに、認可をアプリケーションの実行から分離しています。Regoで記述されたポリシーは認可ロジックを定義し、個別のアプリケーションは、PolicyClientの設定を通じてそれぞれの運用上の制約を提供します。支出上限、承認された受取人、管轄上の制限などの要件は、恒久的に埋め込まれたポリシーロジックではなく、構造化されたランタイム設定になります。

その区別は、最初に見えるよりもずっと重要に思えます。設定を変更するだけで、単一のポリシーは再利用可能なまま、異なるアプリケーションが異なる認可の境界の中で動作できます。ポリシーは意思決定プロセスを記述します。アプリケーションはコンテキストを提供します。これらの責務は意図的に独立しています。

でも、どうしても引っかかることがありました。

再利用性は、承認の生成元となった前提に対する認可がそのまま結びついている場合にのみ機能します。Newtonは、PolicyClientの設定が変更されるたびに新しいポリシー識別子を生成することでこれに対応しています。以前の設定で生成されたアテステーションは、参照されるポリシー識別子が変更された時点で適用されなくなります。したがって、認可はポリシーの論理だけでなく、承認が生成された時点で存在していた正確な設定にも結びつくことになります。

その設計は境界を変えます。

運用上の要件が進化するたびにアプリケーションのコードを修正するのではなく、開発者はアプリケーションのロジックを保ったまま、ポリシーや設定を調整します。これは複数のアプリケーションにまたがる保守を簡単にする可能性がありますが、同時に責任がポリシー管理側へ移ります。設定そのものが、単なる配備の詳細ではなくセキュリティモデルの一部になります。外部情報は、別の責任の層を持ち込みます。PolicyDataオラクルは隔離されたWASMコンポーネントとして実行され、ポリシーが決定的に評価できる構造化された実行時データを返します。実行時ランタイムは意図的にネットワークアクセスを制限し、失敗はそれが起きた場所に応じて扱いが異なります。構造化されたアプリケーションエラーはポリシー評価に引き続き見える一方で、実行失敗は DataProviderError イベントとして扱われ、通常の判断を生成するのではなく、認可を完全に停止します。

信頼は消えません。信頼の置き場所が変わるだけです。

アテステーションの期限切れは、もう一つの運用上の意思決定を導入します。短い承認ウィンドウはリプレイの機会を減らしますが、長いウィンドウは実行前にユーザーへより多くの柔軟性を与えます。どちらの選択も、リプレイ耐性と使いやすさのバランスを取るための期限切れウィンドウではありません。ユーザーが最終的にやり取りするのは、契約状態だけではなく、ポリシーのバージョンと実行コンテキストの両方に反映される有効性を持つアテステーションです。

この見方では、Newtonはスマートコントラクトのロジックを置き換えることにそれほど注力するというより、アプリケーション要件が変わると認可が進化する場所を移し替えることに関心があるように見えます。

配備済みのコントラクトからポリシーの進化を切り離すことで、長期的なセキュリティは単純化されるのでしょうか。それとも、運用の複雑さがたまっていく別の層を作るだけなのでしょうか？

$NEWT #Newt $SUI $ETH