Analisis Pro dan Kontra Pengusul Paralel Berganda (MCP)

Penulis: Maven11; Terjemahan: Jinse Caijing xiaozou

Multiple Concurrent Proposers (MCP) adalah mekanisme yang memungkinkan beberapa proposer berada dalam keadaan aktif secara bersamaan (perlu diingat untuk tidak bingung dengan Multi Context Protocol atau Secure Multi-Party Computation (MPC), meskipun ada beberapa kesamaan di antara mereka). Ini adalah solusi inovatif untuk masalah sensor. Artikel ini akan membahas mengapa membiarkan beberapa, dan bukan satu proposer, bertanggung jawab atas usulan blok menjadi elemen kunci dalam perbaikan desain mekanisme blockchain, termasuk prinsip operasinya dan signifikansi implementasinya.

Meskipun konsep inti MCP relatif mudah dipahami, saat ini hampir tidak ada blockchain yang benar-benar mengadopsi mekanisme tersebut. Namun, dalam beberapa hal, model operasi pool penambangan Bitcoin memiliki kesamaan dengan banyak pengusul yang bersamaan - siapa pun yang menjalankan node penuh Bitcoin dapat membuat transaksi dibundel ke dalam blockchain.

Di sisi lain, mekanisme pembangun konkuren ganda Solana memiliki beberapa kesamaan dengan bentuk implementasi MCP lengkap, setidaknya mencerminkan gagasan partisipasi bersama beberapa peserta yang berbeda dalam pembangunan blok (tetapi bukan usulan blok). Sementara di Ethereum, sekitar 95% blok dibangun melalui MEV-Boost. Meskipun terdapat beberapa pembangun aktif secara bersamaan, hanya satu pemenang yang dapat ditentukan dalam setiap lelang, sehingga keuntungan yang diperoleh Solana melalui pembangun konkuren ganda tidak berlaku di sini. Faktanya, saat ini tidak ada satu pun rantai yang dapat mewujudkan beberapa usulan yang secara bersamaan memiliki hak usulan blok.

Cara paling intuitif untuk memahami MCP adalah dengan membaginya menjadi dua aspek: banyak pengusul yang menyediakan blok secara bersamaan, dan penggabungan akhir dari sub-blok ini.

Kelompok pengusul ini kemungkinan besar akan mengadopsi bentuk subkomite (mirip dengan mekanisme yang ada di Ethereum), karena tidak realistis untuk melibatkan semua validator. Ini juga berarti bahwa perlu memastikan bahwa subkomite tunggal tidak didominasi oleh suatu kolam staking, jika tidak, ini dapat memicu masalah penyensoran dan kolusi. Selain itu, perlu dicatat bahwa para staker rumah yang legendaris biasanya memiliki keterampilan teknis yang terbatas—MCP akan secara signifikan meningkatkan kompleksitas sistem.

Berikut adalah keunggulan inti MCP yang layak diadopsi:

Alasan mendukung beberapa pengusul koncurrent:

--Meningkatkan ketahanan terhadap sensor (sangat penting dalam situasi saat ini)

--perluasan di tingkat protokol dasar dan bukan bergantung pada solusi eksternal

--Desentralisasi MEV (tidak lagi ditentukan oleh satu pencalon atau pembangun untuk mengemas transaksi)

Masalah yang secara langsung terungkap dengan penerapan MCP:

--Persaingan dalam pengurutan transaksi (pengemasan dan urutan) semakin intens (apakah ini dapat menyebabkan munculnya fenomena PGA?)

--Tantangan simulasi yang disebabkan oleh transaksi tidak valid

--Peningkatan Kebutuhan Perangkat Keras

--Masalah ketersediaan data transaksi yang tidak valid

--perlu memperkenalkan alat finality

Mari kita analisis fitur-fitur ini secara rinci, mulai dari keunggulan, kemudian mengevaluasi apakah potensi masalah dapat menjadi hambatan implementasi bagi blockchain publik yang memiliki beban teknis yang berat.

1. Keunggulan MCP

(1) Meningkatkan ketahanan terhadap sensor

Sebagian besar blockchain saat ini menggunakan mekanisme finalitas deterministik, dan proses konsensus mereka bergantung pada satu pemimpin untuk menentukan konten blok (dengan sedikit perbedaan). Setelah blok disiarkan, mayoritas validator mencapai konsensus dan memasukkannya ke dalam rantai kanonik. Ethereum mempercepat produksi blok melalui mekanisme subkomite (tetapi butuh waktu lebih lama bagi set lengkap validator untuk mencapai konsensus). Dalam kerangka kerja MCP, beberapa pengusul masing-masing membangun blok mereka sendiri dan akhirnya bergabung, yang berarti bahwa entri blok berpindah dari satu prinsipal (pengusul / pembangun / repeater, peran ini idealnya harus dibuang oleh MCP) ke model multi-saluran. Ini membuatnya jauh lebih sulit untuk ditinjau. Ketika ada beberapa badan kemasan, ketahanan sensor sistem akan ditingkatkan secara signifikan.

Titik kendala saat ini (perlu dicatat bahwa tim seperti Flashbots sedang memperbaiki situasi) terletak pada: pembangun tunggal memperoleh hak membangun blok dari satu penyelenggara tunggal melalui lelang, dan perantara (yang dapat dipercaya) sebagai pihak lelang semakin memperburuk sentralisasi. Meskipun protokol inti Ethereum terdesentralisasi, proses transaksi yang ada untuk masuk ke dalam rantai tidak demikian. Solana juga menghadapi masalah sentralisasi dari perantara/pembangun Jito, dan berusaha untuk menyelesaikannya melalui skema staking ulang (staking ulang "AVS" dengan hasil nyata pertama!). Pengguna Bitcoin dapat menyelesaikannya secara mandiri dengan menjalankan node penuh (biaya rendah), tetapi ini mengorbankan finalitas—Bitcoin mengadopsi finalitas probabilistik dan kekurangan "alat finalitas" yang diperlukan untuk mewujudkan MCP, yang bergantung pada aturan rantai terpanjang.

(2) Ekspansi di tingkat protokol dasar

Seringkali, banyak pengembangan dialihdayakan ke tim pihak ketiga untuk memperbaiki kelemahan desain yang melekat pada L1 (tidak terbatas pada Ethereum) untuk memecahkan masalah protokol inti. Menerapkan MCP berarti secara langsung menangani masalah yang seharusnya diselesaikan/disebabkan oleh solusi off-chain. Ini meningkatkan persyaratan perangkat keras (sambil meningkatkan ketahanan sensor), yang mungkin merupakan trade-off yang berharga tergantung pada kebutuhan desentralisasi oleh pengguna protokol. Solana, khususnya, kemungkinan akan menggunakan pendekatan ini untuk mengatasi sentralisasi Jito. Selain itu, karena upaya pembangunan blok didistribusikan ke banyak pihak, permintaan bandwidth jaringan secara keseluruhan pada akhirnya akan meningkat.

(3) Dispersi MEV

Efek paling unik dari MCP adalah bahwa ia mengubah model "lotere MEV" asli dengan memungkinkan MEV dari blok tertentu untuk dibagikan di antara beberapa pengusul aktif (daripada dimonopoli oleh satu pengusul atau pembangun). Validator (kebanyakan entitas perusahaan) lebih memilih aliran pendapatan yang stabil, dan mekanisme ini juga efektif dalam mencegah eksploitasi sepihak MEV (status quo) melalui penataan ulang transaksi. Fitur ini memiliki efek sinergis dengan tujuan tahan sensor.

Catatan: Jika Anda pernah membaca artikel kami sebelumnya, Anda mungkin sudah akrab dengan istilah teorema CAP ini: Ini adalah tiga karakteristik dasar yang harus dipenuhi agar sistem terdistribusi berfungsi dengan baik.

C： mewakili konsistensi (consistency), yaitu pengalaman pengguna harus tetap seragam di antara semua pengguna, setiap kali menggunakan sistem, harus terasa seperti berinteraksi dengan satu database.

**A：**Mewakili ketersediaan (availability), yang juga kita sebut sebagai keberlangsungan (liveness), yang berarti semua pesan harus diproses oleh node sistem dan tercermin dalam blok/kueri berikutnya, semua perintah harus dieksekusi.

P： Mewakili toleransi partisi (partition tolerance, atau anti-sensor), yang berarti sistem harus tetap konsisten dan tersedia meskipun mengalami serangan atau pemisahan jaringan node.

MCP adalah salah satu cara terbaik untuk mencapai elemen kunci dari teorema CAP (terutama ketahanan terhadap sensor) — elemen-elemen ini sering disederhanakan sebagai masalah teori permainan. Ingatlah: percaya pada protokol itu sendiri, bukan teori permainan.

Namun, keuntungan pasti disertai dengan biaya, hukum operasi teorema CAP menunjukkan: pencapaian besar selalu disertai dengan kekurangan yang sesuai - hampir tidak mungkin untuk sepenuhnya mempertimbangkan semua karakteristik. Oleh karena itu, mari kita periksa masalah yang mungkin muncul dari pelaksanaan MCP.

2、Masalah yang perlu diselesaikan oleh MCP

Masalah utamanya adalah bahwa MCP entah bagaimana dapat memicu fase persaingan ganda dalam sebuah blok. Yang pertama adalah biaya pengemasan transaksi, dan yang kedua adalah biaya penyortiran. Biaya penyortiran sangat sulit untuk ditangani, karena pada tahap pertama, produsen lokal hanya memiliki tampilan blok lokal dan bukan tampilan global. Ini berarti bahwa adalah tugas yang sulit untuk menghitung tawaran optimal secara akurat untuk posisi blok tertentu.

Ini tidak hanya sulit untuk dioperasikan, lebih penting lagi adalah (di bawah mekanisme lelang) ini akan membawa kita kembali ke era lelang Gas prioritas (PGA). Meskipun ketahanan terhadap sensor mendapatkan jaminan yang lebih kuat, pada dasarnya ini menghidupkan kembali masalah yang coba diselesaikan oleh MEV-Boost — median biaya Gas tinggi dari blok kompetitif, fenomena harga eksklusif pada tahap peng打包, dan sebagainya.

Selain menyortir masalah, termasuk pandangan lokal vs. global, ada tantangan terkait transaksi lainnya. Ini mengacu secara khusus pada masalah yang disebabkan oleh transaksi yang tidak valid selama penyebaran tampilan lokal-global blok. Mengingat bahwa tidak mungkin untuk memprediksi dampak perubahan status pada transaksi pengusul lain di awal fase (sebelum subblok digabungkan menjadi blok yang dibangun bersama oleh beberapa pengusul), mungkin ada kasus di mana pengusul meneruskan transaksi yang tidak valid satu sama lain (masalahnya diperburuk jika transaksi ini diunggah ke rantai sebagai konten ketersediaan data). Validator dalam set MCP saat ini juga dapat melanggar batas parameter (misalnya, melanggar nilai gas maksimum). Meskipun ini dapat diselesaikan dengan memperkenalkan arbiter (atau aturan bawaan protokol) yang dapat memfilter transaksi dengan harga rendah dengan perubahan status yang sama dengan biaya setelah pengungkapan ketersediaan data, ini membawa kita kembali ke dilema PGA yang terselesaikan. Namun, tidak menggunakan mekanisme seperti lelang sama sekali untuk memberi pencari/pembangun kendali atas lokasi blok akan menyebabkan banjir transaksi spam dan memperburuk perjudian latensi – yang semuanya akan merusak kemungkinan preconfs. Ethereum (setelah peningkatan Petra) dan Solana memiliki pertimbangan tambahan: proposal Ethereum 7702 membuat transaksi tidak lagi dibatalkan karena nonces, dan Solana tidak memiliki nonce transaksi (akun nonce masih ada). Hal ini membuatnya jauh lebih sulit untuk menilai validitas transaksi – pada dasarnya mensimulasikan semua kombinasi untuk menentukan urutan yang benar, yang dapat memberikan tekanan besar pada bandwidth jaringan. Solana mungkin lebih mudah ditangani dengan hambatan perangkat kerasnya yang tinggi untuk masuk, tetapi Ethereum tidak diragukan lagi akan membutuhkan peningkatan perangkat keras. Namun, solusi potensial Ethereum adalah klien eksekusi (bukan pembuat + repeater) untuk benar-benar menghitung pemesanan selama fase penggabungan sub-blok – menegaskan kembali perlunya peningkatan perangkat keras.

Dalam hal ketersediaan data (DA), seperti yang disebutkan sebelumnya, masalah penting lainnya adalah transaksi yang tidak valid ini dapat bocor secara on-chain (pada dasarnya menjadi transaksi gratis). Hal ini semakin memperburuk beban komputasi simulasi yang disebutkan dalam fase pra-konsensus - meskipun Anda dapat menyaring transaksi yang tidak valid selama fase penggabungan. Beberapa implementasi FOCIL yang ada (alamat kirim daripada transaksi penuh) dapat digunakan kembali (kecuali mereka hanya mengandalkan validasi simulasi, tetapi intervensi manusia daripada aturan protokol dapat mengganggu proses simulasi dengan membatalkan transaksi lain).

Seperti disebutkan sebelumnya, implementasi MCP kemungkinan besar akan membutuhkan alat finalitas untuk menangani masalah sinkronisasi - yang tersirat dalam bagian simulasi pemesanan pra-konsensus di atas. Hal ini juga menimbulkan masalah penundaan permainan waktu proposal blok (fenomena yang telah terlihat dalam lelang MEV-Boost), dengan efek bahwa pengusul dapat melihat blok lain sebelum membangun blok mereka sendiri, dan dengan demikian dengan sengaja mengirim transaksi yang membatalkan transaksi orang lain (terutama bermanfaat bagi pencari). Jika aturan permainan anti-waktu terlalu ketat, itu akan mengarah pada penghapusan validator yang lebih buruk (artinya lebih banyak blok yang hilang).

Solusi yang mungkin untuk permainan waktu dapat dipinjam dari peningkatan rantai seperti Monad, yang menggunakan mekanisme eksekusi asinkron (deferred execution). Misalnya, Anda dapat menetapkan aturan: efek lengkap dari kumpulan transaksi dari semua pengusul aktif dalam satu periode waktu harus menunggu hingga semua set dibuat. Ini secara signifikan membatasi throughput, karena ada kemungkinan besar bahwa beberapa pengusul akan berisi transaksi yang sama. Eksekusi yang tertunda juga berarti bahwa bahkan jika transaksi "disertakan" dalam subblok, itu mungkin tidak berhasil mencapai blok penggabungan akhir, menghasilkan transaksi "disertakan tetapi kembali" (menggemakan masalah inklusi ganda yang disebutkan di awal). Perhatikan bahwa ini mungkin memerlukan alat finalitas khusus untuk melakukan operasi tersebut (termasuk eksekusi, propagasi, dan finalisasi blok).

Meskipun kami fokus utama pada Ethereum, perlu dicatat bahwa Solana sedang aktif memajukan MCP. Dengan bergabungnya Max Resnick ke Anza dan Anatoly secara terbuka menyatakan dukungan untuk implementasi, tren ini semakin jelas. Artikel terbaru yang dirilis oleh Anatoly menyebutkan beberapa poin perhatian kunci berikut:

--Apa yang harus dilakukan jika waktu kedatangan blok dari validator yang berbeda berbeda (ini juga bisa menjadi permainan waktu)

--Bagaimana cara menggabungkan transaksi (telah dibahas sebelumnya)

--Bagaimana cara mendistribusikan kapasitas blok (batas Gas maksimum) di antara para validator untuk memaksimalkan bandwidth

--Masalah pemborosan sumber daya (transaksi yang sama dimasukkan ke dalam beberapa subblok, masalah ini juga telah disebutkan sebelumnya)

Banyak masalah dalam menerapkan MCP di Solana seringkali beresonansi dengan masalah yang dihadapi Ethereum. Namun, Solana lebih berfokus pada optimasi bandwidth dan kinerja, yang berarti bahwa pengelolaan sumber daya blok dan penggabungan blok menjadi lebih penting sambil memastikan konsensus tetap kuat.

Poin penting lainnya yang kami sebutkan di awal artikel adalah bahwa MCP tidak hanya memperkuat protokol, tetapi juga dapat digunakan untuk memperluas protokol. Bahkan dapat menggabungkan serialisasi khusus aplikasi (ASS) ke dalam lapisan protokol melalui mekanisme penyortiran. Di masa depan, mungkin ada skenario di mana alih-alih menjadi pengusul transaksi XYZ, aplikasi itu sendiri bertindak sebagai pengusul dan menyortir kumpulan transaksi sesuai dengan kebutuhannya sendiri (yang sedang dikerjakan oleh Project Delta) - atau sebaliknya, aplikasi menyediakan penyusunan transaksi kepada pengusul. Perlu dicatat bahwa opsi untuk mentransfer pajak MEV ke pihak aplikasi (inisiator transaksi) dan menggabungkannya dengan MCP juga sedang dieksplorasi (yang akan lebih mudah diterapkan karena tidak lagi dikendalikan oleh satu pengusul).

Dalam sebuah posting baru-baru ini, Max dan Anatoly berpendapat bahwa MCP dapat mencapai spread bid-ask yang lebih sempit dengan menerapkan serialisasi khusus (konsep NASDAQ terdesentralisasi). Di lingkungan saat ini, seperti yang disebutkan sebelumnya, hanya satu pemimpin yang dapat mengusulkan blok. Artinya, ketika harga berfluktuasi, pihak yang mengutip di buku pesanan akan mencoba membalikkan kutipan tertentu. Di bawah model pengusul tunggal Solana, itu hanya dapat dilakukan melalui lelang Jito karena monopoli pengusul atas kekuasaan. Idealnya, seperti yang ditunjukkan Hyperliquid, permintaan tolak bayar harus diprioritaskan untuk memungkinkan pembuat pasar mempertahankan spread yang lebih ketat. Oleh karena itu, diharapkan hal ini akan dicapai melalui ASS sebagai aplikasi - mereka memiliki monopoli atas kekuatan lelang di bawah model pemimpin tunggal, dan monopoli ini dapat dihilangkan dengan mengadopsi MPC. Namun, solusi ASS ini kemungkinan akan terbatas pada skenario isolasi negara. Inti dari proposal ini adalah untuk memungkinkan pengembang aplikasi untuk menentukan tindakan prioritas (misalnya, pembatalan pesanan) untuk akun tertentu, dan memprioritaskan transaksi prioritas tertinggi (belum tentu transaksi tip tertinggi, tetapi sumber daya likuiditas) untuk akun tertentu. Ide intinya adalah menetapkan ambang batas biaya untuk perdagangan reguler, sambil memungkinkan perdagangan prioritas tertentu untuk menembus batas.

Masalah biaya peng打包 dan biaya penyortiran yang dibahas sebelumnya, tampaknya Solana sudah memiliki solusi. Biaya peng打包 masuk ke validator transaksi, sementara biaya penyortiran dibayarkan kepada protokol (dihancurkan). Saat menggabungkan beberapa sub-blok, hanya perlu menyortir dan mengeksekusi kumpulan transaksi yang digabungkan berdasarkan biaya penyortiran yang telah ditentukan.

Mekanisme di atas bekerja sama erat dengan mekanisme penyebaran blok Solana yang disebut Turbine. Para Pemimpin (MCP) menggunakan potongan data (shreds), yang dikirim ke node relay dalam struktur pohon Turbine—node relay ini harus mencakup potongan dari semua pemimpin. Node relay mengirimkan informasi konfirmasi potongan ke pemimpin konsensus tunggal, yang harus mengumpulkan cukup banyak potongan pesan sebelum melakukan siaran dan mencapai konsensus.

Dengan dirilisnya Alpenglow, mengingat pembatalan arsitektur node relay lapisan tunggal dan mekanisme pemungutan suara di chain (sekarang sepenuhnya di chain), implementasi spesifik mungkin mengalami penyesuaian. Perubahan ini diharapkan dapat mengurangi biaya operasional validator, sehingga meningkatkan jumlah validator dan menarik peserta dengan keterampilan teknis yang lebih lemah. Ini tentu bermanfaat bagi desentralisasi, tetapi mungkin mempengaruhi kinerja chain. Yang patut dibahas adalah, setelah Solana menerapkan MCP, bagaimana mereka akan menangani masalah kegagalan validator.

**3、**Praktik MCP di Ekosistem Lain

Ekosistem Cosmos juga sedang mendorong implementasi MCP, lembaga terkenal Informal Systems baru saja merilis spesifikasi multi-pemohon di bawah model konsensus BFT. Mereka menggunakan protokol siaran aman dan meminta agar setiap sub-blok dari setiap validator harus mendapatkan konfirmasi dari validator lain melalui mekanisme pemungutan suara. Modul pembangunan blok Tendermint/CometBFT kemudian mencapai konsensus pada kumpulan sub-blok ini, yang berarti validator tertentu akan menghasilkan banyak sub-blok.

Sei sedang mengembangkan MCP melalui proyek Sei Giga (berusaha menjadi proyek pertama yang diluncurkan), sebagian inspirasi desainnya berasal dari artikel Autobahn (sangat dianjurkan untuk dibaca). Inti pemikirannya adalah memisahkan ketersediaan data dari pengurutan, mempercepat ketersediaan data melalui beberapa saluran paralel, dan akhirnya mengurutkannya ke dalam rantai global. Ini sedikit berbeda dari konsep MCP Ethereum—validator tidak menyelaraskan blok pada periode waktu tetap, tetapi terus memproduksi blok dan kemudian menggabungkannya menjadi tampilan global.

Patrick O'Grady dari Commonware juga sedang menjelajahi solusi terkait.

Akhirnya, proyek Delta merancang lapisan dasar yang memiliki fungsi papan pengumuman anti-sensor, sementara setiap aplikasi menjalankan pengurut serentak sendiri, blok yang dihasilkan akhirnya diselesaikan ke lapisan status global.