Ini adalah primer tentang eksekusi asinkron: bagaimana kami membuatnya bekerja di Monad, mengapa EIP-7702 merusaknya, dan bagaimana memperbaikinya Untuk konteks, eksekusi asinkron telah ada di Monad sejak klien konsensus dan eksekusi terhubung satu sama lain. Eksekusi asinkron memungkinkan eksekusi untuk tertinggal konsensus dengan jumlah blok tetap dari perspektif interaksi. Sebagian besar blockchain memiliki konsensus yang diselingi. Artinya, eksekusi terjadi sebelum konsensus, yang berarti menjejalkan eksekusi ke dalam anggaran waktu yang merupakan sebagian kecil dari waktu blok (sisanya ditempati oleh pesan keliling dunia, alias konsensus). Ini secara inheren membatasi gas per detik sistem. L2 menyiasati ini dengan tidak memiliki konsensus sama sekali. Tetapi kami menginginkan perilaku L1 terdistribusi dan terdesentralisasi yang mempertahankan kinerja tinggi. Eksekusi asinkron memungkinkan kita menghindari masalah ini dengan memindahkan eksekusi keluar dari jalur konsensus yang panas. Sebaliknya, konsensus dan eksekusi terjadi di jalur renang paralel. Konsensus pada blok 2 terjadi saat eksekusi blok 1 berjalan secara paralel. Masih perlu ada kesepakatan antara konsensus dan eksekusi. Secara khusus, kesepakatan itu adalah: eksekusi hanya diperbolehkan untuk tertinggal konsensus hingga k blok, karena proposal blok berisi akar merkle yang tertunda. Juga, konsensus adalah blok bangunan dengan tampilan status yang tertunda (tertunda oleh k blok). Ini berarti bahwa ada bahaya bahwa konsensus akan mencakup transaksi dari pengirim yang, pada saat kita mengeksekusi, ternyata memiliki saldo kosong. Akan buruk jika protokol mengizinkan ini terjadi, karena akan membuka vektor Denial-of-Service (DOS). Oleh karena itu, untuk mengatasi masalah ini dan mengaktifkan eksekusi asinkron dengan aman, klien konsensus Monad menghitung debit MON maksimum dari setiap transaksi sebagai MON_spent = gas_bid * gas_limit + nilai. Klien konsensus menyimpan daftar saldo akun yang tersedia untuk setiap pengirim setelah dikurangi MON_spent untuk setiap transaksi yang mereka kirim. Keluar dari saldo berjalan itu, klien konsensus hanya menyertakan transaksi jika dapat dipastikan bahwa transaksi dapat dibayar. Ini adalah pendekatan pesimis untuk membangun blok karena tidak memperhitungkan kemungkinan akun apa pun yang mendapatkan saldo dari transfer masuk. Izinkan saya menjelaskan apa yang saya maksud dengan sebuah contoh. Misalkan akun Alice memiliki 100 MON. Kemudian, 3 transaksi berikut termasuk dalam blok 1000: Tx 1: Alice mengirim 20 MON ke Bob, dengan biaya 1 JUTA Tx 2: Alice menghabiskan 70 JUTA untuk membeli memecoin, dengan biaya 1 JUTA dalam biaya...