Saya melihat seorang teman mengeluh bahwa @zkSync selalu down. Nyatanya, menyebutnya "downtime" agak berlebihan. Tepatnya, ini adalah "pembuatan blok yang tidak stabil".
Pada dasarnya, waktu Terverifikasi terakhir dari transaksi yang diajukan oleh Sequencer tidak stabil, tetapi persepsi pengguna tidak jelas di akhir interaktif, karena desain Verifikasi zkSync memiliki penundaan konfirmasi.
Ketidakstabilan dalam tahap desentralisasi di masa mendatang akan berkurang. Saya menggambar alur kerja untuk didiskusikan dengan Anda.
Alasan mengapa pengguna menganggap "waktu henti" mungkin karena masalah kegagalan transaksi yang disebabkan oleh kompatibilitas antara beberapa DApps dan lapisan bawah rantai. Lagi pula, mengembangkan DApps di zkSync sendiri sangat menantang.
Dibutuhkan sekitar 30 menit-1 jam bagi saya untuk mengamati perubahan status dari Komit ke Terverifikasi dari browser resmi, sedangkan DApp interaktif sisi pengguna hampir tidak terpengaruh oleh hal ini.
Artikel ini berfokus pada logika yang mendasari teknologi zkSync sains populer, dan memberi Anda pemahaman yang jelas tentang zkSync.
Seperti yang diperlihatkan dalam alur kerja, zkSync berjalan dalam langkah-langkah berikut:
Pengguna mengirimkan transaksi batch ke Sequencer melalui penerusan relai;
Sequencer bertanggung jawab untuk menyortir transaksi, menggabungkan, dan mengemas batch ke dalam pohon Merkle;
zkPorter menghasilkan sertifikat zk-SNARK dari pohon Merkle; sertifikat zk-SNARK masing-masing diteruskan ke Validator L2 dan rantai utama L1 untuk menghasilkan Commit Hash; Validator bertanggung jawab untuk verifikasi
Kebenaran bukti zk-SNARK diserahkan ke kontrak cerdas L1 untuk menghasilkan Verifikasi Hash;
Kontrak pintar zkSync di L1 memverifikasi pencocokan Commit Hash dan Verify Hash;
Setelah pencocokan berhasil, Transaksi Terverifikasi dibuat dan transaksi akhirnya diunggah ke rantai;
Jika pencocokan gagal, Commit Hash yang asli akan dibatalkan, dan sequencer akan mengirimkan kembali batch dan melakukan proses lagi.
Perlu ditekankan di sini bahwa zkSync mengadopsi "komit dua fase (2PC)", dan akhirnya menentukan kumpulan transaksi legal melalui verifikasi Hash dalam dua tahap Commit Hash dan Verify Hash.
Di satu sisi, ini dapat memastikan konsistensi dan keamanan data dalam proses operasi sistem, menurut pemahaman saya pribadi, ini juga merupakan manifestasi dari gagasan desentralisasi yang menahan dua komponen sistem, Sequencer dan Validator, dan layak pujian.
Alur Kerja zkSync terutama memiliki empat peran: Relay, Sequencer, zkPorter, dan Validator.Akan ada banyak "faktor tidak stabil" dalam pekerjaan koordinasi.
Ini dapat diringkas sebagai stabilitas fungsi simpul, stabilitas kerja sama simpul, dan kompleksitas algoritme dan protokol yang mendasarinya. Kesalahan apa pun di tautan apa pun dapat menyebabkan penundaan pemblokiran. Kegagalan teknis Common Arbitrum Sequencer adalah tipikal, dan zkSync hanya akan menghadapi lebih banyak tantangan.
Adapun kerumitan algoritme, inilah takdir rantai zkSync, dan pengembang ekologis perlu bekerja keras untuk mengatasinya. Adapun stabilitas kecerdasan simpul dan kolaborasi, saya pikir setelah datangnya tahap desentralisasi di masa depan, itu akan ditingkatkan secara efektif. Logikanya juga sederhana:
Beberapa node terdistribusi dapat menghindari ketidakstabilan jaringan yang disebabkan oleh satu titik kegagalan, dan sistemnya kuat; mekanisme insentif token terdistribusi dapat memberi pengembang sumber motivasi untuk menjaga stabilitas node.
Berpikir dari sudut lain, waktu Verifing yang lama bukanlah masalah pada tahap awal ekologi, ini dapat secara efektif meningkatkan keamanan rantai dan mencegah beberapa node dalam sistem melakukan kejahatan.
Singkatnya, jika Anda mengklarifikasi seluruh proses operasi zkSync, dan lebih memahami kompleksitas teknis lapisan 2 dan mekanisme "khusus" yang dirancang untuk keamanan, Anda dapat memperkuat kepercayaan Anda pada jalur teknis L2.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Mekanisme operasi zkSync disortir, tidak sering "downtime".
Saya melihat seorang teman mengeluh bahwa @zkSync selalu down. Nyatanya, menyebutnya "downtime" agak berlebihan. Tepatnya, ini adalah "pembuatan blok yang tidak stabil".
Pada dasarnya, waktu Terverifikasi terakhir dari transaksi yang diajukan oleh Sequencer tidak stabil, tetapi persepsi pengguna tidak jelas di akhir interaktif, karena desain Verifikasi zkSync memiliki penundaan konfirmasi.
Ketidakstabilan dalam tahap desentralisasi di masa mendatang akan berkurang. Saya menggambar alur kerja untuk didiskusikan dengan Anda.
Alasan mengapa pengguna menganggap "waktu henti" mungkin karena masalah kegagalan transaksi yang disebabkan oleh kompatibilitas antara beberapa DApps dan lapisan bawah rantai. Lagi pula, mengembangkan DApps di zkSync sendiri sangat menantang.
Dibutuhkan sekitar 30 menit-1 jam bagi saya untuk mengamati perubahan status dari Komit ke Terverifikasi dari browser resmi, sedangkan DApp interaktif sisi pengguna hampir tidak terpengaruh oleh hal ini.
Artikel ini berfokus pada logika yang mendasari teknologi zkSync sains populer, dan memberi Anda pemahaman yang jelas tentang zkSync.
Seperti yang diperlihatkan dalam alur kerja, zkSync berjalan dalam langkah-langkah berikut:
Pengguna mengirimkan transaksi batch ke Sequencer melalui penerusan relai;
Sequencer bertanggung jawab untuk menyortir transaksi, menggabungkan, dan mengemas batch ke dalam pohon Merkle;
zkPorter menghasilkan sertifikat zk-SNARK dari pohon Merkle; sertifikat zk-SNARK masing-masing diteruskan ke Validator L2 dan rantai utama L1 untuk menghasilkan Commit Hash; Validator bertanggung jawab untuk verifikasi
Kebenaran bukti zk-SNARK diserahkan ke kontrak cerdas L1 untuk menghasilkan Verifikasi Hash;
Kontrak pintar zkSync di L1 memverifikasi pencocokan Commit Hash dan Verify Hash;
Setelah pencocokan berhasil, Transaksi Terverifikasi dibuat dan transaksi akhirnya diunggah ke rantai;
Jika pencocokan gagal, Commit Hash yang asli akan dibatalkan, dan sequencer akan mengirimkan kembali batch dan melakukan proses lagi.
Perlu ditekankan di sini bahwa zkSync mengadopsi "komit dua fase (2PC)", dan akhirnya menentukan kumpulan transaksi legal melalui verifikasi Hash dalam dua tahap Commit Hash dan Verify Hash.
Di satu sisi, ini dapat memastikan konsistensi dan keamanan data dalam proses operasi sistem, menurut pemahaman saya pribadi, ini juga merupakan manifestasi dari gagasan desentralisasi yang menahan dua komponen sistem, Sequencer dan Validator, dan layak pujian.
Alur Kerja zkSync terutama memiliki empat peran: Relay, Sequencer, zkPorter, dan Validator.Akan ada banyak "faktor tidak stabil" dalam pekerjaan koordinasi.
Ini dapat diringkas sebagai stabilitas fungsi simpul, stabilitas kerja sama simpul, dan kompleksitas algoritme dan protokol yang mendasarinya. Kesalahan apa pun di tautan apa pun dapat menyebabkan penundaan pemblokiran. Kegagalan teknis Common Arbitrum Sequencer adalah tipikal, dan zkSync hanya akan menghadapi lebih banyak tantangan.
Adapun kerumitan algoritme, inilah takdir rantai zkSync, dan pengembang ekologis perlu bekerja keras untuk mengatasinya. Adapun stabilitas kecerdasan simpul dan kolaborasi, saya pikir setelah datangnya tahap desentralisasi di masa depan, itu akan ditingkatkan secara efektif. Logikanya juga sederhana:
Beberapa node terdistribusi dapat menghindari ketidakstabilan jaringan yang disebabkan oleh satu titik kegagalan, dan sistemnya kuat; mekanisme insentif token terdistribusi dapat memberi pengembang sumber motivasi untuk menjaga stabilitas node.
Berpikir dari sudut lain, waktu Verifing yang lama bukanlah masalah pada tahap awal ekologi, ini dapat secara efektif meningkatkan keamanan rantai dan mencegah beberapa node dalam sistem melakukan kejahatan.
Singkatnya, jika Anda mengklarifikasi seluruh proses operasi zkSync, dan lebih memahami kompleksitas teknis lapisan 2 dan mekanisme "khusus" yang dirancang untuk keamanan, Anda dapat memperkuat kepercayaan Anda pada jalur teknis L2.