質問は技術的に聞こえますが、暗号が向かう先について、より深い部分に触れています。私たちは何年もかけて決済を完璧にしてきました――取引を速く、安く、不可逆にすることです。ニュートンは逆方向からこの問題に取り組みます。つまり、決済の前に何が起きるべきなのか、そして、その決済前の瞬間に私たちは実際どれほどの制御を及ぼしたいのかを問うのです。
ご存じない方のために説明すると、ニュートンは6月下旬にBaseとEthereumで稼働を開始した認可レイヤーです。Magic Labsによって開発されており、EigenLayerのオペレーターとゼロ知識証明を用いて、実行される前に取引をポリシーに照らして評価します。保管庫は担保比率、制裁リスト、またはオラクルの健全性を確認したいですか？ニュートンは、必要なデータ――オンチェーンまたはオフチェーン――を照会し、署名付きで「合格」か「不合格」を返します。クリアした場合にのみ取引は進みます。
私を惹きつけるのは、単なるアーキテクチャではありません。その下にあるデザイン哲学です。ニュートンは本質的に、Visaの認可モデルをオンチェーンに持ち込んでいます。意図と実行の間に位置する、意思決定のレイヤーです。伝統的な金融では、このステップは明白です。しかし暗号領域では、これがほとんど欠けてきました。ルールはドキュメントやフロントエンド、あるいは手作業のプロセスに存在し、すべての取引を統治する、執行可能なコードとしては存在していないのです。#NEWT
ここがややこしいところです。Rego言語をベースにしたニュートンのポリシーエンジンは、非常に表現力があります。Chainalysisの制裁データ、RedStoneの価格フィード、Credoraのリスク評価、Webacyのウォレット評判、ボルトの健全性スコアなどから条件を組み合わせ続けられます。単一のボルトのリバランス承認の前に、ポリシーが10種類ものシグナルを確認することも可能です。細かさの限界はほとんどありません。
でも、それでいいのでしょうか？
この緊張感については、かなり考えてきました。片方では、機関投資家の資本は精密さを求めます。もしTVLが数千万ドル規模のボールトを運用しているなら、「キュレーターを信頼する」はリスクの枠組みとしては不十分です。執行可能な命令が必要です。例えば、X倍を超えるレバレッジへのエクスポージャー禁止、フラグ付きアドレスとの接触禁止、オラクルの乖離がYベーシスポイントを超える場合の実行禁止。ニュートンならそれを実現できますが、ハードコードされたスマートコントラクトの論理では単純には不可能です。
一方で、認可を作り込みすぎることには現実のコストがあります。追加のポリシーチェックが増えるたびに、レイテンシー、複雑性、そして潜在的な障害ポイントが増えます。例えば、リバランスのたびに6種類のオラクルのアテステーション、2つのコンプライアンス画面、そしてリスク評価の更新を要求するボルトは、技術的には素晴らしいかもしれませんが、実務的には脆くなりがちです。あるデータ提供者が遅れたり、ポリシー設定が誤っていたりすれば、正当な取引が失敗します。システムは、提供しようとしている市場よりも遅くなってしまいます。
答えは、どこか中間にあると思います。ニュートンの本当の価値は、最大のきめ細かさではなく、選択的なきめ細かさです。リスクに比例してポリシーの強度を設定できること。ホワイトリストに載った相手同士での定型のステーブルコイン送金なら、フルのコンプライアンス・スタックは不要でしょう。プロトコルをまたいだボルトの再配分でレバレッジが絡むなら、重いチェックを投入するべきです。
私が最も説得力を感じるのは、ニュートンのモジュール型のアプローチです。ポリシーパックは組み合わせ可能です。キュレーターは、自分の使命に合う執行レベルを選びます。この柔軟性が重要なのは、ユースケースによって必要な閾値が異なるからです。RWAはアイデンティティやコンプライアンスを優先するかもしれません。AIエージェントのウォレットはレート制限やコントラクトの許可リスト登録を優先するかもしれません。イールド・バルトはオラクルの健全性や担保の閾値を優先するかもしれません。
私が抱えている懸念の1つは、採用のスピードです。メインネットのベータは稼働していますが、ニュートンの成功は、ビルダーたちが実際の金融フローにこれらのポリシーチェックを組み込むかにかかっています。インフラは、それが生み出す習慣の質次第です。VaultKit SDKは役に立ちますが、「execute then monitor（実行してから監視）」から「authorize then execute（承認してから実行）」へと、開発者の取引フローの考え方を変えるのは、時間のかかるマインドセットの転換です。
私の結論です。ニュートンは単なるツールではありません。暗号の次のフェーズでは、プログラム可能な信頼境界が必要になるという賭けです。論点は、オンチェーン認可が必要かどうかではありません。必要です。では、システムが慎重すぎて役に立たなくなるほどまで、どの程度まで強制するのかが論点です。ニュートンはそのダイヤルを私たちに与えてくれます。難しいのは、どこに設定するかを知ることです。#Nevvt
もし今日、あなたがボルトのポリシーを設計するなら、どちらを優先しますか。オーバーヘッドの高い、よりきめ細かな制御か、それとも、シンプルなルールで実行を速くするか？
