Dokumentasi resmi ditulis dengan jelas. Di dalam struktur Attestation terdapat sebuah field bernama policyClient. Tipe datanya adalah address. Di struktur Task terdapat sebuah field bernama Policy Client Address. Catatan menyebutkan bahwa ini adalah alamat kontrak cerdas yang dilindungi oleh kebijakan. Pada contoh kode SDK, field to pada intent menunjuk ke kontrak PolicyClient. Kontrak Shield sebelum dieksekusi akan memverifikasi apakah alamat client ini cocok. Jika verifikasinya gagal, permintaan akan ditolak untuk diteruskan.
Berdasarkan alur verifikasi Shield, jika alamat Policy Client tidak sama dengan yang tercatat di Attestation, verifikasi tidak akan dapat berhasil. Ini berarti cakupan penerapan Attestation dibatasi pada konteks kontrak tertentu.
Awalnya saya merasa ini over-engineering. Kenapa perlu menambah lapisan binding ini. Bukankah cukup memverifikasi tanda tangan pengguna langsung saja.
Namun, logika kode Shield dalam dokumentasi membuat saya paham alasannya. Setelah Attestation diikat ke policyClient, setiap kali dieksekusi Shield perlu memverifikasi ulang taskId, policyId, client address, intent signature, chain, expiration, dan replay status. Hanya jika semuanya cocok barulah diteruskan. Saya mengerti bahwa binding seperti ini dapat mengurangi kemungkinan Attestation digunakan untuk Policy Client lainnya.
Dari sisi arsitektur, desain seperti ini juga membantu membatasi cakupan penggunaan Attestation. Jika sebuah Attestation bisa digunakan pada kontrak mana pun, maka batas otorisasi akan jadi semakin luas. @undefined Memilih untuk memperinci cakupan otorisasi ke level kontrak, bukan hanya berhenti pada level tanda tangan pengguna.
Biayanya juga jelas. Setiap kontrak perlu didaftarkan secara terpisah sebagai Policy Client. PolicyClientRegistry yang disebut dalam dokumentasi adalah untuk melakukan itu. Kontrak harus didaftarkan dulu di registry ini. Baru kemudian bisa terhubung ke alur otorisasi Newton. Ini menjadi friction bagi pengembang. Binding Policy Client juga berarti proses integrasi akan menjadi lebih kompleks.
Tapi jelas Newton menganggap friction ini sepadan. Karena jika tidak ada lapisan binding ini, batas otorisasi Attestation akan menjadi jauh lebih luas. Tanda tangan BLS seindah apa pun. Jaringan operator makin terdesentralisasi. Selama Attestation dapat digunakan lintas kontrak secara bebas, asumsi keamanan akan melemah.
Saya masih punya satu pertanyaan. Binding Policy Client menyelesaikan masalah cakupan otorisasi di level kontrak. Tapi bagaimana jika kontrak Policy Client itu sendiri memiliki celah atau di-upgrade. Dokumentasi mengatakan pembaruan PolicyConfig tidak memengaruhi Attestation lama. Lalu bagaimana jika alamat Policy Client berubah? Saat ini saya belum melihat penjelasan detail untuk hal ini di dokumentasi resmi.
Selain itu, binding Policy Client membuat model otorisasi Newton membutuhkan lebih banyak langkah. Setiap dApp, setiap modul fungsi, dan setiap aksi pengguna memerlukan siklus hidup Attestation yang terpisah. Ini menjadi beban untuk skenario operasi frekuensi tinggi.
Newton memilih untuk memperinci tingkat granularity otorisasi ke level kontrak. Ini adalah keputusan desain yang mengutamakan keamanan. Tapi keputusan ini juga membuat integrasi Newton jauh lebih rumit dibanding verifikasi tanda tangan tradisional.
Contoh VaultKit dalam dokumentasi sangat menjelaskan. Setiap operasi vault yang dilindungi berubah menjadi Intent. Setiap Intent dinilai oleh operator. Setiap approved action diikat ke Attestation. Lalu barulah Shield meneruskan. Struktur tiga lapis. Tiga titik verifikasi. Semuanya berpusat pada Policy Client.
Mengapa Newton lebih memilih menambah lapisan binding kontrak ini daripada membiarkan otorisasi hanya berhenti pada level tanda tangan pengguna.
