Penulis asli |Vitalik
Kompilasi |. Harian Planet Odaily Nan Zhi
Salah satu atribut penting dari pengalaman pengguna blockchain yang baik adalah waktu konfirmasi transaksi yang cepat. Saat ini, Ethereum jauh lebih baik dibandingkan lima tahun lalu. Berkat EIP-1559 dan waktu blok yang stabil setelah beralih ke PoS (The Merge), transaksi yang dikirim oleh pengguna di L1 biasanya dapat dikonfirmasi dalam waktu 5-20 detik, yang kira-kira setara dengan pengalaman membayar dengan kartu kredit. Namun, ada manfaatnya untuk lebih meningkatkan pengalaman pengguna, dan beberapa aplikasi bahkan memerlukan latensi ratusan milidetik atau kurang. Artikel ini akan membahas beberapa opsi praktis untuk meningkatkan waktu konfirmasi transaksi di Ethereum.
Tinjauan ide dan teknik yang ada
finalitas slot tunggal
Saat ini, konsensus Gasper Ethereum menggunakan satu slot (Slot) dan arsitektur Epoch. Setiap 12 detik sebuah slot, sebagian validator memberikan suara pada bagian atas rantai, dan setiap 32 slot (6,4 menit), semua validator memiliki kesempatan untuk memberikan suara satu kali. Pemungutan suara ini kemudian diinterpretasikan kembali sebagai pesan dalam algoritma konsensus yang mirip dengan PBFT, memberikan jaminan ekonomi yang sangat kuat yang disebut finalitas setelah dua Epoch (12,8 menit).
Selama beberapa tahun terakhir kami semakin tidak puas dengan pendekatan kami saat ini. Ada dua alasan utama untuk hal ini. Pertama, metode ini rumit dan terdapat banyak kesalahan interaksi antara mekanisme pemungutan suara slot-ke-slot dan mekanisme finalitas Epoch-to-Epoch. Kedua, 12,8 menit terlalu lama dan tidak ada yang mau untuk menunggu selama itu.
Single Slot Finality (SSF) menggantikan arsitektur ini dengan mekanisme yang mirip dengan konsensus Tendermint, di mana blok N diselesaikan sebelum blok N+1 dibuat. Perbedaan utama dengan Tendermint adalah kami mempertahankan mekanisme "kebocoran tidak aktif", yang memungkinkan rantai terus berjalan dan pulih jika lebih dari 1/3 validator sedang offline.
Tantangan utama dalam finalitas slot tunggal adalah setiap pemangku kepentingan Ethereum harus mempublikasikan dua pesan setiap 12 detik, yang merupakan beban signifikan pada rantai. Ada beberapa ide cerdas untuk mengurangi masalah ini, termasuk proposal Orbit SSF baru-baru ini. Meskipun hal ini secara signifikan mempercepat "finalitas" untuk meningkatkan pengalaman pengguna, hal ini tidak mengubah fakta bahwa pengguna perlu menunggu 5-20 detik.
Rollup pra-konfirmasi
Ethereum telah mengikuti peta jalan yang berpusat pada rollup selama beberapa tahun terakhir, merancang lapisan dasar Ethereum (L1) untuk mendukung ketersediaan data dan fitur lainnya, yang kemudian tersedia untuk protokol L2 seperti rollup, validium, dan plasma memberi pengguna tingkat keamanan yang sama seperti Ethereum dalam skala yang lebih besar.
Hal ini menciptakan pemisahan kekhawatiran dalam ekosistem Ethereum: Ethereum L1 berfokus pada ketahanan sensor, keandalan, stabilitas, serta mempertahankan dan meningkatkan fungsionalitas inti dari lapisan dasar tertentu, sementara L2 berfokus pada komunikasi yang lebih langsung melalui budaya dan teknologi yang berbeda kepada pengguna. Namun jika Anda mengambil jalur ini, masalah yang tak terhindarkan akan muncul: L2 ingin memberikan konfirmasi lebih cepat kepada pengguna daripada 5-20 detik.
Sejauh ini, setidaknya secara teori, L2 bertanggung jawab untuk menciptakan jaringan "sequencer terdesentralisasi" miliknya sendiri. Sekelompok kecil validator dapat menandatangani blok setiap beberapa ratus milidetik dan mempertaruhkan saham mereka di belakang blok tersebut. Akhirnya, file header untuk potongan L2 ini diterbitkan ke L1.
Namun set validator L2 dapat melakukan "penipuan": mereka dapat menandatangani blok B1 terlebih dahulu, lalu menandatangani blok B2 yang bertentangan dan mengkomitnya ke rantai sebelum B1. Namun jika mereka melakukannya, mereka akan ketahuan dan kehilangan aset yang dijaminkan. Kami sebenarnya telah melihat contoh praktis dari versi terpusat, namun rollup di sisi lain lambat dalam mengembangkan jaringan pemesanan yang terdesentralisasi. Anda dapat berargumentasi bahwa tidak adil jika mengharuskan semua L2 didesentralisasi: kami meminta rollup melakukan pekerjaan yang hampir sama seperti membuat L1 yang benar-benar baru. Oleh karena itu, Justin Drake telah mempromosikan cara agar semua L2 (dan juga L1) menggunakan mekanisme pra-konfirmasi bersama di seluruh Ethereum: pra-konfirmasi dasar.
Pra-konfirmasi dasar
Pendekatan Prakonfirmasi Berbasis mengasumsikan bahwa pengusul Ethereum adalah peserta yang sangat canggih yang terkait dengan MEV. Pendekatan berbasis prakonfirmasi mengeksploitasi kompleksitas ini dengan memberikan insentif kepada para pengusul yang kompleks untuk menerima tanggung jawab dalam menyediakan layanan prakonfirmasi.
Ide dasar dari pendekatan ini adalah untuk menciptakan protokol standar di mana pengguna dapat memberikan jaminan langsung bahwa suatu transaksi akan dimasukkan dalam blok berikutnya dengan biaya tambahan, serta klaim atas hasil pelaksanaan transaksi tersebut. Jika pengusul mengingkari janji yang dibuat kepada pengguna mana pun, janji tersebut dapat dipotong.
Sebagaimana dinyatakan, transaksi L1 dijamin berdasarkan pra-konfirmasi. Jika rollup bersifat "berbasis", maka semua blok L2 adalah transaksi L1, sehingga mekanisme yang sama dapat digunakan untuk memberikan konfirmasi awal untuk L2 mana pun.
Apa yang sebenarnya kita lihat?
Misalkan kita mencapai finalitas slot tunggal. Kami menggunakan teknologi yang mirip dengan Orbit untuk mengurangi jumlah validator yang menandatangani per slot, namun tidak terlalu banyak sehingga kami juga dapat mencapai kemajuan dalam tujuan utama mengurangi minimal staking 32 ETH. Waktu slot dapat ditingkatkan menjadi 16 detik, dan kemudian kami menggunakan pra-konfirmasi rollup atau pra-konfirmasi dasar untuk memberikan konfirmasi yang lebih cepat kepada pengguna. Apa yang kami dapatkan pada akhirnya: arsitektur slot zaman.
Ada alasan filosofis yang mendalam mengapa arsitektur zaman-dan-slot tampaknya begitu sulit untuk dihindari: Dibutuhkan lebih sedikit waktu untuk menyepakati sesuatu secara kasar dibandingkan untuk mencapai kesepakatan mengenai sesuatu dengan tingkat "finalitas ekonomi" yang paling tinggi.
Alasan sederhananya adalah jumlah node. Meskipun desentralisasi linier/waktu finalitas/pertukaran overhead yang lama kini tampak ringan karena agregasi BLS yang sangat optimal dan ZK-STARK yang akan datang, alasan berikut tidak dapat diabaikan:
âPerkiraan konsensusâ hanya membutuhkan sejumlah kecil node, sedangkan finalitas ekonomi memerlukan mayoritas node yang besar.
Setelah jumlah node melebihi ukuran tertentu, Anda perlu menghabiskan lebih banyak waktu untuk mengumpulkan tanda tangan.
Di Ethereum saat ini, slot 12 detik dibagi menjadi tiga sub-slot: penerbitan dan distribusi blok, pengesahan, dan agregasi pengesahan. Jika jumlah pembuktian berkurang secara signifikan, kita dapat mengurangi menjadi dua subslot dan menggunakan waktu slot 8 detik. Faktor lain yang lebih realistis dan lebih besar adalah "kualitas" node. Faktor lain yang lebih besar adalah "kualitas" node. Jika kita juga dapat mengandalkan subset node khusus untuk mencapai perkiraan kesepakatan (dan masih menggunakan set lengkap validator untuk menentukan finalitas), kita dapat mempersingkatnya menjadi ~2 detik.
Jadi menurut saya, arsitektur epoch-and-slot jelas benar, namun tidak semua arsitektur epoch-and-slot diciptakan sama, dan ada gunanya mengeksplorasi ruang desain secara lebih menyeluruh. Arah yang layak untuk diteliti lebih lanjut tidak begitu erat seperti yang ada di Gasper, namun dengan pemisahan kekhawatiran yang lebih kuat di antara kedua mekanisme tersebut.
Apa yang harus dilakukan L2?
Menurut pendapat saya, L2 saat ini memiliki tiga strategi yang masuk akal:
Baik "berbasis" secara teknis dan spiritual. Artinya, mereka mengoptimalkan sifat teknis lapisan dasar Ethereum dan nilainya (desentralisasi tinggi, ketahanan sensor, dll.). Dalam bentuknya yang paling sederhana, Anda dapat menganggap rollup ini sebagai "pecahan bermerek", namun rollup ini juga bisa jauh lebih ambisius, banyak bereksperimen dengan desain VM baru dan peningkatan teknis lainnya.
Jadilah âserver dengan perancah blockchainâ dan manfaatkan semaksimal mungkin. Jika Anda memulai dengan server dan kemudian menambahkan bukti validitas STARK untuk memastikan bahwa server mengikuti aturan; untuk memastikan hak pengguna untuk menarik atau memaksa transaksi; dan kebebasan memilih secara kolektif, baik melalui penarikan massal yang terkoordinasi atau dengan mengubah pemesan pilih, maka Anda mendapatkan sebagian besar manfaat uplinking sambil mempertahankan sebagian besar efisiensi server.
Jalan tengah: rantai cepat dengan seratus node, Ethereum memberikan interoperabilitas dan keamanan ekstra. Ini adalah peta jalan de facto saat ini untuk banyak proyek L2.
Untuk beberapa aplikasi (misalnya ENS, penyimpanan kunci, beberapa protokol pembayaran), waktu blok 12 detik sudah cukup. Untuk aplikasi yang tidak dapat menerapkan hal ini, satu-satunya solusi adalah arsitektur epoch-and-slot. Dalam tiga kasus, "epoch" adalah SSF Ethereum, namun slotnya berbeda dalam masing-masing dari tiga kasus di atas:
Arsitektur zaman dan slot asli Ethereum
Pra-konfirmasi server
konfirmasi awal panitia
Pertanyaan kuncinya adalah, seberapa baik kita bisa berada di Kategori 1? Secara khusus, jika hasilnya sangat bagus, sepertinya Kategori 3 tidak akan terlalu berarti. Karena semua solusi "berbasis" tidak berlaku untuk data off-chain L2 seperti plasma dan validium, kategori 2 akan selalu ada. Jika arsitektur epoch-and-slot asli Ethereum dapat dikurangi menjadi waktu slot 1 detik, maka ruang untuk Kategori 3 akan menjadi jauh lebih kecil.
Saat ini, kita masih jauh dari jawaban akhir atas pertanyaan-pertanyaan ini. Pertanyaan kuncinya adalah seberapa kompleksnya pengusul blok, yang masih menjadi area ketidakpastian yang cukup besar. Desain seperti Orbit SSF sangat baru, sehingga ruang desain skema seperti menggunakan Orbit SSF sebagai epoch dalam epoch-and-slot masih layak untuk dieksplorasi sepenuhnya. Semakin banyak pilihan yang kita miliki, semakin baik yang bisa kita lakukan untuk pengguna L1 dan L2, dan kita bisa membuat hidup lebih mudah bagi pengembang L2.
