Block Assembly Marketplace (BAM)

Wawasan yang Dapat Ditindaklanjuti

• Saat ini, leader Solana memiliki wewenang penuh atas urutan transaksi selama slot mereka, dengan transparansi yang terbatas terkait cara blok dikonstruksi. BAM menghadirkan alternatif terdesentralisasi dan dapat diverifikasi yang membuat logika pengurutan dapat diaudit.
• Jaringan BAM memisahkan tanggung jawab secara jelas: node BAM menangani pengambilan, penentuan prioritas, dan penyaringan transaksi Solana, sedangkan validator BAM menangani eksekusi, konsensus, dan pengelolaan state. Pendekatan ini membawa Solana lebih dekat ke arsitektur seperti Proposer-Builder Separation (PBS).
• Framework plugin BAM memungkinkan developer menentukan logika pengurutan khusus dan menghadirkan primitive penjadwalan baru. Hal ini memungkinkan Application-Controlled Execution (ACE), sehingga aplikasi dapat menerapkan aturan penjadwalan transaksinya sendiri.
• Jito telah berkomitmen untuk menjadikan BAM open-source dan merancangnya dengan transparansi sebagai prinsip utama. Ini merupakan peningkatan besar dibandingkan block engine Jito saat ini, yang bersifat closed-source dan dijalankan oleh satu pihak tepercaya.
• Node BAM akan berjalan pada prosesor AMD yang mendukung Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) yang disempurnakan. Berkat akselerasi perangkat keras, SEV-SNP hanya menimbulkan overhead sebesar 2–5%, cukup cepat untuk pemrosesan real-time.
• Scheduler pertama yang diimplementasikan untuk node BAM akan menjalankan lelang intra-blok secara berkala di dalam mempool, dengan membagi blok menjadi N slot dan mengalokasikan CU secara merata pada setiap lelang.
• Application-Controlled Execution (ACE) dapat mengurangi kebutuhan akan rollup atau ekstensi jaringan untuk menerapkan logika khusus, sehingga membantu mempertahankan lebih banyak aktivitas di mainnet Solana. ACE juga secara signifikan memperluas ruang desain bagi aplikasi baru yang memanfaatkan blockspace yang dapat diprogram.
• Jito berencana menyalurkan 100% biaya protokol dari Block Engine dan sistem BAM mendatang ke Jito DAO Treasury. Saat ini, Jito mengenakan biaya 6% atas tip, yang dibagi rata antara Jito Labs dan DAO. Pada Q2 2025, DAO memperoleh 22.391,31 SOL (~$4 juta) dari biaya ini melalui Tip Router.
• BAM mengambil inspirasi dari BuilderNet milik Flashbots dengan mengadopsi pendekatan serupa untuk membangun blok di dalam trusted execution environment. Di mainnet Ethereum, sekitar 40% blok telah dibangun dalam TEE.

Pendahuluan

Block Assembly Marketplace (BAM) dari Jito merupakan desain ulang paling ambisius terhadap proses konstruksi blok Solana hingga saat ini. Setelah dikembangkan selama lebih dari delapan bulan, BAM lahir dari keinginan untuk menghadirkan privasi, transparansi, dan eksekusi intra-slot yang deterministik di Solana guna memungkinkan gelombang aplikasi canggih berikutnya. Hasilnya adalah pipeline transaksi yang dirancang ulang untuk menggantikan model pengurutan saat ini, yang tidak transparan dan dikendalikan validator, dengan sistem pengurutan transaksi yang privat, dapat diprogram, dan terbukti adil.

BAM menghadirkan mempool terenkripsi yang berjalan di dalam Trusted Execution Environment (TEE), tempat semua transaksi tetap dirahasiakan hingga dieksekusi. Arsitektur yang menjaga privasi ini bertujuan mengurangi secara signifikan, atau bahkan menghilangkan, berbagai bentuk MEV yang paling eksploitatif, sehingga memberikan jaminan eksekusi yang lebih kuat dan harga yang lebih baik kepada pengguna. Validator dapat menawarkan eksekusi berkualitas lebih tinggi, sedangkan developer dan searcher dapat membangun langsung di atas lapisan blockspace baru yang dapat diprogram.

BAM menghadirkan logika application-controlled execution (ACE) melalui sistem plugin. Hal ini memungkinkan berbagai kasus penggunaan, seperti pencocokan berbasis prioritas maker untuk perpetual, pembaruan oracle just-in-time, penerapan time-in-force pada order, serta bentuk routing dan eksekusi khusus lainnya. Dengan kontrol terperinci atas urutan transaksi, developer dapat membangun primitive keuangan yang lebih canggih dan andal di Solana, termasuk central limit order book, dark pool, dan lapisan aggregator.

Dengan demikian, BAM secara langsung menjawab banyak kritik yang telah lama ditujukan pada model produksi blok Solana: perilaku validator yang tidak transparan, kualitas eksekusi yang tidak konsisten, serta berkembangnya pasar abu-abu melalui mempool privat dan kesepakatan di luar sistem. Saat ini, leader Solana memiliki kendali sepihak atas urutan transaksi selama slot mereka, dengan informasi yang sangat terbatas tentang cara blok akhir disusun. BAM menggantikannya dengan alternatif terdesentralisasi dan dapat diverifikasi yang tetap terintegrasi dengan baik ke runtime Solana berperforma tinggi.

BAM dibangun berdasarkan preseden di dunia nyata dan mengambil inspirasi dari BuilderNet milik Flashbots, dengan mengadopsi pendekatan serupa untuk membangun blok di dalam trusted execution environment. Di mainnet Ethereum, sekitar 40% blok telah dibangun dalam TEE, sedangkan di Unichain (L2 khusus milik Uniswap), angkanya mencapai 100%. BAM memperluas model ini ke Solana, dengan keunggulan berupa dukungan native untuk kemampuan pemrograman tingkat aplikasi, eksekusi berlatensi rendah, dan integrasi mendalam dengan klien validator Jito, yang saat ini mengamankan lebih dari 89% total stake melalui Jito-Agave dan Jito-Firedancer.

Yang terpenting, Jito telah berkomitmen untuk menjadikan BAM open-source dan merancangnya dengan transparansi sebagai prinsip utama. Ini merupakan peningkatan besar dibandingkan block engine Jito saat ini, yang bersifat closed-source dan dijalankan oleh satu pihak tepercaya. BAM menghasilkan atestasi on-chain, yaitu bukti bertanda tangan kriptografis yang mengonfirmasi secara tepat kode yang dijalankan dan cara transaksi diurutkan, sehingga setiap pengamat dapat memverifikasi eksekusi yang adil.

Gambaran Umum BAM

Pada dasarnya, BAM adalah jaringan pengurutan transaksi. Node BAM menangani pengambilan, penentuan prioritas, dan penyaringan transaksi Solana, sedangkan validator BAM berfokus pada eksekusi, konsensus, dan pengelolaan state. Pemisahan tanggung jawab ini mempertahankan tanggung jawab inti yang penting bagi keaktifan jaringan di dalam validator, sekaligus memungkinkan fleksibilitas dan eksperimen yang lebih besar terkait logika pengurutan di dalam node BAM.

Node BAM terdiri dari transaction processing unit (TPU) dan scheduler transaksi yang beroperasi di dalam TEE. Node ini juga menjalankan server gRPC untuk berkomunikasi dengan validator yang terhubung. Klien Jito-validator yang telah dimodifikasi dilengkapi executor first-in-first-out (FIFO), yang dioptimalkan untuk konkurensi dan paralelisme melalui penguncian yang memahami account.

Setiap node BAM dapat mendukung beberapa validator, meskipun setiap validator hanya terhubung ke satu node BAM pada satu waktu. Saat ini, Jito mengoperasikan tujuh block engine. Dengan BAM, jaringan ini bertujuan meningkatkan skala secara signifikan, dengan target 50 hingga lebih dari 100 node BAM yang tersebar di seluruh wilayah geografis utama demi desentralisasi dan redundansi yang lebih besar. Komunikasi antara node BAM dan validator berlangsung melalui stream gRPC dua arah, sedangkan hasil eksekusi dikirim kembali melalui stream dari validator ke node BAM untuk memberikan umpan balik real-time.

Semua transaksi di dalam node BAM dienkripsi dalam Trusted Execution Environment (TEE) hingga saat eksekusi, sehingga alur transaksi tetap privat sampai transaksi tersebut dieksekusi.

Untuk menjamin eksekusi yang adil, urutan transaksi dicatat secara terverifikasi menggunakan atestasi. Atestasi merupakan bukti kriptografis yang ditandatangani dan diberi timestamp oleh node BAM untuk mengonfirmasi bahwa peristiwa atau kondisi tertentu telah diamati. Hasilnya adalah jejak audit yang tidak dapat diubah, sehingga pengamat dapat membuktikan bahwa transaksi dieksekusi dalam urutan yang benar.

Jejak audit mencakup transaksi yang diteruskan ke validator beserta urutannya, misalnya transaksi A, B, dan C dikirim ke validator Helius pada slot ini. Sistem ini menyediakan alat pemantauan dan analitik real-time, sehingga pengguna dapat melacak transaksi mereka sejak dikirim hingga dieksekusi. Pengguna dan aplikasi akan dapat memverifikasi apakah validator BAM menjalankan urutan tersebut dan mengetahui secara tepat kode yang dijalankan di node BAM.

Node BAM terlihat secara transparan di jaringan, serupa dengan relayer Jito yang sudah ada. Ketika validator terhubung ke BAM, validator tersebut mengiklankan instance BAM melalui port TPU dan TPU forward, yang berfungsi sebagai titik masuk untuk menerima transaksi.

Pengguna tetap dapat mengirimkan transaksi melalui klien RPC yang biasa mereka gunakan. Namun, demi keamanan yang lebih baik, mereka dapat mengirim transaksi langsung ke instance BAM, sehingga mencegah validator berbahaya mencegat atau melihat paket transaksi.

Ketika transaksi masuk ke BAM, transaksi tersebut menjalani proses sanitasi standar yang mencakup deduplikasi, verifikasi tanda tangan, serta pemeriksaan format, blockhash, pembayar biaya, nonce, dan Address Lookup Table yang valid.

Setelah divalidasi, transaksi memasuki mempool BAM dan berpartisipasi dalam lelang berkala yang sering diadakan. Setelah lelang selesai, transaksi dikirim ke validator. Seluruh urutan transaksi ditandatangani oleh software BAM dan dicatat dalam database. Validator kemudian mengirimkan kembali hasil eksekusi melalui stream menggunakan API yang dirancang berdasarkan API yang diusulkan oleh scheduler modular Anza.

Dengan lingkungan penjadwalan yang aman dan pasar biaya lokal, validator kini beroperasi berdasarkan kontrak opt-in yang jauh lebih kuat. Validator menerima urutan transaksi yang telah ditentukan sebelumnya dan harus menjadwalkannya persis seperti yang diberikan, sehingga tidak ada peluang untuk menyisipkan atau mengubah urutan transaksi demi tujuan berbahaya.

Beberapa mekanisme penegakan sedang dipertimbangkan untuk menangani setiap kejadian penyimpangan validator, seperti sandwiching, berdasarkan bukti jejak audit. Meskipun belum ditetapkan, kemungkinan tindakannya meliputi:

• Menghapus validator yang melanggar dari jaringan BAM.
• Mewajibkan validator menyediakan agunan dalam bentuk bond, yang dapat dipotong jika terjadi pelanggaran (meskipun hal ini dapat meningkatkan hambatan masuk bagi validator baru).
• Menerapkan blacklist atau greylist untuk membatasi sebagian partisipasi pihak yang melanggar.

Biaya

Jito Labs dan Jito Foundation tengah bersama-sama menyusun Jito Improvement Proposal (JIP) yang akan mengalihkan 100% biaya protokol yang dikumpulkan dari Block Engine dan sistem BAM mendatang ke Jito DAO Treasury. Proposal ini diperkirakan akan diajukan secara resmi dalam beberapa minggu mendatang, menandai perubahan signifikan dalam model ekonomi Jito, dan harus mendapatkan persetujuan DAO. Jika disetujui, proposal ini akan memperkuat peran sentral DAO dan pemegang token JTO dalam ekosistem Jito.

Saat ini, protokol Jito mengenakan biaya 6% atas tip, yang dibagi rata antara Jito Labs dan DAO. Pada Q2 2025 saja, DAO memperoleh 22.391,31 SOL (~$4 juta) dari biaya ini melalui Tip Router. Sumber pendapatan utama DAO lainnya berasal dari biaya jitoSOL, yang mencapai total 13.223,73 SOL (~$2,38 juta) pada periode yang sama.

Trusted Execution Environment (TEE)

Trusted Execution Environment (TEE) adalah arsitektur berbasis perangkat keras yang dirancang untuk memastikan kerahasiaan dan integritas komputasi serta memori. TEE, yang juga dikenal sebagai enclave, mengisolasi eksekusi kode dari sistem operasi, kernel, dan hypervisor sistem host, biasanya melalui pemisahan di tingkat perangkat keras. Isolasi ini secara signifikan mengurangi permukaan serangan, sehingga operasi enclave sangat sulit, meskipun bukan mustahil, untuk diamati atau dimanipulasi.

TEE telah digunakan sejak tahun 2000-an dalam bidang seperti pengelolaan hak digital, perlindungan konten, dan sistem pembayaran aman. Saat ini, TEE digunakan secara luas di perangkat konsumen dan layanan cloud untuk menangani data serta kode sensitif secara aman. Di smartphone dan laptop, Secure Enclave dari Apple dan TrustZone dari Android melindungi data biometrik, kredensial pembayaran, dan kunci enkripsi. Konsol game seperti PlayStation dan Xbox menggunakan prosesor berbasis AMD atau Pluton untuk mencegah manipulasi dan pembajakan. Di cloud, penyedia seperti Azure dan Google Cloud memanfaatkan AMD SEV-SNP, Intel TDX, atau AWS Nitro Enclaves untuk mengisolasi workload dan memungkinkan confidential computing. Wallet kripto seperti Ledger dan Trezor menggunakan secure element untuk melindungi private key, sedangkan ponsel Solana Seeker yang baru mengandalkan TEE untuk tujuan yang sama.

TEE merupakan pendekatan standar berbasis perangkat keras untuk memproses data privat, yang menyediakan alternatif praktis bagi metode kriptografis murni seperti fully homomorphic encryption (FHE) dan secure multiparty computation (MPC). Meskipun FHE dan MPC memberikan jaminan teoretis yang kuat, keduanya sering kali tidak praktis dalam penggunaan di dunia nyata karena kompleksitas dan overhead performanya yang tinggi.

BAM mengandalkan dua properti utama TEE:

Kerahasiaan: Kode dan data di dalam TEE dienkripsi serta diisolasi dari bagian sistem lainnya. Sistem operasi, hypervisor, maupun software eksternal tidak dapat mengakses atau memeriksa apa yang berjalan di dalam enclave.

Kemampuan Atestasi: TEE mendukung atestasi, yaitu mekanisme yang menghasilkan bukti kriptografis tentang asal dan state terkini enclave. Hal ini memungkinkan pihak ketiga memverifikasi bahwa suatu hasil diproduksi oleh TEE asli yang menjalankan kode tepercaya, bukan oleh lingkungan yang telah disusupi atau diemulasi.

Implementasi TEE di BAM

BAM akan berjalan pada prosesor AMD yang mendukung Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) yang disempurnakan. Tidak seperti pendekatan berbasis enclave yang lebih kecil, SEV-SNP melindungi seluruh aplikasi BAM dengan overhead performa minimal, sehingga sangat cocok untuk sistem transaksi dengan throughput tinggi dan latensi rendah.

Berkat akselerasi perangkat keras, SEV-SNP hanya menimbulkan overhead sebesar 2–5%, cukup cepat untuk pemrosesan real-time. Teknologi ini dapat mendukung aplikasi berjaringan yang kompleks dan memiliki state, bukan sekadar komputasi terisolasi. Teknologi ini telah teruji, dengan deployment di berbagai penyedia cloud besar termasuk Google Cloud, Azure, dan AWS, serta didukung oleh riset keamanan dan pengalaman operasional selama bertahun-tahun.

SEV-SNP yang digunakan dalam BAM memberikan beberapa jaminan keamanan utama. Setiap instance TEE berjalan di dalam virtual machine sendiri yang diisolasi oleh perangkat keras, dengan memori yang dienkripsi saat runtime untuk memastikan isolasi tingkat VM yang kuat. BAM memanfaatkan atestasi yang berakar pada perangkat keras, sehingga setiap TEE dapat membuktikan secara kriptografis bahwa TEE tersebut menjalankan kode asli yang belum dimodifikasi. Rantai atestasi ini tertambat pada root key perangkat keras AMD, yang ditanam secara fisik dalam CPU saat proses produksi. Selain itu, kunci TLS dibuat menggunakan hardware random number generator internal prosesor, sehingga tidak pernah terekspos dalam memori yang tidak terenkripsi.

Ketika klien terhubung ke BAM, klien menerima sertifikat TLS yang berisi sertifikat koneksi standar, laporan atestasi AMD SEV-SNP, dan bukti kriptografis bahwa private key TLS dibuat di dalam TEE yang telah diatestasi. Rantai sertifikat ini terikat secara kriptografis pada hardware root of trust AMD. Rantai ini tidak dapat dipalsukan tanpa akses ke private root key AMD, sehingga tidak perlu memercayai perantara mana pun selain proses produksi chip AMD.

Plugin

Saat ini, aplikasi di Solana hanya dapat memengaruhi urutan transaksi melalui priority fee atau transaksi bundle dengan tip terkait. Karena beberapa sequencer digunakan di berbagai klien seperti Agave dan Firedancer, tidak ada jaminan tentang logika pengurutan mana yang akan diterapkan, sehingga aplikasi hanya memiliki kontrol terbatas atas cara transaksi mereka diurutkan.

Plugin mengatasi masalah ini. 

Melalui framework plugin BAM, developer dapat mengimplementasikan logika pengurutan khusus dan menghadirkan primitive penjadwalan baru. Plugin memungkinkan Application-Controlled Execution (ACE), sehingga aplikasi dapat menentukan kebijakan penjadwalan transaksi khusus. Meskipun ACE memiliki banyak potensi penggunaan, kasus penggunaan yang paling dikenal dan dibahas adalah memprioritaskan pembatalan order book—mekanisme yang mengurangi adverse selection dan memungkinkan spread yang lebih ketat.

Memprioritaskan Pembatalan oleh Maker di Order Book

Saat ini, market maker order book on-chain di Solana beroperasi dalam posisi yang kurang menguntungkan. Market maker mengelola risiko dengan terus memperbarui atau membatalkan quote yang sudah tidak relevan ketika harga wajar berubah. Ketika harga pasar bergerak, mereka harus membatalkan order yang ada sebelum taker yang memiliki informasi lebih baik dapat memanfaatkan peluang tersebut.  

Tanpa kontrol terperinci atas urutan transaksi, quote mereka rentan terhadap aliran toksik yang mengeksploitasi harga yang sudah tidak relevan. Market maker dapat mengalami kerugian meskipun bertindak cepat karena lelang Jito memprioritaskan bid, bukan intent. Pada dasarnya, pihak yang membayar lebih besar akan diurutkan lebih dahulu.

Dinamika ini memaksa market maker memperlebar spread untuk mengelola risiko, sehingga mengurangi likuiditas secara keseluruhan dan menghasilkan harga yang lebih buruk bagi pengguna. Transaksi toksik ini—ketika taker meraih keuntungan dari harga yang sudah tidak relevan dan pihak lawan segera menyesali transaksi tersebut—tidak banyak meningkatkan pengalaman pengguna, tetapi secara signifikan menambah hambatan bagi market maker dan penyedia likuiditas.

Plugin BAM memungkinkan kebijakan "cancel-before-take" diterapkan pada tingkat aplikasi. Dengan memberikan kontrol terperinci atas urutan transaksi kepada program, aplikasi dapat memilih untuk memproses pembatalan oleh maker sebelum transaksi taker. Perubahan kebijakan sederhana ini memiliki dampak besar:

• Mengurangi Adverse Selection: Maker tidak lagi secara rutin dirugikan ketika pasar bergerak.
• Menyaring Aliran Toksik: Meskipun volume keseluruhan dapat menurun karena lebih sedikit transaksi toksik, kualitas aliran dan eksekusi meningkat.
• Memungkinkan Spread yang Lebih Ketat: Dengan risiko yang lebih rendah, maker dapat memberikan quote yang lebih agresif.
• Meningkatkan Likuiditas: Maker profesional dan trader ritel menjadi lebih yakin untuk memberikan quote, sehingga menghasilkan likuiditas yang lebih dalam.

Pembaruan Oracle Just-in-Time

Contoh lain dari plugin khusus aplikasi adalah implementasi pembaruan oracle just-in-time yang direncanakan Pyth. Sebagai penyedia oracle terkemuka di Solana, Pyth mengelola lebih dari 1.700 feed harga individual. Memperbarui semuanya pada setiap blok akan sangat mahal dan tidak efisien dalam penggunaan blockspace.

Dengan BAM, Pyth dapat memperbarui feed harga tertentu tepat ketika diperlukan dengan menyisipkan pembaruan oracle langsung sebelum transaksi pengguna di dalam blok yang sama. Hal ini mengurangi risiko yang berkaitan dengan data oracle yang sudah tidak relevan, seperti likuidasi yang tidak efisien dan manipulasi oracle, sehingga aplikasi DeFi dapat beroperasi dengan lebih andal dan kompetitif.

Plugin Lainnya

Pada akhirnya, BAM bertujuan menjadi platform permissionless tempat developer aplikasi dapat membangun, menguji, dan men-deploy plugin untuk mengontrol pengurutan transaksi mereka. Diperkirakan akan ada lebih banyak plugin, dan node BAM pada akhirnya akan mendukung ratusan ekstensi yang dapat disesuaikan. Meskipun sebagian besar aplikasi akan terus beroperasi menggunakan scheduler default, aplikasi yang membutuhkan logika pengurutan khusus akan bertanggung jawab mengembangkan dan memelihara plugin mereka sendiri. 

Selain itu, aplikasi akan dapat memonetisasi fungsionalitas plugin dengan mengenakan biaya, dengan kemungkinan sebagian pendapatan dibagikan kepada pemegang token tata kelola atau validator.

Kandidat Plugin Serbaguna

Plugin tidak terbatas pada satu aplikasi. Jito telah mengusulkan beberapa contoh plugin serbaguna lintas aplikasi yang dapat dikembangkan untuk BAM:

Futures Blockspace: Memungkinkan pengguna dan aplikasi mencadangkan atau memperdagangkan hak untuk menggunakan blockspace pada waktu mendatang, sehingga memberikan akses dan harga yang dapat diprediksi bahkan ketika permintaan jaringan sedang tinggi.

Time in Force (TIF): mengacu pada durasi suatu order tetap aktif sebelum dibatalkan secara otomatis jika tidak dieksekusi sepenuhnya, misalnya dengan membuat transaksi order book hanya berlaku selama 20 milidetik. Versi sederhananya sudah dapat diterapkan di Solana saat ini dengan sengaja menggunakan blockhash yang lebih lama untuk memastikan transaksi hanya berlaku pada satu atau beberapa blok terbaru.

Pre-Confirmations: Pengguna dapat diberi tahu ketika transaksi mereka diteruskan ke validator sebelum dieksekusi dan disebarkan ke jaringan. Hal ini memungkinkan konfirmasi transaksi lebih awal dengan tingkat keyakinan tertentu.

Transaksi tanpa biaya: memungkinkan pengguna membayar biaya transaksi menggunakan token SPL (misalnya stablecoin), bukan SOL, sehingga mengabstraksikan kebutuhan token native dan menyediakan pembayaran biaya yang fleksibel.

Aggregator Berlatensi Rendah dan Request for Quotation (RFQ): Pengguna mengirimkan intent perdagangan langsung ke BAM, lalu aggregator yang berjalan secara lokal mengidentifikasi rute optimal.

Pembatalan dan Penggantian Transaksi: Pengguna dapat mengirimkan transaksi dengan penanda khusus yang memungkinkan mereka membatalkan, menghapus, atau mengganti transaksi yang telah dikirim sebelumnya.

Peluncuran

Selama fase peluncuran, Jito Labs akan mengoperasikan kumpulan awal Node BAM untuk memastikan stabilitas, performa, dan keamanan. Sekelompok partner validator awal dengan izin, termasuk Helius, SOL Strategies, Triton One, dan Figment, akan menjalankan klien BAM dan mengamankan persentase satu digit yang tinggi dari total stake jaringan tidak lama setelah peluncuran. 

Secara paralel, kelompok awal aplikasi Solana, termasuk Drift, Pyth, dan DFlow, akan mulai merancang serta menguji gelombang pertama Plugin. Pada akhir fase peluncuran, BAM diharapkan telah memvalidasi fungsionalitas intinya dan membangun fondasi bagi partisipasi yang lebih luas dari operator node dan validator. 

Validator, developer aplikasi, atau searcher yang tertarik berpartisipasi dalam BAM dapat mengisi formulir ini.

Ecosystem Advisory Committee, yang terdiri dari para pemangku kepentingan terkemuka dari komunitas validator dan developer Solana, termasuk Solana Foundation, akan memberikan saran kepada Jito Labs. Komite ini akan membantu mengarahkan ekspansi BAM, mendorong desentralisasi, dan mengembangkan inovasi yang dipimpin komunitas.

Saat ini, codebase BAM masih bersifat closed-source, dengan rencana untuk membukanya dalam waktu dekat guna memungkinkan pengembangan plugin oleh pihak ketiga. Setelah menjadi open-source, BAM akan menerima kontribusi komunitas di beberapa bidang utama:

• Pengembangan Plugin: Membangun plugin khusus untuk memperluas kemampuan BAM.
• Algoritma Penjadwalan: Merancang dan menyumbangkan strategi baru untuk mengurutkan transaksi yang disesuaikan dengan kasus penggunaan tertentu.
• Library Integrasi: Mengembangkan SDK dalam berbagai bahasa pemrograman untuk menyederhanakan integrasi BAM.
• Alat Analitik: Membuat dashboard dan sistem pemantauan yang memanfaatkan data atestasi BAM.
• Kontribusi Riset: Mengusulkan dan mengimplementasikan pendekatan baru untuk mitigasi MEV dan optimalisasi sistem.

Implikasi

BAM merupakan titik penting bagi Solana—yang berpotensi membuka gelombang inovasi dengan mengatasi kekhawatiran seputar eksploitasi MEV dan pengemasan blok yang efisien. Pengurutan yang diamankan TEE dan kerangka kerja plugin BAM dapat mengurangi insentif bagi tim aplikasi untuk membangun ekstensi jaringan, rollup, atau Lingkungan Berizin Solana guna menerapkan logika khusus atau blockspace dengan aturan mereka sendiri, sehingga lebih banyak aktivitas tetap berlangsung di mainnet Solana. Selain itu, dengan peningkatan batas komputasi per blok dan permintaan akan program token serta kerangka kerja yang lebih efisien dan menggunakan lebih sedikit CU (misalnya, meningkatnya popularitas Pinocchio dan p-token), akan tersedia lebih banyak bandwidth di mainnet, yang makin mengurangi insentif bagi pengembang untuk membangun solusi khusus.

Fitur privasi BAM juga seharusnya secara signifikan mengurangi prevalensi serangan sandwich karena transaksi tetap tersembunyi hingga dieksekusi, sehingga membatasi kemampuan bot untuk mendahului pengguna. Hal ini kemungkinan akan meningkatkan efisiensi DEX dan menghasilkan harga yang lebih kompetitif bagi pengguna. Namun, kecil kemungkinan BAM akan sepenuhnya menghapus MEV. MEV pada dasarnya merupakan permainan kucing-kucingan, dan pelaku sandwich akan beradaptasi, mungkin melalui eksploitasi plugin yang terselubung atau manipulasi oracle eksternal (yaitu, oracle yang tidak memiliki plugin sendiri) karena oracle tersebut bukan bagian dari pipeline terenkripsi. 

Pengurangan MEV melalui BAM dapat berdampak negatif pada pendapatan Jito, mengulangi dampak penghentian mempool pada 2024, yang memangkas pendapatan jangka pendek tetapi pada akhirnya menguntungkan jaringan. Peningkatan dari BAM dapat mengimbanginya dengan mendorong volume transaksi dan biaya plugin yang lebih tinggi secara keseluruhan, sehingga meningkatkan pendapatan jangka panjang melalui tingkat adopsi yang lebih baik. Namun, implementasi persis BAM, peluncurannya secara bertahap, dan aspek ekonominya menimbulkan potensi risiko sentralisasi serta pertanyaan terbuka, yang kami bahas di bagian berikutnya. Meski demikian, risiko dan pertanyaan terbuka ini diimbangi oleh berbagai manfaat, masing-masing dengan implikasinya sendiri terkait redistribusi MEV, PBS, dan pengembangan klien “baru”.

Redistribusi MEV

BAM secara mendasar membentuk ulang lanskap MEV Solana dari ekstraksi tanpa kendali menjadi model redistribusi yang lebih terstruktur. Dalam konfigurasi tradisional, MEV sering mengurangi nilai milik pengguna melalui frontrunning atau spam, sementara validator atau bot mengambil nilai menggunakan taktik merugikan seperti serangan sandwich. Namun, mempool terenkripsi TEE milik BAM menyembunyikan transaksi hingga dieksekusi, sehingga membatasi visibilitas bagi MEV negatif. Sebagai gantinya, nilai diinternalisasi melalui plugin dan pengurutan khusus. Hal ini kemudian memungkinkan aplikasi, pengembang, dan searcher memperoleh bentuk MEV positif yang meningkatkan efisiensi ekosistem (misalnya, spread DeFi yang lebih ketat dan berkurangnya spam oracle).

Redistribusi ini menyalurkan kembali keuntungan MEV kepada para pemangku kepentingannya karena biaya plugin dibagikan di antara operator BAM Node, validator, staker, dan DAO Jito. Hal ini berpotensi menciptakan aliran pendapatan yang berkelanjutan. Sebagai contoh, sebuah DEX dapat memiliki plugin yang mengoptimalkan pencocokan pesanan dan mengubah potensi MEV yang diekstraksi validator menjadi biaya yang dihasilkan aplikasi, yang dapat didistribusikan kembali kepada pemegang token. Pendekatan “terlindungi” terhadap aktivitas trader ini dapat mengubah MEV dari permainan zero-sum menjadi mekanisme yang memperdalam likuiditas dan menarik modal institusional.

Namun, redistribusi disertai risiko. Hal penting yang perlu diperhatikan adalah bahwa BAM tidak menghapus MEV—BAM memindahkannya. Pemindahan ini berpotensi membuat pembuat plugin awal, operator BAM Node, dan entitas yang berafiliasi dengan Jito memperoleh keuntungan yang tidak proporsional. Meskipun dibatasi oleh atestasi kriptografis, jika muncul kerentanan TEE (misalnya, serangan side-channel), akses istimewa bagi searcher dapat menciptakan vektor ekstraksi baru yang terselubung dan pada akhirnya merusak jaminan privasi. Hal ini juga membuka peluang bagi bentuk backrunning “terlindungi”, yaitu searcher dapat menerapkan kode untuk menambahkan transaksi setelah transaksi pengguna (misalnya, untuk mengambil keuntungan arbitrase dari swap yang menggerakkan harga) tanpa mengungkap strategi atau memungkinkan frontrunning. Selain itu, tanpa slashing terprogram, penyerang adaptif dapat menjalankan strategi berbahaya seputar atestasi, yang dilakukan setelah eksekusi dan saat ini bergantung pada penegakan oleh komunitas.

Pada akhirnya, meskipun redistribusi MEV menempatkan BAM sebagai katalis bagi tujuan utama Solana (yaitu, NASDAQ terdesentralisasi), keberhasilannya bergantung pada penerapan model biaya yang adil dan keamanan TEE yang tangguh. Jika tidak ditangani dengan baik, hal ini dapat memecah jaringan, mengikis kepercayaan pengguna, dan mengundang pengawasan terhadap aktivitas searcher yang “terlindungi” tetapi tidak transparan.

Pemisahan Pengusul-Pembangun (PBS)

Sebagian besar blockchain dirancang agar entitas yang sama mengusulkan sekaligus membangun blok, sehingga memberinya kendali monopoli atas pengurutan dan penyertaan transaksi dalam slot yang ditetapkan. Hal ini menguntungkan entitas tersebut karena mereka bebas menyensor atau memanipulasi aliran transaksi dengan cara lain. Misalnya, mereka dapat mengusulkan dan membangun blok menggunakan strategi canggih, meskipun berbahaya, untuk menyertakan transaksi dalam urutan tertentu, sehingga memaksimalkan MEV.

Pemisahan Pengusul-Pembangun (PBS) adalah pola desain yang mengatasi masalah ini dengan memisahkan pembangunan blok dari pengusulan blok. Dalam desain ini, pembangun blok membuat daftar transaksi yang telah diurutkan dan mengajukan penawaran untuk blok tersebut. Pengusul blok, biasanya validator, kemudian menerima dan menetapkan blok dengan penawaran tertinggi, serta mendistribusikan kembali MEV melalui lelang atau tip tanpa perlu menjalankan sendiri strategi pengurutan yang canggih. 

PBS telah diterapkan di luar protokol melalui MEV-Boost di Ethereum sejak The Merge pada 2022. MEV-Boost adalah “sidecar” yang berjalan berdampingan dengan perangkat lunak klien lapisan eksekusi dan lapisan konsensus milik validator. Validator yang menjalankan MEV-Boost dapat terhubung ke beberapa relay dan menerima blok yang telah dibuat sebelumnya dari pembangun blok. Mereka tidak melihat isi blok sebelum blok tersebut disertakan secara on-chain karena mereka hanya menerima jumlah imbalan blok dan header blok dari relay. Perhatikan bahwa desain ini masih berada dalam tahap penelitian aktif karena PBS menunggu integrasi penuh ke dalam protokol (ePBS), yang mungkin mencakup fitur seperti daftar penyertaan untuk makin mengurangi penyensoran.

Dengan BAM, Solana bergerak menuju masa depan seperti PBS, yang memisahkan konstruksi blok (yaitu, pengurutan dalam BAM Node yang diamankan TEE) dari eksekusi, yang tetap menjadi tanggung jawab validator. Hal ini berpotensi mendemokratisasi bentuk MEV positif bagi aplikasi dan searcher melalui plugin. Namun, hal ini juga berisiko memperburuk sentralisasi stake Solana jika ekonomi plugin menguntungkan pemain lama. Hal ini terlihat di Ethereum, tempat tiga pembangun (yaitu, Titan Builder, BuilderNet, Beaverbuild) kini mendominasi lebih dari ~90% seluruh blok, sehingga menimbulkan masalah kepercayaan terhadap relay dan hambatan bagi peserta yang lebih kecil. 

Meskipun MEV-Boost memperkenalkan PBS ke Ethereum, perbandingan yang lebih adil di sini adalah BuilderNet, jaringan pembangunan blok terdesentralisasi yang diluncurkan pada November 2024 dan dioperasikan oleh Flashbots, Beaverbuild, dan Nethermind. BuilderNet menggunakan TEE untuk pembangunan blok privat, yang mendesentralisasikan proses tersebut di antara beberapa operator node guna menetralkan kesepakatan orderflow eksklusif dan mengurangi sentralisasi. BuilderNet berfokus pada penciptaan nilai (yaitu, membagikan pengembalian dana MEV kepada penyedia overflow, seperti pengguna, dompet, dan aplikasi), bukan permainan orderflow (misalnya, memperebutkan kesepakatan privat). BuilderNet masih menggunakan relay MEV-Boost, tetapi relay tersebut tidak diwajibkan secara ketat, yang berarti interaksi langsung antara pembangun dan pengusul dapat berlangsung dalam TEE. 

Peluncuran BAM yang bertahap dan berizin harus memprioritaskan biaya yang adil serta plugin sumber terbuka untuk mengurangi kelemahan yang dialami Ethereum ini, terutama mengingat ketergantungannya pada perangkat keras (yaitu, TEE dibandingkan relay berbasis perangkat lunak milik Ethereum), yang menimbulkan aspek vendor lock-in dan biaya pemeliharaan. Solana berharap dapat melewati permainan orderflow dan langsung beralih ke sistem seperti BuilderNet yang berfokus pada penciptaan nilai. 

Pada akhirnya, pergeseran dalam konstruksi dan pengusulan blok ini mengurangi peran validator, memindahkan kompleksitas pengurutan dari validator tetapi berpotensi mengurangi kewenangan dan pendapatan mereka jika biaya tidak dibagikan secara luas. Kami membahasnya secara lebih terperinci dalam bagian berjudul Berkurangnya Peran Validator.

Di atas: perbandingan PBS Ethereum dengan BAM Solana

Klien “Baru” Muncul

Klien Jito-Agave sangat menyerupai codebase inti Agave, dengan pembeda utama berupa penambahan kemampuan MEV. Model “Agave plus MEV” milik Jito memungkinkan kliennya berintegrasi secara lancar dengan ekosistem validator Solana yang sudah ada, meningkatkan imbalan sekaligus meminimalkan perubahan pada arsitektur inti. Akibatnya, saat tulisan ini dibuat, klien Jito-Agave memimpin jaringan dengan pangsa adopsi validator sebesar 79%. Dengan demikian, validator dapat mengandalkan logika dasar Agave sekaligus memperoleh manfaat dari aliran pendapatan tambahan Jito.

BAM menandai pergeseran dari pendekatan Jito sebelumnya yang sangat menyerupai Agave. Pengenalan jaringan khusus BAM Node membentuk lapisan infrastruktur baru. Evolusi ini mengubah Jito dari sekadar “Agave yang ditingkatkan” menjadi klien yang lebih berbeda, lengkap dengan ekosistem terprogramnya sendiri untuk menyematkan logika khusus aplikasi.

Perbedaan ini terlihat dalam scheduler bindings Agave yang akan datang, yang diumumkan Anza pada Mei. Implementasi scheduler khusus makin umum seiring makin matangnya MEV di Solana. Meskipun scheduler khusus dapat meningkatkan pendapatan operatornya, implementasinya saat ini memiliki beberapa kekurangan, termasuk kebutuhan untuk menjalankan binary versi validator yang berbeda, ketergantungan pada kode sumber tertutup, dan potensi masalah liveness. 

Scheduler bindings Anza yang akan datang menghadirkan modularitas dengan memungkinkan validator terhubung ke layanan pembangunan blok eksternal tanpa mengubah binary validator inti, sehingga mendukung scheduler khusus. Desain ini meningkatkan transparansi, keamanan, dan kemudahan DevOps. Namun, BAM menghilangkan kebutuhan pengguna Jito untuk memakai bindings ini karena pengurutan ditangani di hulu oleh scheduler BAM Node. Hal ini melewati scheduler bindings yang direncanakan Agave, sehingga berpotensi menyederhanakan operasi tetapi menimbulkan pertanyaan tentang fragmentasi ekosistem di masa depan akibat perbedaannya dari upaya standardisasi Anza (misalnya, mempersulit integrasi Firedancer).

Namun, Jito memosisikan BAM sebagai bagian dari klien validator terpadu. Validator BAM akan menjalankan versi terbaru klien Agave yang mengintegrasikan scheduler BAM dan hanya menerima transaksi dari BAM Node dalam urutan FIFO. Desain ini menghindari fragmentasi klien sekaligus meningkatkan ketahanan sistem. Jito berencana merilis klien yang kompatibel dengan BAM sebelum peluncuran scheduler modular Anza. Langkah ini menyoroti dampak ganda BAM: mendorong inovasi dan memajukan infrastruktur MEV Solana, tetapi juga berisiko makin memperkuat posisi Jito sebagai klien validator yang dominan.

BAM juga mungkin menggunakan bindings ini. Jika BAM beroperasi dalam scheduler modular, dukungan Firedancer menjadi mudah, dan muncul pertanyaan baru mengenai apakah Jito benar-benar membutuhkan klien validator. Hanya waktu yang dapat menjawabnya sembari kita menunggu implementasi kode sumber terbuka dan peluncuran BAM.

Pertanyaan Terbuka

Berkurangnya Peran Validator

Desain BAM secara mendasar mengubah lanskap validator Solana dengan memindahkan pengurutan transaksi ke jaringan BAM Node terpisah yang diamankan TEE. Hal ini membuat validator terutama bertanggung jawab atas eksekusi, konsensus, dan pengelolaan state. Pemisahan tersebut menguntungkan aplikasi karena memungkinkan pengurutan khusus dan peluang pembagian pendapatan bagi pemegang token. Hal ini juga menguntungkan pengguna dengan mengurangi MEV negatif dan menawarkan harga yang lebih menguntungkan. Namun, pemisahan ini menimbulkan pertanyaan tentang berkurangnya kewenangan dan insentif ekonomi bagi validator.

Saat memproduksi blok sebagai pemimpin, validator saat ini memiliki keleluasaan penuh atas pengurutan transaksi, sehingga mereka dapat menjalankan scheduler khusus untuk mengoptimalkan blok sesuai keinginan. BAM menghapus tanggung jawab ini dari validator. Kini, validator menerima transaksi yang telah diurutkan sebelumnya untuk dieksekusi dalam urutan FIFO yang ketat, sehingga otonomi mereka atas konstruksi blok hilang. Dalam kondisi paling ekstrem, jika semua transaksi melewati BAM, validator hanya menjadi “stempel persetujuan”, sehingga kebutuhan akan validator terdesentralisasi dipertanyakan. 

Namun, ada faktor-faktor penyeimbang. Secara khusus, biaya plugin menyediakan aliran pendapatan baru yang dibagikan kepada validator dan staker. Klien terpadu dan fallback otomatis BAM menyelaraskan kepentingan pribadi dengan kesehatan jaringan, sehingga meningkatkan ketahanan secara keseluruhan. Peluncuran bertahap dengan mekanisme opt-in juga mempertahankan pilihan, sedangkan pembukaan sumber dalam jangka panjang memungkinkan validator menyuarakan pendapat dalam pengembangan BAM, mendorong peningkatan berbasis komunitas, dan mempertahankan sebagian kewenangan.  Validator juga dapat mengusulkan peningkatan scheduler kepada BAM, yang berpotensi membuka peluang untuk memperoleh biaya dari volume yang lebih tinggi. Selain itu, anggapan bahwa validator hanyalah stempel persetujuan kemungkinan berlebihan karena validator masih memiliki peran penting dalam konsensus dan pemilihan fork. Pertanyaan sebenarnya adalah seberapa besar kewenangan yang akan benar-benar hilang dari validator? Mungkinkah BAM justru meningkatkan fokus validator pada liveness dan integritas state?

Beberapa pertanyaan masih belum terjawab:

• Bagaimana validator bersaing di luar perangkat keras dan uptime jika BAM Node menangani pengurutan dan ekstraksi MEV? 
• Dalam skenario adopsi tinggi, apakah fokus validator yang hanya pada eksekusi akan mengurangi desentralisasi Solana secara keseluruhan, dan jika demikian, metrik apa yang dapat mengukur pengurangan ini?
• Jika BAM mendorong validator menuju cara-cara yang lebih berbahaya dalam mencari pendapatan, perlindungan apa selain atestasi yang dapat mencegahnya tanpa makin mengurangi insentif?
• Apakah kerentanan TEE atau eksploitasi plugin dapat menyebabkan validator dihukum secara tidak adil? 
• Berdasarkan pengalaman Ethereum dengan PBS, apa yang dapat dilakukan Solana untuk mengatasi berkurangnya kewenangan validator?

Operator Node Berbahaya

Arsitektur BAM memperkenalkan asumsi kepercayaan baru terkait validator. Artinya, validator diasumsikan tidak bertindak jahat saat berinteraksi dengan BAM Node, seperti mengutak-atik transaksi yang telah diurutkan sebelumnya atau membocorkan data. Saat diluncurkan, BAM akan mengandalkan sekumpulan operator berizin karena keterbatasan TEE. Kumpulan berizin ini akan dipercaya untuk menjalankan klien Jito-Solana yang telah diperbarui dan mengeksekusi transaksi yang diteruskan dengan benar. Validator tersebut harus memercayai BAM Node untuk tidak memanipulasi ingress, sehingga menciptakan kepercayaan dua lapis (yaitu, BAM Node sebelum TEE dan validator setelah TEE), yang meningkatkan risiko dalam konfigurasi berizin. Pertanyaan pentingnya adalah: apa yang mencegah operator BAM Node mengintip transaksi sebelum transaksi tersebut mencapai TEE? Jawabannya adalah enkripsi QUIC untuk node terverifikasi—mereka akan menyematkan atestasi dalam sertifikat QUIC. Cara lain untuk mengamati apakah BAM Node bersikap jujur adalah memeriksa hash-nya terhadap repositori sumber terbuka BAM guna melihat apakah BAM Node tertentu menjalankan perangkat lunak yang diklaimnya. Dengan asumsi tidak ada pihak yang berhasil membobol TEE, sertifikat QUIC untuk TPU akan dibuat di dalam TEE. Dengan demikian, seluruh lalu lintas masuk dan keluar akan dienkripsi.

Namun, penyensoran dan manipulasi selektif terhadap paket transaksi di titik ingress dan egress jaringan merupakan kekhawatiran penting. Operator berbahaya tetap memiliki kemampuan penyensoran yang signifikan meskipun tidak dapat melihat detail transaksi terenkripsi. Operator dapat mengidentifikasi jenis protokol melalui signature TLS, memfilter berdasarkan endpoint koneksi, melakukan analisis waktu untuk mengidentifikasi pola tertentu, serta memblokir semua data terenkripsi yang cocok dengan karakteristik tertentu. Jadi, operator berbahaya mungkin tidak mengetahui transaksi persis yang dikirimkan, tetapi masih dapat membuang paket berdasarkan metadata dan pola lalu lintas tertentu. Untuk mengurangi risiko ini, transparansi yang lebih baik dapat dicapai dengan menggabungkan kemampuan pemfilteran paket dan timestamping DoubleZero. Pada akhirnya, mitigasi serangan penyensoran jaringan merupakan alasan yang valid untuk melakukan peluncuran berizin.

Ada pula asumsi kepercayaan baru terkait akses fisik karena akses semacam itu hampir selalu merupakan kegagalan keamanan, dan TEE pun tidak terkecuali. Meskipun TEE memberikan jaminan keamanan yang kuat, TEE tetap dapat disusupi jika penyerang memperoleh akses fisik ke server. Kemitraan eksklusif dengan penyedia yang mematuhi SOC 2 akan membantu mengurangi risiko ini dengan memastikan keamanan berlapis yang tangguh di tingkat pusat data.

Beberapa pertanyaan masih belum terjawab:

• Jika operator berbahaya menyensor paket atau membocorkan data, bagaimana penegakan akan dilakukan?
• Dalam fase berizin, bagaimana pemilihan operator akan menghindari kolusi, dan metrik apa yang dapat digunakan untuk mengukur kemajuan menuju desentralisasi? 

Komposabilitas dan Interaksi Plugin

Salah satu pertanyaan terbuka terpenting bagi BAM adalah bagaimana plugin akan berinteraksi satu sama lain dalam praktiknya. Satu transaksi dapat bergantung pada beberapa plugin secara bersamaan, misalnya menggunakan plugin oracle untuk pembaruan harga just-in-time, plugin DEX untuk menentukan rute swap optimal, dan plugin token untuk menangani perilaku token SPL tertentu. Memastikan komponen-komponen ini bekerja bersama secara terprediksi dan aman sangatlah penting.

Plugin mungkin perlu mengambil data eksternal agar dapat berfungsi secara efektif. Namun, hal ini menciptakan potensi permukaan serangan karena plugin berbahaya dapat menyalahgunakan panggilan eksternal untuk membocorkan informasi transaksi sensitif. Menetapkan batasan ketat mengenai hal yang dapat diakses dan dibagikan oleh plugin sangat penting untuk mempertahankan kepercayaan terhadap sistem.

Lapisan kompleksitas lain berasal dari interaksi antara logika plugin tingkat aplikasi dan mekanisme biaya Solana. Bagaimana urutan eksekusi plugin, tip Jito, dan biaya prioritas berinteraksi ketika beberapa plugin bersaing untuk memengaruhi konstruksi blok? Dinamika ekonomi ini harus didefinisikan dengan jelas dan diterapkan secara transparan untuk menghindari manipulasi atau penyalahgunaan yang tidak disengaja.

Untuk mengelola risiko ini, peluncuran plugin BAM diperkirakan akan dimulai dalam lingkungan berizin. Hal ini memungkinkan eksperimen tahap awal dan audit perilaku plugin sebelum beralih secara bertahap menuju model tanpa izin.

Kepercayaan dan Tanggung Jawab TEE

Ketergantungan pada TEE memperkenalkan asumsi kepercayaan baru karena TEE menggunakan enclave perangkat keras khusus, bukan menciptakan sistem trustless untuk menjamin komputasi yang dapat diverifikasi. Ketergantungan pada satu vendor perangkat keras, seperti Intel atau AMD, menimbulkan risiko monokultur—penarikan firmware atau eksploitasi berpotensi menghentikan BAM dan mungkin memicu downtime di seluruh jaringan, tergantung pada tingkat adopsi jaringan. Jika kerentanan ini tidak dapat diperbaiki melalui pembaruan firmware, microcode, atau BIOS, penggantian perangkat keras membutuhkan waktu dan membebankan belanja modal berulang kepada operator BAM Node, sehingga makin memperburuk dampak potensi downtime. 

Kekhawatiran ini didasarkan pada kerentanan historis yang menunjukkan bahwa TEE dapat gagal dan berpotensi mengekspos data terenkripsi. Sebagai contoh, Software Guard Extensions (SGX) milik Intel telah mengalami berbagai masalah yang memengaruhi blockchain. Pada Agustus 2022, Secret Network rentan terhadap kerentanan xAPIC dan MMIO. Jika digabungkan, kerentanan ini dapat digunakan untuk mengekstrak seed konsensus—kunci dekripsi utama bagi transaksi privat yang dieksekusi di jaringan. 

Banyak masalah lainnya pada akhirnya menyebabkan Intel menghentikan dukungan SGX pada prosesor Intel Core generasi ke-11 dan ke-12. Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) milik AMD juga memiliki beberapa kerentanan yang telah diungkapkan. Khususnya, pada Februari, CVE-2024-56161 diungkapkan—kerentanan yang memungkinkan injeksi microcode berbahaya dengan akses admin. 

Pembaruan untuk mengurangi kerentanan tidak selalu kompatibel dengan versi sebelumnya dan mungkin memerlukan peningkatan fisik. Sebagai contoh, pengungkapan CVE02020-12967 dan CVE-2021-26311 menunjukkan adanya kemungkinan eksekusi kode arbitrer di dalam mesin virtual tamu pada mesin AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES), yaitu implementasi TEE generasi sebelumnya milik perusahaan tersebut. AMD tidak merilis firmware terbaru untuk mengatasi kerentanan ini dan menyediakan mitigasi melalui fitur SEV-SNP, yang hanya didukung pada prosesor AMD EPYC Generasi ke-3 (yaitu, “Milan”). 

Infrastruktur TEE BAM dibangun di atas arsitektur SEV-SNP generasi terbaru, yang mencakup perlindungan tingkat perangkat keras yang diperlukan untuk mencegah eksploitasi yang telah diketahui ini. Perlu diperhatikan juga bahwa jika kerentanan zero-day ditemukan, jaringan dapat tetap beroperasi karena Jito-Validator dapat secara otomatis kembali menggunakan TPU mereka sendiri ketika terputus dari BAM Node. Mekanisme failover ini memastikan validator terus berjalan selagi patch keamanan diterapkan.

Beberapa pertanyaan masih belum terjawab:

• Bagaimana ketergantungan BAM pada vendor perangkat keras memengaruhi kepercayaan jangka panjang, mengingat eksploitasi sebelumnya? Dapatkah alternatif seperti Zero Trust Execution Environments (ZTEE) digunakan untuk mengurangi ketergantungan ini?
• Siapa yang menanggung tanggung jawab atas kerugian finansial jika data transaksi privat bocor dari TEE yang telah disusupi?
• Bagaimana kepercayaan dapat dipulihkan jika terjadi kegagalan TEE? Dapatkah alternatif ditawarkan?

Kesimpulan

Validator pada akhirnya bebas menjalankan perangkat lunak pilihan mereka. Sebagai bisnis yang berorientasi pada laba dan beroperasi di pasar yang sangat kompetitif, keputusan mereka dipengaruhi oleh potensi imbal hasil bagi diri mereka sendiri dan para delegator mereka, yang bebas memindahkan stake ke mana pun imbal hasilnya paling tinggi. Adopsi Jito-client secara luas mencerminkan dinamika ini. Keberhasilannya sebagian besar didorong oleh kemampuannya memberikan pendapatan tambahan kepada operator dan delegator. Adopsi BAM akan bergantung pada dinamika serupa. Jika menjalankan BAM terbukti secara konsisten lebih menguntungkan daripada kondisi saat ini, validator akan mengadopsinya. Jika tidak, mereka mungkin enggan beralih meskipun BAM berhasil memberikan manfaat besar bagi pemangku kepentingan lainnya.

Karena BAM baru saja diumumkan, masih banyak pertanyaan tentang desain dan operasinya yang belum terjawab. Kami menantikan detail, dokumentasi, dan diskusi komunitas lebih lanjut dalam beberapa bulan mendatang mengenai perkembangan menarik ini.

Referensi Lebih Lanjut

• Memperkenalkan BAM: Masa Depan Pembuatan Blok di Solana - Jito
• Seri Papan Tulis BAM - Jito Learn
• Jito BAM dan Masa Depan Solana - 0xResearch