Constellation: Proposal MCP di Solana

Wawasan yang Dapat Ditindaklanjuti

• Constellation adalah proposal formal tingkat protokol pertama untuk mengimplementasikan Multiple Concurrent Proposers (MCP) pada blockchain produksi dalam skala besar.
• Constellation memperkenalkan dua peran baru (yaitu pengusul dan pemberi atestasi) yang membatasi keleluasaan pemimpin dalam penyusunan blok. Sekitar 16 pengusul beroperasi secara konkuren dalam siklus 50 md, menyusun transaksi menjadi pslice berkode penghapusan yang didistribusikan kepada 256 pemberi atestasi. Catatan atestasi mengikat pemimpin secara kriptografis pada kumpulan transaksi yang disertakannya. Jika sebuah pslice mendapat atestasi dari cukup banyak pemberi atestasi, pemimpin tidak dapat mengecualikan transaksi tersebut tanpa menghasilkan blok tidak valid yang akan ditolak jaringan.
• Constellation memiliki sifat ketahanan terhadap penyensoran selektif: semua transaksi dengan biaya kompetitif disertakan atau tidak satu pun disertakan dalam suatu siklus.
• Serangan pengurutan yang dapat melihat konten dan manipulasi waktu masih belum teratasi. Transaksi dalam Constellation dapat dilihat oleh semua pengusul yang menerima transaksi tersebut pada saat pengiriman. Karena arsitektur multipengusul MCP, hal ini justru dapat memperluas permukaan serangan tersebut alih-alih mempersempitnya. Permainan latensi berbasis waktu diakui tidak dapat dihukum dalam desain saat ini.
• Constellation merestrukturisasi biaya yang ada—biaya penyertaan dipetakan ke biaya dasar saat ini, sedangkan biaya pengurutan dipetakan ke biaya prioritas yang ada. Pergeseran ekonomi yang lebih signifikan adalah aktivitas yang saat ini mengalir melalui layanan pendaratan di luar protokol dan pengaturan biaya off-chain seharusnya kembali ke protokol. Pemilihan peran berbobot stake berarti dinamika konsentrasi yang ada akan berlanjut, dan dampak bersih terhadap masing-masing validator belum dapat dimodelkan hingga SIMD Constellation kelak tersedia.
• MCP meningkatkan latensi urutan, tetapi menurunkan latensi penyertaan. Putaran pemberi atestasi, jendela siklus 50 md, dan penyusunan batch semuanya menambah waktu dibandingkan jalur pengiriman langsung ke TPU saat ini. Saat ini, latensi lebih tinggi bagi validator yang langsung mengemas transaksi TPU dan lebih rendah bagi validator yang menundanya. Dalam Constellation, transaksi valid kini memiliki jaminan penyertaan dengan batas waktu yang ditegakkan protokol.
• Constellation secara eksplisit tidak kompatibel dengan model Proposer-Builder Separation (PBS). Setelah catatan atestasi membatasi keleluasaan pemimpin, tidak ada lagi yang dapat dijual oleh builder khusus. Pendekatan ini merepresentasikan filosofi yang secara fundamental berbeda dari pendekatan Ethereum saat ini terhadap MEV.
• Tolok ukur empiris dalam kondisi jaringan realistis belum tersedia. Data terpenting yang dapat diberikan Anza adalah proyeksi perbandingan latensi untuk slot 200 md dalam protokol saat ini dengan slot 200 md dalam Constellation. Hingga data ini tersedia, komunitas memperdebatkan kompromi yang belum dapat dikuantifikasi. 
• Constellation dibangun di atas Alpenglow, yang menargetkan peluncuran mainnet pada kuartal ketiga 2026.

Pendahuluan

Meski sama sekali tidak ada tanaman agave yang memukau, Brennan Watt, CEO Anza, pergi ke gurun California untuk memperkenalkan Constellation—sebuah proposal untuk menghadirkan Multiple Concurrent Proposers (MCP) ke Solana. Ini adalah peningkatan paling ambisius secara struktural dan, bisa dibilang, proposal MCP tingkat protokol paling penting yang sejauh ini diajukan oleh blockchain produksi mana pun. Proposal ini berupaya mengatasi monopoli sementara pemimpin atas pengurutan transaksi dan nilai yang dapat diekstraksi dari monopoli tersebut. Constellation adalah demokratisasi ruang blok di Solana.

Artikel ini merupakan analisis kritis terhadap Constellation: masalah yang diatasinya, hal yang secara sadar ditundanya, dan persoalan yang benar-benar belum terselesaikan. Kami memperkenalkan kerangka tiga lapis untuk menilai ketahanan terhadap penyensoran, membandingkan Constellation dengan lanskap MCP saat ini, dan mengkaji apakah kompromi yang diperkenalkannya selaras dengan identitas performa yang telah dibangun Solana.

Diasumsikan bahwa Anda telah memahami Alpenglow. 

Masalah yang Diatasi Constellation

Transaksi adalah urat nadi Solana. Transaksi dikelompokkan dan ditulis secara permanen ke jaringan dalam bentuk blok. Namun, proses penentuan transaksi mana yang masuk ke blok tersebut dan dalam urutan apa bukanlah proses yang netral. 

Monopoli Pemimpin atas Produksi Blok

Produksi blok bergilir berdasarkan jadwal pemimpin, dengan satu validator pada satu waktu bertanggung jawab memproduksi blok dalam jendela tertentu.

Selama waktu ini, transaksi diteruskan langsung ke Transaction Processing Unit (TPU) milik pemimpin, sehingga pemimpin biasanya menerimanya sebelum pihak lain.

Pemimpin menempati posisi dengan kekuasaan yang tidak lazim. Artinya, mereka dapat mengamati transaksi yang masuk sebelum transaksi tersebut terlihat oleh publik.

Pemimpin dapat memutuskan untuk tidak menyertakan transaksi tertentu, mengurutkannya kembali secara sewenang-wenang, atau memasukkan transaksi mereka sendiri.

Ini adalah fitur struktural dari cara kerja konsensus pemimpin tunggal saat ini dan, dalam tingkat yang berbeda-beda, terdapat pada hampir setiap blockchain produksi berbasis Proof of Stake saat ini.

Ketiadaan mempool publik di Solana justru mempertegas asimetri ini, bukan menguranginya. Mempool publik Ethereum memberi peserta visibilitas tertentu terhadap transaksi tertunda, sehingga menciptakan arena persaingan yang relatif setara di antara pelaku canggih yang berlomba memanfaatkan pengurutan transaksi.

Di Solana, keunggulan informasi pemimpin lebih sulit ditandingi karena karakter penerusan transaksi. 

Maximal Extractable Value (MEV)

Dalam kondisi normal dan dengan validator yang jujur, kekuasaan ini sebagian besar tidak dimanfaatkan. Namun, masalahnya adalah validator merupakan pelaku ekonomi yang rasional. Seiring Solana berkembang dan aktivitas keuangan terus bertumbuh, keuntungan yang tersedia dari pemanfaatan monopoli sementara pemimpin juga meningkat. Validator yang memilih untuk tidak memanfaatkan posisi ini pada dasarnya membiarkan peluang keuntungan berlalu begitu saja. Node yang berperilaku benar berada dalam posisi ekonomi yang tidak menguntungkan—kerugian yang mendorong mereka untuk merusak kualitas sistem yang mereka ikuti.

Keuntungan yang dapat diekstraksi ini dikenal sebagai Maximal Extractable Value (MEV), istilah yang pertama kali dirumuskan secara formal oleh Daian dkk. dalam Flash Boys 2.0 sebagai Miner Extractable Value sebelum diterapkan pada jaringan Proof of Stake. Istilah ini mencakup segala hal, mulai dari arbitrase dan frontrunning hingga serangan sandwich, penyensoran selektif, serta strategi apa pun yang memanfaatkan keunggulan informasi dan posisi pemimpin terhadap pengguna yang transaksinya mereka proses.

Respons utama industri terhadap MEV adalah model Proposer-Builder Separation (PBS), yang diimplementasikan di Ethereum melalui MEV-Boost. Dalam PBS, builder khusus bersaing menyusun blok yang memaksimalkan nilai yang dapat diekstraksi, sedangkan pengusul cukup memilih blok paling menguntungkan untuk diproduksi. Ini adalah pembingkaian ulang masalah secara pragmatis untuk mendemokratisasi akses ke MEV dan mendistribusikan kembali hasilnya ke seluruh kumpulan validator, alih-alih memusatkannya pada pelaku paling canggih, karena model ini mengasumsikan ekstraksi MEV tidak dapat dihindari.

Masalah dari pembingkaian ini adalah PBS tidak mengurangi kerugian bagi pengguna—ekstraksi tetap terjadi, hanya penerima manfaatnya yang berubah. PBS mengatasi beberapa dampak negatif MEV bagi node jaringan, tetapi tidak mengurangi kerugian bagi pengguna jaringan.

Solana memiliki hubungan tersendiri dengan MEV yang terus berkembang. Kombinasi waktu blok yang cepat, pengiriman langsung ke TPU, dan kumpulan validator yang kompetitif telah menghasilkan lanskap MEV tersendiri yang ditandai oleh spam, lelang biaya prioritas, dan pengurutan ulang transaksi pada tingkat validator. Mesin blok Jito dapat dianggap sebagian serupa dengan MEV-Boost karena menyediakan mekanisme lelang off-chain tempat pencari peluang mengajukan penawaran untuk pengurutan transaksi, dengan hasil yang dibagikan antara validator dan staker. Artinya, seperti PBS, Jito mengelola dan mendistribusikan kembali MEV secara lebih demokratis alih-alih menghapusnya sepenuhnya.

Constellation berupaya mengatasi hal ini. Alih-alih menerima monopoli pemimpin dan mengelola konsekuensinya, Constellation berupaya membatasi monopoli tersebut secara struktural sehingga bentuk MEV yang paling merugikan mustahil terjadi berdasarkan desain. Whitepaper Constellation menggambarkan ambisi ini sebagai “infrastruktur Internet Capital Markets, wadah universal untuk aktivitas ekonomi tempat pengguna dapat memercayai bahwa struktur pasarnya adil.”

Pasar keuangan tradisional berupaya menerapkan perlindungan serupa melalui regulasi dan pengawasan yurisdiksi. Perlindungan ini bersifat reaktif dan tidak merata, serta berulang kali terbukti tidak memadai. Ambisi Constellation adalah menegakkan keadilan pada tingkat protokol agar tidak dapat dielakkan atau diterapkan secara selektif. Constellation berupaya melakukannya dengan mengimplementasikan Multiple Concurrent Proposers (MCP) di Solana.

Multiple Concurrent Proposers

Dalam blockchain tradisional dengan pemimpin tunggal, satu validator bertanggung jawab memproduksi setiap blok. Validator ini (yaitu pemimpin) untuk sementara memiliki kendali eksklusif atas penyertaan dan pengurutan transaksi. Selama validator ini berwenang memproduksi blok, semua peserta jaringan lainnya menjadi pengamat pasif dalam jendela tersebut. Pada akhirnya, pemimpin memutuskan transaksi mana yang disertakan dan dalam urutan apa.

Desain ini menarik karena sederhana. Satu validator yang mengawasi produksi blok berarti tidak ada beban koordinasi, tidak ada proposal bertentangan yang harus diselesaikan, dan model akuntabilitasnya jelas. Namun, ini juga berarti ada satu titik eksploitasi. Monopoli sementara pemimpin merupakan akar penyebab MEV, dan setiap mitigasi utama sejauh ini menerima struktur tersebut serta berupaya mengelola konsekuensinya.

Multiple Concurrent Proposers (MCP) adalah kelas desain protokol yang mematahkan monopoli ini pada tingkat struktural. Alih-alih bergilir ke satu pemimpin yang memiliki hak eksklusif atas produksi blok, MCP memungkinkan beberapa node mengusulkan transaksi secara bersamaan. Tidak ada satu pengusul yang mengendalikan seluruh kumpulan transaksi. Sebaliknya, proposal mereka digabungkan, biasanya oleh peran perakit yang dibatasi, sesuai dengan aturan protokol.

Pengguna yang mengirim transaksi ke beberapa pengusul sekaligus tidak lagi bergantung pada satu node karena kini memiliki beberapa jalur independen untuk penyertaan. Pemimpin yang mencoba mengecualikan transaksi mereka harus menghadapi fakta bahwa pengusul lain sudah melihatnya dan pemberi atestasi sudah memberikan atestasi untuk transaksi tersebut. Satu pemimpin menyusun blok akhir, tetapi keleluasaannya dibatasi secara ketat.

Kompromi utama MCP adalah kompleksitas koordinasi. Mengizinkan beberapa node mengusulkan transaksi secara bersamaan menimbulkan pertanyaan yang sepenuhnya dihindari desain pemimpin tunggal. Bagaimana transaksi yang bertentangan diselesaikan ketika dua pengusul menyertakan transaksi yang sama? Bagaimana urutan antarproposal ditentukan? Bagaimana Anda mencegah pengusul canggih memanipulasi aturan penggabungan? Hal ini menambah kompleksitas protokol yang cukup besar—tim harus mengatasi tantangan koordinasi yang melibatkan peran node baru, logika penjadwalan, asumsi kriptografis, dan mode kegagalan, yang semuanya memerlukan pengujian ketat.

Ketepatan istilah penting di sini karena MCP digunakan secara longgar di seluruh industri untuk merujuk pada beragam desain dengan sifat yang sangat berbeda. Pada tingkat paling rendah, MCP memberikan ketahanan probabilistik terhadap penyensoran—transaksi yang dikirim ke beberapa pengusul lebih sulit disensor karena penyensoran memerlukan koordinasi di antara beberapa node. Pada tingkat yang lebih tinggi, MCP dapat memberikan ketahanan struktural terhadap penyensoran—secara matematis, pemimpin tidak mungkin memproduksi blok yang menyensor transaksi yang telah mendapat atestasi dari kuorum yang memadai. Inilah yang ditargetkan Constellation, dan perbedaannya sangat penting bagi aplikasi keuangan yang memerlukan jaminan pasti.

Constellation: Cara Kerjanya

Constellation adalah protokol untuk mengimplementasikan MCP di Solana. Protokol ini melengkapi Alpenglow: Alpenglow menangani konsensus (yaitu keamanan, keaktifan, dan finalitas), sedangkan Constellation menangani struktur pasar—siapa yang dapat mengusulkan transaksi, bagaimana proposal tersebut diakui, dan apa yang boleh dilakukan pemimpin terhadapnya. Constellation menghasilkan muatan yang difinalisasi Alpenglow.

Arsitektur

Constellation memperkenalkan dua peran baru ke dalam tumpukan protokol Solana, masing-masing dengan tanggung jawab berbeda, sekaligus mengubah peran pemimpin dan validator.

Pengusul adalah titik masuk bagi transaksi. Pada waktu tertentu, sekitar 16 pengusul aktif secara konkuren, dipilih secara acak berdasarkan stake dan dirotasi setiap 32 siklus (yaitu ~1,6 detik). Pengguna mengirim transaksi mereka langsung ke satu atau beberapa pengusul pilihan mereka. Pengusul bebas menerima atau menolak transaksi apa pun, dengan ketentuan bahwa transaksi yang diterima harus valid. Tidak ada aturan protokol yang mewajibkan penyertaan transaksi pada tahap ini; jaminan ketahanan terhadap penyensoran hadir kemudian dalam alur. Setiap pengusul beroperasi dalam siklus 50 milidetik. Dalam setiap siklus, pengusul menyusun transaksi yang diterimanya ke dalam struktur bernama pslice—awalan “p” tidak dibaca dan hanya digunakan untuk membedakannya dari slice Alpenglow. pslice diberi kode penghapusan menjadi 256 bagian lebih kecil yang disebut pshred, dan satu pshred didistribusikan kepada masing-masing dari 256 pemberi atestasi aktif. Pengodean penghapusan menggunakan ambang pemulihan 64, yang berarti 64 dari 256 pshred mana pun sudah cukup untuk merekonstruksi pslice secara penuh. Setiap pshred memuat komitmen hash kriptografis terhadap daftar transaksi lengkap, yang memastikan pemimpin tidak dapat mengganti transaksi dengan transaksi lain atau mengubah urutan dalam pslice setelah pemberi atestasi menyetujuinya.

Pemberi atestasi menerima pshred dari pengusul dan segera meneruskannya kepada ~2 pemimpin berikutnya untuk mengantisipasi kesalahan atau ketidakhadiran, lalu mencatat hash komitmen dari pslice yang diterima. Pada akhir setiap siklus, pemberi atestasi menandatangani sebuah atestasi—pernyataan yang mengikat secara kriptografis dan mencantumkan setiap hash komitmen pslice yang diamatinya selama siklus tersebut. Atestasi ini dikirim kepada pemimpin dan berfungsi sebagai catatan bukti yang membatasi transaksi mana yang boleh disertakan pemimpin. Catatan tersebut berbobot stake dan ditandatangani, sehingga tidak dapat dipalsukan atau diam-diam diabaikan. 

Pemimpin dalam Constellation sama dengan pemimpin Alpenglow—node yang bertanggung jawab memproduksi blok akhir yang masuk ke konsensus. Perbedaannya dalam Constellation adalah keleluasaan pemimpin dibatasi secara ketat oleh catatan atestasi. Constellation memberlakukan dua ambang yang berbeda. Agar atestasi agregat valid, setidaknya 60% pemberi atestasi harus berpartisipasi. Jika ambang ini tidak terpenuhi, blok dilewati sepenuhnya. Dalam kondisi tersebut, setiap pslice yang telah mendapat atestasi dari setidaknya 40% pemberi atestasi wajib disertakan oleh pemimpin. Jika tidak, blok yang dihasilkan menjadi tidak valid dan akan ditolak jaringan. Desain dua ambang ini memisahkan validitas tingkat blok dari penyertaan per pengusul. Artinya, pemimpin dapat memproduksi blok yang valid meskipun data beberapa pengusul tidak mencapai cukup banyak pemberi atestasi, tetapi tidak dapat secara selektif mengecualikan pengusul yang datanya berhasil mencapainya. Setelah pemimpin mengompilasi semua pslice yang telah mendapat atestasi menjadi satu batch, pemimpin mengirimkan batch tersebut kepada validator melalui Rotor milik Alpenglow. 

Validator menerima batch dari pemimpin melalui Rotor dan menjalankan eksekusi berpipa saat batch tiba. Setelah blok lengkap diterima, validator memeriksanya terhadap catatan atestasi untuk memastikan setiap pslice yang telah mendapat atestasi memiliki kiriman terkait dalam blok. Hanya jika semua pemeriksaan lolos, validator memberikan suara untuk memfinalisasinya; jika pemeriksaan gagal, validator akan memberikan suara untuk melewati seluruh jendela pemimpin melalui pemanggilan TrySkipWindow. 

Siklus dan Blok

Siklus adalah unit waktu fundamental Constellation. Siklus merupakan jendela 50 milidetik yang diperoleh dari waktu nyata UTC dengan membagi stempel waktu nanodetik Unix dengan 50.000.000. Hal yang penting, siklus tidak diselaraskan dengan slot Alpenglow. Satu slot berisi beberapa siklus, dan batch yang dihasilkan sepanjang siklus tersebut membentuk muatan blok pemimpin. Perbedaan ini penting karena siklus 50 md adalah detak ekonomi (yaitu jendela tempat ketahanan terhadap penyensoran ditegakkan), sementara slot tetap menjadi unit konsensus Alpenglow.

Whitepaper tersebut menetapkan toleransi untuk selisih jam antara pengusul dan pemberi atestasi, lalu menyesuaikan jendela atestasi berdasarkan selisih itu. Untuk menggambarkan pentingnya hal ini, misalkan jam pengusul berjalan 5 md lebih cepat daripada kumpulan pemberi atestasi. pshred dari pengusul ini mungkin tiba pada pemberi atestasi lebih awal daripada yang diperkirakan relatif terhadap batas siklus, sehingga transaksi dalam pslice tersebut memiliki jendela yang sedikit lebih panjang untuk mengumpulkan atestasi. Sebaliknya, pengusul yang jamnya tertinggal mungkin mendapati pshred miliknya tiba begitu terlambat hingga sepenuhnya keluar dari jendela atestasi, meskipun pengusul mengirimkannya “tepat waktu.” Dalam lingkungan pusat data yang menggunakan alat seperti chrony atau penerima GPS, sinkronisasi jam merupakan hal rutin dan penyimpangannya biasanya kurang dari satu milidetik, jauh di dalam batas toleransi Constellation. Kekhawatirannya adalah Constellation memperkenalkan variabel baru yang tidak ada dalam model waktu murni logis Alpenglow, dan SIMD Constellation kelak sebaiknya menetapkan batas pemantauan untuk variabel tersebut.

Saat Constellation mendekati akhir suatu epoch, pengusul dan pemberi atestasi mungkin sejenak tidak yakin apakah epoch berikutnya telah dimulai. Selama jendela ini, Constellation beroperasi dalam kedua epoch secara konkuren dengan dua kumpulan pengusul dan pemberi atestasi yang aktif secara bersamaan. Konsensus Alpenglow secara alami menentukan siklus mana yang termasuk dalam epoch tertentu.

Siklus Hidup dan Biaya Transaksi

Sebuah transaksi harus melewati empat gerbang sebelum dieksekusi:

• Transaksi harus diterima dan disertakan dalam pslice oleh pengusul.
• pslice tersebut harus mengumpulkan atestasi yang memadai agar disertakan dalam batch pemimpin.
• Transaksi harus memiliki penawaran yang cukup tinggi agar dipilih untuk dieksekusi dalam batas komputasi batch.
• Blok yang memuat batch harus dikonfirmasi oleh konsensus Alpenglow.

Setiap transaksi membawa penawaran (yaitu biaya eksekusi per unit komputasi) yang menentukan urutannya dalam batch yang sama. Penawaran yang lebih tinggi dieksekusi lebih dahulu.

Constellation membagi biaya transaksi menjadi dua biaya yang berbeda:

• Biaya penyertaan.
• Biaya pengurutan.

Biaya penyertaan adalah tarif tetap berjumlah kecil yang didasarkan pada ukuran transaksi dan jumlah tanda tangan. Biaya ini dibayarkan kepada pengusul yang menyertakan transaksi dalam pslice miliknya dan dikenakan sejak transaksi melewati ambang atestasi, terlepas dari apakah transaksi tersebut akhirnya dieksekusi. Biaya ini serupa dengan biaya dasar dalam sistem Solana saat ini, tetapi dengan satu catatan penting: jika pengguna mengirim transaksi yang sama kepada tiga pengusul untuk redundansi, mereka membayar biaya penyertaan tiga kali (yaitu satu kali per pengusul) karena setiap pengusul secara independen melakukan pekerjaan untuk menyertakannya. Oleh karena itu, jika pengguna mengirim transaksi yang sama kepada n pengusul berbeda untuk redundansi, mereka membayar biaya penyertaan sebanyak n kali.

Biaya pengurutan adalah komponen yang lebih besar dan berbasis prioritas, yaitu total unit komputasi transaksi dikalikan dengan penawarannya. Biaya ini hanya dikenakan sekali karena transaksi hanya dapat dieksekusi satu kali, terlepas dari berapa banyak pengusul yang menyertakannya. Sebagai contoh, transaksi yang meminta 200.000 unit komputasi dengan penawaran 0,00001 SOL per unit komputasi membayar biaya pengurutan sebesar 2 SOL. Jika transaksi yang sama dikirim kepada empat pengusul untuk redundansi, pengguna akan membayar empat biaya penyertaan ditambah satu biaya pengurutan sebesar 2 SOL. Biaya pengurutan dikembalikan ke ekosistem secara proporsional berdasarkan stake node—whitepaper menyerahkan desain mekanisme ini kepada SIMD kelak.

Setiap akun pembayar biaya harus mempertahankan saldo cadangan minimum sekitar 0,001 SOL untuk mencegah manipulasi biaya di antara pengusul konkuren. Hal ini memastikan biaya penyertaan selalu dapat dibayar, bahkan ketika beberapa pengusul secara konkuren menyertakan transaksi yang menyentuh akun yang sama.

Constellation dan Alpenglow

Alpenglow adalah protokol konsensus Solana. Protokol ini menentukan blok mana yang valid, urutan finalisasinya, dan cara jaringan pulih dari kesalahan. Komponen Votor dan Rotor miliknya menggantikan Tower BFT dan propagasi suara berbasis gossip, sehingga secara signifikan mempercepat finalitas. Alpenglow tidak mengatur siapa yang mengusulkan transaksi atau bagaimana pengurutan dalam blok ditentukan.

Constellation adalah lapisan struktur pasar yang membatasi tindakan yang boleh dilakukan pemimpin Alpenglow terhadap blok yang disusunnya—lapisan ini menentukan siapa yang mengusulkan transaksi dan bagaimana urutan dalam setiap blok ditetapkan. Batch yang dihasilkan Constellation menjadi muatan blok Alpenglow. Votor milik Alpenglow kemudian menotariskan blok tersebut sesuai dengan aturan pemungutan suara yang telah ditetapkan. Kedua protokol disusun sedemikian rupa sehingga Alpenglow memberikan keamanan dan keaktifan, sedangkan Constellation memberikan keadilan pengurutan.

Komposabilitas ini berarti Constellation juga mewarisi asumsi keamanan Alpenglow tanpa melemahkannya. Constellation tidak mengubah jaminan Alpenglow. Sebaliknya, Constellation memperkenalkan jaminan dan asumsi baru untuk peran pengusul dan pemberi atestasi yang baru, serta sinkronisasi waktu nyata UTC dalam model waktu baru berbasis siklus.

Constellation adalah proposal formal tingkat protokol pertama untuk mengimplementasikan MCP pada blockchain produksi yang dapat diskalakan. Ini merupakan tambahan penting untuk menghadirkan ketahanan terhadap penyensoran di Solana—bab berikutnya dalam peta jalan protokol yang dibuka oleh Alpenglow.

Apa yang Sebenarnya Dibutuhkan untuk Resistansi terhadap Penyensoran

Literatur MEV secara historis mengkaji masalah ini melalui beberapa perspektif berbeda yang, jika digabungkan, membentuk gambaran lebih terpadu mengenai hal-hal yang benar-benar perlu diselesaikan oleh setiap proposal resistansi terhadap penyensoran. Berdasarkan taksonomi mendasar Eskandari et al. tentang serangan front-running, kerangka formal dua properti dari Garimidi et al. untuk protokol MCP, serta analisis Landers dan Marsh mengenai saluran MEV khusus MCP, kami mengusulkan pengelompokan permukaan serangan menjadi tiga lapisan berbeda, yang masing-masing memerlukan kelas solusi berbeda. Kerangka ini merupakan sintesis kami sendiri dan diperkenalkan di sini untuk mengevaluasi desain Constellation.

Lapisan 1: Penyensoran Keras

Penyensoran keras mengacu pada kemampuan leader atau proposer untuk menolak menyertakan transaksi yang telah mereka identifikasi. Ini adalah bentuk manipulasi yang paling mudah dikenali dan diselesaikan secara struktural oleh Constellation. Dengan Constellation, leader secara kriptografis tidak mungkin menghasilkan blok valid yang mengecualikan transaksi dengan fee kompetitif yang telah diatestasi oleh kuorum attester yang memadai. Slashing tidak diperlukan untuk hal ini karena penegakannya bersifat arsitektural.

Lapisan 2: Pengurutan dengan Konten Terlihat

Lapisan kedua lebih sulit ditangani. Meskipun proposer tidak dapat menyensor secara langsung, mereka masih dapat mengamati konten transaksi sebelum pengurutan final dan mencoba memanfaatkan visibilitas tersebut (misalnya, melakukan sandwich terhadap perdagangan besar). Inilah yang diformalkan Garimidi et al. sebagai properti penyembunyian—adversary tidak boleh dapat melihat isi transaksi sebelum transaksi tersebut dikonfirmasi. Constellation menerapkan penyembunyian parsial. Artinya, transaksi hanya terlihat oleh proposer yang menerimanya—bukan semua proposer—dan leader baru melihat konten transaksi setelah tenggat siklus berlalu. Ini lebih baik daripada visibilitas penuh, tetapi belum sepenuhnya memenuhi properti penyembunyian Garimidi et al., yang mengharuskan isi transaksi tetap tidak terlihat oleh semua pihak sebelum konfirmasi. Proposer penerima masih dapat mengamati dan memanfaatkan isi transaksi yang diterimanya.

Kekhawatiran yang lebih mendalam mengenai Constellation adalah bahwa MCP dengan pengiriman transaksi publik dapat memperbesar eksploitasi berdasarkan konten yang terlihat. Hal ini menghadirkan sistem tempat setiap proposer mengamati transaksi yang diterimanya dan dapat memanfaatkan visibilitas tersebut di dalam pslice miliknya. Permukaan serangannya berbeda dari model leader tunggal karena beberapa entitas masing-masing dapat melihat suatu subset. Pengguna yang mengirimkan transaksi ke satu proposer hanya mengekspos transaksinya kepada proposer tersebut. Namun, pengguna yang mengirimkan ke beberapa proposer demi redundansi memperluas eksposurnya secara proporsional. Landers dan Marsh memformalkan dinamika ini: produksi blok serentak menciptakan permainan timing, peluang duplikasi pada tick yang sama, serta ketiadaan struktural chokepoint builder tunggal yang saat ini membatasi jumlah upaya ekstraksi yang dapat berhasil untuk setiap transaksi korban. Mendesentralisasikan kumpulan proposer tanpa menangani visibilitas konten justru melipatgandakan permukaan serangan MEV, bukan menguranginya.

Analisis Landers dan Marsh mengenai saluran MEV khusus MCP mengasumsikan visibilitas konten yang lebih luas daripada yang disediakan Constellation. Dalam penyembunyian parsial Constellation, peningkatan eksploitasi berdasarkan konten yang terlihat bergantung pada strategi pengiriman pengguna, bukan keniscayaan arsitektural. Pengguna yang mengirimkan transaksi ke satu proposer tepercaya memiliki profil eksposur konten yang kurang lebih sama dengan model leader tunggal saat ini. Konsekuensinya, pengiriman ke satu proposer mengorbankan redundansi yang menjadi tumpuan resistansi terhadap penyensoran. 

Lapisan 3: Manipulasi Timing dan Latensi

Lapisan yang paling halus dan paling sulit dihukum berkaitan dengan manipulasi timing dan latensi. Dalam Constellation, proposer dapat menunda penerusan pshreds kepada attester secukupnya sehingga transaksi pesaing berada di luar jendela atestasi, atau memanfaatkan penyimpangan waktu UTC untuk memanipulasi transaksi mana yang mengumpulkan atestasi memadai. Kesenjangan ini diakui secara langsung dalam whitepaper Constellation: pengiriman pesan yang terlambat “tidak dapat dihukum” karena tidak dapat dibedakan dari keterlambatan jaringan yang sebenarnya. Di lapisan inilah slashing mungkin menjadi relevan, sekaligus menjadi pertanyaan terbuka utama yang perlu ditangani oleh SIMD Constellation nantinya. 

Asumsi mendasar dalam desain Constellation adalah bahwa hubungan proposer-pengguna tidak bersifat anonim—hubungan tersebut merupakan interaksi berulang tempat kepercayaan dapat diukur dan reputasi menjadi penting. Dengan sekitar 16 proposer aktif pada waktu tertentu, pengguna yang terus-menerus menerima perlakuan buruk dari satu proposer dapat mulai mengirimkan transaksi ke salah satu dari 15 proposer lainnya. Meskipun hal ini tidak menghasilkan artefak onchain yang dapat digunakan untuk menghukum pelaku buruk secara langsung, hal tersebut menciptakan konsekuensi ekonomi bagi proposer yang mengeksploitasi posisinya. Sejauh mana tekanan reputasi ini cukup untuk mencegah manipulasi timing dibandingkan solusi seperti slashing masih menjadi pertanyaan terbuka yang kemungkinan bergantung pada seberapa transparan perilaku proposer bagi pengguna seiring waktu. 

Dampak bagi Validator dan Pengguna

Validator

Constellation mendistribusikan ulang peluang MEV di antara validator, bukan menghilangkannya sepenuhnya. Sumber pendapatan yang paling mudah dikenali dan diekstraksi secara langsung oleh leader saat ini (yaitu, penyensoran keras) sengaja dibuat mustahil. Namun, penggantinya adalah serangkaian saluran timing yang lebih halus dan lebih sulit dihukum, yang menguntungkan validator dengan keunggulan latensi, sinkronisasi waktu presisi, dan kecanggihan untuk secara konsisten mengeksploitasi jendela penerusan pshred. Dampak akhirnya adalah perubahan cara validator mengekstraksi nilai, bukan pengurangan total permukaan ekstraksi. Satu-satunya catatan adalah bahwa ekstraksi menjadi jauh lebih sulit.

Constellation tidak benar-benar memperkenalkan aliran fee yang sepenuhnya baru, melainkan merestrukturisasi yang sudah ada. Fee penyertaan serupa dengan base fee saat ini, sedangkan fee pengurutan sepadan dengan priority fee yang ada. Pembagiannya diperkirakan serupa dengan pendapatan validator saat ini. Perbedaannya sebagian besar bersifat operasional. Artinya, operator yang baik seharusnya memperoleh lebih banyak fee penyertaan sebagai proposer, sehingga menciptakan tingkatan berbasis performa dalam ekonomi yang ada, bukan kategori pendapatan terpisah. Peran attester tidak diberi kompensasi terpisah dalam desain saat ini. Alasannya, seperti partisipasi dalam Turbine saat ini, peran tersebut diharapkan dijalankan karena memberikan manfaat bersih bagi jaringan. Pergeseran ekonomi yang lebih signifikan adalah aktivitas yang saat ini mengalir melalui layanan landing di luar protokol, lelang berbasis pasar, dan pengaturan fee off-chain, yang semestinya kembali masuk ke dalam protokol agar lebih langsung menguntungkan validator. Namun, hingga SIMD menetapkan mekanisme yang tepat, dampak ekonomi bersih bagi setiap validator—khususnya validator yang lebih kecil, ketika pemilihan berbobot stake mengurangi frekuensi menjadi proposer dan overhead infrastruktur menaikkan batas minimum biaya—masih menjadi pertanyaan terbuka.

Proposer dan attester dipilih berdasarkan bobot stake, yang berarti dinamika konsentrasi yang membentuk ekonomi validator juga menentukan partisipasi dalam peran-peran tersebut. Jika sejumlah kecil validator dengan stake tinggi mendominasi pemilihan proposer, jaminan resistansi terhadap penyensoran tetap berlaku secara formal, tetapi keragaman praktis kumpulan proposer menyempit, meskipun masih merupakan peningkatan dibandingkan kondisi Solana saat ini (yaitu, memilih 1 dari n dibandingkan memilih 16 dari n). Asumsi independensi mulai melemah dalam praktik meskipun tetap berlaku secara teori. Kekhawatiran ini patut diperhatikan mengingat munculnya penawaran Validator-as-a-Service (VaaS), yang memungkinkan satu entitas mengoperasikan beberapa validator dengan stake tinggi. Apakah SIMD akan memperkenalkan mekanisme antikonsentrasi atau insentif untuk pemilihan proposer merupakan pertanyaan desain yang berimplikasi langsung terhadap kekuatan jaminan yang ditawarkan Constellation. 

Pengguna

Bagi pengguna, transaksi dengan fee kompetitif yang dikirimkan ke jumlah proposer yang memadai kini, untuk pertama kalinya, dilindungi oleh jaminan protokol yang kuat terhadap pengecualian selektif. Aplikasi keuangan kini dapat dibangun dengan jaminan yang sebelumnya sama sekali tidak ada, sehingga mengubah apa saja yang hanya mungkin dilakukan di Solana. 

Pengguna berfrekuensi tinggi dan sensitif terhadap harga kini harus mengirimkan transaksi ke beberapa proposer demi redundansi. Kekhawatirannya adalah bahwa desentralisasi kumpulan proposer tanpa menangani visibilitas konten dapat meningkatkan eksposur terhadap serangan sandwich—setiap proposer dapat mengamati dan mengambil tindakan berdasarkan transaksi yang dikirimkan kepadanya, yang berarti pengguna yang mengirim ke beberapa proposer demi redundansi secara proporsional menambah jumlah pihak yang melihat konten transaksinya. Tindakan ini secara inheren menghilangkan chokepoint leader tunggal dan menyiarkan maksud transaksi kepada kumpulan calon adversary yang lebih luas. Implikasi praktisnya adalah bahwa pengguna yang lebih canggih perlu mengembangkan strategi pengiriman baru yang menyeimbangkan redundansi dengan eksposur, kemungkinan dengan menargetkan proposer secara selektif berdasarkan reputasi atau stake, misalnya, alih-alih menggunakan strategi pengiriman berganda secara luas.

Khusus bagi market maker, jaminan penyertaan Constellation menghilangkan risiko adversarial ketika infrastruktur menentukan kualitas eksekusi. Yang tersisa hanyalah asimetri informasi murni, yaitu profil risiko yang sama dengan yang dihadapi market maker di venue tradisional terbaik saat ini. Konvergensi inilah yang membuat argumen bahwa penyertaan dapat mengurangi latensi menjadi konkret, bukan sekadar aspirasi. Konvergensi ini dibahas lebih mendalam dalam bagian “Pertanyaan Terbuka” kami.

Perubahan bersih pada pengalaman yang dirasakan rata-rata pengguna kemungkinan kecil, tetapi jaminan penyertaan merupakan peningkatan keandalan yang berarti. Sambil menunggu benchmark mendatang, dampak bersih terhadap latensi urutan masih menjadi pertanyaan empiris terbuka.

Lanskap: Perbandingan Constellation

Sei Giga

Sei Giga adalah analog terdekat dengan Constellation dalam lanskap MCP saat ini. Ini adalah blockchain siap produksi yang menjadikan MCP prioritas arsitektural utama, bukan tujuan riset masa depan. Perbandingan keduanya memberikan wawasan karena keduanya mengambil kompromi berbeda pada lapisan yang sama.

Fondasi konsensus Giga disebut Autobahn, sebuah protokol BFT multiproposer tempat setiap validator mengoperasikan “lane” proposalnya sendiri secara paralel dan berkelanjutan. Alih-alih mengandalkan satu leader, setiap node terus menyebarkan stream proposal datanya sendiri melalui lane independen, lalu lapisan konsensus secara berkala menetapkan “tip cut”, yaitu snapshot ringkas yang menggabungkan proposal terbaru dari setiap lane. Secara arsitektural, ini berbeda dari model Constellation, tempat sekitar 16 proposer terpilih beroperasi dalam siklus tetap 50ms. Model berbasis lane Autobahn memungkinkan validator mana pun mempertahankan lane proposal berkelanjutan, alih-alih dipilih dari subset bergilir berbobot stake, sehingga partisipasi dalam produksi blok menjadi jauh lebih luas.

Perbedaan yang paling penting berkaitan dengan pengurutan saat konten terlihat. Autobahn memungkinkan eksekusi asinkron dengan memisahkan pengurutan transaksi dari eksekusi, pilihan desain yang ditangguhkan oleh Constellation. Seperti dibahas di bagian berikutnya, eksekusi asinkron mempersempit permukaan serangan pengurutan dengan konten terlihat karena mencegah proposer menyimulasikan hasil eksekusi terhadap final state yang diketahui pada saat pengurutan.

Giga menawarkan resistansi terhadap penyensoran yang bersifat probabilistik, sedangkan Constellation memberikan jaminan struktural. Dasar pemikiran Giga adalah bahwa transaksi yang dikirimkan ke beberapa proposer lebih sulit disensor karena setiap proposer bekerja dengan informasi tidak lengkap, dan manfaat penyensoran dapat hilang jika proposer lain menyertakan transaksi tersebut pada tick yang sama. Sebagai perbandingan, dalam Constellation, leader yang mengecualikan transaksi dengan atestasi memadai akan menghasilkan blok tidak valid. Resistansi probabilistik meningkatkan biaya penyensoran, sedangkan resistansi struktural membuat penyensoran mustahil secara kriptografis. Bagi aplikasi keuangan yang ingin didukung kedua protokol, perbedaan ini penting. 

Perbedaan tingkat ambisi antara kedua desain ini perlu disampaikan secara terbuka. Constellation adalah spesifikasi protokol yang membuktikan properti kebenaran, mendefinisikan kondisi kesalahan, menetapkan ambang kuorum, dan ditujukan untuk diajukan sebagai proposal formal bagi jaringan produksi yang skalabel dengan nilai stake miliaran dolar. Whitepaper Sei Giga dibaca secara berbeda, dengan orientasi pada klaim throughput dan kompatibilitas EVM, sedangkan MEV dan resistansi terhadap penyensoran diperlakukan sebagai manfaat yang muncul dari arsitektur multiproposer, bukan sebagai jaminan yang ditetapkan secara formal. Arah eksekusi asinkron memang tepat, tetapi Giga tidak memberikan tingkat jaminan formal yang sama dengan Constellation terkait batasan pengurutan, kuorum attester, atau kondisi kesalahan. Ini bukan kritik terhadap pilihan sequencing Giga, melainkan cerminan konteks yang berbeda—Constellation diusulkan di atas blockchain produksi dengan throughput tertinggi di dunia, yang menuntut sekaligus menghasilkan standar spesifikasi yang lebih tinggi.

Kondisi Ideal Akademis

Benchmark teoretis untuk desain MCP adalah Multiple Concurrent Proposers: Why and How (2025) karya Garimidi dan Neu dari a16z Crypto Research serta Max Resnick dari Anza. Makalah tersebut mengusulkan protokol MCP yang menawarkan dua properti yang menurut mereka harus dipenuhi oleh setiap desain yang resistan terhadap penyensoran: resistansi terhadap penyensoran selektif dan penyembunyian. Properti pertama menjamin bahwa adversary tidak dapat menunda transaksi secara selektif, sedangkan properti kedua menjamin konten transaksi tetap tidak terlihat sebelum konfirmasi. Ini adalah satu-satunya desain MCP dalam literatur saat ini yang secara formal mencapai keduanya sekaligus.

Mekanisme yang memungkinkan penyembunyian adalah HECC—Hiding Erasure-Correcting Code. Parameternya diatur sedemikian rupa sehingga T shreds tidak mengungkapkan informasi apa pun mengenai batch transaksi yang mendasarinya, sedangkan K + T shreds memungkinkan rekonstruksi penuh. Detail pentingnya adalah relay baru menyiarkan shreds yang disimpannya setelah konsensus mengonfirmasi batch mana yang disertakan. Hal ini mencegah pengamatan konten transaksi sebelum konfirmasi, sehingga sepenuhnya menutup permukaan serangan pengurutan dengan konten terlihat sebagai jaminan teoretis-informasi. 

Jika dipetakan ke kerangka yang dikembangkan sebelumnya, desain protokol ini adalah satu-satunya yang menangani Lapisan 1 dengan resistansi struktural terhadap penyensoran, Lapisan 2 dengan penyembunyian, dan membatasi Lapisan 3 berkat jaminan resistansi terhadap penyensoran yang diberikan oleh penyembunyian. Baik Constellation maupun Giga belum mencapai semuanya secara penuh.

Hal yang membuat perbandingan ini sangat menarik adalah bahwa Resnick, salah satu penulis kondisi ideal teoretis tersebut, juga merupakan salah satu penulis Constellation, protokol yang secara sadar menyimpang darinya. Ini mencerminkan penilaian yang disengaja bahwa desain penuh berbasis HECC belum dapat diterapkan pada jaringan produksi berskala Solana, dan resistansi struktural terhadap penyensoran merupakan masalah yang lebih mendesak untuk diselesaikan terlebih dahulu. Makalah tersebut menjadi pedoman utama Constellation: spesifikasi formal mengenai arah pengembangan protokol, meskipun semuanya belum dapat diwujudkan sekaligus. 

Ethereum Braid

Braid adalah proposal MCP utama Ethereum yang diperkenalkan oleh Max Resnick dan saat ini sedang dipertimbangkan sebagai bagian dari roadmap Scourge Ethereum bersama desain inclusion list FOCIL yang menjadi pesaingnya. Penyertaannya di sini lebih bertujuan memberikan konteks daripada perbandingan teknis; seluruh industri sedang berupaya menyelesaikan masalah struktural yang sama, tetapi dari titik awal berbeda.

Braid menerapkan MCP dengan memungkinkan beberapa proposer membangun blok pada chain paralel secara bersamaan dalam slot yang sama, sementara lapisan eksekusi menggabungkan, menghapus duplikasi, dan mengurutkan transaksi berdasarkan aturan yang telah ditentukan. Braid tidak memperkenalkan peran protokol tambahan. Perbedaan terpentingnya adalah bahwa keamanan Braid sangat bergantung pada mempool terenkripsi, sehingga penyembunyian menjadi prasyarat, bukan sesuatu yang ditangguhkan. Braid masih berupa proposal riset yang belum diterapkan, dan komunitas Ethereum belum mencapai konsensus mengenai apakah akan memilihnya daripada FOCIL.

Hal yang pada akhirnya dikonfirmasi Braid adalah bahwa argumen struktural untuk MCP melampaui satu chain tertentu. Perlu dicatat pula bahwa Resnick telah mengerjakan tiga dari empat proyek dalam bagian ini, yang mungkin merupakan sinyal paling jelas bahwa Constellation adalah hasil pemikiran berkelanjutan, lintas konteks, dan ketat secara akademis mengenai masalah yang tidak memiliki solusi mudah.

Catatan tentang PBS

Proposer-Builder Separation (PBS) layak disebutkan di sini sebagai pembanding yang kontras, bukan sebagai desain sebanding. Sementara setiap proyek dalam bagian ini mencoba membatasi secara struktural monopoli sementara leader, PBS menerimanya dan mengoptimalkan sistem di sekitarnya untuk mendistribusikan ulang hasil MEV. Constellation secara eksplisit tidak kompatibel dengan PBS—setelah diskresi leader dibatasi oleh catatan atestasi, tidak ada lagi yang dapat dijual oleh builder khusus. Fakta bahwa PBS telah menjadi mitigasi MEV dominan di Ethereum meskipun sama sekali tidak mengurangi kerugian pengguna merupakan mode kegagalan yang secara khusus ingin dihindari MCP.

Preseden di Luar Protokol

Sebelum Constellation diluncurkan, ekosistem Solana telah mereplikasi beberapa aspek MCP di luar protokol. Harmonic, misalnya, adalah lapisan agregasi pembangunan blok terbuka yang terus mengumpulkan dan mengevaluasi proposal blok dari beberapa builder independen, lalu menyajikannya kepada validator untuk dipilih secara kompetitif dalam waktu nyata. Ini bukan MCP dalam pengertian formal karena tidak ada resistansi terhadap penyensoran yang ditegakkan protokol, kuorum atestasi, atau batasan kriptografis terhadap diskresi leader. Namun, validator yang menjalankan Harmonic sudah memilih di antara beberapa proposal blok serentak, yang merupakan mekanisme inti yang ingin diabadikan MCP. Bersama BAM, keduanya merepresentasikan upaya ekosistem untuk menyelesaikan masalah struktur pasar tanpa menunggu penegakan pada tingkat protokol. Sistem di luar protokol ini menunjukkan bahwa permintaan terhadap properti menyerupai MCP cukup nyata sehingga builder tidak menunggu Constellation diluncurkan.

Pertanyaan Terbuka

Whitepaper Constellation adalah spesifikasi protokol. Dokumen ini membuktikan properti kebenaran berdasarkan asumsi yang dinyatakan dan secara tepat menangguhkan hal lainnya, yang sesuai untuk proposal v0.9. Berikut ini bukanlah daftar kegagalan Constellation, melainkan peta hal-hal yang perlu ditangani oleh SIMD dan iterasi mendatang agar MCP dapat diterapkan secara efektif di Solana. 

Tingkat kesulitan pertanyaan-pertanyaan ini tidak sama. Sebagian merupakan pekerjaan spesifikasi; keputusan desain yang dapat dan perlu diselesaikan Anza melalui proses SIMD normal. Sebagian lainnya adalah masalah terbuka yang benar-benar belum diselesaikan oleh komunitas riset MCP yang lebih luas, tetapi harus kita sadari saat membuka jalan untuk menjadi blockchain berskala besar pertama yang menerapkan MCP. Tidak ada satu SIMD pun yang dapat menyelesaikan masalah-masalah ini sendirian. Perbedaan ini penting karena mencampuradukkan keduanya berisiko melebih-lebihkan kekurangan Constellation atau meremehkan banyaknya pekerjaan yang tersisa.

Pekerjaan SIMD yang relatif langsung mencakup:

• Distribusi Fee: cara priority fee dibagi antara proposer, attester, dan kumpulan validator yang lebih luas telah dijelaskan, tetapi belum diuraikan sepenuhnya. Whitepaper menyatakan bahwa priority fee dikembalikan kepada ekosistem secara proporsional terhadap stake, tetapi mekanisme distribusi yang tepat antara proposer, attester, dan validator belum ditentukan.
• Struktur Imbalan Validator: cara proposer diberi kompensasi dibandingkan imbalan validator yang ada, serta apakah penghapusan fee transaksi voting dalam Alpenglow mengubah perhitungan bagi validator yang lebih kecil.
• Urutan Deployment: Constellation bergantung pada Alpenglow, yang dijadwalkan untuk Q3 2026. SIMD perlu menetapkan dependensi tersebut secara eksplisit dan menangani apa yang terjadi selama masa transisi dari Alpenglow standar ke Constellation+Alpenglow. Apakah ada SIMD prasyarat yang harus lebih dahulu diterapkan di mainnet?
• Tata Kelola Parameter Peran: jumlah proposer (p ≈ 16), jumlah attester (q ≈ 256), durasi siklus (△cycle = 50ms), dan parameter lain dari Tabel 1 whitepaper Constellation hanya disajikan sebagai saran. SIMD perlu menentukan cara parameter ini ditetapkan, dikelola, dan berpotensi diubah seiring waktu.

Pertanyaan yang lebih sulit (misalnya, eksekusi asinkron, slashing, dan privasi lapisan pengiriman) dibahas dalam subbagian berikut. Komunitas riset MCP sedang aktif mengerjakan pertanyaan-pertanyaan ini dan kita harus mempertimbangkannya karena pilihan desain Constellation dapat mempersempit atau memperluas jalan menuju solusi tertentu di masa mendatang.

Eksekusi Asinkron

Dalam eksekusi sinkron, proposer yang menerima transaksi dalam plaintext, atau dapat mendekodenya lebih awal dalam model pengiriman naif, mengetahui konten transaksi dan dapat menyimulasikan hasilnya. Proposer dapat menjalankan transaksi terhadap state saat ini untuk menghitung secara tepat hasil eksekusinya, termasuk harga swap, perubahan saldo account, dan peluang arbitrase lanjutan. Inilah yang membuat serangan sandwich presisi secara mekanis. Penyerang dapat melihat swap besar dan menghitung berapa banyak yang diperlukan untuk melakukan front-running demi memaksimalkan keuntungan.

Eksekusi asinkron menghilangkan separuh kedua dari keunggulan tersebut, tetapi hanya jika digabungkan dengan MCP. Jika konsensus menetapkan pengurutan transaksi sebelum eksekusi, proposer yang dapat melihat konten transaksi tidak dapat menyimulasikan hasil eksekusi terhadap final state yang diketahui karena state tersebut belum ada pada saat pengurutan. Keunggulan informasi secara efektif menyempit dari “Saya tahu apa yang dilakukan transaksi ini dan dalam urutan apa transaksi ini dieksekusi” menjadi “Saya tahu transaksi apa ini, tetapi tidak tahu apa yang akan dilakukannya relatif terhadap kumpulan akhir yang telah diurutkan.” Manfaat ini bergantung pada proposer yang tidak mengendalikan pengurutan final. Dalam model leader tunggal, eksekusi asinkron saja tidak memberikan perlindungan ini karena leader tetap memiliki diskresi penuh atas pengurutan dan dapat menempatkan transaksinya sendiri secara menguntungkan, terlepas dari kapan eksekusi berlangsung. Kombinasi pengurutan terbatas dan eksekusi tertunda inilah yang mempersempit permukaan serangan.

Perlu diperhatikan bahwa eksekusi asinkron tidak sepenuhnya menutup Lapisan 2. Proposer yang canggih masih dapat membuat inferensi kategoris. Misalnya, proposer masih dapat melihat bahwa suatu transaksi menyentuh liquidity pool tertentu dan mungkin menyimpulkan arah yang kemungkinan terjadi tanpa mengetahui hasil pastinya. Hal ini secara berarti meningkatkan hambatan terhadap bentuk eksploitasi yang paling mekanis dan menguntungkan, serta merupakan jalur arsitektural paling jelas untuk mempersempit Lapisan 2 tanpa memerlukan penyembunyian kriptografis di lapisan konsensus. Perlu dicatat bahwa inilah pendekatan yang dipilih Sei Giga, dengan menjadikan eksekusi asinkron sebagai prioritas arsitektural utama bersama MCP.

Hal ini memunculkan pertanyaan wajar yang patut direnungkan: Mengapa eksekusi asinkron tidak dikerjakan lebih dahulu? Eksekusi asinkron mempersempit Lapisan 2 dan secara prinsip dapat diterapkan sebagai perubahan terbatas pada lapisan eksekusi tanpa memperkenalkan kompleksitas protokol tambahan MCP (yaitu, peran node baru, persyaratan sinkronisasi waktu UTC, desain slashing yang belum terselesaikan, dan overhead shredding yang berlipat ganda). 

Argumen terkuat untuk urutan ini adalah bahwa eksekusi asinkron dan MCP menyelesaikan masalah berbeda. MCP memberikan batasan pengurutan struktural yang tidak dapat diberikan oleh eksekusi asinkron saja—validator yang tidak dapat menyimulasikan hasil eksekusi, tetapi masih dapat melihat konten transaksi, tetap dapat menggunakan diskresi atas pengurutan dalam jendela yang diizinkan protokol. Alasan untuk mengerjakan MCP terlebih dahulu adalah karena MCP membatasi Lapisan 1 pada tingkat struktural, dan Lapisan 1 merupakan ancaman yang lebih mudah dikenali serta lebih mendesak secara ekonomi. Menambahkan eksekusi asinkron ke model eksekusi sinkron Solana yang ada, mengingat asumsi composability dan arsitektur programnya, merupakan masalah engineering yang lebih sulit daripada membangunnya sejak awal pada chain baru. Sei Giga memiliki keleluasaan untuk mendesain eksekusi asinkron sejak hari pertama, sedangkan Solana tidak. Asimetri praktis ini mungkin sama pentingnya dengan argumen prioritas teoretis dalam menjelaskan mengapa MCP dikerjakan terlebih dahulu. Arsitektur Alpenglow juga membuat MCP lebih mudah diterapkan dibandingkan jika dibangun di atas Tower BFT, yang kami bahas dalam subbagian berikut mengenai kompleksitas protokol.

Apakah urutan tersebut tepat masih merupakan pertanyaan terbuka yang wajar. Constellation membiarkan Lapisan 2 tetap utuh, yang bermasalah mengingat vektor serangan baru yang diperkenalkan MCP di Lapisan 3. Hal ini pada gilirannya dapat membuat serangan Lapisan 2 lebih menguntungkan karena kedua permukaan serangan tersebut saling melengkapi. Misalnya, proposer yang dapat melihat transaksi DEX besar dapat menunda pshreds-nya agar transaksi tersebut keluar dari jendela batch saat ini, sembari melakukan front-running dengan transaksinya sendiri dalam jendela yang sama. Visibilitas Lapisan 2 dan permainan timing Lapisan 3 merupakan senjata terpadu dalam permukaan serangan yang sama dan hanya akan menjadi semakin canggih seiring kematangan Solana.

Slashing

Penegakan kriptografis berfungsi baik ketika perilaku buruk suatu pihak menghasilkan artefak yang dapat diverifikasi (misalnya, tanda tangan yang bertentangan, kegagalan pemeriksaan validitas, atau commitment cacat yang dapat dibuktikan). Constellation menyelesaikan kekhawatiran resistansi terhadap penyensoran di Lapisan 1 dengan sangat bersih karena leader yang mengecualikan transaksi yang telah diatestasi akan menghasilkan blok tidak valid, dan ketidakvalidan tersebut dapat dibuktikan secara matematis. Permainan timing dan manipulasi latensi tidak menghasilkan artefak semacam itu. Kesulitannya adalah bahwa jenis perilaku buruk tersebut tidak dapat dibedakan dari keterlambatan jaringan yang wajar jika dilihat per tindakan. Perilaku buruk itu hadir sebagai suatu ketiadaan, dan ini tidak dapat dibuktikan secara kriptografis. Satu-satunya alat yang tersedia adalah pencegahan ekonomi, yang memerlukan slashing. 

Tantangan slashing adalah bahwa mekanisme ini secara tradisional memerlukan pelanggaran yang dapat dibuktikan. Mekanisme fault witness Constellation menangani kasus ketika proposer yang menandatangani dua pshreds yang bertentangan dapat diidentifikasi dan dikeluarkan. Namun, manipulasi latensi strategis tidak menghasilkan fault witness. Tidak ada equivocation, tidak ada penandatanganan ganda, dan tidak ada jejak onchain. Proposer yang sekadar menunda penerusan pshreds beberapa milidetik secara konsisten dan selektif tidak meninggalkan apa pun untuk dikenai slashing. 

Jika pshreds milik proposer secara konsisten tiba di attester pada beberapa milidetik terakhir jendela siklus—sepanjang banyak siklus, untuk transaksi yang kebetulan menjadi pesaing pengiriman milik proposer itu sendiri—mekanisme slashing dengan spesifikasi yang baik dapat memperlakukan pola ini sebagai bukti manipulasi sistematis tanpa satu pun tindakan yang dapat dibuktikan berbahaya. Slashing tradisional tidak dapat menangani ini secara langsung. Dalam bentuk kanonisnya, slashing memerlukan bukti yang tidak ambigu dan berdiri sendiri, dan bukti semacam itu tidak tersedia bagi proposer yang sekadar menunda penerusan beberapa milidetik. Hal yang berbeda adalah polanya.

Di sinilah keuangan tradisional dapat memberikan pelajaran bagi keuangan terdesentralisasi terkait pendekatan regulator terhadap manipulasi berbasis latensi. Penegakan terhadap spoofing berdasarkan Dodd-Frank Act, misalnya, mengandalkan deteksi pola statistik (misalnya, rasio pembatalan terhadap eksekusi, distribusi timing pembatalan, dan korelasi dampak harga), alih-alih membuktikan niat untuk setiap order. Tidak satu pun kejadian dapat dibuktikan disengaja. Namun, polanya dapat dibuktikan. Logika yang sama berlaku karena keteraturan statistik bersifat objektif meskipun tindakan individual tidak demikian. Selain itu, insentif ekonomi untuk memanipulasi juga ada dalam kumpulan proposer permissionless, sebagaimana pada trader berfrekuensi tinggi dalam keuangan tradisional. Analogi ini tidak lagi berlaku pada aspek penegakan. Dodd-Frank mengandalkan regulator dengan kewenangan mengeluarkan subpoena, sedangkan konteks trustless mengharuskan mekanisme deteksi dan penalti diabadikan dalam protokol itu sendiri.

Kami mengusulkan adaptasi fisherman nodes sebagai kandidat mekanisme untuk mengatasi kesenjangan ini. Awalnya diperkenalkan dalam riset Vitalik mengenai ketersediaan data, fisherman nodes dapat diadaptasi sebagai kelompok pengamat yang memantau data atestasi sepanjang banyak siklus dan mengirimkan statistical fraud proof ke protokol arbitrase yang diabadikan. Keterlambatan individual bersifat subjektif. Namun, pola yang dihitung secara deterministik sepanjang n siklus bersifat objektif. Ini adalah wawasan yang sama dengan dasar fraud proof dalam optimistic rollup, tetapi diterapkan pada perilaku timing alih-alih transisi state. Selain itu, protokol arbitrase yang diabadikan untuk statistical fraud proof pada dasarnya tidak berbeda secara kategoris dari tooling tata kelola baru yang saat ini sedang dikembangkan, yang akan memungkinkan staker mengganti suara validator mereka dalam proposal tata kelola mendatang. Jika Solana siap memiliki infrastruktur untuk penggantian suara oleh staker, fondasi teknis bagi sistem arbitrase berbasis fisherman mungkin lebih dekat daripada yang terlihat.

Eksplorasi fisherman nodes ini menawarkan arah yang lebih kredibel dibandingkan memperluas slashing kanonis untuk mencakup tindakan yang tidak meninggalkan satu pun jejak onchain, serta merupakan arah yang mungkin telah dapat didukung oleh pengembangan infrastruktur tata kelola protokol saat ini. Meskipun demikian, tiga keterbatasan perlu ditangani dalam spesifikasi konkret apa pun. Pertama, melakukan analisis statistik terhadap data timing atestasi sepanjang ribuan siklus bukanlah hal sepele dan dapat dengan mudah meningkatkan persyaratan hardware validator. Hal ini menaikkan biaya operasional dan berpotensi memusatkan peran deteksi fraud pada sekelompok kecil pihak canggih. Kedua, setiap spesifikasi ambang harus cukup tangguh untuk membedakan variasi jaringan yang wajar dari manipulasi strategis tanpa terlalu agresif hingga menghasilkan false positive. Ketiga, protokol arbitrase itu sendiri memperkenalkan permukaan serangan baru yang memungkinkan sistem berbasis fisherman ini dimanipulasi melalui pelaporan terkoordinasi. Desain protokol arbitrase apa pun perlu mempertimbangkan hal ini, mungkin melalui mekanisme insentif yang membuat operasi fisherman layak bagi peserta yang lebih kecil, atau skema agregasi untuk mendistribusikan komputasi ke seluruh kumpulan fisherman.

Pertanyaan riset konkret yang kami ajukan adalah: Dapatkah kerangka statistical fraud proof dirumuskan—dengan mendefinisikan parameter ambang, memperhitungkan variasi jaringan, dan menentukan skala penalti—yang sekaligus cukup tangguh untuk mencegah manipulasi latensi sistemis, cukup konservatif untuk menghindari penalti terhadap variasi yang wajar, dan cukup sederhana untuk menahan manipulasi adversarial oleh operator canggih? Ini termasuk masalah terbuka yang paling menuntut secara teknis dalam literatur MCP dan belum diselesaikan oleh komunitas riset yang lebih luas.

Penyembunyian

Slashing bukan satu-satunya solusi untuk permainan manipulasi timing dan latensi. Penyembunyian menangani masalah pengurutan dengan konten terlihat sekaligus manipulasi timing-latensi, yang tidak dapat ditangani sendiri oleh eksekusi asinkron maupun slashing. Constellation menerapkan penyembunyian parsial (yaitu, konten transaksi hanya terlihat oleh proposer penerima dan oleh leader setelah tenggat siklus), tetapi tidak mencapai properti penyembunyian penuh. Permukaan serangan bertambah sesuai jumlah proposer yang dipilih pengguna sebagai tujuan pengiriman. Meskipun penyembunyian parsial ini mempersempit permukaan serangan dibandingkan visibilitas penuh, mekanisme tersebut tidak menutupnya. Penyembunyian penuh, ketika tidak ada pihak yang mengamati konten transaksi sebelum konfirmasi, masih menjadi masalah terbuka bagi Constellation.

Kondisi ideal teoretisnya adalah pendekatan yang diuraikan dalam Garimidi et al., yang menggunakan Hiding Erasure-Correcting Code (HECC) sebagai primitive. Tidak seperti Reed-Solomon standar milik Constellation, HECC memberikan jaminan teoretis-informasi bahwa adversary yang mengumpulkan shreds di bawah ambang tertentu tidak mempelajari apa pun mengenai konten transaksi. Constellation memilih untuk tetap menggunakan erasure coding yang saat ini aktif di Solana melalui Turbine.

Perkembangan terbaru yang paling relevan adalah Block Assembly Marketplace (BAM) dari Jito, yang menggunakan Trusted Execution Environments (TEEs) untuk membuat mempool terenkripsi tempat transaksi tetap privat hingga eksekusi. BAM menunjukkan adanya peningkatan permintaan nyata terhadap privasi konten di Solana. Namun, penyembunyian berbasis TEE memiliki keterbatasan karena memindahkan asumsi kepercayaan kepada produsen hardware, yang merupakan batasan penting bagi protokol yang menginginkan operasi trustless. Jalur ke depan yang menggunakan enkripsi ambang untuk menawarkan alternatif yang lebih berprinsip perlu dieksplorasi secara menyeluruh.

BAM penting karena merepresentasikan upaya di luar protokol untuk menyelesaikan masalah visibilitas konten yang ditangguhkan Constellation. Secara operasional, Jito berada dalam posisi untuk menyediakan privasi transaksi berskala besar melalui BAM bahkan sebelum Constellation diluncurkan. Hal ini memunculkan pertanyaan apakah penyembunyian pada tingkat protokol tetap mendesak jika solusi lapisan aplikasi sudah dapat menyediakannya. Jawabannya sepenuhnya bergantung pada asumsi kepercayaan dan apakah produsen hardware dianggap “cukup” dapat dipercaya dibandingkan jaminan yang secara teori dapat diberikan protokol. Meskipun demikian, ini tidak dapat diperlakukan sebagai solusi permanen. Jalur yang mungkin ditempuh adalah BAM memberikan privasi jangka pendek, sementara iterasi Constellation mendatang mengeksplorasi enkripsi ambang sebagai alternatif jangka panjang.

Bagi protokol yang bercita-cita menjadi infrastruktur Internet Capital Markets, penyembunyian parsial adalah langkah maju yang berarti, tetapi bukan tujuan akhir. Kesenjangan yang tersisa adalah perbedaan antara struktur pasar yang adil dan struktur yang sekadar tidak seburuk struktur yang ada saat ini. 

Kompleksitas Protokol

Constellation adalah upgrade paling ambisius secara struktural yang pernah diusulkan untuk Solana sejak awal keberadaannya. Constellation memperkenalkan tiga peran node baru, model timing baru yang bergantung pada sinkronisasi wall-clock UTC, proses erasure coding baru, jenis pesan baru, dan mode kegagalan baru, semuanya dibangun di atas Alpenglow, yang bahkan belum aktif di mainnet. Pertanyaan apakah ini waktu yang tepat untuk menanggung kompleksitas tersebut merupakan persoalan serius yang memerlukan lebih dari sekadar optimisme.

Solana dahulu memperoleh reputasi buruk karena berbagai gangguan yang melanda jaringan selama 2021 dan 2022. Gangguan tersebut memiliki tema yang sama—semuanya disebabkan oleh sulitnya menalar edge case dalam protokol baru ber-throughput tinggi di bawah kondisi beban dunia nyata. Uptime lebih dari dua tahun yang dicapai jaringan sejak saat itu merupakan pencapaian nyata, yang ditempa melalui proses iterasi penuh kesulitan. Rekam jejak tersebut mendukung keyakinan terhadap kematangan Solana. 

Kini, setiap perubahan tingkat protokol sebesar Constellation memerlukan implementasi serentak di Agave dan Firedancer. Hal ini memerlukan penyelarasan antara dua tim pengembangan independen terkait semantik protokol, edge case, dan asumsi timing yang baru bagi keduanya. Kompleksitas untuk mencapai hal ini pada Alpenglow saja sudah signifikan, dan Constellation hanya akan menambahnya. Ini bukan argumen untuk tidak melanjutkannya. Sebaliknya, ini adalah argumen bahwa SIMD Constellation nantinya harus menyertakan rencana yang jelas untuk implementasi multiklien.

Lembaga keuangan mulai hadir secara onchain. Konsekuensi dari gangguan besar secara nyata lebih tinggi dibandingkan pada 2021, baik dalam hal kerugian reputasi maupun ekonomi. Sebagai komunitas, kita perlu jujur mengenai kompleksitas yang diperkenalkan Constellation. SIMD mendatang harus ditangani dengan ketelitian yang layak bagi sistem keuangan global. 

Pertanyaan mengapa harus sekarang tentu muncul. Apakah kita benar-benar ingin menanggung risiko upgrade sebesar ini? Tidakkah ada upgrade bertahap yang dapat kita lakukan seiring waktu untuk memperhalus perubahan ini? Eksplorasi eksekusi asinkron dan slashing yang disebutkan sebelumnya, misalnya, menunjukkan bahwa alternatif bertahap mungkin dilakukan. Versi roadmap Constellation yang memungkinkan ekosistem memperoleh manfaat dari deployment bertahap untuk berbagai upgrade pelengkap juga mungkin dilakukan. Apakah pendekatan ini dianggap bijaksana atau menghambat percepatan merupakan pertanyaan mengenai nilai sekaligus teknis, dan perbedaan pendapat yang wajar dapat terjadi. Kita membangun sistem makna sama besarnya dengan membangun sistem untuk keuangan.

Hal ini sudah terjadi dalam praktik. Anza telah mengonfirmasi bahwa slot 200ms dan jendela leader dua slot akan diluncurkan sebelum Constellation. Ini berarti Solana akan mengalami peningkatan performa berarti yang menangani sebagian kekhawatiran latensi urutan yang disampaikan komunitas—yang akan kami bahas di bagian berikut—tanpa memerlukan seluruh kompleksitas MCP. Jika slot 200ms membuat jalur konfirmasi Solana cukup mendekati overhead yang diproyeksikan Constellation sehingga biaya marginal MCP menjadi kecil, argumen politisnya jauh lebih mudah disampaikan. Namun, jika 200ms dianggap “cukup baik” oleh pelaku perdagangan yang sudah mapan, urgensi Constellation akan berkurang. Proyeksi latensi komparatif yang menampilkan slot 200ms dibandingkan slot 200ms dengan Constellation dapat membantu komunitas mengevaluasi biaya inkremental terhadap jaminan inkremental. Tentu saja, kita perlu menunggu dan melihat SIMD serta usulan implementasi Constellation nantinya.

Argumen terkuat untuk melanjutkan adalah peluang yang diciptakan Alpenglow. Constellation mewarisi model keamanan Alpenglow, menggunakan Rotor sebagai lapisan penyebaran datanya, dan memperoleh manfaat dari dihilangkannya kompleksitas Tower BFT. Biaya marginal penambahan MCP di atas Alpenglow lebih rendah daripada biaya memulai dari awal dengan desain konsensus masa depan. Menunggu tidaklah bebas biaya, mengingat eksplorasi pesaing kita untuk membawa MCP secara onchain, serta fakta bahwa menangguhkan resistansi terhadap penyensoran ke siklus upgrade mendatang pasti akan menghadirkan kompleksitas dan hambatan politisnya sendiri.

Jika bukan sekarang, kapan?

Kompleksitas ini dapat dibenarkan, tetapi pembenaran tersebut harus diperoleh melalui spesifikasi yang ketat, deployment bertahap, serta validasi empiris terhadap klaim latensi dan bandwidth yang saat ini diperdebatkan komunitas hanya berdasarkan teori. 

Apakah Constellation Selaras dengan IBRL?

Latensi Urutan versus Latensi Penyertaan

Reaksi awal komunitas Solana terhadap Constellation sangat terpolarisasi. Reaksi ini memunculkan perdebatan penting yang layak mendapatkan jawaban tepat, bukan jawaban diplomatis. Formulasi paling tajam berasal dari tweet Cavey, yang menyatakan bahwa “MCP dan IBRL pada dasarnya tidak kompatibel.” Ia berpendapat bahwa MCP secara langsung dan tidak diragukan lagi mengurangi bandwidth dan meningkatkan latensi dalam upaya memperbaiki struktur pasar. Tanggapan Toly sama tegasnya: “Anda salah. Tidak ada cara untuk mengurangi latensi penyertaan tanpa MCP.”

Keduanya benar secara teknis; mereka mengukur hal yang berbeda.

MCP mengurangi latensi penyertaan dan meningkatkan latensi urutan. Keduanya bukan properti yang sama, dan pencampuradukan keduanya merupakan sumber sebagian besar kebingungan dalam perdebatan saat ini.

Latensi urutan adalah waktu sejak transaksi dikirimkan hingga dieksekusi. Latensi ini secara inheren meningkat dalam MCP karena putaran attester, jendela siklus 50ms, dan langkah penyusunan batch semuanya menambahkan waktu yang tidak ada dalam jalur pengiriman TPU saat ini menuju leader yang kooperatif. Kritik bahwa pihak rasional yang mengirim ke beberapa proposer menggunakan lebih banyak bandwidth adalah benar. Jendela penggabungan yang menambah latensi juga benar. Semua ini merupakan biaya nyata yang harus diukur dan disampaikan kepada komunitas sebagai konsekuensi untuk menghapus penyensoran keras.

Latensi penyertaan adalah jangka waktu yang dijamin untuk menyertakan transaksi valid dengan fee kompetitif. Dalam model leader tunggal saat ini, jaminan ini pada dasarnya tidak memiliki batas. Artinya, leader yang ingin menunda atau mengecualikan transaksi tertentu dapat melakukannya, dan tidak ada mekanisme protokol untuk menghentikannya. Latensi yang telah dialami pengguna mencakup seluruh hambatan dari penahanan, penjadwalan, dan permainan timing, serta pengurutan selektif yang diberlakukan leader. Argumen tandingan bahwa waktu konfirmasi dunia nyata mencakup latensi akibat permainan tersebut, sehingga pengalaman bersih pengguna dapat meningkat, secara umum benar dalam kerangka ini dan didukung oleh diskusi komunitas yang saat ini berlangsung di X. 

Pertanyaan sebenarnya adalah latensi mana yang perlu dioptimalkan.

FIFO versus FCFS versus FBO

Sebelum menelaah latensi mana yang perlu dioptimalkan, penting untuk memahami perdebatan terkait yang sedang dibahas komunitas secara bersamaan: apakah MCP kompatibel dengan FIFO.

FIFO (First In, First Out) adalah prinsip pengurutan umum yang memproses transaksi sesuai urutan kedatangannya. Umberto menjelaskan panjang lebar bahwa jawabannya secara inheren bernuansa. MCP dapat menghasilkan apa yang disebut “FIFO probabilistik,” tetapi hanya dalam kondisi infrastruktur tertentu. Pada dasarnya, jika pengguna secara geografis cukup dekat dengan cukup banyak pengusul untuk menghindari penyensoran, dan para pengusul tersebut cukup dekat dengan atestator untuk dengan cepat mencapai ambang atestasi 40% yang menjamin penyertaan, maka secara praktis pengguna akan mengalami penyertaan FIFO. Artinya, transaksi mereka disertakan sebelum pesaing sempat mengamati dan bereaksi terhadapnya. Perlombaan berakhir saat penyertaan, bukan saat eksekusi. Dalam kondisi tersebut, MCP mendekati FIFO sebagai properti yang muncul secara alami, bukan sebagai aturan protokol.

Masalahnya, infrastruktur Solana saat ini tidak memenuhi kondisi tersebut. Stake terkonsentrasi di beberapa wilayah, sehingga pembentukan kuorum terhambat oleh kebutuhan untuk menjangkau kantong-kantong stake yang padat. Konsentrasi ini menciptakan jendela waktu yang memungkinkan pengamat yang “diuntungkan secara geografis” melakukan frontrunning terhadap transaksi yang sedang dikirim. Apakah deployment Constellation disertai distribusi geografis dan kepadatan atestator yang dibutuhkan FIFO probabilistik sama pentingnya dengan desain protokol itu sendiri. Protokol yang menjamin ketahanan terhadap penyensoran tetapi memungkinkan frontrunning berbasis latensi akibat infrastruktur yang tersebar jarang tidak akan menghadirkan keadilan pasar yang dijanjikan buku putihnya.

Pertanyaan terkait tetapi berbeda adalah apakah Constellation sebenarnya dapat menerapkan FCFS, tetapi memilih untuk tidak melakukannya. FIFO merupakan properti infrastruktur yang muncul secara alami, sedangkan FCFS (First Come, First Served) adalah aturan protokol spesifik yang memastikan transaksi yang pertama tiba diproses secara deterministik. Perlu dicatat bahwa Constellation memang mengurutkan secara deterministik—transaksi diurutkan berdasarkan priority fee dalam setiap batch—jadi pertanyaannya bukan apakah pengurutan ditegakkan oleh protokol, melainkan apakah waktu kedatangan seharusnya menentukan pengurutan tersebut dibandingkan dengan priority fee.

Perdebatan terbaru telah memunculkan keberatan yang lebih mendasar daripada yang awalnya diajukan—FCFS mungkin sama sekali tidak dapat ditegakkan dalam konteks trustless. Validator dapat dengan mudah memberikan informasi palsu tentang urutan kedatangan transaksi tanpa meninggalkan artefak onchain apa pun. Ini adalah masalah ketiadaan bukti yang sama, yang membuat manipulasi waktu tidak dapat dikenai slashing dalam pengertian tradisional, dan mungkin memerlukan solusi yang lebih kreatif (misalnya, pendekatan deteksi pola statistik yang dikembangkan dalam subbagian slashing). Aturan protokol yang akan dipatuhi validator jujur tetapi dapat diam-diam diabaikan validator tidak jujur bukanlah jaminan yang bermakna. Hal ini mengubah cara pandang terhadap tidak disertakannya FCFS oleh Constellation: dari preferensi desain yang perlu dijelaskan menjadi pengakuan bahwa, dalam kumpulan validator permissionless, FCFS mungkin belum dapat diterapkan di Solana sebagai properti protokol yang tegas, setidaknya berdasarkan asumsi saat ini. Jika FCFS benar-benar tidak dapat ditegakkan dalam kumpulan validator permissionless berdasarkan asumsi saat ini, maka tugas SIMD adalah menyatakan batasan ini secara eksplisit dan membenarkan pengurutan berdasarkan priority fee sebagai desain default yang tepat. Membiarkan komunitas memperdebatkan FCFS seolah-olah itu merupakan alternatif yang layak tetapi sengaja tidak diterapkan Constellation, alih-alih menjelaskannya sebagai properti yang mungkin tidak dapat diterapkan, hanya akan menimbulkan lebih banyak gesekan dalam komunitas.

Pengurutan berdasarkan priority fee dalam interval waktu tetap bukanlah kompromi baru. Pendekatan ini dikenal sebagai frequent batch auction (FBA), yaitu desain mikrostruktur pasar yang mendapat dukungan akademis signifikan. Sebagai contoh, Budish, Cramton, dan Shim berpendapat dalam Perlombaan Senjata Perdagangan Frekuensi Tinggi: Frequent Batch Auction sebagai Respons Desain Pasar (2015) bahwa lelang batch waktu diskret dengan harga kliring seragam menghilangkan perlombaan kecepatan yang diciptakan pasar waktu kontinu. Ini menggantikan persaingan berbasis latensi dengan persaingan berbasis harga. Constellation mengadopsi pendekatan ini untuk memperkenalkan Fixed Batch Ordering (FBO) berdasarkan priority fee. Dengan demikian, siklus 50ms Constellation menerapkan pendekatan tersebut: transaksi bersaing berdasarkan biaya, bukan waktu kedatangan dalam setiap batch, dan semua transaksi dalam batch yang sama menerima perlakuan pengurutan yang sama. Inilah tepatnya kelas aplikasi yang sebelumnya diidentifikasi sebagai belum tersedia dalam skala besar di Solana. 

Perdebatan FIFO, FCFS, dan FBO pada dasarnya membahas kekhawatiran mendasar yang sama: siapa yang mengendalikan pengurutan setelah ketahanan terhadap penyensoran dijamin, dan apakah struktur pasar yang ingin diciptakan Constellation benar-benar adil atau sekadar tidak seburuk kondisi yang ada saat ini. Constellation menutup bentuk manipulasi yang paling mudah dikenali. Apa yang menggantikannya bergantung pada pilihan yang diserahkan buku putih kepada SIMD.     

Jadi, Apa yang Kita Optimalkan?

Latensi urutan paling penting bagi aplikasi perdagangan yang sudah ada (yaitu AMM, prop desk, dan CLOB). Aplikasi ini dirancang berdasarkan asumsi bahwa pihak yang paling cepat dan paling kompetitif dalam biaya akan menang, dan mereka telah membangun infrastrukturnya sesuai asumsi tersebut. Perdagangan seharusnya hanya dibatasi oleh hukum fisika agar menghadirkan pengalaman pengguna yang tak tertandingi di Solana. Bagi sebagian pengguna ini, Constellation merupakan kemunduran dalam metrik yang paling penting bagi mereka. Kekhawatirannya adalah Solana dapat mengulangi kesalahan fatal yang pernah dilakukan Ethereum, yaitu memprioritaskan struktur pasar di atas performa, yang dapat menyebabkan eksekusi berpindah dari chain. Ini adalah risiko nyata yang patut dibahas.

Untuk aplikasi keuangan yang dirancang agar dapat diwujudkan oleh Constellation (yaitu lelang onchain, order book dengan jaminan penyertaan yang andal, dan protokol DeFi yang tahan penyensoran), latensi penyertaan adalah metrik yang tepat. Limit order yang dapat dikenai frontrunning atau ditunda secara selektif memberikan jaminan yang lebih lemah daripada order bergaya bursa, terlepas dari seberapa cepat konfirmasinya secara nominal. Solana kini dapat mendukung aplikasi perdagangan berbasis lelang batch dengan harga kliring seragam, di mana pengurutan seharusnya tidak memengaruhi harga eksekusi. Kelas aplikasi ini pada dasarnya belum tersedia di Solana saat ini, tepat karena jaminan penyertaan belum tersedia. Dapat dikatakan bahwa Constellation terlalu berfokus pada desain yang dioptimalkan bagi pengguna yang belum hadir dalam skala besar di Solana, dengan mengorbankan pengguna yang sudah ada; argumen yang telah disampaikan oleh kontributor inti.   

Kekhawatiran tentang latensi urutan perlu dipahami dalam konteks bahwa Solana saat ini kehilangan pangsa signifikan dalam perdagangan perpetual kepada Hyperliquid—bursa perpetual dengan sequencer terpusat yang dibangun khusus, yang sama sekali tidak berpura-pura terdesentralisasi, tetapi menawarkan pengalaman eksekusi submilidetik yang menarik dan dibutuhkan oleh trader serta aplikasi canggih. Hyperliquid secara sadar memilih untuk membangun produk yang benar-benar ingin digunakan para profesional, dengan mengorbankan prinsip-prinsip inti yang membuat kripto benar-benar menjadi “kripto.” Risiko implisit Constellation adalah bahwa penambahan overhead komunikasi dan putaran atestasi ke jalur konfirmasi merupakan tradeoff yang sama seperti yang dilakukan Hyperliquid, tetapi ke arah yang keliru. Para pengkritik memandang negatif pengorbanan potensi keunggulan performa apa pun yang saat ini membuat Solana mampu bersaing dengan aplikasi perdagangan terpusat, sementara belum ada aplikasi keuangan yang membenarkan tradeoff tersebut, dan mereka menyuarakannya dengan lantang.

Kekhawatiran ini tidak boleh begitu saja dikesampingkan. Kita dapat merumuskan ulang pertanyaan sebelumnya tentang apakah sebaiknya mengoptimalkan latensi urutan atau penyertaan menjadi apakah Solana mampu menanggung tradeoff tersebut, mengingat sumber persaingannya saat ini.

Namun, ada persoalan yang lebih mendalam. Perbandingan dengan Hyperliquid memperjelas bahwa makna IBRL mungkin telah bergeser seiring waktu. Motivasi awal Toly dan Raj dalam membangun Solana adalah ketahanan terhadap penyensoran: “Agar produk DeFi dapat menarik miliaran pengguna dan perangkat, kita perlu menskalakan ketahanan terhadap penyensoran….Ini adalah satu-satunya masalah terpenting yang harus diselesaikan dan seluruh motivasi kami dalam membangun Solana.” IBRL muncul jauh kemudian sebagai perwujudan rekayasa dari misi tersebut: membangun dengan cukup cepat agar jaringan terdesentralisasi dapat mengungguli infrastruktur terpusat dalam metrik yang penting. Sejak saat itu, IBRL memperoleh makna tekno-optimisnya sendiri dan menjadi bagian yang ada di mana-mana dalam semangat budaya Solana. IBRL merupakan perpaduan seimbang antara diktat rekayasa, semboyan budaya, dan doa sekuler. Bagi banyak orang, IBRL telah menjadi tujuan, bukan sarana, dengan minimalisasi latensi urutan sebagai tujuan itu sendiri yang terlepas dari sasaran ketahanan terhadap penyensoran yang awalnya ingin diwujudkannya.

Jika pergeseran ini telah terjadi, dan tampaknya memang demikian, Constellation akan menghadapi penolakan budaya yang kuat. Dinamika ini bukan hal baru, mengingat penolakan komunitas terhadap SIMD-228, proposal kontroversial untuk mengurangi inflasi yang gagal lolos dalam pemungutan suara tata kelola. Bahkan proposal yang manfaatnya paling luas dapat gagal ketika bertentangan dengan pandangan komunitas yang telah mengakar. Constellation lebih bernuansa karena biaya bandwidth dan latensinya nyata, tetapi dampak bersihnya terhadap pengalaman pengguna belum dikuantifikasi. Menarik kesimpulan tegas ke arah mana pun terlalu dini tanpa data. Yang belum dimiliki komunitas, dan yang perlu disediakan Anza agar SIMD meyakinkan, adalah data empiris tentang kondisi jalur konfirmasi dalam keadaan jaringan yang realistis. Alpenglow tidak menghadapi masalah ini karena selaras dengan IBRL: pengurangan waktu hingga finalitas transaksi sebesar 100x dan konsensus yang lebih efisien. Argumen untuk Constellation lebih sulit diterima secara naluriah, tetapi tetap nyata jika benchmark mendatang mendukungnya.

Tampaknya komunitas akan menilai upgrade tahan penyensoran berdasarkan metrik performa yang sejak awal tidak dirancang untuk dioptimalkannya. Pertanyaan yang lebih produktif adalah apakah tradeoff tersebut sepadan. Ada biaya yang nyata dan terukur: sedikit tambahan latensi urutan dan bandwidth sebagai imbalan atas jaminan tegas yang ditegakkan protokol bahwa tidak ada leader yang dapat mengecualikan transaksi secara selektif. Ini merupakan prasyarat bagi aplikasi keuangan yang saat ini ingin dihadirkan Solana.

Pandangan kami adalah bahwa Constellation selaras dengan IBRL berdasarkan interpretasi yang tepat tentang tujuan awal IBRL. Apakah komunitas akan mencapai kesimpulan yang sama tidak terlalu bergantung pada keunggulan teknis, tetapi lebih pada apakah argumen empirisnya dapat dibuktikan dan pilihan desainnya dijelaskan.  

Kesimpulan

Constellation adalah proposal formal tingkat protokol pertama yang menghadirkan MCP ke blockchain produksi dalam skala besar. Constellation menyelesaikan penyensoran keras secara struktural sehingga transaksi dengan biaya kompetitif yang telah diatestasi oleh kuorum memadai tidak dapat dikecualikan dari blok yang valid. Jaminan kriptografis ini mengubah apa yang dapat dibangun di Solana. 

Hal-hal yang secara sadar ditunda Constellation juga sama pentingnya. Pengurutan dengan konten yang terlihat dimitigasi sebagian oleh model pengiriman Constellation, di mana hanya pengusul penerima yang melihat konten transaksi, tetapi permukaan serangan yang tersisa bertambah seiring jumlah pengusul yang menerima kiriman pengguna. Manipulasi waktu dan latensi tetap menjadi masalah terbesar yang belum terselesaikan dan saat ini tidak dapat dihukum berdasarkan desain yang ada. Potensi langkah selanjutnya (yaitu eksekusi asinkron, slashing, dan penyembunyian) telah diidentifikasi tetapi belum ditentukan, dan masing-masing menimbulkan kompleksitas tersendiri. Buku putih Constellation terbuka mengenai batasan-batasan ini, dan SIMD akhirnya juga harus demikian.

Pertanyaan tersulit yang diajukan Constellation adalah apakah Solana mampu menanggung tradeoff yang diperkenalkannya. Ada biaya yang nyata dan terukur dalam latensi pengurutan dan bandwidth yang masih belum dikuantifikasi. Di sisi lain, ada manfaat nyata tetapi belum terukur dari jaminan penyertaan yang belum memiliki basis aplikasi untuk membenarkannya dalam skala besar. Komunitas diminta berinvestasi dalam infrastruktur bagi aplikasi keuangan yang saat ini pada dasarnya belum tersedia di Solana, dengan potensi mengorbankan aplikasi perdagangan yang sudah ada. Apakah ini visioner atau prematur bergantung pada data yang belum dimiliki komunitas.

Argumen Constellation pada akhirnya akan terbukti atau gugur berdasarkan benchmark empirisnya di masa mendatang dalam kondisi realistis. Perbandingan jalur konfirmasi dengan slot 200ms saja dan slot 200ms di bawah Constellation adalah satu-satunya angka terpenting yang dapat disediakan Anza. Hingga saat itu, komunitas memperdebatkan tradeoff yang tidak dapat dikuantifikasi.

Pandangan kami adalah bahwa Constellation merupakan langkah selanjutnya yang tepat dalam roadmap protokol yang telah dibuka Alpenglow. Constellation selaras dengan IBRL berdasarkan interpretasi IBRL yang pada awalnya ingin diwujudkan Solana. Namun, pandangan ini bergantung pada apakah SIMD mencapai standar ketelitian yang layak bagi sistem keuangan global—dalam spesifikasi, deployment bertahap, pengujian, dan argumen empiris yang disajikannya kepada komunitas yang diminta untuk mengadopsinya.

Sumber Daya Tambahan

• Budish, E., Cramton, P., dan Shim, J. (2015). Perlombaan Senjata Perdagangan Frekuensi Tinggi: Frequent Batch Auction sebagai Respons Desain Pasar. https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., et al. (2019). Flash Boys 2.0: Frontrunning, Pengurutan Ulang Transaksi, dan Ketidakstabilan Konsensus di Bursa Terdesentralisasi. https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S., dan Clark, J. (2019). SoK: Ketidakjujuran Transparan: Serangan Front-Running pada Blockchain. https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J., dan Resnick, M. (2025). Multiple Concurrent Proposers: Mengapa dan Bagaimana. https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J., dan Wattenhofer, R. (2026). Solana Constellation: Pasar Modal Internet. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. dan Marsh, B. (2025). MEV dalam Blockchain Multiple Concurrent Proposer. https://arxiv.org/abs/2511.13080
• Yakovenko, T., dan Gokal, R. Pengembang Blockchain Berfokus pada Masalah yang Keliru. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem