Haseeb Ghiffari

しばらくの間、ニュートンのモデルレジストリに付随している「マーケットプレイス」という言葉をそのまま受け取り、複数の競合オペレーター、評判システム、そしてユーザーがエージェントのライブラリを閲覧して自分の戦略に合うものを選ぶ、というイメージを想定していました。ですが、今日そのレジストリに実際に何が掲載されているのかを調べてみると、そこに描写されている内容よりもずっと小規模な状況でした。
現在、レジストリは単一の稼働エージェントである「定期購入エージェント（Recurring Buy Agent）」で動いています。ロードマップでは、複数のエージェントからなるコンポーザブルなエコシステムへの移行を、すでに出荷済みのものではなく、まだ先にあるものとして明確に位置づけています。目標は、最初の単一エージェントである「定期購入エージェント」を超えて、検証可能なエージェントのコンポーザブルなエコシステムを育てることです。一方で、独立した書き起こし（writeup）で広まっている市場全体の説明では、ユーザーが手数料を付随させた自動化の意図を提出し、オペレーターがそれを効率的かつ検証可能に実行するために競い合う、板（orderbook）ベースのシステムだと語られています。プロトコルは、ユーザーとオペレーターの間で自動化リクエストを照合する順番待ち（板）ベースのマーケットプレイスとして動作し、オペレーターはタスクを効率的かつ検証可能に実行するために競い合います。そしてバリデータは、最終的な状態遷移の前に実行の証明を検証します。これは確かに現実的な設計ですが、説明されているとおりに機能するには複数性（plurality）が必要です。競争や評判といった概念は、競い合ったり、評判を築いたりできる選択肢が複数あって初めて意味を持ちます。

先週ちょっと面白いことがあったんだけど、仕事用のラップトップをリセットしてたら、BIOSアップデートの後からずっとセキュアブートに失敗し続けてね。ある設定が切り替わってしまって、マシンが自分自身のファームウェアを信頼するのを拒否するようになってた。しかも「measured boot（計測ブート）」ってそもそも何なのか理解するのに、ググって20分かかった。で、もちろん――たぶん今の自分の脳はもううまく区画化できないみたいで、その寄り道のせいで結局、Newton Protocolのドキュメントにまっすぐ戻っちゃった。特に、これまで何度も読み飛ばしてきたあの部分：Oracle Adapter Layer。

私はほとんどこの項目を見落としかけました。Newton自身のロードマップでは「upcoming（近日公開）」として掲載されており、ボールトやIDオラクルに関するより大きな発表の隣にあるため見逃しやすいのです。ですが、Multichain Newton Keystore Rollupの根底にある考え方は、単なる表題の規模を超えています。1つのzkPermissionsロールアップで、プログラム可能な権限を一度だけ、しかも安価に保持できるようにし、Newtonに接続するすべてのチェーンが、その同じ記録を参照するのです。各チェーンで同じポリシー・ロジックをそれぞれ再展開し、再検証し直す必要はありません。
この問題が解決しようとしていることは現実的です。現状では、ポリシーをEthereumやBase、そしてNewtonが次に展開する先のネットワークなどに適用する必要がある場合、そのようなロジックをそれぞれのチェーンで個別に評価し、実行して支払いを行う必要があります。その結果、計算が冗長になり、ガスも無駄になり、同一のポリシーが展開のたびに静かに同期からずれていくための“攻撃面”が増えていきます。冗長性の問題をきれいに解消するのは、そのために作られたロールアップが権限を保持することです。単一の正本となる記録、状態を裏付けるゼロ知識証明。ほかのチェーンは、そのロジックを自前で丸ごと保持して持ち運ぶ代わりに、そこに照合するだけで済みます。

そのデザインの裏に何があるのかに気づくまで、しばらく見惚れていました。Newtonは、再ステーキングされたオペレーター、ゼロ知識証明、ディスピュート・ウィンドウ、スラッシングによってポリシー評価を検証します。あの一連の仕組みは、説得力をもって一つの疑問に答えるために作られています――つまり、このネットワークが、このポリシーに照らして、この取引を正しくチェックしたのかどうか。これは本当に難しいエンジニアリング課題で、Newtonのアプローチは慎重です。しかし、ポリシーチェックの健全性は、照合している事実の健全性にしか依存しません。そして、私が確認したほとんどすべての実在するNewtonポリシーでは、その事実はまったく別の場所から来ています。

私は、実際にニュートンのコンプライアンス・ポリシーに基づく生データ（原材料）を供給しているのは誰なのかを調べに行きましたが、答えは結局ある名前に回帰していきました――Magic Labsです。中立的なベンダーとして、競合するデータ提供者が数多く並ぶ中の1社として存在しているのではなく、プロトコルを最初に構築したのと同じ会社であり、さらにその主要なリスクスコアリングの入力の1つも、いわゆる「Magic Labs Risk Scoring Data Oracle（Magic Labs リスクスコアリング・データ・オラクル）」を通じて提供しているのです。
少し立ち止まって考える価値があります。というのも、ニュートンのアーキテクチャ全体の売りは、2つのものの分離にかかっているからです。つまり、分散されオペレーターによって検証される「ポリシー・ロジック」と、そのロジックが動作するデータです。そしてそのデータは、プロバイダーが集うオープンなマーケットプレイスから来るはずだとされています。ニュートン自身はこれを強みだと位置づけています。ポリシーはモジュール化されており、開発者はデータソースを自由に組み合わせられ、ハードコードされたものはない。ですが、看板であり最初に立ち上げられたデータオラクルが、プロトコルを運用する同一組織のウォレットおよびメールのリスク・インテリジェンスから構築されていて、さらにPolymarketやNaverのようなクライアント向けにMagicがすでに運用している5000万ウォレットをまたぐ7年間の取引履歴に基づいているとなると、「分散されたポリシー・エンジン」と「ある1社の社内リスクモデルが、プロトコルの体裁をまとっている」という境界線は、マーケティングが示唆する以上にかなり曖昧になります。