Prasasti mania ditransmisikan ke Lapisan 2, mengapa zkSync dapat lulus uji stres perdagangan setinggi langit?

** Ditulis oleh: Haotian **

Prasasti yang terukir pada rantai zkSync dan masuknya transaksi setinggi langit dalam jangka pendek memang merupakan “uji stres” kinerja rantai publik layer2, tetapi hasilnya bukan “downtime”, sebaliknya, ini adalah pelatihan publik zkSync, dan hasilnya adalah puncak TPS dan stabilitas GAS telah diuji dengan sempurna.

Pada pandangan pertama, bukankah itu terdengar agak berlawanan dengan intuisi? Selanjutnya, dengan logika teknis, izinkan saya menjelaskannya untuk Anda:

Prinsip kerja blok pengemasan zkSync sederhananya: pengguna membangun transaksi ke dalam urutan penyortiran zkSync Sequencer, dan kemudian Sequencer mengemasnya ke dalam blok sesuai dengan peringkat biaya gas, dan kemudian meneruskan blok ke sistem Bukti untuk verifikasi, dan akhirnya mengirimkannya ke mainnet untuk menyelesaikan konfirmasi status finalitas.

Ada 2 poin penting di sini yang dapat dengan mudah menciptakan ilusi “pengalaman buruk”:

1. Pengguna membangun transaksi: Sebagian besar pengguna akan memulai transaksi melalui dompet seperti Metamask, dan mengirim transaksi ke zkSync melalui dompet, dan transaksi pertama-tama akan memasuki server panggilan jarak jauh RPC, dan kemudian Sequencer akan menerima transaksi ini dan memasuki urutan antrian. Waktu antrian di sini bisa sesingkat beberapa detik atau selama beberapa menit, dan jika Anda menunggu lama, MetaMask akan menganggap bahwa transaksi telah gagal, dan kemudian front-end akan mengembalikan pesan bahwa transaksi telah gagal.

Namun, ini tidak berarti bahwa transaksi benar-benar gagal, tetapi hanya karena ada “ketidakcocokan” antara waktu respons RPC Metamask dan logika umpan balik dan logika transaksi antrian dan pengemasan Sequencer zkSync. Itu sebabnya, setelah menunggu beberapa saat, server backend menunjukkan bahwa beberapa transaksi yang ditunjukkan MetaMask gagal.

Jika pengguna tidak melalui saluran dompet dan langsung menggunakan kode backend untuk memanggil RPC zkSync, tidak akan ada batas waktu waktu respons dan kegagalan cepat, dan pengalaman akan relatif lancar. Ini memang memberikan keuntungan bagi beberapa “ilmuwan” yang dapat menggunakan instruksi kode backend, tetapi pada dasarnya ini adalah masalah di sisi pengalaman dompet dan tidak ada hubungannya dengan kekuatan pemrosesan rantai zkSync.

2. Sequencer fair ordering link: ketika pengguna mengirim transaksi ke antrian RPC untuk waktu yang singkat, setiap transaksi akan ditumpangkan dari nilai nonce 0, jika transaksi sebelumnya masih dalam keadaan antrian, nonce adalah 0, maka pengguna memulai transaksi baru dengan nonce 1, Sequencer zkSync akan menetapkan nonce untuk transaksi ini sesuai dengan waktu, dan kemudian mengurutkannya secara berurutan.

Namun, jika pengguna mengirimkan transaksi baru pada saat yang sama setelah melihat bahwa transaksi sebelumnya gagal di bagian MetaMask sebelumnya, kemungkinan beberapa transaksi yang baru dikirimkan tidak akan berhasil dikirimkan ke antrian RPC karena masalah sisi dompet dan panggilan antarmuka API zkSync. Pengguna berpikir bahwa banyak transaksi telah dikirimkan, tetapi sebenarnya zkSync hanya menerima beberapa di antaranya, dan segera setelah mereka menerimanya, mereka akan menyortirnya.

Melihatnya dengan cara ini, pengguna melihat bahwa MetaMask melaporkan bahwa transaksi telah gagal, dan perilaku terus-menerus mengirimkan transaksi baru juga akan menyebabkan sejumlah besar kegagalan transaksi, karena tidak ada pengiriman ke backend rantai zkSync sama sekali, tetapi Anda pikir Anda telah mengirimkannya di frontend.

Secara keseluruhan, logika waktu respons RPC dari dompet MetaMask dan terburu-buru pengguna untuk melapisi transaksi pada rantai akan menyebabkan sejumlah besar “kegagalan” transaksi, dan relatif mudah untuk menghindari masalah pengalaman pengoptimalan ini jika Anda jelas tentang alur kerja pemrosesan transaksi latar belakang zkSync.

Berdasarkan ilmu pengetahuan populer di atas, mari kita perjelas masalah “downtime”:

Rantai zkSync tidak “turun”, itu hanya masalah tampilan di front-end browser, karena browser akan menarik data terbaru melalui antarmuka RPC zkSync, tetapi akan ada penundaan dalam respons antarmuka, dan sejumlah besar transaksi baru akan memperlambat respons.

Singkatnya, kecepatan sinkronisasi data tarik browser tidak dapat mengimbangi kecepatan proliferasi transaksi antrian, yang merupakan masalah dengan front-end browser dan tidak ada hubungannya dengan pengoperasian rantai. Biasanya, masalah akan terpecahkan ketika kecepatan transaksi melambat dengan tepat dan browser dapat menangkap data baru.

Ketika browser tidak berfungsi, Anda dapat menggunakan browser lain yang menyinkronkan informasi data blok zkSync untuk memverifikasi silang, seperti:

Apa “kinerja operasional” dari rantai nyata?

1. Setelah apa yang disebut rumor pemadaman pecah, Anthony Rose, anggota staf resmi zkSync, sering men-tweet laporan penyegaran TPS. Faktanya, TPS zkSync telah melonjak ke puncak 187,9, dan dalam keadaan normal, TPS hanya sekitar 50-100, yang menunjukkan bahwa ada gelombang besar transaksi baru, dan zkSync sebenarnya telah menahan tekanan. Ini memang “stress test” yang cukup untuk ribuan bahkan puluhan ribu TPS di masa depan.

2. Mekanisme khusus ZK-Rollup menentukan bahwa semakin besar volume transaksi yang diproses, semakin murah biaya gas, pada kenyataannya, biaya gas zkSync memang lebih murah, karena biaya transaksi juga dibagi, menurut data growthepie, dalam 24 jam terakhir, rata-rata gas zkSync juga menurun sebesar 5,2%, dengan rata-rata sekitar $0,19, data ini mungkin tidak sama untuk semua orang, tetapi data operasi rantai terintegrasi memang lebih murah. Ini membuktikan bahwa pengalaman ZK-Rollup yang lebih lancar perlu meningkatkan skala pengguna yang ada dengan urutan besarnya.

Apa dampak dari peristiwa prasasti pada rantai publik layer2?

Menurut data gundukan pasir, pencetakan prasasti Sync telah menambahkan 5 juta transaksi dalam 14 jam, dan 65.575 Pemegang telah berpartisipasi. Seperti disebutkan di atas, pejabat zkSync mengetahui “tes stres” yang diprakarsai komunitas ini dan mengambil langkah-langkah mendesak untuk memastikan bahwa rantai zkSync berjalan dengan tertib.

Data ini memang merupakan eksperimen uji stres yang baik untuk zkSync, dan efek positifnya lebih besar daripada yang negatif. Dalam jangka panjang, insiden prasasti tidak merusak, melainkan memberikan pengalaman praktis untuk optimalisasi kinerja lebih lanjut dari Layer 2.

Namun, sejauh yang saya tahu, ada prasasti lain yang dicetak selain Sync, yang tidak segila Sync, tetapi menambah bahan bakar ke api uji stres ini.

Bagaimanapun, hasilnya umumnya baik, jika Anda mengklarifikasi logika teknis backend zkSync memilah blok, dan kemudian menghilangkan kesalahpahaman tentang “pengalaman buruk”, Anda harus memahami bahwa semuanya berjalan dengan baik, dan kami harus memberi layer2 sedikit lebih percaya diri.