Saya telah memikirkan bagaimana perubahan keamanan terjadi ketika sebuah smart contract diperbarui (di-upgrade) alih-alih dideploy dari nol. Kontrak baru dimulai dengan pengaturan yang bersih, tetapi kontrak yang sudah ada sudah memiliki pengguna, data tersimpan, dan logika yang tidak bisa begitu saja digantikan. Itulah mengapa pendekatan Newton menarik perhatian saya. Alih-alih meminta developer membangun semuanya kembali, pendekatan ini memungkinkan sebuah smart contract yang dapat di-upgrade untuk mewarisi "NewtonPolicyClient" melalui proxy upgrade sambil tetap mempertahankan state yang sudah ada serta logika bisnis inti dari kontrak tersebut. Ini membuat adopsi jauh lebih praktis untuk proyek yang sudah berjalan, karena mereka dapat memperkenalkan otorisasi berbasis kebijakan tanpa memaksa pengguna untuk bermigrasi ke aplikasi baru yang sepenuhnya berbeda.
Semakin dalam saya menelusuri proses integrasinya, semakin saya menyadari bahwa upgrade itu sendiri hanya satu bagian dari cerita. Apa yang terjadi segera setelah upgrade tampaknya sama pentingnya. Klien kebijakan (policy client) masih perlu diinisialisasi dengan benar, terhubung ke TaskManager yang dimaksud, dan ditetapkan ke pemilik policy-client yang tepat. Newton menyertakan flag inisialisasi khusus agar penyiapan ini hanya dapat terjadi sekali, yang membantu mencegah seseorang mengulang proses tersebut nanti. Pada saat yang sama, perlindungan ini memiliki keterbatasannya sendiri. Perlindungan ini mencegah inisialisasi lain, tetapi tidak dapat memverifikasi apakah inisialisasi pertama selesai dengan konfigurasi yang benar. Jika alamat yang keliru diberikan selama penyiapan awal itu, kontrak akan dengan setia mengingat pilihan tersebut sampai diubah melalui fungsi manajemen yang tersedia.
Detail lain yang layak mendapat perhatian lebih adalah tata letak penyimpanan. Kontrak yang dapat diupgrade bergantung pada mempertahankan urutan persis variabel penyimpanan yang sudah ada, sehingga setiap variabel baru yang diperkenalkan selama proses integrasi Newton harus ditambahkan di akhir, bukan disisipkan di antara variabel-variabel lama. Kedengarannya mungkin seperti persyaratan teknis kecil, tetapi itu melindungi kontrak agar tidak secara tidak sengaja menimpa state yang sudah ada. Bahkan jika lapisan otorisasi diimplementasikan dengan benar, tata letak penyimpanan yang salah dapat menimbulkan masalah yang jauh lebih sulit dideteksi karena memengaruhi data yang sudah digunakan aplikasi sebelum upgrade.
Hal lain yang menonjol saat membaca panduannya adalah ini. Menambahkan Newton ke sebuah kontrak tidak langsung mengamankan setiap fungsi di dalam kontrak tersebut. Perlindungan hanya berlaku pada bagian yang secara sengaja diminta oleh developer untuk melakukan validasi attestasi sebelum logika bisnis dieksekusi. Jika fungsi lama masih melakukan tindakan yang sama tanpa memanggil "_validateAttestation" atau "_validateAttestationDirect", jalur tersebut tetap berada di luar sistem kebijakan (policy system). Dengan kata lain, mengintegrasikan kerangka otorisasi hanyalah permulaan. Setiap jalur eksekusi yang seharusnya dilindungi harus ditinjau dengan saksama untuk memastikan validasi terjadi sebelum perubahan state penting apa pun.
Di sinilah menurut saya rancangan Newton menjadi menarik. Struktur modularnya memberi fleksibilitas yang dibutuhkan banyak protokol yang sudah ada. Mereka dapat memperkuat keamanan secara bertahap alih-alih mengganti bertahun-tahun pengembangan dengan arsitektur yang benar-benar baru. Itu membuat upgrade menjadi lebih tidak mengganggu bagi pembangun dan pengguna. Namun, fleksibilitas itu juga mengalihkan lebih banyak tanggung jawab ke proses upgrade itu sendiri. Menguji upgrade pada fork, memverifikasi tata letak penyimpanan, memastikan alamat TaskManager, dan melindungi transaksi inisialisasi dengan multisig atau timelock tidak hanya merupakan langkah yang disarankan—langkah-langkah itu menjadi bagian dari model keamanan secara keseluruhan.
Semakin saya memikirkannya, semakin saya tidak melihat upgrade ini sebagai rutinitas deployment. Rasanya lebih seperti serah-terima yang direncanakan dengan matang antara aplikasi yang sudah ada dan lapisan otorisasi yang baru. Setelah serah-terima itu selesai, Newton dapat memberikan penegakan kebijakan tanpa memaksa developer meninggalkan logika yang sudah mereka bangun. Tantangan sebenarnya adalah memastikan transisi ditangani dengan tingkat kehati-hatian yang sama seperti sistem keamanan yang diperkenalkan, karena lapisan otorisasi yang dirancang dengan baik hanya dapat diandalkan sejauh cara ia diintegrasikan ke kontrak yang benar-benar berjalan.