M4KELL

アップグレード可能性は、たいてい「契約（コントラクト）の問題」として語られていることに、ずっと気づいていました。 Newtonのスマートコントラクト統合ドキュメントを読んで、見方が変わりました。つまり、「中の認可ロジックが進化していく一方で、コントラクトアドレス自体は安定したまま」だとしたらどうなるのか？ @NewtonProtocol $NEWT #Newt NewtonProtocolでは、既存のPolicyClientを新しいポリシーに向けることができます。 setPolicyAddress(newPolicy) しかしこれは、単なる盲目的なポインタの更新ではありません。 setPolicyAddress()が呼ばれると、ポリシーのファクトリバージョンがTaskManagerの最低互換ランタイムバージョンと照合されます。互換性がない場合は、サポートされていないポリシーロジックを取り付ける代わりに更新がリバートされます。 移行フローはさらに次の通りです。 互換性チェック ↓ 互換性のないポリシーデータを再デプロイ ↓ 最新のファクトリ経由でポリシーをデプロイ ↓ 既存のPolicyClientを更新 ↓ 移行の検証 私が特に注目したのは、「動かないもの」がある点です。 PolicyClientのアドレスは同じままです。 つまり、ポリシーの実装や互換性のあるポリシーデータが進化しても、実行に向けたクライアントは安定したままにできます。Newtonのドキュメントでも、クライアントアドレスが変わらないため、アイデンティティリンクとユーザー同意はそのまま維持される、とされています。 私にとって、これは面白いアーキテクチャ上の分離を生み出します。 安定したクライアントのアイデンティティ ≠ 固定された認可ロジック クライアントは継続性を提供します。 ポリシーは変更を提供します。 互換性チェックが、取り付けてよい変更を定義します。 これは「単なるアップグレード機能」よりも重要だと感じます。認可システムは進化する必要がありますが、それに基づく統合もまた継続性を必要とします。 私に残された疑問は同意（コンセント）についてです。 PolicyClientは同じままで、そのポリシーが変わるとしたら、ユーザーは何を承認したと考えるべきでしょうか？ クライアント自身でしょうか。それとも、その背後にある特定のポリシーバージョンでしょうか？ 同意はどこに紐づくべきでしょうか？ #VitalikOutlinesLeanEthereumRoadmap #BrazilCentralBankSaysStablecoinsElectronicMoney #UKFCAPublishesCryptoRegFramework #BitcoinFallsOver50%FromOctoberHigh $LAB $VANRY