Kalimat yang mengubah Midnight bagi saya sangat jelas: sebuah transaksi dapat gagal di fase yang bisa gagal dan tetap meninggalkan efek yang dijamin.
Setelah saya membaca itu, saya tidak bisa kembali ke model mental kripto yang normal. Dokumen Midnight mengatakan transaksi menjalani pemeriksaan kelayakan yang baik, kemudian fase yang dijamin, kemudian fase yang bisa gagal. Jika kegagalan terjadi di fase yang dijamin, transaksi tidak termasuk. Tetapi jika kegagalan terjadi kemudian, efek yang dijamin tetap berlaku dan buku besar mencatat keberhasilan parsial. Dokumen tersebut juga mengatakan bahwa biaya untuk semua fase dikumpulkan di fase yang dijamin dan akan hangus jika fase yang bisa gagal gagal. Itu berarti kegagalan di Midnight tidak selalu bisa diulang. Terkadang itu adalah sisa.
Itu adalah fakta produk yang jauh lebih besar daripada yang terdengar pada awalnya.
Banyak orang masih berpikir tentang kegagalan transaksi dalam istilah yang sederhana. Itu berhasil, atau gagal dan tidak ada yang benar-benar terjadi. Midnight melemahkan jalan pintas itu. Semantiknya terstaging. Beberapa bagian dari tindakan dapat menjadi nyata sebelum bagian-bagian selanjutnya diizinkan untuk gagal. Dokumen jelas bahwa eksekusi fase dapat mencakup hal-hal seperti menyisipkan komitmen, menyisipkan nullifier, memeriksa akar masa lalu, dan memperbarui set akar masa lalu. Jadi pada saat kondisi yang bisa gagal rusak, transaksi mungkin sudah mengubah status buku besar dengan cara yang tidak bisa dipura-pura oleh aplikasi.
Biaya sudah hilang juga.
Kombinasi itu adalah apa yang membuat model ini serius. Kegagalan terlambat bukan hanya pesan kesalahan. Itu bisa menjadi rencana yang gagal yang duduk di atas prefiks yang berhasil.
Cara paling bersih untuk melihat masalahnya adalah dengan alur akses pribadi. Bayangkan sebuah aplikasi Midnight di mana seorang pengguna mencoba untuk menjalankan beberapa izin pribadi. Aplikasi ingin tindakan itu terasa sederhana. Pengguna menekan sekali dan mengharapkan satu jawaban yang bersih. Di balik layar, meskipun, transaksi mungkin melewati bentuk yang baik, masuk ke fase terjamin, mengumpulkan biaya, dan menerapkan efek yang menjadi miliknya. Kemudian kondisi yang bisa gagal di kemudian hari gagal. Mungkin beberapa aturan bisnis tidak terpenuhi. Mungkin cabang selanjutnya tidak dapat diselesaikan. Dari sudut pandang pengguna, tindakan itu gagal. Dari sudut pandang Midnight, kegagalan tiba setelah buku besar sudah bergerak.
Itu bukan kasus tepi semantik yang kecil. Itu adalah perilaku produk.
Dan Midnight tidak memperlakukan pemisahan itu sebagai kebetulan. Dokumen mengatakan bahwa jika panggilan kontrak mengandung bagian yang terjamin dan bagian yang bisa gagal, bagian yang bisa gagal harus dimulai dengan ckpt. Saya suka detail itu karena membuat arsitektur jujur. Garis antara "ini harus bertahan" dan "ini mungkin masih abort" adalah eksplisit. Para pembangun tidak hanya memutuskan apa yang dilakukan logika pribadi mereka. Mereka memutuskan apa yang diizinkan sistem untuk disimpan jika niat penuh tidak pernah tiba.
Itu adalah tempat tekanan desain dimulai.
Seorang pembangun dapat melihat kontrak Midnight, melihat bahwa buktinya benar, dan tetap melewatkan pertanyaan yang lebih sulit. Jika tindakan ini gagal terlambat, apa yang sudah menjadi kenyataan. Jika jawabannya adalah "beberapa komitmen, beberapa nullifier, biaya, dan catatan keberhasilan parsial," maka aplikasi tidak dapat membicarakan kegagalan dengan cara yang sama seperti sistem rollback normal. Logika coba lagi berubah. Pesan pengguna berubah. Dukungan berubah. Status kesalahan merah tidak lagi dapat berarti "tidak ada yang terjadi."
Itu adalah pertukaran yang nyata. Midnight mendapatkan model transaksi yang lebih ekspresif. Pekerjaan yang terjamin dapat dipisahkan dari pekerjaan yang bisa gagal di kemudian hari. Itu berguna. Ini memberi para pembangun lebih banyak kontrol atas struktur eksekusi. Tetapi harganya adalah aplikasi harus merancang seputar keberhasilan parsial sebagai keadaan kelas satu. Bukan bug. Bukan kecelakaan implementasi. Sebuah keadaan.
Jika mereka tidak, produk mulai berbohong.
Pengguna melihat "gagal." Buku besar mengatakan "sebagian selesai." Biaya hilang dalam kedua cara. Celah itu adalah tempat kebingungan dimulai. Sebuah tim dapat dengan mudah salah membaca itu juga. Mereka dapat memperlakukan masalah itu seperti kegagalan waktu jalan normal, ketika masalah yang sebenarnya adalah bahwa model transaksi mengizinkan beberapa efek untuk bertahan berdasarkan desain. Midnight tidak menyembunyikan itu dari mereka. Dokumen memberi tahu mereka. Kesalahan adalah berpura-pura bahwa pengalaman pengguna dapat tetap semua-atau-tidak ada setelah semantik berhenti menjadi semua-atau-tidak ada.
Itu sebabnya saya pikir model eksekusi Midnight layak mendapatkan lebih banyak perhatian daripada yang didapatnya. Orang-orang akan berbicara tentang privasi, pengungkapan selektif, dan apa yang dapat tetap tersembunyi. Baiklah. Tapi produk yang serius tidak hanya didefinisikan oleh apa yang bisa disembunyikannya. Itu juga didefinisikan oleh apa yang dimaksudkan dengan kegagalan. Midnight mengubah makna itu dengan cara yang sangat tepat. Tindakan pribadi yang gagal mungkin masih memiliki setengah depan yang tidak dapat diubah.
Jadi standar ulasan yang sebenarnya tidak bisa berhenti di "apakah bukti memverifikasi." Itu juga harus bertanya: efek mana yang ditempatkan di fase terjamin, apa yang bertahan dari kegagalan terlambat, dan apakah aplikasi menjelaskan itu dengan jujur kepada pengguna. Pada Midnight, itu bukan detail UX sekunder. Mereka adalah bagian dari semantik.
Aplikasi Midnight yang terkuat akan menjadi yang memperlakukan keberhasilan parsial seperti keadaan produk yang nyata sejak hari pertama. Yang lebih lemah akan terus menyebutnya kegagalan dan berharap tidak ada yang menyadari buku besar sudah bergerak.
\u003cm-39/\u003e\u003cc-40/\u003e\u003ct-41/\u003e
