ニュートン・プロトコルのアップグレードガイドを読んでいるうちに、ある実装上の細部に何度も立ち返りました。新しいストレージ変数は、既存のストレージレイアウトに挿入されるのではなく、常にその末尾に追加されます。
それはほとんど些細なことに思えます
そうは思いません
ストレージレイアウトを見誤ったせいで、アップグレーダブルコントラクトが壊れるのを見たことがあります。プロキシのアップグレードは成功してテストも問題ないように見えるのに、それから数週間後に、ストレージの順序が変わったことである変数が上書きされていたと誰かが気づくんです。めちゃくちゃです。コントラクトは必ずしもすぐに失敗するとは限りません。時には、ほんの少し違う挙動をし始めるだけで、それがはるかに原因究明しにくいんです。
Newton Protocolは、ストレージレイアウトを、再配置して整え直すものではなく、保持されるべきものとして扱うことで、その罠を避けています。このアプローチは、アップグレード可能なプロキシがいかに脆いかを尊重しているので、私は好ましいと思います
目立った別の点は、newtonPolicyClientInitializedフラグです。その目的はシンプルです。アップグレード後の初期化は一度だけ行えます。Newton Protocolは、フォーク上でアップグレードをテストし、初期化トランザクションを実行するときはtimelockまたはmultisigを使うことも推奨しています。これは、私には定型のアドバイスには感じませんでした。むしろ、新しい実装がデプロイされた時点ではアップグレードが完了していないことを認めるものに感じました
初期化はアップグレードの一部です
そのステップが完了するまで、認可ロジックはすでにコントラクト内部に存在している可能性がありますが、ポリシークライアントはまだ正しいTaskManagerに接続されていない、または意図したポリシークライアントのオーナーに割り当てられていないかもしれません。どちらかの値が間違っていれば、デプロイ自体は成功したように見えても、認可レイヤーが失敗することがあります
だからこそ、私は一度限りの初期化フラグが重要だと思います
誰かが初期化をもう一度実行するのを防げますが、最初の実行を間違えることまでは防げません。初期設定にミスが含まれているなら、それを一度限りのフラグでロックしても、魔法のようにそれが解消されるわけではありません。ただ、最初の実行が、デプロイ全体の中でも最も重大な瞬間の1つになるだけです
また、Newton Protocolは初期化後にすべての設定を恒久的にフリーズしないことにも気づきました。ポリシークライアントのオーナーは、その後でもポリシー設定を更新したり、ポリシーコントラクトのアドレスを変更したり、所有権を移転したりできます。私は、システムが決して進化する必要はないふりをするより、こちらのほうを実際に好みます。インフラの変更。ガバナンスの変更。要件の変更。課題は、それらの権限が時間の経過とともに適切に管理されたままでいることです。ストレージの互換性は、まったく別種のリスクを生み出します
Newton Protocolの良い点の1つは、チームがアプリケーションをゼロから作り直さずに、ポリシーの強制を導入できることです。これは実務的な設計判断です。とはいえ、プロキシのアップグレードでは、ストレージの互換性を完全に維持し続ける必要があります。変数を間違った位置に1つ挿入するだけで、認可レイヤーがまったく健全に見えても、無関係なアプリケーション状態が静かに壊れてしまう可能性があります
私は、十分に多くのアップグレード可能なシステムを見てきたので、それが机上の懸念ではないことを知っています
見落としてはいけない別の詳細として、実行フローがあります。新しいNewtonの保護（protected）関数を追加しても、同じアクションを行う古い関数が自動的に安全になるわけではありません。認可を強制すべきあらゆる経路は、保護されたビジネスロジックが実行される前に、必ずvalidateAttestationまたはvalidateAttestationDirectを呼び出す必要があります。その実行経路を1つ見落とすだけで、気づかないうちにセキュリティ保証が不整合になってしまいます
Newton Protocolについて私が最も面白いと感じたのは、おそらくそこだと思います
そのアーキテクチャでは、NewtonPolicyClientが分離されています
アプリケーションのビジネスロジックから考える、つまり開発者に新しいフレームワークのためにすべてを作り直させるのではなく。私は一般的に、その種のモジュール化されたアプローチを好みます。大規模なシステムは、最初から丸ごと作り直されることはめったにありません。アップグレードを1回ずつ重ねながら進化していくからです
同時に、ふと考え続けています。本当にそのリスクは消えてしまうのだろうか、と
あるいは、単に移動するだけなのか
Newton Protocolは、既存のアップグレード可能なコントラクトに認可をより簡単に統合できるようにします。これは価値があると思います。ですが、その一方で、プロキシのアップグレード、ストレージ移行、そして最初の初期化呼び出しが、ほぼすべての運用上のリスクが集中するポイントになります
それは設計の弱点とは見ていません
私は、それは「良いアーキテクチャは難しい判断を排除しない」というリマインダーだと捉えています。たいていの場合、それらの判断を見つけやすくするだけです
すべてのアップグレードはコードを変えますが、すべてのアップグレードがセキュリティを強化するわけではありません。私にとってNewton Protocolは、レジリエントなスマートコントラクトを作るうえで、小さな実装上の細部こそが大きな影響を与えることを示しています