Pasar benar-benar tidak melakukan apa-apa lagi, jadi akhirnya saya mengklik dokumentasi pengembang Newton daripada menonton pergerakan candle lain yang naik setengah persen lalu berbalik.
Saya tidak mencari apa pun yang spesifik. Saya hanya terus melihat janji yang sama di situs Newton: transaksi dicek sebelum penyelesaian, tetapi katanya dengan "tanpa perubahan UX". Kebijakan itu berjalan di latar belakang; tindakan yang patuh diteruskan, dan pengguna melanjutkan aktivitas seolah lapisan keamanan tambahan itu tidak pernah ada.
Bersihkan pitch.
Tapi kemudian saya membuka alur integrasi frontend, dan… kata "tidak" mulai bekerja lebih banyak daripada yang saya kira.
Karena transaksi yang dilindungi Newton tidak sekadar berpindah dari konfirmasi dompet ke eksekusi blockchain. Aplikasi pertama-tama membangun sebuah intent yang mendeskripsikan apa yang ingin dilakukan pengguna. Pengguna menandatangani intent tersebut menggunakan EIP-712. Aplikasi mengirimkannya untuk evaluasi kebijakan. Operator Newton mengevaluasi permintaan dan menghasilkan sebuah attestation. Hanya setelah kebijakan menyetujuinya, aplikasi mengirim transaksi onchain yang sebenarnya bersama data tugas, respons operator, dan tanda tangan BLS.
Itu bukan satu tindakan.
Itu adalah urutan otorisasi yang dirancang agar terasa seperti satu kesatuan.
Inilah yang membuat saya langsung terpaku.
Saat pertama kali saya membaca “tanpa perubahan UX,” saya mengira Newton menambahkan langkah verifikasi yang berperilaku hampir seperti pengecekan kontrak biasa—sesuatu yang deterministik, langsung, dan tidak terlihat setelah diintegrasikan.
Namun, lapisan otorisasi Newton bergantung pada jaringan operator di luar rantai yang menyelesaikan pekerjaannya sebelum transaksi yang dilindungi bisa dieksekusi. Metode RPC sinkron menunggu agregasi BLS, dengan timeout default terdokumentasi selama 30 detik. Contoh frontend menggunakan timeout 60 detik. Tugas dapat berpindah dari status pending, processing, success, failed, atau timeout.
Kebanyakan transaksi kemungkinan tidak akan bertahan di sana selama 30 atau 60 detik.
Itu bukan intinya.
Intinya adalah: aplikasi harus dirancang untuk kemungkinan bahwa semuanya bisa terjadi seperti itu.
Bagian penelusuran masalah milik Newton sendiri memberi tahu pengembang untuk menangani situasi ketika jaringan operator lambat atau tidak tersedia dengan meningkatkan timeout atau mencoba ulang. Dokumentasi RPC-nya mencakup langganan WebSocket dan callback webhook sehingga aplikasi dapat menampilkan pembaruan tugas dan merespons kegagalan seperti timeout, kuorum yang tidak mencukupi, kegagalan pengiriman onchain, kesalahan evaluasi kebijakan, atau masalah verifikasi tanda tangan.
Jadi lapisan otorisasi bisa saja tidak terlihat oleh pengguna saat semuanya berjalan.
Tapi membuatnya tetap tidak terlihat adalah pekerjaan pengembang.
Tetap ada yang harus merancang status pemuatan. Tetap ada yang harus memutuskan apa yang dikatakan antarmuka saat operator sedang mengevaluasi permintaan. Tetap ada yang harus membedakan “transaksi Anda ditolak oleh kebijakan” dari “jaringan otorisasi tidak menjawab.” Tetap ada yang harus mencegah pengguna mengklik lagi secara tidak sengaja sehingga membuat permintaan kedua karena permintaan pertama terlihat seperti macet.
Kesenjangan itulah yang penting.
Newton tidak menghilangkan gesekan. Newton meminta aplikasi untuk menanggungnya.
Dan terus terang, itu mungkin benar-benar masuk akal. Pemeriksaan kepatuhan atau risiko yang terjadi sebelum modal bergerak kemungkinan bernilai lebih daripada memangkas satu detik dari antarmuka. Untuk brankas institusional, penerbit stablecoin, atau dompet agen otonom, jeda otorisasi singkat kemungkinan lebih disukai daripada baru mengetahui setelah eksekusi bahwa transaksi melanggar kebijakan.
Keamanan biasanya ada biayanya.
Arsitektur Newton hanya mencoba memastikan bahwa pengguna akhir tidak yang memikirkan biaya.
Pilihan validasi onchain pun tetap membawa trade-off. Newton mendokumentasikan rute standar yang menunggu agregator mengirimkan respons secara onchain dan rute langsung yang memverifikasi bukti BLS segera di dalam transaksi. Rute standar diperkirakan sekitar 50.000–100.000 gas, sedangkan validasi langsung diperkirakan sekitar 200.000–500.000 gas. Jalur yang lebih cepat menghindari menunggu agregator, tetapi memindahkan biaya verifikasi lebih besar ke saat eksekusi.
Itu terasa lebih jujur daripada slogan.
Anda bisa mengurangi waktu tunggu yang terlihat, tetapi Anda mungkin membayar lebih banyak gas.
Anda bisa mengurangi gas, tetapi Anda mungkin lebih bergantung pada agregator untuk menyelesaikan bagiannya terlebih dahulu.
Anda bisa menyembunyikan seluruh rangkaian di balik tombol yang rapi, tetapi aplikasinya tetap harus mengelola tanda tangan, respons operator, keputusan kebijakan, percobaan ulang, kedaluwarsa, dan eksekusi transaksi di balik layar.
Tidak ada yang berarti desainnya buruk. Sebenarnya, pemisahan itu mungkin adalah keseluruhan produknya: otorisasi menjadi fase tersendiri, bukan dicampur ke dalam transaksi setelah sesuatu sudah berjalan salah.
Tapi klaim “tidak ada perubahan UX” dan “tidak ada kompleksitas UX tambahan” itu tidak sama.
Yang pertama mungkin bisa dicapai.
Yang kedua jelas bukan begitu.
Saya pikir uji nyata untuk Newton bukan apakah transaksi demo terasa normal saat jaringan sehat. Melainkan apa yang dialami pengguna ketika sebuah oracle lambat, kuorum untuk sementara tidak tersedia, attestation kedaluwarsa, atau sebuah permintaan ditolak karena alasan yang harus dijelaskan antarmuka dengan bahasa yang sederhana.
Itulah saat infrastruktur yang tak terlihat menjadi terlihat.
Dan mungkin cara yang lebih baik untuk menilai lapisan otorisasi—bagaimanapun juga—bukan dari seberapa sedikit pengguna memperhatikan ketika semuanya berjalan, melainkan dari seberapa jelas aplikasi berperilaku ketika otorisasi gagal.
Apakah Newton mempertahankan pengalaman transaksi yang familiar di bawah beban nyata, atau langkah keamanan tambahan itu akhirnya menjadi satu lagi penundaan yang harus dipahami pengguna?