@NewtonProtocol $NEWT #Newt

暗号資産における最も高額なバグは「エクスプロイト（脆弱性悪用）」ではありません。何千人もの開発者が、まったく同じセキュリティ課題を、ほんの少し違うやり方で独立して解いているのです。そこで私は、NewtonのVault SDKをまったく別の視点で見直しました。つまり、ポート間で何千もの独自のハンドリング処理を排除する、ひとつの標準を生み出していたのです。私の主張は、NewtonのVault SDKが開発者向け機能を追加することで価値を生み出しているのではなく、協調（コーディネーション）の複雑さを取り除くことで価値が生まれている、というものです。

当初私は、コンプライアンス・エンジニアリングは主に規制上の問題だと考えていました。深掘りしてみると、実際にはしばしば統合（インテグレーション）の問題です。アイデンティティ確認、ポリシーの適用、認可、そしてアテステーション（証明）の仕組みを、それぞれが独自に実装しているアプリケーションが、私が「Integration Debt（統合負債）」と呼んだものを生み出します。これは、複数のコードベースにまたがって分断されたセキュリティロジックを維持する際に生じる、見えにくいコストです。

興味深いのは、Newtonが別のSDKを提供していることではありません。Vault SDKが、共通の認可モデルの周りに、ポリシーを理解したビルディングブロックを集約している点です。別々のアイデンティティプロバイダや権限システム、コンプライアンスのワークフローをつなぎ合わせる代わりに、開発者は、実行前にポリシーを評価する標準化されたコンポーネントを再利用できます。これにより、インフラを作り直す作業から、アプリケーションを構築する作業へと労力の向け先が変わります。

このトレードオフも同様に重要です。抽象化が進むほど、SDKのガバナンスと、新しい規制や脅威モデルに合わせて進化できるかどうかへの依存度も高まります。もしそうした前提が時代遅れになれば、それらを継承するすべてのアプリケーションが同じ盲点を共有することになります。

このアプローチが成功すれば、Web3における競争上の優位性は、より多くのインフラを書き足すことから、不要なインフラを取り除くことへとシフトするかもしれません。オープンな問いは、「どのエコシステムが開発者に最も多くのツールを提供するのか」ではありません。「新しい依存関係を生み出さずに、最も多くの複雑さを取り除くのはどれか」です。