senja memiliki dua lingkungan kontrak, tetapi bagian yang menarik bukanlah itu ada dua.

duskvm berjalan langsung di l1, eksekusi kontrak dan penyelesaian (settlement) dusk terjadi di tempat yang sama. duskevm

terlihat terpisah di permukaan: solidity, wallet evm, rpc-nya sendiri, tetapi transaksi duskevm sebenarnya melewati empat tahap sebelum benar-benar diselesaikan. ia pertama kali menuju sequencer, lalu dimasukkan ke dalam blok l2, lalu.

batcher mempublikasikan data transaksi itu ke duskds, dan hanya setelah itu komitmen state dan fault proof menghubungkan state hasilnya kembali ke settlement duskds.

mudah terlewat bahwa inklusi dan settlement adalah.

secara eksplisit dua tahap yang berbeda di sini, bukan satu. sebuah transaksi bisa muncul dengan cepat di blok l2, sementara langkah settlement yang sebenarnya masih tertinggal di belakangnya.

pembedaan itu jauh lebih penting daripada yang terdengar.

dokumentasinya secara khusus memperingatkan untuk tidak menyimpulkan finalitas dari waktu yang berlalu dan mengatakan aplikasi yang memindahkan nilai antara duskevm dan l1 harus memeriksa status protokol atau status wallet. saya tidak menyangka ada celah antara inklusi dan.

setlement yang disebutkan secara langsung seperti ini—rasanya ini adalah tempat yang persis di mana bug akan bersembunyi jika sebuah tim menganggap transaksi cepat sudah final.

kalau Anda membangun di duskevm, apakah Anda akan memeriksa status settlement sebelum atau sesudah menampilkan layar sukses kepada pengguna??

#dusk @Dusk $DUSK