以前私たちは、オンチェーンのやり取りを理解する際、より多くを「取引そのものが成功したかどうか」に注目していました。取引をブロードキャストし、ブロックでの確認が完了し、資産が変化する——この一連の流れはシンプルで直感的です。しかし、アプリケーションが複雑になり始めると、真の問題が姿を現します。1つの取引の背後には複数のプロトコルが連結されているかもしれませんし、1つの戦略には複数のステップが含まれているかもしれません。自動化プログラムは長期間稼働する必要があるかもしれません。このとき、結果が成功であったとしても、プロセスが当初の目標に確実に合致しているとは限りません。
これが、私が後にNewton Protocolを注目するようになった理由でもあります。
多くの人がNewtonについて語るとき、AI Agentや自動化の物語の中に位置づけがちですが、私はNewtonが本当に解決しようとしている問題は、もっと基礎的なものだと思っています。つまり、「チェーン上の自動化された振る舞いを、明確なルールに従って実行できるようにすること」です。なぜなら、将来の問題は「機械が実行できるかどうか」ではなく、「実行するときに境界を理解しているか」「条件に従っているか」「自分の行動が期待どおりであることを証明できるか」になるからです。
Newton のホワイトペーパーにおける中核となる設計は、まさにこの点を中心に展開されています。
提案されている Authorization Layer は、単に権限ボタンを増やすだけではありません。アプリと実行の間に、ルール判定の仕組みを構築するものです。従来のスマートコントラクトは主に「コードをどう実行するか」を解決してきましたが、Newton が補おうとしているのは「どのような状況で実行すべきか」です。
この違いは非常に重要です。
従来の方式では、ユーザーがある操作に対して許可を出すことは、通常、ある種の能力をアプリに委ねることを意味します。しかし複雑なシーンでは、このやり方は十分に精緻ではありません。自動化戦略には金額の範囲を制限する必要があるかもしれませんし、資産管理システムには特定の条件を満たす必要があるかもしれません。オンチェーンのプログラムは事前に定めたロジックに従う必要があることもあります。もしすべての判断がアプリ内部に組み込まれて固定されてしまうと、その後の調整コストは非常に高くなります。
Newton の Policy Framework は、これらの複雑な条件を、プログラマブルなルールとして抽象化するものです。
開発者が、実行ロジックのさまざまなタイプを定義できるようにします。たとえば、許可する振る舞い、制限する振る舞い、どのような条件で操作をトリガーするか、実行中に満たす必要がある要件などです。これにより、アプリは固定のコントラクトを呼び出すだけではなく、さまざまなシーンに応じて異なる戦略を組み合わせられるようになります。
それが、Newton と一般的な自動化ツールの最大の違いだと思います。
単にユーザーの操作ステップを減らすためではなく、新しい実行モードを確立しようとしているのです。つまり、システムがルールの範囲内でタスクを完了できるようにすることです。
これは Automation Intent の設計と一体につながっています。
これまでのオンチェーンのやり取りは、ユーザーがシステムに「私は何をするつもりだ」ということを伝えるような感覚に近いものでした。たとえば、資産の交換、資金の移転、あるプロトコルの呼び出しなどです。しかし、将来のより複雑なシーンでは、ユーザーは各ステップの操作よりも、結果をより重視する可能性があります。
たとえば、ユーザーは資産をある状態に保ちたいかもしれないし、戦略は市場の変化に応じて調整したいかもしれませんし、あるタスクを長期的に自動で実行し続けたいかもしれません。
このとき、システムが理解すべきは、単一の指示ではなく目標です。
Newton は Intent によってユーザーが目標を表現できるようにし、そこに Policy の制約を組み合わせて実行パスを決めることで、自動化プロセスを事前に定めたロジックにより合致させようとしています。
もちろん、目標とルールが決まった後には、もう一つの重要な問題があります。実行プロセスが逸脱していないことをどう証明するかです。
これが Newton のアーキテクチャにおける Verifiable Automation の価値です。
Operator Network により、タスクの実行はもはや単一の実行者に完全に依存するのではなく、調整と検証の仕組みが形成されます。さらに TEE と ZK の技術を組み合わせることで、システムは実行環境が信頼できることを保証しつつ、結果に検証可能性を持たせることができます。
要するに、TEE は実行環境の問題を解決し、計算プロセスを信頼できる条件下で実行できるようにします。ZK は証明の問題を解決し、システムが「要求された条件に合う結果である」ことを、すべての詳細を公開せずに証明できるようにします。
この設計で面白いと思ったのは、Newton が「自動化をより速くする」ことに重点を置いていない一方で、「自動化をより信頼できるものにする」ことを考えている点です。
将来、オンチェーンで本当に大規模に稼働するようになれば、効率ももちろん重要ですが、信頼性も同じくらい重要です。
市場の観点から言うと、多くのプロジェクトが新しいアプリをどう生み出すかに注目している一方で、Newton は、より複雑なアプリを長期的に稼働させる方法に注目しています。この種の基盤インフラは、アプリ層のプロジェクトのように素早く注目を集めるとは限りませんが、解決する課題は多くの場合もっと根本的です。
もちろん、Newton は現時点でもまだ市場の検証が必要です。ホワイトペーパーの中のアーキテクチャはあくまで出発点にすぎず、本当に重要なのは将来、より多くのアプリが接続されるのか、これらの能力が実際のシーンで使われるのか、そしてネットワーク全体が継続的に稼働できるエコシステムを形成できるのかです。
$NEWT について私がより注目しているのは、短期的な価格変動ではなく、それがオンチェーン自動化の体系における基礎モジュールになり得るかどうかです。
これまでブロックチェーンは資産移転の問題を解き、スマートコントラクトはルール実行の問題を解いてきました。そして Newton が探っているのは、ますます多くのタスクがシステムによって自動的に完了されるようになったときに、これらの振る舞いを常に明確な目標の周りで動かすにはどうするか、ということです。
もし将来、オンチェーンの世界が本当に高度な自動化段階に入るなら、目標・ルール・実行をつなぐインフラは、非常に重要なレイヤーになり得ます。