Pengeksplorasi Dusk larut suatu malam menemukan dua panggilan kontrak yang tampak secara fungsional identik di permukaan menghasilkan jejak gas yang cukup berbeda. Dugaan pertamaku adalah bahwa salah satunya hanya memiliki logika yang lebih kompleks. Ternyata itu keliru.
Setelah menyelidik lebih jauh, kutemukan perbedaannya berasal dari cara masing-masing kontrak menangani langkah verifikasi kriptografisnya. Salah satu jalur memicu fungsi host, kode native yang dijalankan langsung oleh runtime di luar sandbox WASM, sedangkan jalur lainnya menjalankan rutinitas verifikasi yang dikompilasi ke dalam WASM itu sendiri. Dusk membatasi fungsi host untuk operasi tertentu seperti hashing dan verifikasi bukti, dan celah gas itu sebenarnya merupakan celah visibilitas yang mengungkap pemisahan tersebut.
Ini mengubah cara pandang sesuatu yang selama ini kupahami sebagai satu kategori: "komputasi on-chain." Aku selama ini mengelompokkan eksekusi tersandbox dan eksekusi native seolah biaya dan perilakunya akan meningkat dengan cara yang sama untuk keduanya. Ternyata tidak. Panggilan native menghindari overhead interpretasi WASM, yang berarti pilihan desain kontrak di hulu diam-diam menentukan jalur eksekusi mana yang akan diambil transaksi di hilir.
Yang masih tidak jelas bagiku adalah bagaimana Dusk memutuskan protokol kriptografis apa yang kelak naik status menjadi fungsi host, dibandingkan tetap berada di dalam WASM. Apakah ada ambang batas performa yang telah ditetapkan, atau dinilai satu per satu setiap kali skema verifikasi baru ditambahkan? Ketidakjelasan itu jadi semakin penting seiring daftar primitive bertambah.
Ke depan, aku akan mengamati seberapa konsisten biaya gas mengelompok untuk kontrak-kontrak yang secara logis mirip, dan apakah alat bantu pengembang mulai menampilkan pemisahan eksekusi ini sebelum deployment, bukan setelahnya. Pola berulang di sana akan memberitahuku apakah ini merupakan tepi desain yang stabil atau sesuatu yang harus dipelajari para penulis kontrak dengan cara yang sulit.
Aku masih belum tahu apakah pemisahan ini memang dimaksudkan untuk tetap sempit secara desain atau justru akan melebar seiring protokol semakin matang, dan aku juga belum yakin hasil mana yang sebenarnya akan lebih sehat bagi para pembangun di jaringan.
@Dusk #Dusk
$ACE
$DUSK
$BOME
Setelah menyelidik lebih jauh, kutemukan perbedaannya berasal dari cara masing-masing kontrak menangani langkah verifikasi kriptografisnya. Salah satu jalur memicu fungsi host, kode native yang dijalankan langsung oleh runtime di luar sandbox WASM, sedangkan jalur lainnya menjalankan rutinitas verifikasi yang dikompilasi ke dalam WASM itu sendiri. Dusk membatasi fungsi host untuk operasi tertentu seperti hashing dan verifikasi bukti, dan celah gas itu sebenarnya merupakan celah visibilitas yang mengungkap pemisahan tersebut.
Ini mengubah cara pandang sesuatu yang selama ini kupahami sebagai satu kategori: "komputasi on-chain." Aku selama ini mengelompokkan eksekusi tersandbox dan eksekusi native seolah biaya dan perilakunya akan meningkat dengan cara yang sama untuk keduanya. Ternyata tidak. Panggilan native menghindari overhead interpretasi WASM, yang berarti pilihan desain kontrak di hulu diam-diam menentukan jalur eksekusi mana yang akan diambil transaksi di hilir.
Yang masih tidak jelas bagiku adalah bagaimana Dusk memutuskan protokol kriptografis apa yang kelak naik status menjadi fungsi host, dibandingkan tetap berada di dalam WASM. Apakah ada ambang batas performa yang telah ditetapkan, atau dinilai satu per satu setiap kali skema verifikasi baru ditambahkan? Ketidakjelasan itu jadi semakin penting seiring daftar primitive bertambah.
Ke depan, aku akan mengamati seberapa konsisten biaya gas mengelompok untuk kontrak-kontrak yang secara logis mirip, dan apakah alat bantu pengembang mulai menampilkan pemisahan eksekusi ini sebelum deployment, bukan setelahnya. Pola berulang di sana akan memberitahuku apakah ini merupakan tepi desain yang stabil atau sesuatu yang harus dipelajari para penulis kontrak dengan cara yang sulit.
Aku masih belum tahu apakah pemisahan ini memang dimaksudkan untuk tetap sempit secara desain atau justru akan melebar seiring protokol semakin matang, dan aku juga belum yakin hasil mana yang sebenarnya akan lebih sehat bagi para pembangun di jaringan.
@Dusk #Dusk
$ACE
$DUSK
$BOME
