Evolusi "detik" Ethereum: Dari konfirmasi cepat hingga kompresi penyelesaian, bagaimana Interop menghilangkan waktu tunggu?

Penulis: imToken

Jika Anda sering melakukan lintas rantai di antara Base, Arbitrum, atau Optimism, Anda pasti merasakan semacam “perasaan terputus” yang halus.

Meskipun transaksi L2 tunggal hampir selesai dalam hitungan detik, ketika Anda mencoba memindahkan aset dari rantai A ke rantai B, seringkali Anda harus menunggu beberapa menit bahkan lebih lama. Ini bukan karena L2 sendiri tidak cukup cepat, tetapi karena dalam proses tradisional, transaksi yang melibatkan lintas lapisan dan lintas rantai harus melalui jalur yang panjang dan ketat:

L2 sorter → dikirim ke L1 → mencapai konsensus dan finalitas, secara keseluruhan, dalam arsitektur Ethereum saat ini, finalitas di L1 biasanya membutuhkan dua Epoch (sekitar 13 menit). Ini memang diperlukan untuk keamanan, tetapi untuk interoperabilitas (Interop), waktu tunggu ini terasa terlalu lambat.

Pada akhirnya, jika mengikuti visi besar Ethereum, di masa depan akan ada ratusan bahkan ribuan L2 yang tidak seharusnya menjadi pulau eksekusi yang terisolasi, melainkan bekerja secara kolaboratif seperti satu kesatuan. Masalah utamanya adalah apakah kita bisa mempersingkat waktu tunggu ini sebanyak mungkin.

Dalam konteks ini, peta jalan Interop Ethereum dalam fase percepatan (Acceleration) secara tegas mengusulkan tiga arah perbaikan yang sangat terkoordinasi: aturan konfirmasi cepat (Fast L1 Confirmation Rule), memperpendek waktu slot L1 (Shorter L1 Slots), dan mengurangi siklus penyelesaian jaringan lapis dua (Shorter L2 Settlement).

Bisa dikatakan, ini bukan sekadar optimisasi acak, melainkan sebuah rekonstruksi sistematis yang berfokus pada “konfirmasi, irama, dan penyelesaian.”

Pertama, Aturan Konfirmasi Cepat: Sebelum Finalitas, berikan sistem jawaban yang “dapat dipercaya”

Seperti diketahui, dalam arsitektur Ethereum saat ini, interval blok utama sekitar 12 detik, validator akan melakukan voting pada setiap slot terhadap status rantai saat ini, dan finalitas (Finality) tertunda beberapa slot.

Singkatnya, meskipun transaksi sudah dikemas ke dalam blok, sistem masih harus menunggu waktu yang cukup lama untuk memastikan bahwa transaksi tersebut tidak akan di-reorganisasi atau di-rollback. Saat ini, transaksi dianggap final sekitar dua Epoch (sekitar 13 menit) sebelum dapat di-rollback. Untuk sebagian besar skenario keuangan di blockchain, 13 menit tentu terlalu lama.

Lalu, bisakah kita sebelum Finality tercapai, memberikan sinyal konfirmasi yang “cukup cepat dan cukup terpercaya” kepada aplikasi dan sistem lintas rantai? Ini juga merupakan poin yang secara tegas diajukan dalam peta jalan Interop Ethereum, yaitu Project #4: Fast L1 Confirmation Rule (Aturan Konfirmasi Cepat).

Tujuan utamanya sangat langsung, yaitu memungkinkan aplikasi dan sistem lintas rantai mendapatkan sinyal konfirmasi L1 yang “kuat dan dapat diverifikasi” dalam waktu 15–30 detik, tanpa harus menunggu 13 menit penuh untuk Finality.

Secara mekanisme, aturan konfirmasi cepat ini bukan memperkenalkan proses konsensus baru, melainkan memanfaatkan voting dari attester yang terjadi di setiap slot dalam sistem PoS Ethereum. Ketika sebuah blok telah mengumpulkan cukup banyak suara dari validator yang tersebar secara acak di awal slot, bahkan sebelum masuk ke tahap finalisasi, blok tersebut dapat dianggap “dalam model serangan yang wajar, sangat kecil kemungkinannya untuk di-rollback.”

Singkatnya, tingkat konfirmasi ini tidak menggantikan Finality, tetapi menyediakan sebuah konfirmasi kuat yang diakui secara protokol sebelum Finality tercapai. Bagi interoperabilitas, ini sangat penting: Sistem lintas rantai, Intent Solver, dan dompet tidak lagi perlu menunggu finalitas mutlak, melainkan dapat secara aman melanjutkan langkah berikutnya dalam 15–30 detik berdasarkan sinyal konfirmasi protokol.

Saat ini, preconfirmation yang didorong secara besar oleh narasi Based Rollup berperan sebagai jembatan penting dalam tahap transisi ini. Logikanya sangat sederhana, bayangkan:

Ketika kita membeli tiket kereta di 12306, begitu memilih jadwal dan melakukan transaksi tanda tangan, sistem pemesanan akan memberi kita informasi preconfirmation yang menyatakan bahwa transaksi pembelian tiket (setiap transaksi) telah diterima dan sedang diproses. Saat itu, kita bisa mulai merencanakan perjalanan, menyiapkan barang bawaan, dan lain-lain. Baru setelah tiket benar-benar dikonfirmasi ke kereta dan tempat duduk (transaksi dipublikasi ke L1), kita resmi menyelesaikan transaksi pembelian dan reservasi.

Singkatnya, dalam Based Rollup, preconfirmation berarti bahwa sebelum transaksi resmi dikirim ke L1 untuk dikonfirmasi, sistem sudah berjanji akan memasukkan transaksi tersebut ke dalam blok. Ini seperti memberi pengguna sinyal konfirmasi awal, bahwa transaksi telah diterima dan sedang diproses.

“Ini saya berikan janji lisan yang kuat, dan konfirmasi final akan menyusul kemudian,” Dengan logika konfirmasi berlapis ini, peta jalan Interop Ethereum secara efektif memetakan tingkat kepercayaan yang berbeda antara “keamanan” dan “kecepatan,” membangun pengalaman interoperabilitas yang sangat mulus.

Kedua, Perpendek Slot L1: Mempercepat siklus “detak jantung” Ethereum

Sejalan dengan aturan konfirmasi cepat yang merupakan rekonstruksi logika di tingkat konsensus, ada perubahan yang lebih mendasar dan bersifat fisik—memperkecil ukuran Slot.

Jika konfirmasi cepat adalah “menulis cek tertunda” sebelum mencapai finalitas, maka memperpendek waktu Slot L1 adalah mempercepat siklus penyelesaian buku besar. Dalam peta jalan Interop, target tahap Project #5 sangat jelas: mengurangi waktu Slot utama Ethereum dari 12 detik menjadi 6 detik.

Perubahan “setengah” ini tampaknya sederhana, tetapi akan memicu reaksi berantai di seluruh rantai. Semakin pendek Slot, semakin cepat transaksi masuk ke blok, didistribusikan ke validator, dan dikonfirmasi, sehingga mengurangi latensi keseluruhan protokol.

Dampaknya terhadap pengalaman pengguna juga langsung terasa, termasuk percepatan konfirmasi interaksi L1 (seperti transfer ETH), pengiriman status L2 ke L1 yang lebih cepat, bahkan kombinasi Slot yang lebih pendek dan aturan konfirmasi cepat akan menciptakan “feedback on-chain hampir waktu nyata,” yang berarti DApp, dompet, dan protokol lintas rantai dapat membangun pengalaman konfirmasi dalam hitungan detik.

Bagi protokol interoperabilitas lintas rantai, pengurangan waktu ini juga berarti peningkatan efisiensi dana. Saat ini, bridge lintas rantai atau market maker harus menanggung risiko “dana dalam perjalanan” selama beberapa menit bahkan lebih lama saat mengatur aset antar rantai. Untuk mengimbangi risiko fluktuasi ini, mereka biasanya mengenakan biaya yang lebih tinggi.

Ketika siklus penyelesaian L1 dipercepat dan perputaran dana meningkat dua kali lipat, penggunaan modal dalam perjalanan ini akan berkurang secara signifikan. Hasilnya jelas: biaya gesekan yang lebih rendah, biaya pengguna yang lebih rendah, dan penundaan penerimaan yang lebih singkat, yang akan sangat mendorong pengembang dan pengguna kembali ke lapisan penyelesaian L1 yang aman, bukan bergantung pada relay pihak ketiga yang rapuh.

Tentu saja, meningkatkan frekuensi “detak jantung” dua kali lipat bukan hal yang mudah. Beberapa tim kerja di Ethereum Foundation sedang secara paralel mendorong proyek kompleks ini:

• Analisis jaringan: Tim riset (termasuk Maria Silva dan lainnya) melakukan analisis data ketat untuk memastikan bahwa Slot yang lebih pendek tidak menyebabkan risiko reorganisasi (Reorg) yang serius karena latensi jaringan, atau menimbulkan tekanan sentralisasi pada node rumah tangga dengan bandwidth terbatas;
• Implementasi klien: Ini adalah rekonstruksi mendalam di tingkat konsensus dan eksekusi. Perlu dicatat bahwa pekerjaan ini terpisah dari EIP-7732 (penyisipan staking asli - pemisahan builder dan validator ePBS), yang berarti bahwa apapun kemajuan ePBS, rencana percepatan “heartbeat” ini dapat berjalan secara independen.

Secara keseluruhan, ketika Slot 6 detik dan aturan konfirmasi cepat digabungkan, Ethereum berpotensi memiliki “feedback on-chain hampir waktu nyata,” memungkinkan ekosistem DApp dan dompet membangun pengalaman konfirmasi dalam hitungan detik yang belum pernah ada sebelumnya.

Ketiga, Perpendek Siklus Penyelesaian L2: Membuat aset “langsung tarik dan jalan”

Dalam peta jalan Interop, Project #6: Shorter L2 Settlement adalah bagian yang paling kontroversial, tetapi juga penuh potensi imajinasi.

Dalam arsitektur saat ini, Optimistic Rollup biasanya bergantung pada periode tantangan selama 7 hari, dan bahkan ZK Rollup pun terbatas oleh kecepatan pembuatan dan verifikasi bukti. Secara jujur, desain ini sangat aman, tetapi dari sudut pandang interoperabilitas, ada masalah nyata:

Aset dan status terkunci “waktu” di antara rantai. Ini tidak hanya meningkatkan biaya lintas rantai, tetapi juga secara signifikan meningkatkan beban rebalancing Solver, yang akhirnya tercermin dalam biaya pengguna yang lebih tinggi. Oleh karena itu, memperpendek siklus penyelesaian dianggap sebagai salah satu kunci keberhasilan skalabilitas Interop. Fokus utama saat ini meliputi:

• Bukti real-time ZK: Dengan percepatan perangkat keras dan kemajuan bukti rekursif, waktu pembuatan bukti sedang dipercepat dari menit ke detik;
• Mekanisme penyelesaian yang lebih cepat: Misalnya, memperkenalkan model penyelesaian 2-dari-3 yang aman;
• Lapisan penyelesaian bersama: Membiarkan beberapa L2 melakukan perubahan status di bawah semantic penyelesaian yang seragam, bukan “penarikan—menunggu—deposit” secara berurutan;

Tentu saja, dalam diskusi Interop, ada pertanyaan mendasar yang tidak bisa dihindari: jika untuk mempercepat konfirmasi lintas rantai, tantangan penyelesaian dipercepat dari 7 hari menjadi 1 jam, apakah ini memberi celah bagi penyerang untuk melakukan kejahatan?

Secara teori, kekhawatiran ini bukan tanpa dasar. Berbeda dari “peninjauan keras” (validator kolektif melakukan kejahatan), yang lebih perlu diwaspadai adalah serangan lunak yang dipimpin oleh pembangun blok: penyerang tidak perlu mengendalikan konsensus, cukup menekan terus-menerus validator lain agar transaksi penting tidak masuk ke rantai.

Menariknya, satu-satunya analisis ekonomi sistematis tentang skenario ini berasal dari makalah Offchain Labs berjudul “Economic Censorship Games in Fraud Proofs” yang dipublikasikan Februari 2025. Makalah ini membangun tiga model, dari yang paling pesimis hingga yang relatif optimis, yaitu:

• G¹: Isi blok sepenuhnya ditentukan oleh penawar tertinggi;
• G¹ₖ: Beberapa validator selalu membangun blok secara lokal;
• Gᵐ: Beberapa validator bersama-sama memutuskan isi blok, selama salah satu dari mereka memilih transaksi pembela.

Dalam praktik, karena validator bisa memilih slot kosong (miss slots), beberapa desain bahkan bisa berkurang menjadi skenario G¹ yang lebih pesimis. Oleh karena itu, makalah ini memilih analisis dari skenario terburuk.

Berdasarkan asumsi ini, para peneliti mengusulkan sebuah mekanisme pertahanan yang sangat relevan—“menggunakan kekuatan kecil untuk melawan yang besar” dengan mekanisme penundaan. Inti logikanya adalah validator memiliki hak “penundaan satu klik,” artinya mereka tidak perlu menyelesaikan seluruh proses pengecekan yang rumit dalam waktu singkat, cukup dengan berhasil mengirimkan satu transaksi kunci.

Transaksi kunci ini sangat jelas fungsinya: begitu masuk ke rantai, otomatis akan memperpanjang periode tantangan dari 1 jam kembali ke 7 hari tradisional. Misalnya, jika validator menemukan ketidaksesuaian status L2, mereka tidak perlu menyelesaikan semua proses pengecekan dalam 1 jam, cukup dengan mengirimkan transaksi khusus ke L1. Transaksi ini seperti alarm pertahanan udara, secara otomatis memperpanjang periode tantangan kembali ke 7 hari.

Ini berarti penyerang akan dipaksa masuk ke dalam perang biaya yang sangat tidak seimbang—untuk mencegah transaksi ini masuk ke rantai, penyerang harus terus-menerus membayar biaya prioritas lebih tinggi dari validator, dan perlawanannya harus berlangsung selama seluruh periode tantangan.

Hasil kuantitatif dari makalah ini sangat jelas: jika seorang penyerang yang kuat berniat menghabiskan 100 miliar dolar untuk serangan pengawasan terus-menerus, maka:

• Dalam jendela 1 jam, validator cukup menyiapkan anggaran sekitar 33 juta dolar untuk melawan;
• Jika berhasil memicu mekanisme penundaan, periode tantangan diperpanjang ke 7 hari, biaya balasan validator bahkan bisa turun menjadi sekitar 20 ribu dolar;

Dengan kata lain, ini adalah keunggulan struktural yang sangat penting: biaya penyerang meningkat secara linier, sementara biaya pertahanan hanya perlu dilakukan sekali dan berhasil.

Perbedaan besar antara biaya serangan dan biaya pertahanan ini (Cost to Attack vs. Cost to Defend) memastikan bahwa bahkan jika siklus penyelesaian dipercepat secara drastis, keamanan ekonomi Ethereum tetap kokoh dan tangguh.

Bagi interoperabilitas, hal ini juga sangat penting—seperti yang disebutkan sebelumnya, konfirmasi cepat dan siklus penyelesaian yang lebih pendek tidak harus mengorbankan keamanan. Dengan desain sistem yang tepat, konfirmasi lintas rantai dalam hitungan detik dan keamanan ekonomi bisa berjalan bersamaan, setidaknya memberikan fondasi yang sangat kuat untuk mewujudkan cross-chain dalam waktu singkat.

Penutup

Mungkin ada yang bertanya, mengapa harus repot-repot mengoptimalkan delay beberapa detik atau menit ini?

Di era geek Web3, kita terbiasa menunggu, bahkan menganggap “menunggu” sebagai biaya yang harus dibayar untuk desentralisasi. Tapi, dalam perjalanan Web3 menuju arus utama, pengguna seharusnya, bahkan tidak perlu, peduli di rantai mana mereka beroperasi, apalagi menghitung logika finalitas L1.

Konfirmasi cepat, irama 6 detik, dan mekanisme pertahanan yang tidak simetris, secara esensial melakukan satu hal—menghapus variabel “waktu” dari persepsi pengguna.

Ini mengingatkan saya pada satu kalimat yang sering saya ulang: bentuk terbaik dari teknologi adalah yang membuat kompleksitas menghilang dalam konfirmasi yang sangat cepat.