Memberikan waktu konfirmasi transaksi yang lebih cepat untuk ETH, meningkatkan pengalaman pengguna

Waktu konfirmasi transaksi yang cepat adalah salah satu fitur penting dari pengalaman pengguna blockchain yang baik. Dalam beberapa tahun terakhir, Ethereum telah membuat kemajuan signifikan dalam hal ini. Berkat EIP-1559 dan waktu blok yang stabil setelah beralih ke PoS, transaksi yang dikirim oleh pengguna di L1 biasanya dapat dikonfirmasi dalam waktu 5-20 detik, pada dasarnya setara dengan pengalaman pembayaran kartu kredit. Namun, masih ada nilai dalam meningkatkan pengalaman pengguna lebih lanjut, beberapa aplikasi bahkan mengharuskan latensi sub-detik. Artikel ini akan membahas beberapa opsi yang dapat dilakukan Ethereum dalam meningkatkan waktu konfirmasi transaksi.

Tinjauan Teknologi yang Ada

penyelesaian akhir slot tunggal

Saat ini, konsensus Gasper Ethereum menggunakan arsitektur slot dan epoch. Setiap 12 detik ada satu slot, di mana sebagian validator memberikan suara pada kepala rantai, dan semua validator memiliki kesempatan untuk memberikan suara sekali dalam 32 slot (6,4 menit). Suara-suara ini ditafsirkan kembali sebagai pesan dalam algoritma konsensus yang mirip dengan PBFT, dan setelah dua epoch (12,8 menit), memberikan jaminan ekonomi yang kuat yang disebut finalitas.

Dalam beberapa tahun terakhir, metode ini semakin tidak populer, terutama karena dua alasan: pertama, itu terlalu rumit, ada banyak masalah interaksi antara mekanisme pemungutan suara slot ke slot dan mekanisme finalitas epoch ke epoch; kedua, waktu tunggu 12,8 menit terlalu lama.

Finalitas Slot Tunggal (SSF) menggantikan arsitektur ini melalui mekanisme serupa Tendermint, di mana blok N sudah dipastikan sebelum blok N+1 dihasilkan. Perbedaan utama dengan Tendermint adalah mempertahankan mekanisme "kebocoran tidak aktif", yang memungkinkan rantai untuk terus beroperasi dan pulih saat lebih dari 1/3 validator offline.

Tantangan utama SSF adalah setiap staker perlu mengirimkan dua pesan setiap 12 detik, yang merupakan beban besar bagi rantai. Meskipun ada beberapa ide inovatif seperti Orbit SSF yang dapat meringankan masalah ini, pengguna masih perlu menunggu 5-20 detik.

Pra-konfirmasi Rollup

Ethereum selalu mengikuti peta jalan yang berfokus pada rollup, merancang lapisan dasar (L1) untuk mendukung ketersediaan data dan fungsi lainnya untuk digunakan oleh protokol L2. Ini menciptakan pemisahan fokus di dalam ekosistem: L1 berfokus pada ketahanan terhadap sensor, keandalan, dan stabilitas, sementara L2 lebih langsung ditujukan kepada pengguna.

Secara teori, menciptakan jaringan pengurut terdesentralisasi adalah tanggung jawab L2. Sekelompok kecil validator mungkin menandatangani blok setiap beberapa ratus milidetik, dan kemudian mempertaruhkan aset di belakang blok-blok ini. Header dari blok L2 ini akhirnya akan dipublikasikan ke L1.

Namun, meminta semua L2 untuk melakukan pengurutan desentralisasi tampaknya tidak terlalu adil, ini setara dengan meminta rollup untuk menyelesaikan pekerjaan yang hampir sama dengan menciptakan L1 yang baru. Oleh karena itu, ada yang mengusulkan agar semua L2 (dan L1) menggunakan mekanisme pra-konfirmasi yang dibagikan dalam rentang Ethereum: pra-konfirmasi dasar.

Konfirmasi Awal Dasar

Metode pra-konfirmasi dasar mengasumsikan bahwa pengusul Ethereum adalah peserta yang sangat kompleks terkait MEV. Ini memanfaatkan kompleksitas ini dengan memberi insentif kepada pengusul tersebut untuk menerima tanggung jawab dalam menyediakan layanan pra-konfirmasi.

Metode ini menciptakan protokol yang distandarisasi, di mana pengguna dapat memberikan biaya tambahan untuk mendapatkan jaminan instan bahwa transaksi akan dimasukkan dalam blok berikutnya, serta pernyataan tentang hasil eksekusi transaksi tersebut. Jika pengusul melanggar janji, mereka dapat dikenakan denda.

Mekanisme ini tidak hanya memberikan jaminan untuk transaksi L1, tetapi juga untuk rollup "berbasis", semua blok L2 adalah transaksi L1, sehingga juga dapat memberikan pra-konfirmasi untuk L2 mana pun.

Prospek Masa Depan

Misalkan finalitas slot tunggal telah dicapai, menggunakan teknologi serupa Orbit untuk mengurangi jumlah validator yang menandatangani setiap slot, sambil juga membuat kemajuan dalam mengurangi batas minimum staking 32 ETH. Durasi slot mungkin meningkat menjadi 16 detik, kemudian menggunakan pra-konfirmasi rollup atau pra-konfirmasi dasar untuk memberikan konfirmasi yang lebih cepat kepada pengguna. Akhirnya, kita mendapatkan era baru - arsitektur slot.

Arsitektur seperti ini tampaknya sulit untuk dihindari, karena waktu yang dibutuhkan untuk mencapai konsensus yang kira-kira sama tentang sesuatu lebih singkat daripada waktu yang dibutuhkan untuk mencapai "finalitas ekonomi" maksimum. Alasan termasuk jumlah node dan "kualitas" node. Jika kita dapat mengandalkan subset node yang terdesentralisasi untuk mencapai kesepakatan yang mendekati (masih menggunakan kumpulan validator lengkap untuk menentukan finalitas), kita dapat mengurangi waktu konfirmasi menjadi sekitar 2 detik.

Oleh karena itu, eksplorasi ruang desain masih memiliki nilai, terutama dalam arah di mana terdapat pemisahan perhatian yang lebih kuat antara dua mekanisme.

Pilihan Strategi L2

L2 saat ini memiliki tiga strategi yang wajar:

1. Secara teknis dan konseptual "berbasis" ETH, mengoptimalkan atribut teknis dan nilai dasarnya.
2. Menjadi "server dengan kerangka kerja blockchain", memaksimalkan efisiensi server dan keamanan blockchain.
3. Metode kompromi: jaringan cepat dengan sekitar seratus node, Ethereum menyediakan interoperabilitas dan keamanan tambahan.

Untuk beberapa aplikasi, waktu blok 12 detik sudah cukup. Untuk aplikasi lainnya, satu-satunya solusi adalah arsitektur epoch-slot. Masalah kunci adalah seberapa baik arsitektur epoch-slot asli Ethereum dapat bekerja? Jika dapat menurunkan waktu slot menjadi 1 detik, maka ruang untuk strategi ketiga akan menjadi sangat kecil.

Saat ini, kami masih jauh dari jawaban akhir untuk masalah-masalah ini. Tingkat kompleksitas proposer blok masih ada ketidakpastian, desain baru seperti Orbit SSF juga layak untuk dieksplorasi lebih lanjut. Semakin banyak opsi yang kami miliki, semakin baik kami dapat melayani pengguna L1 dan L2, serta menyederhanakan pekerjaan pengembang L2.