Rincian transaksi Senja yang terus membuatku mentok adalah bahwa eksekusi kontrak bisa dibatalkan tanpa membuat transaksi itu sendiri menghilang.
Insting pertamaku adalah menyatukan semuanya jadi satu hasil.
panggilan berhasil = transaksi terjadi.
panggilan dibatalkan = transaksi tidak.
Moonlight tidak bekerja sesederhana itu.
sebelum penerimaan, jaringan memeriksa bahwa pengirim bisa menanggung nilai, setoran kontrak, dan gas maksimum: gas_limit × gas_price.
jaringan memverifikasi tanda tangan, lalu memastikan nonce adalah satu angka di atas nonce saat ini pada akun.
masuk akal.
bagian menariknya muncul setelah eksekusi.
dokumen whitepaper mengatakan bahwa jika eksekusi smart contract dibatalkan, jumlah yang sesuai dikembalikan. gas yang tidak terpakai juga dikembalikan.
tapi nonce tetap bertambah saat penerimaan.
jadi “kontrak membatalkan perubahan state” dan “jaringan menghabiskan percobaan transaksi ini” bukan state yang sama.
pembatalan bisa mengurungkan efek sisi kontrak sementara mekanisme pengurutan di sisi akun tetap maju.
gas membuat batas lain.
pengguna harus menanggung gas maksimum sebelum eksekusi, meskipun pada akhirnya mereka bisa membayar lebih sedikit karena gas yang tidak terpakai akan kembali.
jadi ada tiga jumlah yang perlu diperhatikan:
yang harus bisa kamu tanggung,
yang dikonsumsi oleh eksekusi,
dan yang dikembalikan setelahnya.
mudah keliru kalau gas_limit terbaca seperti biaya, bukan batas pengeluaran.
sekarang bayangkan sebuah aplikasi menyiapkan beberapa transaksi Moonlight secara berurutan.
transaksi N memanggil sebuah kontrak dan dibatalkan.
efek kontraknya hilang.
tapi jika N diterima, nonce pengirim sudah bergeser.
transaksi N+1 tidak bisa menalar dari “panggilan sebelumnya gagal” seolah-olah tidak terjadi apa-apa.
kegagalan telah mengubah sesuatu di luar kontrak.
itulah perbedaannya yang aku suka:
rollback eksekusi bersifat lokal.
sejarah transaksi tidak.
dan ini mengubah pertanyaan integrasinya.
ketika sebuah aplikasi memberi tahu pengguna “transaksi ini gagal,” apa sebenarnya yang gagal?
perubahan state yang dimaksudkan?
atau transaksi itu sendiri?
di Dusk, dua jawaban itu bisa berbeda.
@Dusk #Dusk $DUSK $GPS $TUT
Insting pertamaku adalah menyatukan semuanya jadi satu hasil.
panggilan berhasil = transaksi terjadi.
panggilan dibatalkan = transaksi tidak.
Moonlight tidak bekerja sesederhana itu.
sebelum penerimaan, jaringan memeriksa bahwa pengirim bisa menanggung nilai, setoran kontrak, dan gas maksimum: gas_limit × gas_price.
jaringan memverifikasi tanda tangan, lalu memastikan nonce adalah satu angka di atas nonce saat ini pada akun.
masuk akal.
bagian menariknya muncul setelah eksekusi.
dokumen whitepaper mengatakan bahwa jika eksekusi smart contract dibatalkan, jumlah yang sesuai dikembalikan. gas yang tidak terpakai juga dikembalikan.
tapi nonce tetap bertambah saat penerimaan.
jadi “kontrak membatalkan perubahan state” dan “jaringan menghabiskan percobaan transaksi ini” bukan state yang sama.
pembatalan bisa mengurungkan efek sisi kontrak sementara mekanisme pengurutan di sisi akun tetap maju.
gas membuat batas lain.
pengguna harus menanggung gas maksimum sebelum eksekusi, meskipun pada akhirnya mereka bisa membayar lebih sedikit karena gas yang tidak terpakai akan kembali.
jadi ada tiga jumlah yang perlu diperhatikan:
yang harus bisa kamu tanggung,
yang dikonsumsi oleh eksekusi,
dan yang dikembalikan setelahnya.
mudah keliru kalau gas_limit terbaca seperti biaya, bukan batas pengeluaran.
sekarang bayangkan sebuah aplikasi menyiapkan beberapa transaksi Moonlight secara berurutan.
transaksi N memanggil sebuah kontrak dan dibatalkan.
efek kontraknya hilang.
tapi jika N diterima, nonce pengirim sudah bergeser.
transaksi N+1 tidak bisa menalar dari “panggilan sebelumnya gagal” seolah-olah tidak terjadi apa-apa.
kegagalan telah mengubah sesuatu di luar kontrak.
itulah perbedaannya yang aku suka:
rollback eksekusi bersifat lokal.
sejarah transaksi tidak.
dan ini mengubah pertanyaan integrasinya.
ketika sebuah aplikasi memberi tahu pengguna “transaksi ini gagal,” apa sebenarnya yang gagal?
perubahan state yang dimaksudkan?
atau transaksi itu sendiri?
di Dusk, dua jawaban itu bisa berbeda.
@Dusk #Dusk $DUSK $GPS $TUT