Di bawah uji stres prasasti, zkSync menyelesaikan "pelatihan terbuka" yang sukses

Penulis asli: Haotian (X: @tmel0211)

Catatan editor: Jalur prasasti masih panas, rantai zkSync telah dibanjiri sejumlah besar transaksi dalam waktu singkat, dalam “uji stres” ini, zkSync turun karena prasasti, atau telah diuji dengan sempurna? Peneliti Crypto Haotian (X: @tmel0211) mengklarifikasi ilusi dan kesalahpahaman tentang “pengalaman buruk” zkSync dari logika teknis, dan Odaily Planet Daily menyelesaikannya sebagai berikut:

Prasasti yang terukir pada rantai zkSync dan masuknya transaksi setinggi langit dalam jangka pendek memang merupakan “uji stres” kinerja rantai publik Lapisan 2, tetapi hasilnya bukan “downtime”, sebaliknya, ini adalah pelatihan publik yang @zksync, dan hasilnya adalah puncak TPS, stabilitas GAS, dll. 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 adalah sebagai berikut: 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 mudah untuk menciptakan ilusi “pengalaman buruk”:

1. Pengguna membangun tautan 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 “ketidakcocokan” antara waktu respons RPC Metamask dan logika umpan balik dan logika transaksi paket antrian Sequencer zkSync. **Ini adalah alasan mengapa beberapa transaksi yang tampaknya gagal di MetaMask menunjukkan keberhasilan lagi setelah menunggu beberapa saat.

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 Session: Ketika pengguna mengirim transaksi ke antrian RPC untuk waktu yang singkat, setiap transaksi akan ditumpuk dari nilai nonce 0, jika transaksi sebelumnya masih dalam keadaan antrian, nonce adalah 0, maka pengguna memulai transaksi baru dengan nonce 1, dan 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 sebagian dari mereka, dan segera setelah mereka menerimanya, mereka akan menyortirnya.

Melihatnya dengan cara ini, pengguna melihat bahwa MetaMask melaporkan bahwa transaksi telah gagal, dan tindakan 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, masalah logika waktu respons RPC dompet MetaMask dan terburu-buru pengguna untuk melapisi transaksi on-chain akan menyebabkan sejumlah besar “kegagalan” transaksi, dan relatif lebih mudah untuk menghindari masalah pengalaman pengoptimalan ini jika Anda jelas tentang alur kerja pemrosesan transaksi back-end 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 lonjakan transaksi antrian, yang merupakan masalah dengan front-end browser dan tidak ada hubungannya dengan pengoperasian rantai. **Masalah biasanya teratasi 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, staf resmi zkSync @anthonykrose men-tweet 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 memberikan “tes stres” penuh untuk ribuan, jika tidak 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 memerlukan urutan peningkatan besarnya dalam skala pengguna yang ada.

-Dampak peristiwa prasasti pada rantai publik lapisan 2?

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 optimasi kinerja Layer 2 lebih lanjut. **

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 blok penyortiran backend zkSync, dan kemudian menghilangkan kesalahpahaman tentang “pengalaman buruk”, Anda harus memahami bahwa semuanya berjalan dengan baik, dan kami perlu memberi lapisan 2 sedikit lebih percaya diri.

Link ke artikel asli