Alpenglow: Penulisan Ulang Besar-Besaran Konsensus Solana

Wawasan yang Dapat Ditindaklanjuti 

• Manfaat utama Alpenglow bagi Solana adalah pengurangan waktu finalitas transaksi sebesar 100x. Bergantung pada lokasi geografis validator, waktu ini akan turun dari 12,8 detik menjadi 100–150 md, sehingga Solana dapat bersaing dengan infrastruktur Web2 yang lebih tersentralisasi dan mendukung aplikasi real-time.
• Alpenglow menyederhanakan konsensus dengan menghapus beberapa komponen lama Solana, termasuk Proof of History, Tower BFT, dan propagasi suara berbasis gossip. Sebagai pengganti Proof of History, Alpenglow memperkenalkan waktu blok tetap sebesar 400 md, yang tidak sama dengan memiliki jam yang tersinkronisasi secara global, untuk mengoordinasikan waktu di seluruh jaringan.
• Protokol ini dibangun di atas dua komponen dasar: Rotor, protokol propagasi blok yang ditingkatkan dengan memperluas dan menyempurnakan arsitektur Turbine Solana yang sudah ada; serta Votor, mekanisme pemungutan suara baru yang menggantikan Tower BFT, Proof of History, dan penggunaan gossip untuk propagasi suara.
• Seluruh aktivitas konsensus berpindah ke luar chain—sertifikat suara akan tetap ditambatkan di chain, menggantikan transaksi suara per slot dengan sistem sertifikat BLS yang ringan. Perubahan ini menghapus biaya pemungutan suara seperti yang kita kenal saat ini, yang selama ini menjadi biaya operasional utama validator, sehingga secara signifikan meningkatkan keekonomian validator bagi operator yang lebih kecil. Model ekonomi pastinya masih dalam tahap finalisasi.
• Alpenglow menawarkan model ketahanan “20+20”: keamanan tetap terjaga jika hingga 20% stake dikuasai pihak adversarial, dan liveness tetap terjaga jika 20% stake tambahan yang terpisah sedang offline atau tidak merespons. Dengan demikian, protokol dapat menoleransi kondisi jaringan yang tidak stabil maupun penuh serangan.
• Votor menggunakan sistem pemungutan suara konsensus dua tingkat yang berjalan bersamaan. Dalam jalur Fast-Finalization, jika sebuah blok memperoleh persetujuan ≥80% stake pada putaran pertama, blok tersebut langsung difinalisasi dengan Fast-Finalization Certificate. Dalam jalur Slow-Finalization, putaran kedua dimulai segera setelah sebuah blok memperoleh persetujuan ≥60% stake. Jika putaran ini mencapai persetujuan ≥60%, blok difinalisasi dengan Finalized Certificate.
• Berbeda dengan Turbine, yang mengandalkan struktur pohon berlapis dengan fanout 200, Rotor menggunakan model single-hop dengan node relay yang menangani penyebaran shred. Setiap shred dikirim sebagai satu paket berkode erasure, dan desain Rotor secara native kompatibel dengan sistem multicast seperti DoubleZero. Perlu diperhatikan bahwa Rotor kemungkinan besar akan menjadi SIMD terpisah dari Votor.
• Alpenglow saat ini diperkirakan akan diluncurkan ke mainnet Solana pada awal tahun depan. Implementasi referensi protokol ini tersedia di Github.

Pendahuluan

Algoritma konsensus Alpenglow merupakan perombakan paling signifikan terhadap protokol inti Solana hingga saat ini. Dengan memanfaatkan kemajuan terbaru dalam riset blockchain, Alpenglow merancang ulang secara mendasar cara konsensus dicapai di seluruh jaringan.

Alpenglow dikembangkan oleh divisi riset baru Anza, yang dipimpin Profesor Roger Wattenhofer dari ETH Zurich, salah satu institusi ilmu komputer berperingkat tertinggi di dunia. Sebagai pakar terkemuka dalam sistem terdistribusi, Profesor Wattenhofer sebelumnya turut menulis makalah tahun 2024 Menghentikan Blockchain Solana dengan Epsilon Stake, yang mengungkap potensi kerentanan liveness dalam protokol konsensus Solana saat ini. Di Anza, Profesor Wattenhofer bekerja bersama mantan mahasiswa PhD-nya, Kobi Sliwinski dan Quentin Kniep.

Tugas tim ini adalah merancang ulang algoritma konsensus Solana agar berperforma lebih tinggi dan dapat dibuktikan kebenarannya, sekaligus mempertahankan arsitektur berbasis Turbine. Alpenglow menggabungkan banyak kemajuan terbaru dalam riset sistem terdistribusi, terutama dalam menangani perilaku jaringan adversarial.

Nama Alpenglow berasal dari kata bahasa Jerman Alpenglühen, yang berarti “cahaya Alpen.” Istilah ini merujuk pada cahaya mencolok yang terlihat di puncak gunung saat matahari terbit atau terbenam, sekaligus menjadi penghormatan kepada asal-usul protokol ini di Swiss.

Apa manfaat Alpenglow?

Berikut adalah ringkasan umum manfaat utama yang diharapkan dari Alpenglow. Masing-masing akan dibahas lebih mendalam di bagian selanjutnya dari artikel ini.

Finalitas Lebih Cepat

Manfaat utama Alpenglow bagi Solana adalah pengurangan waktu finalitas transaksi sebesar 100x, yaitu waktu yang dibutuhkan hingga transaksi pengguna berakar di jaringan blockchain. Bergantung pada lokasi geografis validator, waktu ini akan turun dari 12,8 detik menjadi 100–150 md, sehingga Solana dapat bersaing dengan infrastruktur Web2 yang lebih tersentralisasi dan mendukung aplikasi real-time.

• Finalitas Solana Saat Ini: 12,8 detik 
• Konfirmasi Optimistis Solana Saat Ini: 500–600 milidetik
• Finalitas Alpenglow: 150 milidetik (nilai median)*
• Finalitas Kompetitor Tercepat: 400 milidetik (berdasarkan laporan sendiri)

*berfluktuasi berdasarkan geografi dan distribusi cluster.

Tidak Ada Lagi Transaksi Suara

Dengan Alpenglow, seluruh aktivitas konsensus berlangsung di luar chain. Hal ini akan mengurangi beban pada transaction processing unit (TPU) dan replay, yang tidak lagi perlu memproses transaksi suara.

Alpenglow juga akan meningkatkan secara signifikan keekonomian bagi validator yang lebih kecil. Biaya transaksi suara merupakan pengeluaran operasional terbesar bagi validator. Dengan menghapus biaya ini melalui pemungutan suara di luar chain, biaya partisipasi turun drastis, sehingga validator yang lebih kecil lebih layak beroperasi dan hambatan untuk berkontribusi terhadap keamanan jaringan menjadi lebih rendah.

Keuntungan lainnya mencakup logika commitment yang lebih sederhana dan pertumbuhan ledger yang lebih lambat, karena transaksi suara tidak lagi menggunakan ruang blok atau memperbesar ukuran ledger.

Perubahan ini juga menghilangkan ambiguitas dalam metrik transaksi per detik (TPS) Solana. Saat ini, TPS sering dilaporkan dengan dua cara: TPS total, yang mencakup transaksi suara, dan TPS sebenarnya, yang hanya menghitung transaksi non-suara.

Protokol yang Lebih Ramping

Alpenglow merampingkan proses pencapaian konsensus dengan menghapus beberapa komponen lama Solana, termasuk Proof of History, Tower BFT, dan penggunaan gossip untuk propagasi suara. Meski mengadopsi kemajuan mutakhir dari riset blockchain modern, Alpenglow melakukannya tanpa menambah kompleksitas yang tidak perlu.

Votor dan Rotor milik Alpenglow membangun fondasi bagi peningkatan mendatang, seperti eksekusi asinkron dan beberapa pemimpin secara bersamaan (MCL), sehingga Solana siap meraih peningkatan performa dan evolusi protokol lebih lanjut.

Apa mekanisme konsensus Solana saat ini?

Proof of History

Proof of History (PoH) bukan algoritma konsensus. Sebaliknya, PoH adalah alat yang membantu mencapai konsensus. Kebingungan ini mungkin muncul karena penamaannya—”Proof of X” yang bagi mereka yang memahami Proof of Work dan Proof of Stake menyiratkan bahwa objek tersebut merupakan algoritma konsensus. Akan lebih tepat jika PoH dianggap sebagai algoritma “pra-konsensus” yang merampingkan konsensus melalui pemrosesan transaksi yang efisien.

Secara umum, PoH adalah jam terdesentralisasi yang digunakan untuk membuktikan waktu dalam jaringan adversarial. Secara lebih formal, PoH adalah fungsi stempel waktu kriptografis yang memungkinkan node menyepakati urutan peristiwa tanpa saling berkomunikasi. PoH menggunakan fungsi hash sekuensial yang tahan preimage untuk membuat rantai hash. Pemimpin menerapkan stempel waktu pada blok menggunakan hash tersebut untuk membuktikan bahwa durasi waktu tertentu telah berlalu. Karena semua hash dirangkai, PoH menyediakan catatan historis yang membuktikan bahwa data ada pada waktu tertentu. 

Pendekatan ini berbeda dari chain lain, yang sering menentukan urutan blok selama konsensus lalu menambahkan stempel waktu setelahnya. Di Solana, jam yang dapat diverifikasi secara kriptografis dibuat terlebih dahulu, transaksi dialirkan mengikuti jam tersebut, lalu konsensus memverifikasi log transaksi yang telah diurutkan sebelumnya. Perangkaian hash membuat urutan waktunya tidak dapat disangkal. 

Tower BFT

Tower BFT beroperasi setelah shred (yaitu, blok parsial) dipropagasikan ke validator lain dan jaringan melakukan replay untuk menentukan apakah blok tersebut menjadi bagian dari ledger. Secara konseptual, Tower BFT adalah algoritma konsensus mirip pBFT yang dirancang untuk memanfaatkan jam Proof of History di seluruh jaringan. Alih-alih memerlukan putaran konsensus sinkron untuk setiap slot, validator melakukan pra-commit terhadap slot mendatang berdasarkan urutan Proof of History yang telah diamati, sehingga produksi blok dapat berlangsung terus-menerus.

Validator memberikan satu transaksi suara per slot, yang ditandatangani oleh akun suara mereka. Suara pada fork tertentu akan dikenai lockout (yaitu, timeout) untuk fork tersebut. Lockout adalah periode slot yang ditentukan, saat validator tidak dapat memberikan suara pada fork lain. Tujuannya adalah memaksa validator berkomitmen pada satu fork dan meningkatkan lockout secara eksponensial jika ingin berpindah fork. Setiap suara membawa penghitung lockout yang nilainya berlipat dua setiap kali validator memberikan suara pada slot turunannya, sehingga membentuk “menara suara” berisi berbagai commitment. Jadi, jika validator memberikan suara untuk blok X, validator tersebut tidak dapat memberikan suara pada fork yang bertentangan selama sejumlah slot mendatang yang terus meningkat secara eksponensial (misalnya, 1, 2, 4, 8…). Pelanggaran lockout dapat dibuktikan dan dihukum, meski slashing belum diterapkan di mainnet.

Solana mencapai dua tingkat finalitas dalam Tower BFT: konfirmasi optimistis dan finalitas deterministik. 

Saat blok baru diproduksi dan ≥66% stake memberikan suara untuknya, blok tersebut diakui sebagai bagian dari fork utama atau kanonis. Ini disebut konfirmasi optimistis karena blok diberi tingkat commitment “confirmed” segera setelah supermayoritas memberikan suara. Konfirmasi optimistis diperkenalkan pada v1.3 klien Solana Labs (sekarang Agave) untuk meningkatkan UX dengan memperlakukan blok sebagai telah difinalisasi sebelum finalisasi formal terjadi.

Sejak blok genesis Solana, belum pernah ada blok yang dikonfirmasi secara optimistis mengalami rollback. Untuk melakukannya, setidaknya sepertiga dari total stake harus mengungkap fork yang bertentangan setelah 66% sebelumnya memberikan suara secara jujur. Dengan kata lain, setelah jumlah konfirmasi optimistis suatu blok mencapai ~87% stake, pihak adversarial memerlukan ≥20% dari stake yang sama untuk melakukan tanda tangan ganda, suatu tindakan yang terbukti dapat dikenai slashing. Meski bukan finalitas absolut dalam pengertian teori konsensus yang ketat, konfirmasi optimistis memberikan jaminan kuat dalam praktiknya. Blok ini dapat dianggap telah difinalisasi untuk hampir semua kasus penggunaan—itulah sebabnya finalitas Solana umumnya disebut 500–600 milidetik untuk tujuan praktis.

Finalitas deterministik sejati mengharuskan blok mencapai lockout maksimum dalam menara suara, yang berarti terdapat 32 suara bertumpuk yang mengonfirmasinya. Artinya, harus ada 32 blok tambahan yang dibangun di atas blok tersebut agar dapat dianggap “finalized” atau berakar di jaringan. Waktu yang dibutuhkan blok untuk mencapai finalitas deterministik adalah ~12,8 detik, berdasarkan persyaratan 32 slot dan waktu slot ~0,4 detik. Finalitas deterministik tercapai setelah kedalaman suara lockout membuat rollback mustahil dilakukan.

Apa keterbatasan mekanisme konsensus Solana saat ini?

Proof of History dan Tower BFT membantu Solana mencapai throughput tinggi dan konfirmasi optimistis yang cepat. Namun, desain ini memiliki sejumlah keterbatasan terkait biaya, latensi, liveness, dan operasional validator.

Overhead dan Biaya Pemungutan Suara yang Tinggi

Setiap validator harus terus memberikan suara pada setiap slot untuk berkontribusi pada konsensus. Suara merupakan transaksi yang berinteraksi dengan program suara, menggunakan sumber daya jaringan, dan membayar biaya. 

Sekitar tiga perempat transaksi di Solana adalah transaksi suara, yang menimbulkan overhead jaringan signifikan sekaligus biaya nyata bagi validator di setiap slot. Ketergantungan yang tidak perlu pada pemungutan suara tanpa henti ini menghasilkan overhead dan biaya tinggi yang meningkat seiring jumlah slot yang diproses dan jumlah validator dalam cluster. 

Latensi Finalitas

Meski konfirmasi optimistis berlangsung cepat, finalitas deterministik tidak demikian. Waktu ~12,8 detik tergolong lambat dibandingkan protokol konsensus yang lebih baru seperti Mysticeti milik Sui, yang mengklaim waktu finalitas ~500 md. Hal ini menimbulkan masalah bagi aplikasi seperti bursa yang memerlukan kepastian mutlak dalam operasinya. Dalam praktiknya, pengguna memercayai blok yang telah dikonfirmasi. Namun, jaringan tetap perlu mempertahankan riwayat fork yang panjang untuk mengantisipasi kemungkinan reorg kecil sebelum finalisasi. 

Kesenjangan antara konfirmasi optimistis dan latensi deterministik merupakan sebuah kompromi: Tower BFT mengutamakan liveness dengan jendela kontingensi fork yang singkat, tetapi mengorbankan kecepatan finalitas. Bahkan tanpa serangan atau bug konsensus apa pun, finalitas ~12,8 detik jauh tertinggal dibandingkan chain dengan finalitas cepat dan infrastruktur Web2 yang sudah ada.

Liveness dan Toleransi terhadap Partisi Jaringan

Tower BFT mengharuskan supermayoritas validator tetap online dan responsif agar dapat mengonfirmasi serta memfinalisasi blok baru. Konsensus dapat terhenti jika lebih dari sepertiga stake offline atau jaringan mengalami partisi parah. Solana mungkin masih memproduksi blok dengan mengutamakan liveness, tetapi jaringan dapat gagal mencapai ambang suara untuk mengonfirmasi blok tersebut secara optimistis. Dalam skenario terburuk, seperti yang terlihat pada gangguan Solana baru-baru ini, validator yang terjebak menunggu suara atau tidak dapat memproses fork optimistis dapat memicu penghentian jaringan yang memerlukan restart terkoordinasi.

Ini merupakan keterbatasan klasik konsensus BFT. Solana tidak memiliki toleransi bawaan untuk sebagian besar validator yang tidak merespons sementara waktu. Karena itu, liveness Solana terganggu dalam kondisi ekstrem karena protokol tidak dapat menangani penurunan di bawah ambang supermayoritas konsensus dengan baik. Tower BFT harus terus memproduksi blok saat kurang dari 60% stake online. Akibatnya, blok tersebut tidak akan pernah mencapai konfirmasi optimistis dan mungkin mengalami rollback.

Kompleksitas Operasional Validator

Tower BFT menuntut banyak hal dari validator: transaksi suara terus-menerus, jaringan yang andal, peningkatan klien, menghindari status delinquent, dan mempertahankan “status menara.” Jika validator melakukan restart atau kehilangan status menara terbarunya, validator tersebut berisiko memberikan suara yang melanggar commitment lockout sebelumnya, sehingga kehilangan kredit suara.

Ketergantungan protokol pada hashing berkelanjutan dari Proof of History dan propagasi gossip untuk suara membuat validator harus bekerja keras mengikuti waktu slot Solana yang sebesar ~400 md. Persyaratan hardware Solana yang tinggi, meski terus menurun seiring waktu, juga tidak dapat diabaikan. Selain itu, terlepas dari jumlah stake, semua validator harus memberikan suara pada setiap slot untuk memaksimalkan imbalan. Artinya, sebagian besar validator kecil membayar biaya dan menanggung beban kerja yang sama dengan validator besar. Karena slot pemimpin dialokasikan secara proporsional terhadap stake, validator dengan stake lebih besar memproduksi lebih banyak blok dan dengan demikian menerima lebih banyak biaya suara yang dibayarkan validator lain. Hal ini menciptakan aliran nilai melingkar, dengan biaya suara yang secara efektif mendistribusikan kembali modal kepada validator dengan stake lebih besar.

Selain itu, mekanisme konsensus Solana saat ini membuat replay blok duplikat sangat kompleks karena klien harus mengelola beberapa kandidat untuk slot yang sama. Sistem sertifikat Votor menjamin bahwa setiap slot melakukan commit pada satu hash atau skip eksplisit, sehingga replay blok duplikat menjadi mudah.

Terlihat jelas bahwa desain Tower BFT, meski inovatif, menghasilkan kompleksitas operasional validator yang cukup besar.

Bagaimana Cara Kerja Alpenglow?

Alpenglow dibangun di atas dua komponen inti:

• Rotor: protokol propagasi blok yang ditingkatkan, dibangun di atas dan menyempurnakan arsitektur Turbine yang sudah ada.
• Votor: protokol pemungutan suara baru yang menggantikan Tower BFT, propagasi suara berbasis gossip, dan Proof of History untuk partisipasi konsensus.

Pada bagian berikut, kita akan membahas kedua komponen ini secara mendetail.

Rotor: Lapisan Penyebaran Data Baru

Rotor adalah protokol propagasi blok yang ditingkatkan dan dibangun di atas desain Turbine Solana yang sudah ada, dengan penyempurnaan utama pada efisiensi dan kesederhanaan. Berbeda dengan Turbine, yang menggunakan struktur pohon berlapis dengan fanout 200, Rotor menggunakan model single-hop (2δ). 

Blok dibagi menjadi slice, lalu setiap slice dikodekan menjadi beberapa shred menggunakan kode erasure Reed-Solomon. Untuk memastikan keaslian shred, pemimpin membuat pohon Merkle dari hash shred dan menandatangani root-nya. Setiap shred menyertakan jalurnya dalam pohon ini dan tanda tangan pemimpin.

Setiap shred dikirim langsung ke node relay. Relay kemudian menyiarkan shred mereka ke semua node dalam jaringan, dengan pemimpin berikutnya sebagai penerima pertama. Pendekatan satu lapisan ini mengurangi latensi dan menyederhanakan jalur propagasi. Pendekatan ini juga ternyata sangat cepat:

Pemimpin dan relay shred dipilih melalui sampling berbobot stake, yang berarti setiap node bertanggung jawab mengirim data secara proporsional terhadap stake-nya. Berkat pengodean erasure, node hanya perlu menerima sebagian shred untuk merekonstruksi slice blok asli.

Perbedaan penting dari Turbine adalah Rotor hanya mengirim satu versi berkode erasure untuk setiap shred, sehingga tidak perlu mengirim shred data dan pemulihan secara terpisah seperti yang dilakukan Turbine. Meski redundansi (yaitu, rasio ekspansi data) tetap sama, desain ini menghilangkan berbagai manipulasi aneh terkait penerusan shred data dan memastikan kesederhanaan desain protokol.

Arsitektur Rotor juga kompatibel dengan sistem multicast seperti DoubleZero, sehingga memberikan fleksibilitas dalam cara blok dikirim. Karena propagasi blok menggunakan bandwidth yang signifikan (saat ini, validator besar mendekati 150.000 paket keluar per detik), Rotor memperkenalkan model yang memberikan imbalan kepada relay karena mendistribusikan data, sehingga insentif selaras untuk mendukung performa jaringan.

Whitepaper Alpenglow tidak menetapkan mekanisme konkret untuk menghitung atau mendistribusikan imbalan. Namun, whitepaper tersebut menyebutkan bahwa imbalan Rotor harus memperhitungkan bandwidth yang digunakan, dan node yang me-relay lebih banyak data diharapkan menerima bagian imbalan yang lebih besar.

Apa itu Blokstor?

Blokstor adalah tempat node menyimpan dan mengelola data blok yang diterima dari Rotor. Secara lebih formal, Blokstor adalah struktur data yang mengelola penyimpanan slice. Saat shred diterima, isinya ditambahkan ke Blokstor jika memenuhi sejumlah kondisi, termasuk:

• Blokstor belum berisi shred untuk indeks tersebut
• Tanda tangan pemimpin yang valid
• Jalur pohon Merkle yang valid

Blokstor memancarkan peristiwa "Block(slot(b), hash(b) hash(parent(b)))" saat menerima blok lengkap pertama b untuk slot(b). Blokstor juga dapat menjalankan prosedur perbaikan untuk mengumpulkan dan menyimpan blok alternatif bagi slot yang sama. Saat sebuah blok difinalisasi, Blokstor hanya boleh menyimpan blok tersebut dalam slot yang bersangkutan.

Votor: Mesin Pemungutan Suara dan Finalisasi Baru

Votor adalah mesin pemungutan suara dan finalisasi baru milik Aplenglow, yang menggantikan Tower BFT untuk melakukan notarisasi dan finalisasi blok. Votor terinspirasi oleh rangkaian riset Simplex untuk meningkatkan efisiensi dan kesederhanaan, lalu menerapkannya dalam konteks Proof of Stake. 

Simplex menunjukkan bahwa kesepakatan Byzantine yang efisien dapat dicapai dalam pengaturan Proof of Stake dengan pemimpin bergilir menggunakan pesan yang sangat kecil, asalkan terdapat batas atas yang ketat untuk penundaan jaringan. Berdasarkan wawasan ini, Votor mencapai konsensus dalam satu atau dua putaran.

Secara umum, Votor memastikan bahwa untuk setiap slot, terdapat skip certificate yang menunjukkan bahwa slot tersebut dilewati, atau blok ternotarisasi yang dibangun di atas chain kanonis dari blok-blok ternotarisasi. Agar dapat dinotarisasi, sebuah blok harus memiliki sertifikat yang valid. Alih-alih membanjiri gossip dengan suara, validator menyiarkan pesan suara ringan ke sekumpulan peer berbobot stake sebagai semacam mesh “pengiriman langsung”, bukan melalui gossip Solana tradisional. Setiap node dapat mengagregasi tanda tangan ini menjadi sertifikat menggunakan skema tanda tangan Boneh–Lynn–Shacham (BLS) setelah kuorum tercapai. Hal ini menghilangkan kebutuhan akan transaksi suara per slot, karena header sertifikat teragregasilah yang ditambatkan di chain.

Bagaimana cara kerja mekanisme pemungutan suara Votor?

Votor menggunakan mekanisme pemungutan suara bertingkat dan bersamaan yang dibagi menjadi dua jalur pemungutan suara:

• Fast-Finalization: Jika blok yang diusulkan memperoleh persetujuan ≥80% stake pada putaran pemungutan suara pertama, blok tersebut langsung difinalisasi dan Fast-Finalization Certificate diterbitkan. Finalisasi satu putaran ini dimungkinkan karena 80% stake jauh melampaui ambang supermayoritas, sehingga putaran kedua tidak diperlukan untuk finalisasi.
• Slow-Finalization: Jika putaran pertama memperoleh persetujuan <80% stake tetapi ≥60%, Votor segera memulai putaran pemungutan suara kedua. Setelah putaran kedua ini mencapai persetujuan ≥60% stake, Finalized Certificate diterbitkan.

Kedua jalur berjalan bersamaan, dan jalur pertama yang mencapai ambangnya akan memfinalisasi blok. Segera setelah pemimpin selesai menerima blok induk, pemimpin dapat mulai mengirim blok berikutnya sementara suara masih dikumpulkan. Dengan demikian, satu blok diproduksi setiap ~400 md, sama seperti yang dijamin konsensus lama Solana. Desain ini memastikan bahwa jika putaran pertama gagal memperoleh persetujuan ≥80% stake, Votor beralih ke putaran kedua. Desain ini juga memastikan dua blok yang bertentangan tidak dapat sama-sama mencapai finalitas karena adanya tumpang tindih stake.

Apa itu struktur data Pool milik Votor?

Pool adalah struktur data yang dikelola setiap node dan berfungsi sebagai ledger lokal untuk aktivitas pemungutan suara serta pembuatan sertifikat. Struktur ini menyimpan suara yang diterima untuk setiap slot dan setiap node. Setelah cukup banyak suara diterima, sertifikat yang sesuai akan dibuat. Saat sertifikat yang baru diterima atau dibuat sendiri ditambahkan ke Pool, sertifikat tersebut disiarkan ke semua node lainnya. 

Meski beberapa validator dapat membuat sertifikat pada waktu yang hampir bersamaan, sertifikat apa pun yang memenuhi ambang kuorum secara fungsional setara untuk konsensus, terlepas dari validator tertentu yang disertakan dalam kumpulan tanda tangan. Satu-satunya pengecualian adalah Finalized Certificate, karena mungkin terdapat hingga tiga sertifikasi berbeda yang perlu diedarkan. Tidak pernah ada lebih dari empat sertifikat unik dari semua jenis untuk satu slot, dan setiap sertifikat unik hanya disiarkan satu kali. Pendekatan ini mencegah spam suara sekaligus memungkinkan setiap node jujur membuat dan membagikan sertifikat begitu Pool menunjukkan tercapainya kuorum.

Poin-Poin Utama

Suara dialirkan sebagai satu paket UDP ke semua validator, yang menyimpan suara yang diterima untuk setiap slot dan setiap node. Notarisasi dan finalitas blok tertentu dalam Votor ditentukan oleh tiga kondisi berikut:

• Persetujuan ≥80% stake pada putaran pemungutan suara pertama.
• Persetujuan ≥60% stake pada putaran pemungutan suara pertama dan kedua.
• Validator menerima sertifikat valid dari validator lain yang menyatakan blok telah difinalisasi.

Tidak Ada Lagi Proof of History

Karena Rotor mempropagasikan data blok dalam satu hop dan Votor memiliki target batas atas latensi sebesar ~150 md (akan dibahas lebih mendalam di bagian berikutnya), Solana tidak lagi memerlukan jam terdesentralisasi. Jam lokal sederhana sudah cukup. Alpenglow menggantikan Proof of History dengan timer timeout lokal.

Bagaimana cara kerja mekanisme timeout Votor?

Dalam praktiknya, sistem timeout bekerja sebagai berikut:

• Jendela Pemimpin: Pemimpin akan bertanggung jawab atas jendela empat slot dengan Δblock ≈ 400 md per slot.
• Kedatangan Data atau Timeout: Begitu blok induk pemimpin dinotarisasi, setiap validator mengaktifkan timeout dan menetapkan empat tenggat sebelumnya—satu per slot—pada t = now + Δtimeout + slotIndex * Δblock, dengan Δblock ≈ 400 md. Perlu diperhatikan bahwa timer ini tidak pernah direset dan berfungsi sebagai batas atas. Jika shred suatu blok tiba tepat waktu, suara diberikan pada slot tersebut melalui pesan NotarVote, dan timeout yang tertunda tidak melakukan apa pun. Namun, jika waktu habis sebelum shred tiba, validator menganggap pemimpin tidak jujur atau delinquent dan menerbitkan SkipVote.
• Sertifikasi: Fast-Finalization atau Finalized Certificate diterbitkan untuk blok yang dinotarisasi, seperti dijelaskan di atas. Skip Certificate juga dapat diterbitkan untuk slot yang dilewati.

Alpenglow memperkenalkan sistem yang membuat setiap validator mengukur timeout secara lokal dan independen. Karena itu, Solana tidak memerlukan satu jam berbasis hash seperti Proof of History. Karena pesan hanya berupa satu paket UDP dan Rotor hanya menggunakan satu hop, batas 400 md realistis dicapai tanpa hashing. Validator tidak lagi perlu terus-menerus melakukan komputasi hash, dapat memberikan suara menolak blok tanpa dikenai lockout, dan klien alternatif seperti Firedancer tidak akan dipaksa mereplikasi implementasi Proof of History milik klien Agave.

Melewati Slot

Validator juga dapat melewati slot dengan mengirim pesan SkipVote. Jika ≥60% stake memberikan pesan SkipVote, Skip Certificate diterbitkan dan slot tersebut secara resmi dilewati. Suara skip memiliki bobot imbalan yang sama dengan suara notarisasi, sehingga validator tidak memiliki insentif untuk diam ketika pemimpin berperilaku buruk. Perlu diperhatikan bahwa hal ini dapat berubah setelah model ekonomi Alpenglow difinalisasi.

Validator mengirim SkipVote untuk slot setiap kali mereka menentukan bahwa blok untuk slot tersebut tidak dapat difinalisasi. Penyebabnya dapat berupa timeout, blok yang tidak diterima, atau produksi blok yang tidak valid maupun rusak. Jika slot pertama dalam jendela empat slot milik pemimpin memicu salah satu kondisi tersebut, validator menandai seluruh jendela sebagai bermasalah. Slot yang tersisa dalam jendela kemudian diiterasi dan SkipVote diterbitkan untuk setiap slot yang belum mereka beri suara. Dengan demikian, seluruh jendela empat slot dapat diringkas menjadi satu putaran skip. Setiap suara ini tetap berlaku untuk satu slot, tetapi karena sebagian besar validator mengirimkannya dalam lonjakan yang sama, ketiga slot tertunda mencapai ambang 60% pada waktu yang hampir bersamaan. Hal ini mencegah cluster menganggur selama tiga slot kosong tambahan sambil menunggu timeout pemimpin yang offline.

Tentu saja, hal ini menyisakan celah dalam produksi blok. Namun, ritme slot tetap berjalan tanpa gangguan berkat skip certificate yang cepat. Ini menyederhanakan pemilihan fork dan meningkatkan konsistensi karena skip certificate berfungsi sebagai “blok kosong” kanonis untuk slot tersebut, sehingga semua node jujur mengadopsi skip sebagai hasilnya. Dengan demikian, tidak ada fork yang bersaing dan skip tidak menimbulkan fork yang persisten, sehingga waktu produksi blok tetap teratur.

Imbalan Validator

Imbalan validator dalam Votor didasarkan pada partisipasi dalam pemungutan suara dan pembuatan sertifikat. Node yang berkontribusi pada konsensus dengan memberikan suara, baik mendukung (NotarVote) maupun menolak (SkipVote) suatu blok, menerima imbalan yang sama. Hal ini mendorong partisipasi jujur dan memastikan node memberikan suara berdasarkan statusnya sendiri, alih-alih mencoba memprediksi atau mengikuti mayoritas.

Implementasi imbalan yang tepat belum ditetapkan saat ini.

Tolok Ukur Performa dan Hasil Simulasi Alpenglow

Simulasi oleh Anza menunjukkan bahwa Alpenglow memfinalisasi blok dalam waktu sekitar 100–150 ms, bergantung pada apakah jalur Fast-Finalization atau Fallback (yaitu, finalisasi lambat) yang menotarisasi blok tersebut. Jalur Fast-Finalization menargetkan latensi ~100 ms, sedangkan jalur Slow-Finalization menargetkan latensi ~150 ms.

Histogram Latensi

Latensi jaringan menetapkan batas bawah fundamental bagi komunikasi dalam sistem terdistribusi apa pun. Misalnya, jika leader berada di New York dan mayoritas stake berada di Eropa, median latensi satu arah bagi sebuah node untuk mengirimkan informasi ke node jaringan lain dapat mencapai sekitar 200 milidetik. Latensi lebih rendah untuk node yang berdekatan secara geografis (misalnya, yang berada dalam pusat data atau wilayah yang sama) dan jauh lebih tinggi untuk node yang berada di Global South atau wilayah terpencil lainnya.

• Jaringan: Ini adalah latensi jaringan untuk mengirimkan 1 bit ke node lain melalui internet
• Rotor: Seberapa lambat Rotor dibandingkan dengan batas bawah ini
• Notarisasi: Waktu yang diperlukan untuk menerima suara yang telah dinotarisasi dari 60% stake (juga dapat melakukan satu putaran pemungutan suara lagi; setelah diterima, finalitas dapat dimulai)
• Finalitas: Waktu finalisasi

Finalitas Alpenglow secara keseluruhan adalah 2x batas bawah. Artinya, overhead konsensus merupakan pengali 2x terhadap batas minimum jaringan mentah. Jadi, jika hop satu arah terpanjang antara leader dan stake supermayoritas adalah, misalnya, ~70 ms (yaitu, RTT ~140 ms), finalitas jalur cepat seharusnya berada dalam rentang 120–150 ms.

Histogram latensi dari simulasi Anza menunjukkan bahwa 65% stake mencapai finalisasi dalam waktu 50 ms dari latensi jaringan mentah. Ini berarti sebagian besar validator memberikan suara hampir segera setelah data tiba.

Dengan Alpenglow, komitmen deterministik berada jauh di bawah L1 pesaing mana pun, sehingga pengalaman on-chain Solana jauh lebih mendekati layanan Web2 tradisional.

Analisis Keamanan dan Toleransi Kesalahan Alpenglow

Konsensus Alpenglow merupakan peningkatan dari konsensus BFT tradisional, yang mempertahankan ketahanan terhadap penyerang yang menguasai hingga 33% stake jaringan. Ini dinyatakan sebagai “3f + 1.” Alpenglow menurunkan batas ini menjadi 20% stake jaringan berdasarkan batas 5f + 1 yang diperkenalkan oleh Martin dan Alvisi dalam Konsensus Byzantine yang Cepat. Alpenglow menggunakan model ketahanan “20+20” yang membagi keamanan menjadi dua bagian:

• Kesalahan Byzantine ≤ 20%: Keamanan terjaga jika kurang dari 20% total stake dikuasai oleh validator yang bersifat menyerang. Nilainya sangat besar, mencapai miliaran dolar, serta akan mudah diidentifikasi dan dihukum. Karena itu, penyerang berisiko kehilangan seluruh stake mereka, sehingga serangan semacam ini tidak layak secara ekonomi.
• Fenomena Nonmalis ≤ 20%: Liveness terjaga jika paling banyak 20% total stake, terpisah dari stake penyerang, sedang offline, mengalami crash, atau tidak berpartisipasi dalam konsensus karena alasan lain. Ini mencakup gangguan jaringan, kesalahan konfigurasi, dan bug perangkat lunak. Dengan demikian, jaringan dapat terus memfinalisasi blok meskipun sebagian besar minoritas validator tidak merespons.

Keamanan

Keamanan dijamin selama total stake penyerang ≤20% dan tidak dapat menghalangi setidaknya 60% partisipasi jujur pada satu fork. Kondisi ini memastikan bahwa setiap ambang suara yang dianggap final oleh protokol (yaitu, jalur cepat satu putaran dan jalur lambat dua putaran) cukup tinggi sehingga ambang yang berkonflik pada fork lain tidak dapat tercapai. Jika validator penyerang mencoba melakukan equivocation (yaitu, memberikan suara untuk dua fork berbeda atau menghasilkan dua blok berbeda dalam slot yang sama), node jujur pada akhirnya akan menerima tanda tangan mereka yang saling berkonflik. Hal ini mudah diidentifikasi dan, idealnya, pada masa mendatang akan mengakibatkan pelanggaran yang dapat dihukum seperti slashing. 

Selain itu, jika leader mencoba menghasilkan blok yang tidak valid, validator jujur akan menolak memberikan suara untuk blok tersebut. Model komunikasi langsung Alpenglow untuk pemungutan suara menyulitkan pelaku jahat untuk mengisolasi atau melakukan eclipse terhadap node jujur dalam stake karena mereka pada akhirnya akan terungkap oleh suara mayoritas jujur. Paling jauh, leader jahat dapat memaksa konsensus masuk ke jalur yang lebih lambat atau menyebabkan penundaan satu slot, tetapi tidak dapat menghentikan atau memecah chain secara permanen.

Liveness

Liveness dijamin dalam kondisi sinkroni parsial selama ambang kesalahan dipatuhi. Artinya, setelah sejumlah penundaan jaringan, validator jujur akan dapat berkomunikasi dan mengumpulkan ≥60% stake pada suatu blok. Jika tepat 20% dari total stake sedang offline, jalur cepat mungkin masih berhasil jika semua node jujur yang tersisa memberikan suara. Jika sedikit lebih dari 20% total stake sedang offline, jaringan akan secara konsisten menggunakan jalur finalisasi lambat untuk putaran pemungutan suara kedua. Finalitas tetap dijamin, meskipun lebih lambat. Dengan demikian, kegagalan yang tidak berbahaya terutama memengaruhi performa, bukan keamanan.

Ketahanan Tinggi terhadap Crash

Alpenglow secara eksplisit dirancang dengan ketahanan tinggi terhadap crash agar dapat menangani kondisi jaringan yang berat. Artinya, Alpenglow akan tetap aman dan beroperasi dalam skenario 20% stake bersifat jahat dan 20% stake tidak merespons. 

Namun, ini bukan solusi untuk setiap kemungkinan kegagalan. Alpenglow merupakan peningkatan signifikan bagi Solana, tetapi tidak sepenuhnya menghilangkan risiko penghentian atau gangguan jaringan jika asumsinya dilanggar. ≥60% stake diperlukan untuk menghasilkan blok baru, dan ≥20% stake yang bertindak jahat dapat mencegah konsensus atau menyebabkan kesalahan. Meski demikian, dalam batas yang ditentukan, Alpenglow menjamin keamanan dan liveness dalam satu atau dua putaran pemungutan suara.

Apakah penghapusan Proof of History melemahkan keamanan?

Meskipun sangat penting bagi operasi Solana saat ini, penghapusan Proof of History tidak melemahkan keamanan secara signifikan. Seperti disebutkan sebelumnya, batas universal 400 ms menggantikan hash-clock Proof of History. Sekalipun jaringan mengalami penundaan yang signifikan, tumpang tindih stake Votor (yaitu, ≥80% untuk satu putaran dan ≥60% + ≥60% untuk dua putaran) mencegah validator jujur menyetujui dua fork yang berbeda.

Namun, hal ini mengubah jaminan liveness karena liveness bergantung pada pesan sinkroni—liveness akan terjaga selama pesan jujur tiba dalam batas penundaan ini. Penyebaran data satu hop dan suara satu paket Rotor membuat latensi tetap berada dalam batas 400 ms, bahkan saat jaringan mengalami tekanan.

Secara keseluruhan, penghapusan Proof of History akan menghilangkan ketergantungan pada penghitungan hash secara terus-menerus, sehingga meniadakan semua vektor serangan yang menghentikan hash. Seperti disebutkan di atas, hal ini juga mengubah jaminan liveness. Namun, penghapusan Proof of History tidak melemahkan keamanan secara signifikan.

Poin-Poin Utama

Alpenglow menukar sedikit penurunan toleransi Byzantine dengan finalitas deterministik di bawah satu detik, penanganan gangguan nonmalis berskala besar secara mulus, dan identifikasi validator jahat yang lebih mudah. Poin-poin ini dapat dirangkum sebagai berikut:

• Dua blok yang berkonflik tidak dapat sama-sama mencapai finalisasi kecuali ≥20% stake menandatangani keduanya, sebuah tindakan yang sangat mudah dibuktikan dan dihukum.
• Solana akan terus memfinalisasi blok selama ≥60% stake dapat berkomunikasi, meskipun stake lainnya sedang offline.
• Dalam skenario terburuk, finalitas beralih ke pemungutan suara putaran kedua dengan target latensi ~150 ms, sehingga serangan memperlambat chain sebelum mengancam keamanannya.
• Biaya untuk menembus batas Byzantine 20% sangat besar, sedangkan pelanggaran yang lebih kecil dapat dideteksi dan dihukum secara sosial maupun ekonomi setelah slashing aktif di mainnet.

Apa dampak Alpenglow terhadap validator?

Biaya pemungutan suara merupakan hambatan masuk terbesar untuk menjalankan validator Solana. Tidak ada jumlah minimum SOL yang wajib dimiliki untuk menjalankan validator. Namun, pengiriman transaksi suara pada setiap slot, yang diperlukan untuk berpartisipasi dalam konsensus, dapat menghabiskan biaya hingga ~1 SOL per hari.

Alpenglow bertujuan mengganti transaksi suara per slot dengan sistem sertifikat ringkas yang secara efektif menghapus biaya pemungutan suara seperti yang kita kenal saat ini. Setiap validator akan menyiarkan pesan suara ringan ke semua node lainnya. Setelah kuorum tercapai, node mana pun dapat menggabungkan tanda tangan tersebut menjadi sebuah sertifikat melalui skema tanda tangan BLS. Karena suara-suara ini telah digabungkan dengan BLS, hanya header sertifikat yang ditambatkan secara on-chain. Dalam praktiknya, ini akan menghapus biaya harian sebesar ~1 SOL per validator. 

Seperti disebutkan sebelumnya, dengan Alpenglow, setiap proposal blok dievaluasi melalui dua jalur pemungutan suara yang berjalan bersamaan:

• Fast-Finalization (satu putaran)
  • Terpicu ketika jumlah suara yang telah dinotarisasi untuk suatu blok dalam putaran pertama pemungutan suara mencapai ≥80% stake
  • Menghasilkan Fast-Finalization Certificate 
  • Memiliki target latensi ~100 ms
• Slow-Finalization (dua putaran)
  • Terpicu ketika jumlah suara yang telah dinotarisasi untuk suatu blok dalam putaran pertama pemungutan suara mencapai ≥60% stake
  • Menghasilkan Finalization Certificate setelah jumlah suara yang telah dinotarisasi untuk putaran kedua mencapai ≥60% stake
  • Memiliki target latensi ~150 ms

Votor menjalankan kedua jalur secara bersamaan. Artinya, kedua penghitungan diperbarui dari stream suara putaran pertama yang sama, sehingga sertifikat pertama yang melewati ambangnya akan memfinalisasi blok. Kumpulan stake yang tumpang tindih (yaitu, ≥60%) memastikan dua blok yang berkonflik tidak akan pernah sama-sama mencapai finalitas.

Konsekuensi operasional dari desain baru ini bersifat positif bagi validator:

Biaya Operasional yang Lebih Rendah 

Penghapusan biaya pemungutan suara secara signifikan menurunkan hambatan masuk bagi calon validator. Di sisi lain, biaya pemungutan suara membuat validator yang lebih kecil semakin bergantung pada imbalan inflasi selama bear market. Penghapusannya dapat membuka diskusi mendatang mengenai inflasi Solana, mengingat pemungutan suara SIMD-228 yang kontroversial. Berdasarkan implementasi Alpenglow yang saat ini sedang dibahas, pengurangan tersebut akan menurunkan jumlah minimum SOL untuk memperoleh keuntungan dari ~4.850 SOL (~800 ribu USD) menjadi ~450 SOL (~75 ribu USD), sebagaimana dihitung menggunakan Kalkulator Keuntungan Validator Cogent Crypto.

Pengelolaan Kunci yang Lebih Sederhana 

Validator Solana tidak lagi memerlukan penandatanganan suara per slot. Artinya, kunci identitas validator dapat disimpan dalam Hardware Security Module (HSM) tanpa risiko terhadap performa, sehingga secara efektif mengurangi risiko hot wallet.

Beban Jaringan Leader-Slot yang Lebih Rendah

Penggabungan satu sertifikat per blok menggantikan ribuan transaksi suara individual per epoch, sehingga mengurangi beban jaringan leader-slot. 

Tanpa Perhitungan Lock-Out

Tabel lock-out eksponensial bergaya Tower milik Solana dihapus. Kini, validator hanya perlu melacak chain sertifikat terbaru dalam memori, sehingga waktu restart menjadi lebih singkat.

Apa dampak Alpenglow terhadap penyedia RPC?

Konsekuensi operasional desain baru ini sebagian besar bersifat positif bagi penyedia RPC, meskipun beberapa di antaranya dapat menimbulkan kekhawatiran terkait skalabilitas:

Tingkat Komitmen yang Lebih Sederhana 

Tingkat finalitas baru ini akan menghapus kesenjangan historis antara tingkat komitmen confirmed (yaitu, optimistis) dan finalized (yaitu, rooted). Misalnya, ini berarti logika UX apa pun yang menunggu dua tingkat konfirmasi (misalnya, menampilkan spinner hingga finalisasi) dapat disederhanakan menjadi satu pemeriksaan sertifikat.

Ukuran Ledger yang Lebih Kecil

Dengan permintaan Solana saat ini, pertumbuhan ledger akan turun sekitar tiga perempat karena tidak adanya transaksi suara. Ini juga berarti ukuran snapshot dan arsip yang lebih kecil. Namun, mengingat target peningkatan batas CU blok yang diproyeksikan, dampaknya dalam praktik masih belum dapat dipastikan.

Hambatan Fan-Out WebSocket

Dengan Alpenglow, polling transaksi tidak lagi masuk akal karena finalitas tercapai dalam ~100–150 ms dan dikodekan dalam satu sertifikat. Akan lebih masuk akal untuk memperoleh informasi finalitas melalui kanal push yang tetap terbuka selama aplikasi, browser, atau bot aktif, serta menyiarkan setiap sertifikat baru kepada semua klien yang berlangganan. Titik masalah bergeser dari jutaan polling HTTP kecil menjadi ratusan ribu socket real-time.

Kesegaran Cache Real-Time

Cache apa pun yang menyimpan data account lebih lama dari seperempat detik berpotensi menampilkan data kedaluwarsa karena sertifikat menyelesaikan blok dalam 100–150 ms. Edge cache, CDN, dan proxy Layer 7 akan memerlukan TTL yang sangat singkat atau hook pembersihan yang mengenali sertifikat.

Bagaimana linimasa pengembangan Alpenglow?

Alpenglow secara resmi diperkenalkan dalam konferensi New York Accelerate pada akhir Mei. Fase berikutnya mencakup penerbitan Solana Improvement Document (SIMD) formal, yang akan membuka proposal untuk menerima masukan komunitas melalui GitHub, forum tata kelola Solana, dan Discord Solana Tech.

Setelah periode peninjauan komunitas, proposal akan dilanjutkan ke pemungutan suara tata kelola on-chain oleh komunitas validator. Secara paralel, desain baru ini akan menjalani pengujian ekstensif untuk memastikan performa dan keamanan.

Jika semua tahap berjalan sesuai rencana, deployment ke mainnet Solana diperkirakan berlangsung pada awal tahun depan.

Risiko dan Pertanyaan Terbuka Alpenglow

Algoritma Konsensus Baru

Transisi ke protokol konsensus baru merupakan pekerjaan besar, tetapi ada preseden yang kuat. The Merge Ethereum pada 2022 menunjukkan bahwa jaringan aktif berskala besar dapat berhasil mengubah mekanisme konsensus intinya, beralih dari Proof-of-Work ke Proof-of-Stake tanpa mengganggu operasi. Dengan kata lain, masih ada banyak risiko, tetapi ini bukan wilayah yang sepenuhnya belum pernah dijelajahi.

Transisi tersebut juga akan memerlukan panduan migrasi agar aplikasi, SDK, wallet, dan bot tidak mengalami kerusakan tanpa disadari saat Alpenglow melebur tingkat komitmen confirmed dan finalized menjadi satu pemeriksaan sertifikasi. Kode apa pun yang secara eksplisit melakukan polling terhadap dua tingkat komitmen atau menggunakan tingkat komitmen confirmed secara default akan berhenti berfungsi. Diperlukan upaya ekosistem yang terkoordinasi terkait dokumentasi, peringatan lint, metode RPC, dan arsitektur kode secara umum sebelum Alpenglow mulai beroperasi. 

Tata Kelola

Risiko tata kelola merupakan faktor lain yang perlu dipertimbangkan. Pemungutan suara SIMD-228 baru-baru ini menunjukkan bahwa Solana beroperasi sebagai jaringan yang benar-benar terdesentralisasi, tempat proposal—bahkan yang didukung oleh developer inti dan anggota komunitas terkemuka—tidak dijamin akan disetujui. Namun, perubahan mendatang yang diperkenalkan oleh Alpenglow, khususnya pengurangan biaya pemungutan suara, secara umum menguntungkan validator, terutama operator yang lebih kecil. Karena itu, kami meyakini kemungkinan adanya penolakan tata kelola relatif rendah.

Imbalan

Whitepaper Alpenglow dan materi terkait yang telah diterbitkan sejauh ini tidak menjelaskan mekanisme pasti untuk memberikan imbalan atas aktivitas pemungutan suara validator atau memberikan kompensasi kepada relay Rotor atas penggunaan bandwidth. Whitepaper tersebut juga dengan jelas menyatakan bahwa equivocation dapat dihukum, tetapi tidak menjelaskan siapa yang sebenarnya mengajukan penalti, seberapa besar penaltinya, dan apakah hukuman tersebut bersifat otomatis atau ditentukan melalui tata kelola. Ketiadaan informasi ini membuat aspek-aspek penting ekonomi validator belum terdefinisi dan dapat menjadi pokok perdebatan kontroversial dalam ekosistem.

MEV

Alpenglow juga akan merombak lanskap MEV Solana saat ini secara mendasar. Latensi terus menjadi faktor pendorong dalam MEV karena beberapa strategi yang menguntungkan mengandalkan pencerminan traffic TPU atau spam pembatalan dan penggantian transaksi dalam urutan tertentu sebelum transaksi tersebut dikonfirmasi secara optimistis. Semua ini terjadi dalam jendela waktu saat ini sebesar ~500–600 ms, yang hendak dipangkas Alpenglow menjadi ~150 ms. Sekilas, leader, terutama validator yang telah mengoperasikan infrastruktur pembuatan blok khusus, berpeluang memperoleh bagian MEV yang lebih besar. Sementara itu, pelaku arbitrase latensi independen mungkin kehilangan keunggulannya kecuali mereka terus mengembangkan sistem perdagangan yang lebih cepat dan lebih terperinci.

Beberapa Leader Bersamaan

Dibandingkan dengan arsitektur konsensus Solana saat ini, desain Alpenglow jauh lebih fleksibel untuk mengadopsi kerangka kerja multi-leader yang dikenal sebagai Multiple Concurrent Leaders (MCL). Seperti dinyatakan Anatoly Yakovenko, prototipe awal MCL dapat melibatkan pengoperasian dua instance Alpenglow yang berbagi kumpulan Rotor yang sama dan merilis semua shred secara bersamaan. Rotor akan menyebarkan stream paralel, dan Votor akan menotarisasi setiap lane. Namun, beberapa pertanyaan pada lapisan eksekusi mulai muncul. Yaitu,

• Bagaimana write-set sebaiknya dipartisi agar blok dari dua leader tidak pernah mengunci account yang sama—atau, jika terjadi, agar penyelesaian konflik bersifat deterministik dan murah?
• Bagaimana cara menggabungkan sertifikat per lane menjadi satu state root kanonis tanpa menggandakan biaya replay?
• Logika pasar biaya seperti apa yang berlaku saat lane bersaing memperebutkan aset?
• Strategi MEV lintas-lane seperti apa yang dimungkinkan oleh desain ini?
• Bisakah satu validator dengan stake tinggi mendominasi slot bersamaan tanpa batas lane? 

Meskipun desain Alpenglow membantu menjadikan MCL sebagai bagian roadmap yang realistis dengan menghapus hambatan pada tingkat konsensus, MCL tetap merupakan upaya menjanjikan untuk masa mendatang hingga pertanyaan-pertanyaan terbuka ini terjawab.

Kesimpulan

Laporan ini membahas komponen inti Alpenglow dan menelaah bagaimana komponen tersebut membentuk ulang model konsensus Solana. Kami juga telah menganalisis peningkatan teknis, perubahan pada ekonomi validator, dampak pada tingkat jaringan, serta manfaat bagi performa, kesederhanaan, dan skalabilitas.

Whitepaper Alpenglow menandai titik balik bagi Solana, bukan hanya dalam desain protokol, tetapi juga dalam filosofi pengembangan. Untuk pertama kalinya, Solana menerbitkan bukti kebenaran formal untuk algoritma konsensusnya. Hal ini menandai peralihan dari pendekatan tradisionalnya yang empiris dan berorientasi pada rekayasa menuju fondasi yang lebih ketat dan didukung riset. Evolusi ini mencerminkan ekosistem yang semakin matang dan terus memprioritaskan performa, kini dengan disiplin tambahan berupa verifikasi formal.

Penghentian Proof-of-History (PoH) menunjukkan perubahan simbolis serupa dalam identitas jaringan. Meskipun arti penting praktis PoH sering dilebih-lebihkan, PoH telah lama menjadi inovasi khas Solana, ditampilkan secara menonjol dalam panduan teknis dasar, dan menjadi identik dengan mereknya. Penghapusannya menandai akhir sebuah era dan awal era baru. Solana semakin dewasa.

Referensi Tambahan

• Slide Presentasi Accelerate Alpenglow - Roger Wattenhofer
• Alpenglow: Konsensus Baru untuk Solana - Blog Anza
• Implementasi Referensi Alpenglow - GitHub
• Whitepaper Alpenglow - Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Konsensus di Solana - Blog Helius
• Scale or Die di Accelerate 2025: Memperkenalkan Alpenglow - Konsensus Baru Solana - Video YouTube