#newt $NEWT @NewtonProtocol #Newt
dulu saya mengira kebijakan protokol pada dasarnya adalah kumpulan aturan yang statis. Unggah sekali, audit sekali, selesai. Semakin banyak saya membaca tentang Newton Protocol, semakin saya menyadari bahwa asumsi itu bahkan tidak mendekati.
Yang menarik perhatian saya adalah bagaimana Newton Protocol memisahkan logika kebijakan Rego yang dapat digunakan kembali dari konfigurasi dinamis yang melekat pada PolicyClient. Alih-alih menulis ulang kode kebijakan untuk setiap kasus penggunaan, logika yang sama dapat dipakai ulang, sementara parameter seperti ambang batas (threshold), batas eksposur, dan allowlist yang disetujui diteruskan melalui data.params sebagai JSON datar (flat JSON).
Itu mengingatkan saya pada sesuatu yang sederhana dalam kehidupan nyata. Keluarga saya memakai aturan rumah yang sama untuk semua orang, tetapi sepupu saya yang lebih muda punya batas yang berbeda dibanding saya pada usia yang sama. Aturannya tidak berubah. Yang berubah adalah konfigurasi. Prinsipnya tetap konsisten, sementara batasannya menyesuaikan.
Newton mengikuti filosofi serupa, tetapi dengan jaminan yang jauh lebih kuat. Salah satu detail yang saya anggap sangat menarik adalah expireAfter. Ini mendefinisikan jendela blok eksekusi untuk sebuah attestasi, bukan kapan parameter itu sendiri kedaluwarsa. Jika terlalu singkat, eksekusi yang sah bisa gagal karena jendelanya tertutup terlalu cepat. Jika terlalu panjang, peluang untuk replay atau eksekusi yang tertunda meningkat. Tidak ada pilihan yang otomatis benar. Kontekslah yang menentukan.
Pilihan desain yang halus lainnya adalah bahwa memperbarui parameter melalui setPolicy(PolicyConfig) menghasilkan policyId yang baru. Konfigurasi sebelumnya langsung menjadi usang, menciptakan batas yang bersih antara status kebijakan lama dan baru—bukan secara diam-diam memutasi asumsi kepercayaan.
Pelajaran terbesar saya bukanlah fleksibilitas. Tetapi tanggung jawab. Rego mendefinisikan logika, tetapi orang-oranglah yang menentukan parameter, meninjaunya, dan pada akhirnya membentuk hasil.
Jadi, di mana seharusnya para reviewer menghabiskan perhatian paling besar: pada kode kebijakan yang dapat digunakan kembali, atau pada pengaturan yang tersembunyi di dalam data.params? Arsitektur ini membuat aturan bisa dipakai ulang dengan aman, atau memindahkan asumsi kepercayaan yang paling penting ke konfigurasi yang mungkin tidak diperiksa oleh banyak pengguna?
dulu saya mengira kebijakan protokol pada dasarnya adalah kumpulan aturan yang statis. Unggah sekali, audit sekali, selesai. Semakin banyak saya membaca tentang Newton Protocol, semakin saya menyadari bahwa asumsi itu bahkan tidak mendekati.
Yang menarik perhatian saya adalah bagaimana Newton Protocol memisahkan logika kebijakan Rego yang dapat digunakan kembali dari konfigurasi dinamis yang melekat pada PolicyClient. Alih-alih menulis ulang kode kebijakan untuk setiap kasus penggunaan, logika yang sama dapat dipakai ulang, sementara parameter seperti ambang batas (threshold), batas eksposur, dan allowlist yang disetujui diteruskan melalui data.params sebagai JSON datar (flat JSON).
Itu mengingatkan saya pada sesuatu yang sederhana dalam kehidupan nyata. Keluarga saya memakai aturan rumah yang sama untuk semua orang, tetapi sepupu saya yang lebih muda punya batas yang berbeda dibanding saya pada usia yang sama. Aturannya tidak berubah. Yang berubah adalah konfigurasi. Prinsipnya tetap konsisten, sementara batasannya menyesuaikan.
Newton mengikuti filosofi serupa, tetapi dengan jaminan yang jauh lebih kuat. Salah satu detail yang saya anggap sangat menarik adalah expireAfter. Ini mendefinisikan jendela blok eksekusi untuk sebuah attestasi, bukan kapan parameter itu sendiri kedaluwarsa. Jika terlalu singkat, eksekusi yang sah bisa gagal karena jendelanya tertutup terlalu cepat. Jika terlalu panjang, peluang untuk replay atau eksekusi yang tertunda meningkat. Tidak ada pilihan yang otomatis benar. Kontekslah yang menentukan.
Pilihan desain yang halus lainnya adalah bahwa memperbarui parameter melalui setPolicy(PolicyConfig) menghasilkan policyId yang baru. Konfigurasi sebelumnya langsung menjadi usang, menciptakan batas yang bersih antara status kebijakan lama dan baru—bukan secara diam-diam memutasi asumsi kepercayaan.
Pelajaran terbesar saya bukanlah fleksibilitas. Tetapi tanggung jawab. Rego mendefinisikan logika, tetapi orang-oranglah yang menentukan parameter, meninjaunya, dan pada akhirnya membentuk hasil.
Jadi, di mana seharusnya para reviewer menghabiskan perhatian paling besar: pada kode kebijakan yang dapat digunakan kembali, atau pada pengaturan yang tersembunyi di dalam data.params? Arsitektur ini membuat aturan bisa dipakai ulang dengan aman, atau memindahkan asumsi kepercayaan yang paling penting ke konfigurasi yang mungkin tidak diperiksa oleh banyak pengguna?