Penulis asli | Vitalik

编译 | Odaily Planet Daily Nanzhi

Salah satu atribut penting dari pengalaman pengguna blockchain yang baik adalah waktu konfirmasi transaksi yang cepat. Saat ini, Ethereum telah mengalami banyak perbaikan dibandingkan lima tahun yang lalu, berkat waktu blok yang stabil setelah EIP-1559 dan transisi ke PoS (The Merge), penggunaan transaksi yang dikirimkan pada L1 biasanya dapat dikonfirmasi dalam 5-20 detik, pengalaman yang sebanding dengan pembayaran kartu kredit. Namun, perbaikan lebih lanjut pada pengalaman pengguna memiliki nilai, dan beberapa aplikasi bahkan memerlukan keterlambatan dalam hitungan ratusan milidetik atau bahkan lebih pendek. Artikel ini akan membahas beberapa opsi praktis Ethereum (untuk meningkatkan waktu konfirmasi transaksi).

Gambaran tentang gagasan dan teknologi yang ada

Kedalaman Slot Ganda

Saat ini, konsensus Gasper Ethereum menggunakan arsitektur slot tunggal dan Epoch. Setiap 12 detik ada satu slot, sebagian validator akan memilih kepala rantai, dan dalam 32 slot (6,4 menit), semua validator memiliki kesempatan untuk memilih sekali. Suara ini kemudian diinterpretasikan ulang sebagai pesan dalam algoritma konsensus mirip PBFT, setelah dua Epoch (12,8 menit), memberikan jaminan ekonomi yang sangat kuat yang disebut finalitas.

Dalam beberapa tahun terakhir, kami semakin tidak puas dengan metode saat ini. Ada dua alasan utama, pertama metode ini sangat rumit, ada banyak kesalahan interaksi antara mekanisme pemungutan suara dari slot ke slot dan mekanisme kepastian Epoch ke Epoch, kedua 12,8 menit terlalu lama, tidak ada yang mau menunggu begitu lama.

Finalitas Slot Tunggal (SSF) menggantikan arsitektur ini dengan mekanisme mirip dengan konsensus Tendermint, di mana blok N secara final ditentukan sebelum dibuat blok N+1. Perbedaan utamanya dengan Tendermint adalah kami mempertahankan mekanisme 'kebocoran tidak aktif', yang memungkinkan rantai tetap berjalan dan pulih ketika lebih dari 1/3 validator offline.

Tantangan utama dengan finalitas slot tunggal adalah bahwa itu berarti bahwa setiap Ethereum stake perlu mempublikasikan dua pesan setiap 12 detik, yang merupakan beban signifikan pada rantai. Ada beberapa ide cerdas untuk mengatasi masalah ini, termasuk proposal Orbit SSF baru-baru ini. Meskipun ini secara signifikan mempercepat "finalitas" untuk meningkatkan pengalaman pengguna, itu tidak mengubah fakta bahwa pengguna harus menunggu 5-20 detik.

Konfirmasi Rollup

Selama beberapa tahun terakhir, Ethereum telah mengikuti roadmap yang berpusat pada rollup, merancang lapisan dasar Ethereum (L1) untuk mendukung ketersediaan data dan fitur lainnya, yang kemudian dapat digunakan oleh protokol L2 (seperti rollups, validiums, dan plasmas) untuk menyediakan keamanan yang setara dengan Ethereum dalam skala yang lebih besar bagi pengguna.

Ini menyebabkan pemisahan fokus dalam ekosistem Ethereum: Ethereum L1 berfokus pada auditabilitas, keandalan, stabilitas, serta pemeliharaan dan peningkatan fitur inti lapisan dasar tertentu, sedangkan L2 berfokus pada interaksi langsung dengan pengguna melalui budaya dan teknologi yang berbeda. Tetapi jika melanjutkan jalur ini, masalah yang tak terhindarkan muncul: L2 ingin memberikan konfirmasi yang lebih cepat dari 5-20 detik bagi pengguna.

Sampai sejauh ini, setidaknya secara teoritis, menjadi tanggung jawab L2 untuk membuat jaringan 'sorter' terdesentralisasi mereka sendiri. Sebuah kelompok kecil validator dapat menandatangani blok setiap beberapa ratus milidetik dan mengunci aset staking mereka di belakang blok-blok tersebut. Akhirnya, header blok L2 ini akan dipublikasikan ke L1.

Namun, kumpulan validator L2 dapat melakukan 'kecurangan': mereka dapat menandatangani blok B1 terlebih dahulu, kemudian menandatangani blok konflik B2 dan mengirimkannya ke on-chain sebelum B1. Namun jika mereka melakukannya, mereka akan terdeteksi dan kehilangan aset staking. Sebenarnya, kita sudah melihat kasus nyata versi terpusat, namun di sisi lain rollup mengalami kemajuan lambat dalam pengembangan jaringan pengurutan yang desentralisasi. Anda bisa mengatakan bahwa meminta semua L2 untuk melakukan pengurutan yang desentralisasi adalah tidak adil: kita seolah-olah meminta rollup untuk melakukan pekerjaan yang hampir sama dengan membuat L1 yang benar-benar baru. Oleh karena itu, Justin Drake telah terus mempromosikan metode yang memungkinkan semua L2 (dan L1) menggunakan mekanisme pre-commitment yang dapat dibagikan di seluruh jangkauan Ethereum: pre-commitment dasar.

Konfirmasi Pra-Dasar

Metode konfirmasi awal berbasis mengasumsikan proposer Ethereum adalah peserta yang sangat kompleks terkait MEV. Metode berbasis konfirmasi awal memanfaatkan kompleksitas ini dengan mendorong para proposer kompleks ini untuk menerima tanggung jawab menyediakan layanan konfirmasi awal.

Ide dasar metode ini adalah membuat protokol standar di mana pengguna dapat memberikan biaya tambahan untuk memastikan transaksi mereka akan dimasukkan dalam blok berikutnya dengan jaminan segera, serta deklarasi atas hasil eksekusi transaksi tersebut. Jika pengusul melanggar janji yang diberikan kepada pengguna manapun, mereka dapat dikenakan slashing.

Seperti yang disebutkan, memberikan jaminan untuk transaksi L1 berdasarkan prakonfirmasi. Jika rollups adalah 'berbasis', maka semua blok L2 adalah transaksi L1, sehingga mekanisme yang sama dapat digunakan untuk memberikan prakonfirmasi untuk setiap L2.

Apa yang sebenarnya kita lihat?

Anggaplah kita mencapai finalitas satu slot. Kami menggunakan teknologi serupa dengan Orbit untuk mengurangi jumlah validator yang menandatangani setiap slot, namun tidak terlalu banyak, sehingga kami juga dapat membuat kemajuan dalam mencapai target kritis untuk mengurangi jumlah minimum staking 32 ETH. Slot time mungkin akan meningkat menjadi 16 detik, kemudian kami menggunakan pre-confirmation rollup atau pre-confirmation dasar untuk memberikan konfirmasi yang lebih cepat kepada pengguna. Akhirnya, apa yang kami dapatkan: sebuah arsitektur slot-epoch.

Ada alasan filosofis yang mendalam mengapa arsitektur epoch-and-slot tampaknya sangat sulit dihindari: dibandingkan dengan mencapai kesepakatan 'finalitas ekonomi' maksimum dalam sesuatu, dibutuhkan waktu yang lebih sedikit untuk mencapai kesepakatan yang lebih atau kurang setuju dalam sesuatu.

Salah satu alasan sederhana adalah jumlah Node. Meskipun kompromi linear lama antara desentralisasi/waktu akhir/overhead tampaknya lebih ringan sekarang berkat agregasi BLS yang sangat dioptimalkan dan ZK-STARKs yang akan datang, alasan berikut tidak boleh diabaikan:

• 'Konsensus mendekati' hanya membutuhkan sedikit node, sementara kesahihan ekonomi membutuhkan sebagian besar node.
• Begitu jumlah Node melebihi skala tertentu, Anda perlu menghabiskan lebih banyak waktu untuk mengumpulkan tanda tangan.

Dalam Ethereum hari ini, 12 slot kedua dibagi menjadi tiga sub-slot: pemilihan dan distribusi blok, bukti, agregasi bukti. Jika jumlah validator berkurang secara signifikan, kita dapat mengurangi menjadi dua sub-slot dan menggunakan waktu slot 8 detik. Faktor lain yang lebih praktis dan penting adalah 'kualitas' dari node. Jika kita juga dapat mengandalkan subset node yang terkhususkan untuk mencapai kesepakatan yang hampir sama (dan masih menggunakan set validator lengkap untuk menentukan finalitas), kita dapat menguranginya menjadi sekitar 2 detik.

Oleh karena itu, menurut pandangan saya, arsitektur epoch-and-slot jelaslah yang benar, tetapi tidak semua arsitektur epoch-and-slot setara, dan eksplorasi ruang desain yang lebih luas memiliki nilai. Area yang layak mendapat penelitian lebih mendalam bukanlah penggabungan yang erat seperti Gasper, melainkan pemisahan fokus yang lebih kuat antara kedua mekanisme.

Bagaimana cara kerja L2?

Menurut pendapat saya, L2 saat ini memiliki tiga strategi yang masuk akal:

• Secara teknis dan spiritual, mereka didasarkan pada Ethereum. Artinya, mereka mengoptimalkan properti teknologi lapisan dasar Ethereum dan nilai-nilainya (desentralisasi yang tinggi, tahan sensor, dll). Secara sederhana, Anda dapat menganggap rollup ini sebagai 'sharding merek', tetapi mereka juga dapat memiliki ambisi yang lebih besar untuk melakukan banyak eksperimen pada desain mesin virtual baru dan perbaikan teknologi lainnya.
• Menjadi 'server dengan kerangka kerja blockchain' dan memanfaatkannya sepenuhnya. Jika Anda memulai dari server, lalu tambahkan bukti validitas STARK untuk memastikan server mengikuti aturan; memastikan hak pengguna untuk keluar atau memaksa transaksi; kebebasan pilihan kolektif, melalui kelompok keluar yang disinkronkan atau melalui perubahan pemilih pengurutan, maka Anda telah mendapatkan sebagian besar manfaat dari blockchain, sambil mempertahankan sebagian besar efisiensi server.
• Metode Kompromi: Ethereum dengan rantai cepat yang memiliki 100 node memberikan interoperabilitas dan keamanan tambahan. Ini adalah rencana nyata dari banyak proyek L2 saat ini.

Bagi beberapa aplikasi (misalnya ENS, penyimpanan kunci rahasia, sebagian protokol pembayaran), waktu blok 12 detik sudah cukup. Untuk aplikasi yang tidak cocok, satu-satunya solusi adalah arsitektur epoch-and-slot. Dalam tiga kasus, 'epoch' adalah SSF Ethereum, tetapi slot berbeda untuk ketiga kasus tersebut:

• arsitektur epoch-and-slot asli Ethereum
• Konfirmasi Pra-pelayanan
• Pra-konfirmasi Komite

Salah satu masalah kunci adalah, seberapa baik kita bisa melakukan hal itu dalam kategori 1? Terutama jika itu menjadi sangat baik, maka arti dari kategori 3 tidak begitu besar lagi. Karena semua skema "berbasis" tidak berlaku untuk data L2 seperti plasmas dan validiums di luar rantai, maka kategori 2 akan selalu ada. Jika arsitektur epoch-and-slot asli Ethereum dapat menurunkan waktu slot menjadi 1 detik, maka ruang kategori 3 akan jauh lebih kecil.

Hari ini, kita masih jauh dari jawaban akhir atas pertanyaan-pertanyaan ini. Salah satu masalah kunci adalah seberapa kompleks proposer blok akan menjadi, ini masih merupakan area yang memiliki ketidakpastian yang cukup besar. Desain seperti Orbit SSF sangat baru dan inovatif, sehingga pengeksplorasian ruang desain seperti Orbit SSF sebagai skema epoch-and-slot masih layak untuk dilakukan. Semakin banyak pilihan yang kita miliki, semakin baik kita dapat melayani pengguna L1 dan L2, dan semakin kita dapat menyederhanakan pekerjaan pengembang L2.