ニュートン・プロトコルのアーキテクチャを初めて読んだとき、私はそれがソフトウェアを描写しているのだと思い続けていました。読み進めるほど、未来の職業の説明のように感じられてきたのです。

ニュートンがまったく新しいものを発明したからではありません。見落とされがちなスキルを、システムの中心に押し出しているからです。

長年、エンジニアはアプリケーション内にアクセス制御のルールを書いてきました。コンプライアンスチームはポリシーを書き、セキュリティチームがそれを実施してきた。ニュートンは、その境界を曖昧にします。

そのアーキテクチャ全体は、規制、リスク上限、KYC要件、サンクション（制裁）スクリーニング、そして投資家の適格性といったものを、実行可能なコードへと変換することに依存しています。すると突然、「ポリシーを書く」ことが単なるドキュメントではなく、プロダクトそのものの一部になるのです。

それは、将来的にどのプロトコルが必要とする人のタイプまで変えてしまいます。

ポリシーエンジニアは、単にスマートコントラクトを書くわけではありません。リーガルおよびビジネス上のルールを、Regoのようなフレームワークを使って機械が実行できるポリシーへと翻訳し、それをテストし、規制が変わればポリシーを更新し、すべての認可（オーソリゼーション）判断が自動化され、かつ検証可能であることを保証するのです。

興味深いのは、この役割がすでに、従来のセキュリティやアイデンティティの仕組みの中で断片的に存在していることです。ニュートンはゼロからそれを発明しているわけではありません。失敗したログインではなく、現実の資産が影響を受ける可能性がある分散型ファイナンスの世界に、その役割を持ち込んでいるのです。

認可レイヤーが一般的なインフラになっていくなら、再利用可能なポリシーライブラリは、今日のオープンソースソフトウェアパッケージと同じくらい価値を持つかもしれません。開発者はアプリケーションに集中し、ポリシーエンジニアは、それらのアプリが実際に何を許可されるべきかを定義することに集中する。そんな分業が生まれます。

ニュートンが成功するかどうかに関わらず、私はこれがより大きな変化を示していると思います。
何年も前から暗号業界は、より優れたスマートコントラクト開発者を探してきました。

次の採用競争は、コードとコンプライアンスの両方を理解し、片方をもう片方へと翻訳できる人をめぐるものになるかもしれません。

#newt $NEWT $SXT