Bagian pertama dari seri zkEVM: keseluruhan arsitektur dan proses eksekusi transaksi Polygon zkEVM

2023-12-01 09:12:32

Penulis: 0xhhh, Ethstorage (Twitter: @hhh69251498 )

Editor:Red One

Pada tanggal 27 Maret, versi beta dari mainnet Polygon zkEVM secara resmi diluncurkan, dan Vitalik menyelesaikan transaksi pertamanya di atasnya.

Artikel ini adalah yang pertama dari serangkaian artikel tentang Polygon zkEVM, yang menjelaskan secara singkat keseluruhan arsitektur dan proses eksekusi transaksi Polygon zkEVM, dan menganalisis bagaimana Polygon zkEVM mencapai penskalaan komputasi sambil mewarisi keamanan Ethereum.

Dalam dua artikel berikutnya, kami juga akan merinci detail desain Jembatan zkEVM dan zkEVM Polygon zkEVM, serta peta jalan untuk Sequencer terdesentralisasi Polygon zkEVM berikutnya.

Pertama, Rollup adalah untuk mencapai penskalaan komputasi untuk Ethereum

Pertama, kita harus jelas tentang cara kerja Rollups. Munculnya Rollup adalah untuk skala perhitungan Ethereum, metode implementasi khusus adalah untuk mengalihdayakan eksekusi transaksi ke Rollup, dan kemudian menyimpan transaksi dan keadaan (State) setelah eksekusi transaksi dalam kontrak Ethereum.

** Rollup Optimis **

Secara optimis, Transaksi Rollup dan Status Rollup terkait yang dikirim ke Ethereum sudah benar, dan siapa pun dapat menantang Status Rollup yang masih dalam periode tantangan dengan memberikan Bukti Penipuan.

** Rollup Tanpa Pengetahuan **

ZK akan memberikan bukti validitas untuk transaksi rollup yang dikirim ke Ethereum dan status rollup yang sesuai (diverifikasi oleh kontrak di Ethereum untuk membuktikan bahwa rollup dalam keadaan benar setelah eksekusi transaksi yang sesuai).

Lihat definisi resmi Ethereum:

Perbedaan terbesar antara Zero-knowledge Rollup dan Optimistic Rollup adalah bahwa waktu untuk mencapai finalitas berbeda karena cara yang berbeda untuk memverifikasi validitas negara.

Optimistic Rollup optimis bahwa transaksi dan status yang dikirimkan ke Ethereum benar, jadi ada periode tantangan 7 hari (waktu untuk mencapai finalitas adalah 7 hari), di mana siapa pun yang menemukan bahwa keadaan transaksi yang sesuai di Ethereum salah dapat menantang dengan mengirimkan status yang benar.

Waktu yang dibutuhkan untuk Zero-knowledge Rollup (zk-Rollup) untuk mencapai finalitas tergantung pada waktu yang diperlukan untuk Bukti Validitas transaksi untuk diserahkan ke Ethereum dan diverifikasi. Saat ini, mungkin sekitar 1 jam untuk finalitas (karena kebutuhan untuk mempertimbangkan biaya gas).

Kedua, proses eksekusi Polygon zkEVM

Mari kita lihat bagaimana Polygon zkEVM bekerja dengan proses konfirmasi transaksi sederhana, sehingga memiliki pemahaman konkret tentang keseluruhan protokol, dan seluruh prosesnya dapat dibagi menjadi tiga langkah utama:

Sequencer mengemas beberapa transaksi pengguna ke dalam batch dan mengirimkannya ke kontrak L1.
Prover menghasilkan Bukti Validitas untuk setiap transaksi dan menggabungkan bukti validitas beberapa transaksi menjadi satu Bukti Validitas.
Agregator menyerahkan Bukti Validitas agregator beberapa transaksi ke dalam kontrak L1.

1 Sequencer mengemas transaksi pengguna ke dalam batch dan mengirimkannya ke kontrak L1.

Pengguna mengirimkan transaksi ke Sequencer, dan Sequencer akan memproses transaksi secara lokal dalam urutan penerimaan (FRFS), ketika Sequencer mengeksekusi transaksi secara lokal, jika pengguna percaya bahwa Sequencer jujur, maka ia dapat menganggap transaksi telah mencapai finalitas. Penting untuk dicatat di sini bahwa sebagian besar Mempools dalam Sequencer saat ini bersifat pribadi, jadi ada relatif sedikit MEV yang dapat diperoleh untuk saat ini.
Sequencer akan mengemas beberapa transaksi ke dalam batch (saat ini hanya satu transaksi dalam batch) dan kemudian mengirim beberapa batch bersama-sama ke Calldata transaksi L1 melalui fungsi SequenceBatch() PolygonZKEvm.sol di L1.

(Perlu dicatat bahwa beberapa batch dikirimkan sekaligus untuk mengurangi konsumsi gas L1 sebanyak mungkin.)

Ketika PolygonZkEvm.sol menerima Batch yang disediakan oleh Sequencer, itu akan menghitung hash dari setiap batch dalam kontrak secara bergantian, dan kemudian merekam hash dari batch sebelumnya di batch berikutnya, jadi kita mendapatkan struktur Batch pada gambar berikut.

4) Urutan transaksi di setiap batch juga ditentukan, jadi ketika urutan batch ditentukan, kami menganggap urutan semua transaksi yang termasuk dalam batch yang akan diserahkan ke kontrak L1 Polygon zkEVM telah ditentukan.

Proses aktual di atas juga merupakan pekerjaan yang harus diselesaikan L1 sebagai lapisan Rollup DA (tidak ada verifikasi status atau pekerjaan kemajuan yang telah diselesaikan saat ini).

**2. Agregator menghasilkan Bukti Validitas untuk beberapa batch transaksi

Ketika Agregator mendengarkan keberhasilan pengajuan batch baru dalam kontrak PolyonZKEVM.sol pada L1, ia menyinkronkan batch ini ke node-nya dan mengirimkan transaksi ini ke zkProver.
Setelah menerima transaksi ini, zkProver akan menghasilkan Bukti Validitas untuk setiap transaksi, dan kemudian menggabungkan Bukti Validitas transaksi yang terkandung dalam beberapa batch menjadi Bukti Validitas.

zkProver mengirimkan Bukti Validitas penggabungan beberapa transaksi ke Agregator.

3. Agregator menyerahkan kontrak untuk bukti agregat ke L1

Agregator akan menyerahkan Bukti Validitas ini ke kontrak Polygon zkEvm.sol pada L1 bersama dengan status eksekusi batch yang sesuai dengan memanggil metode berikut:

Tindakan berikut kemudian dilakukan dalam kontrak untuk memverifikasi bahwa transisi negara sudah benar.

Ketika langkah ini berhasil dijalankan dalam kontrak L1, semua transaksi yang termasuk dalam bagian batch ini akan benar-benar mencapai Finalitas (sesuai dengan akhir periode tantangan 7 hari OP).

3. Peran Ethereum di Polygon-zkEVM

Sekarang setelah kita melihat keseluruhan proses Polygon zkEVM, mari kita tinjau apa yang telah dilakukan Ethereum untuk Rollup:

Pada langkah pertama, Sequencer mengumpulkan transaksi rollup dan mengemasnya ke dalam batch, yang kemudian diserahkan ke kontrak L1. L1 tidak hanya menyediakan fungsionalitas lapisan DA, tetapi juga benar-benar melengkapi beberapa fungsi pemesanan transaksi, ketika Anda mengirimkan transaksi ke Sequencer, transaksi tidak benar-benar dipesan, karena Sequencer memiliki kekuatan untuk mengubah urutan transaksi sesuka hati, tetapi ketika transaksi dimasukkan dalam Batch dan diserahkan ke kontrak L1, tidak ada yang berhak mengubah urutan transaksi.

Pada langkah kedua, Agregator membawa Bukti Validitas ke kontrak L1 untuk mencapai keadaan baru, Agregator adalah peran seperti Pengusul, dan kontrak tersebut mirip dengan peran Validator, dan Agregator memberikan Bukti Validitas untuk membuktikan bahwa keadaan baru benar dan memberi tahu Validator Validitas yang saya berikan Batch transaksi apa yang terlibat dalam Proof, dan di mana mereka berada di L1.

Kemudian validator mengekstrak batch yang sesuai dari kontrak, dan menggabungkannya dengan Bukti Validitas untuk memverifikasi keabsahan transisi status, dan jika verifikasi berhasil, kontrak sebenarnya akan diperbarui ke status baru dari Bukti Validitas yang sesuai.

Keempat, susun Smart Contract Rollup dari perspektif modularitas

Jika dari perspektif modularitas, Polygon zkEVM termasuk dalam tipe Smart Contract Rollup, kita dapat mencoba mendekonstruksi modulnya, dan dari diagram yang diberikan oleh Delphi, kita juga dapat melihat bahwa Polygon ZkEVM sebenarnya adalah Lapisan Konsensus, Lapisan DA dan Penyelesaian Smart Contrat Rollup Lapisan sebenarnya digabungkan ke kontrak PolygonZkEVM.sol, yang tidak dibedakan dengan baik. Tapi mari kita coba mendekonstruksi modul:

Lapisan Ketersediaan Data: Di mana transaksi rollup disimpan, dan dalam kasus Polygon-zkEVM, ketika Sequencer memanggil metode SequenceBatch(), itu sebenarnya mencakup pengiriman data transaksi ke lapisan DA.

Lapisan Penyelesaian: Secara khusus mengacu pada mekanisme aliran uang antara Rollup dan L1, khususnya jembatan resmi Polygon-zkEVM (lebih lanjut tentang ini di artikel berikutnya).

Lapisan Konsensus: Berisi pemesanan transaksi dan cara menentukan status valid berikutnya (pemilihan fork), Sequencer menyelesaikan pemesanan transaksi saat memanggil SequenceBatch() dalam kontrak L1, dan mengonfirmasi status hukum berikutnya saat Agregator memanggil TustedVerifyBatches() dalam kontrak L1.

Execution Layer: Proses dimana transaksi dieksekusi dan keadaan dunia baru diperoleh, ketika pengguna mengirimkan transaksi ke Sequencer, dan keadaan baru diperoleh setelah Sequencer dieksekusi ( Itu sebabnya kami cenderung mengatakan bahwa Rollups adalah penskalaan komputasi, karena L1 mengalihdayakan proses eksekusi transaksi untuk mendapatkan status baru ke Rollups, dan Sequencer mendelegasikan zkProver untuk membantu menghasilkan Bukti Validitas melalui Aggregator.

5. Mengapa Polygon-zkEVM mewarisi keamanan L1

Dilihat dari keseluruhan proses yang dijelaskan di atas, Sequencer sebenarnya melakukan sesuatu yang mirip dengan Ethereum Proposer, mengusulkan bahwa batch transaksi adalah transaksi yang valid, dan memberikan status baru dari batch transaksi ini setelah eksekusi, dan logika verifikasi kontrak L1 setara dengan semua validator L1 akan dieksekusi di klien Ethereum mereka sendiri, pada kenyataannya, semua validator Ethereum bertindak sebagai validator Rollup, jadi kami pikir Polygon zkEVM Mewarisi keamanan Ethereum.

Di sisi lain, karena semua transaksi dan status Rollup disimpan di Ethereum, bahkan jika tim Polygon zkEVM melarikan diri, siapa pun masih memiliki kemampuan untuk memulihkan seluruh jaringan Rollup berdasarkan data yang disimpan di Ethereum.

6. Mekanisme insentif zkEVM poligon

Insentif rollup terutama tentang bagaimana membuat Sequencer dan Aggregator menguntungkan dan dengan demikian menjaga pekerjaan tetap berjalan?

Pertama-tama, pengguna harus membayar biaya transaksi mereka sendiri di Rollup, yang dalam mata uang ETH dan dibayar dalam Bridged ETH.

Sequencer harus membayar biaya pengunggahan Batch yang berisi transaksi Rollup ke Calldata transaksi L1 (biaya pemanggilan SequenceBatch(batches()), dan Matic harus membayar sejumlah Matic ke kontrak L1 pada saat yang sama saat batch diunggah, yang nantinya akan membayar biaya Agregator yang memberikan Bukti Validitas untuk Batch ini.

Sementara Agregator memanggil VerifyBatches tepercaya untuk memberikan Bukti Validitas untuk Batch dalam kontrak L1 yang belum finalitas, Sequencer juga dapat mengambil token MATIC yang dibayarkan di muka oleh Sequencer dalam kontrak sebagai hadiah untuk memberikan Bukti Validitas.

Pendapatan sequencer = biaya gas untuk semua transaksi dalam rollup - biaya gas jaringan L1 yang dihabiskan untuk mengunggah Batch ke L1 - biaya pengesahan yang dibayarkan kepada Agregator (denominasi MATIC).

Pendapatan agregator = hadiah MATIC yang dibayarkan oleh sequencer - biaya gas yang diserahkan ke bukti validitas ke L1 - biaya perangkat keras yang dihabiskan untuk menghasilkan bukti validitas.

Sesuaikan biaya pengesahan yang dibayarkan kepada Agregator, dan untuk mencegah Sequencer tidak menguntungkan untuk menyerang, mekanisme berikut disediakan untuk menyesuaikan biaya pengesahan yang dibayarkan oleh Sequencer kepada Agregator.

Ada metode dalam kontrak yang menyesuaikan biaya penyediaan bukti untuk batch:

fungsi \ _updateBatchFee (uint64 newLastVerifiedBatch) internal

Ini mengubah variabel dalam kontrak yang disebut BatchFee, yang menentukan jumlah token MATIC yang dibayar Sequencer untuk setiap batch.

Mekanisme perubahannya adalah sebagai berikut:

Kontrak mempertahankan variabel VeryBatchTimeTarget yang mewakili status yang diharapkan dari setiap batch yang akan divalidasi dalam waktu tersebut setelah berkomitmen ke L1 oleh Sequencer.

Kontrak akan mencatat semua batch yang belum divalidasi setelah melebihi VeryBatchTimeTarget, dan jumlah total batch ini akan dicatat sebagai DiffBatches.

Oleh karena itu, ketika Batch terlambat, BatchFee akan disesuaikan dengan rumus berikut:

MultiplierBatchFee adalah angka yang terbatas pada kisaran 1000~1024, yang dapat diubah oleh administrator kontrak melalui fungsi setMultiplierBatchFee():

FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin

Perlu dicatat bahwa penggunaan MultiplierBatchFee dan 10^3 di sini adalah untuk mencapai akurasi penyesuaian setelah 3 koma desimal.

Demikian pula, jika batch berada di muka, mekanisme penyesuaian batchFee yang sesuai akan dipicu: DiffBatches menunjukkan jumlah batch dalam status verifikasi awal.

Ringkasan

Pada artikel ini, kami memilah mekanisme inti Polygon zkEVM dan menganalisis kelayakannya untuk mencapai penskalaan komputasi Ethereum. Dengan garis besar keseluruhan, dalam artikel berikut kita akan menyelami bagian dalam protokol, menganalisis detail desain Jembatan zkEVM, rute desentralisasi Sequencer, implementasi zkProver, dan prinsip-prinsip desain zkEVM.

——Bersambung——

Lihat Asli

Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.