Mengenai batasan mempool terenkripsi

Nilai yang dapat diekstrak dengan memasukkan, mengeluarkan, atau mengurutkan ulang transaksi dalam satu blok dikenal dengan istilah “maximal extractable value” atau MEV. Fenomena MEV sangat umum terjadi di berbagai jaringan blockchain, dan telah lama menjadi topik yang hangat diperbincangkan di komunitas.

Catatan: Blog ini mengasumsikan pembaca sudah memahami konsep dasar MEV. Jika belum, Anda dapat memulai dengan membaca panduan MEV kami.

Banyak peneliti yang mengamati isu MEV kemudian mengajukan pertanyaan penting: Apakah kriptografi dapat menyelesaikan masalah ini? Salah satu pendekatan yang diajukan adalah mempool terenkripsi, di mana pengguna mengirimkan transaksi yang telah dienkripsi dan baru diungkap setelah urutannya ditentukan. Dengan begitu, protokol konsensus harus menentukan urutan transaksi tanpa mengetahui isinya, sehingga secara teori dapat menghalangi upaya mengeksploitasi peluang MEV di tahap pengurutan.

Namun sayangnya, baik dari sisi teori maupun praktik, mempool terenkripsi belum menjadi solusi universal untuk masalah MEV. Dalam artikel ini, kami menjabarkan berbagai tantangan yang ada, sekaligus mengeksplorasi kemungkinan desain mempool terenkripsi.

Bagaimana mempool terenkripsi bekerja

Terdapat beragam proposal mempool terenkripsi, namun pada dasarnya kerangka umumnya sebagai berikut:

1. Pengguna mengirimkan transaksi yang telah dienkripsi.
2. Transaksi terenkripsi dikomitmen di blockchain (pada sebagian proposal, setelah melalui proses pengacakan acak yang dapat dibuktikan).
3. Setelah blok yang berisi komitmen tersebut terfinalisasi, transaksi kemudian didekripsi.
4. Terakhir, transaksi dieksekusi.

Langkah ketiga (proses dekripsi) merupakan tantangan krusial: Siapa yang bertugas mendekripsi, dan apa yang terjadi bila dekripsi tidak dilakukan? Solusi naif adalah membiarkan pengguna mendekripsi transaksi mereka sendiri (bahkan tanpa perlu enkripsi, cukup menyembunyikan komitmen). Namun, pendekatan ini sangat rentan: Ada risiko MEV spekulatif oleh pihak jahat.

Pada MEV spekulatif, pelaku mencoba menebak bahwa sebuah transaksi terenkripsi mengandung nilai MEV. Ia kemudian mengenkripsi transaksinya sendiri dengan harapan transaksinya akan muncul di posisi strategis (misalnya, tepat sebelum atau setelah transaksi target). Jika urutan transaksi sesuai yang diharapkan, pelaku akan mendekripsi dan mengekstrak MEV. Jika tidak, ia cukup memilih tidak melakukan dekripsi sehingga transaksinya tidak akan masuk ke rantai akhir.

Bisa saja pengguna diberikan penalti jika gagal mendekripsi, tetapi penerapannya rumit. Nilai penalti harus sama untuk semua transaksi terenkripsi (karena tidak dapat dibedakan), dan cukup besar untuk mencegah tindakan spekulatif, bahkan terhadap target bernilai tinggi. Ini berarti perlu mengunci modal dalam jumlah besar yang sifatnya anonim (agar tidak membocorkan identitas pengirim). Selain itu, risiko justru menimpa pengguna yang sah bila terjadi bug atau gangguan jaringan yang membuat mereka gagal mendekripsi transaksinya.

Oleh karena itu, kebanyakan proposal menyarankan transaksi dienkripsi sedemikian rupa sehingga dekripsi dijamin bisa dilakukan di masa depan—bahkan jika pengirim transaksi offline atau tidak kooperatif. Ada beberapa pendekatan untuk itu:

TEE (Trusted Execution Environment): Pengguna dapat mengenkripsi transaksi menggunakan kunci yang hanya tersedia pada lingkungan TEE (Trusted Execution Environment). Dalam versi sederhana, TEE hanya akan mendekripsi transaksi setelah melewati batas waktu tertentu (memerlukan waktu internal di TEE). Versi canggih menggunakan TEE untuk mendekripsi dan menyusun blok, mengurutkan transaksi berdasarkan kriteria seperti waktu kedatangan atau besaran biaya. Kelebihan TEE dibanding solusi lain adalah kemampuannya menyaring transaksi plaintext sehingga dapat mengurangi spam on-chain. Namun, pendekatan ini memerlukan kepercayaan pada perangkat keras.

Secret-sharing dan threshold encryption: Di sini, pengguna mengenkripsi transaksi ke sebuah kunci bersama yang dikelola oleh komite (biasanya sebagian validator). Untuk melakukan dekripsi, diperlukan sejumlah (threshold) anggota komite (misal, dua pertiga validator) untuk berkoordinasi.

Pendekatan paling dasar menggunakan kunci dekripsi baru di setiap putaran (misal, setiap blok atau epoch pada Ethereum), yang setelah urutan transaksi ditetapkan dan blok difinalisasi, komite akan merekonstruksi dan mengumumkan kunci tersebut. Cara ini dapat memanfaatkan secret sharing sederhana, tetapi kelemahannya ialah mengungkap semua transaksi dalam mempool, termasuk yang tidak masuk ke dalam blok. Setiap putaran juga membutuhkan proses Distributed Key Generation (DKG) baru.

Pendekatan yang lebih baik dari sisi privasi adalah hanya mendekripsi transaksi yang benar-benar dimasukkan ke blok. Ini bisa dicapai dengan threshold decryption, sehingga komite dapat “menyebar” biaya protokol DKG dengan menggunakan satu kunci untuk beberapa blok, serta melakukan threshold decryption setelah urutan transaksi dipastikan di blok final. Tantangannya, beban kerja komite jauh lebih besar. Secara langsung, jumlah pekerjaan komite sebanding dengan jumlah transaksi yang perlu didekripsi, meskipun penelitianterbaru menunjukkan dekripsi batch threshold dapat mengurangi overhead secara signifikan.

Pada threshold decryption, kepercayaan bergeser dari perangkat keras ke komite. Secara teori, karena sistem konsensus sudah mengasumsikan mayoritas validator jujur, logikanya hal yang sama berlaku untuk komite dekripsi. Namun, perlu dicatat: Kedua asumsi ini berbeda. Kegagalan konsensus seperti forking rantai akan terdeteksi secara publik (asumsi lemah), sedangkan komite jahat yang mendekripsi transaksi lebih awal tidak akan meninggalkan jejak publik dan tidak bisa dideteksi/dihukum (asumsi kuat). Jadi, meski di permukaan tampak serupa, secara praktis kepercayaan pada komite jauh lebih rentan.

Time-lock dan delay encryption: Alternatif threshold encryption adalah delay encryption. Di sini, transaksi dienkripsi menggunakan kunci publik yang kunci rahasianya tersembunyi dalam puzzle kriptografi time-locked, yang hanya bisa dipecahkan setelah waktu tertentu lewat proses komputasi sekuensial. Siapa pun bisa memecahkan puzzle guna memperoleh kunci dan mendekripsi transaksi, tapi hanya setelah waktu komputasi lama yang membuat transaksi tidak dapat didekripsi sebelum blok difinalisasi. Versi terkuat menggunakan delay encryption untuk membentuk puzzle secara publik. Alternatif lainnya adalah komite terpercaya yang memproses time-lock encryption, tetapi keunggulannya dibanding threshold encryption menjadi kurang jelas.

Baik delay encryption maupun komputasi oleh komite terpercaya menghadirkan tantangan praktis. Pertama, sulit memastikan timing dekripsi karena basisnya komputasi, bukan waktu mutlak. Kedua, solusi ini bergantung pada entitas dengan perangkat keras khusus yang mampu menyelesaikan puzzle secara efisien. Meskipun peran ini bisa diambil siapa saja, insentif siapa yang mau menjalankannya belum jelas. Terakhir, semua transaksi yang disiarkan dapat didekripsi, termasuk yang tidak pernah masuk dalam blok. Solusi threshold (atau witness encryption) memungkinkan hanya transaksi yang benar-benar dieksekusi yang didekripsi.

Witness encryption. Pendekatan kriptografi paling mutakhir mempergunakan witness encryption. Secara teori, witness encryption memungkinkan terenkripsi pada pihak mana pun yang mengetahui witness pada relasi NP tertentu. Sebagai contoh, data bisa dienkripsi sedemikian sehingga hanya pihak dengan solusi puzzle Sudoku tertentu atau preimage hash yang dapat mendekripsi.

SNARK juga digunakan untuk relasi NP apapun. Witness encryption bisa dimaknai sebagai enkripsi data bagi siapa pun yang dapat membuktikan kondisi tertentu melalui SNARK. Dalam konteks mempool terenkripsi, contohnya adalah transaksi hanya bisa didekripsi setelah blok dikonfirmasi final.

Ini adalah primitif kriptografi yang sangat kuat—bahkan pendekatan berbasis komite atau delay sebenarnya merupakan kasus khusus dari generalisasi ini. Namun, hingga hari ini belum ada implementasi witness encryption yang praktis. Selain itu, sekalipun teknologi ini sudah ada, belum tentu lebih unggul dibanding pendekatan komite untuk rantai proof-of-stake. Meski pengaturannya membatasi dekripsi pada saat blok sudah final, komite jahat bisa secara privat mensimulasikan konsensus hingga transaksi dianggap final, lalu memakai chain privat itu sebagai witness untuk dekripsi. Pada titik ini, threshold decryption oleh komite yang sama menawarkan tingkat keamanan yang setara dengan proses yang jauh lebih sederhana.

Witness encryption justru jauh lebih unggul pada jaringan dengan konsensus proof-of-work, karena komite jahat tidak bisa secara privat menambang blok-blok baru di atas chain yang berjalan demi mensimulasikan finalitas.

Tantangan teknis pada mempool terenkripsi

Ada sejumlah tantangan praktis yang menghambat efektivitas mempool terenkripsi dalam mencegah MEV. Menjaga kerahasiaan informasi di dunia nyata sangat sulit. Menariknya, banyak sistem web3 selama ini jarang benar-benar mengimplementasikan enkripsi. Kita punya pengalaman panjang mengenai tantangan keamanan enkripsi di web (TLS/HTTPS) dan komunikasi privat (dari PGP hingga platform seperti Signal/Whatsapp). Enkripsi memang alat untuk menjaga kerahasiaan, tetapi tidak menjamin keamanan secara absolut.

Tantangan pertama adalah potensi akses langsung ke data transaksi oleh pihak tertentu. Sering kali, pengguna tidak melakukan enkripsi sendiri, melainkan meminta wallet provider melakukannya. Akibatnya, penyedia wallet bisa melihat transaksi asli dan berpotensi menggunakan atau menjual informasi tersebut untuk MEV. Kekuatan enkripsi tak pernah melebihi entitas yang memegang kuncinya.

Selain itu, masalah terbesar adalah bocornya metadata, yaitu segala informasi seputar transaksi yang tidak ikut terenkripsi. Searcher bisa memanfaatkan metadata ini untuk menebak maksud transaksi lalu mencoba MEV spekulatif. Mereka tidak perlu tahu isi transaksi sepenuhnya—cukup punya peluang menemukan misal, order beli di suatu DEX dengan probabilitas tertentu.

Ada beberapa jenis metadata yang penting untuk diwaspadai, baik yang sudah klasik maupun yang muncul khusus di mempool terenkripsi:

• Ukuran transaksi: Proses enkripsi tidak menyembunyikan ukuran plaintext. (Definisi formal keamanan semantik bahkan membuat pengecualian khusus untuk aspek ini.) Ini sering menjadi titik lemah pada komunikasi terenkripsi. (Sebagai contoh, meski terenkripsi, pihak tertentu dapat menebak film yang diputar di Netflix hanya dari ukuran paket data.) Pada mempool terenkripsi, tipe transaksi bisa dikenali lewat ukuran spesifiknya.

• Waktu transaksi: Enkripsi juga tidak menyamarkan waktu pengiriman pesan (ini adalah celah klasik). Dalam konteks web3, misal pada transaksi penjualan terjadwal, pelaku bisa mengenali pola waktu, atau mengaitkan dengan peristiwa lain di bursa. Yang lebih rumit, data waktu bisa dieksploitasi untuk arbitrase CEX/DEX—sequencer bisa menambahkan transaksi di waktu optimal agar mendapat keuntungan harga terbaru, sambil menolak transaksi lain setelah batas tertentu.

• Alamat IP pengirim: Melalui observasi jaringan peer-to-peer, searcher bisa menebak identitas pengirim dari alamat IP, sebagaimana sudah diidentifikasi sejak awal era Bitcoin. Jika pengirim tertentu punya pola khas, informasi ini bisa mengaitkan transaksi terenkripsi dengan transaksi terdahulu yang sudah terbuka.

• Identitas dan rincian biaya/gas: Data biaya adalah metadata khusus di mempool terenkripsi. Di Ethereum, transaksi selalu mencantumkan alamat pengirim (untuk pembayaran biaya), besaran gas maksimum, besaran biaya per satuan gas. Alamat pengirim dan detail gas bisa digunakan untuk mengaitkan transaksi satu sama lain, atau memprediksi tujuan transaksi (misal, interaksi dengan DEX tertentu biasanya memerlukan gas khusus).

Searcher tingkat lanjut dapat menggabungkan berbagai metadata di atas untuk memperkirakan isi transaksi sebenarnya.

Memang semua informasi ini dapat dikaburkan, tetapi dengan biaya kinerja dan kompleksitas tinggi. Contoh: membuat ukuran transaksi standar (padding) menutupi ukuran asli tapi mengorbankan bandwidth/ruang on-chain. Menunda pengiriman pesan bisa mengaburkan waktu, tetapi memperlambat sistem. Mengirim transaksi lewat jaringan anonim seperti Tor bisa menyembunyikan IP—namun juga mengandung tantangan tersendiri.

Yang paling sulit ditutupi adalah informasi biaya transaksi. Jika bagian biaya dienkripsi, builder tidak bisa memfilter transaksi yang tak mampu membayar biaya, sehingga spam menjadi masalah besar. Usulan mengatasinya dengan SNARK agar bisa membuktikan transaksi valid, namun ini meningkatkan overhead jauh lebih besar.

Masalah berikutnya adalah efisiensi block building dan lelang biaya. Builder umumnya memilih transaksi dengan biaya tertinggi untuk memaksimalkan pendapatan dan menentukan harga di jaringan. Bila informasi biaya dienkripsi, proses ini terganggu. Solusinya bisa berupa biaya flat per blok, tetapi kurang efisien secara ekonomi dan bisa melahirkan pasar gelap untuk prioritas transaksi. Opsi dengan secure multiparty computation atau perangkat keras khusus ada, namun biayanya tinggi.

Selain itu, penggunaan mempool terenkripsi menambah beban sistem: Latensi meningkat, komputasi bertambah, bandwidth membesar. Integrasi dengan teknologi masa depan seperti sharding atau eksekusi paralel belum jelas penerapannya. Selain itu, sistem ini juga menciptakan titik kegagalan tambahan (contoh: komite dekripsi pada threshold solution atau peran solver pada delay function), serta meningkatkan kompleksitas desain & implementasi.

Banyak tantangan yang ditemui mempool terenkripsi juga dijumpai pada blockchain yang memang mengutamakan privasi transaksi (seperti Zcash, Monero). Sisi positifnya, jika tantangan enkripsi untuk MEV dapat dipecahkan, otomatis masalah privasi transaksi juga akan ikut terselesaikan.

Tantangan ekonomi mempool terenkripsi

Pada akhirnya, mempool terenkripsi juga menghadapi tantangan ekonomi. Tidak seperti tantangan teknis yang mungkin bisa diatasi lewat rekayasa, tantangan ekonomi bersifat fundamental dan sukar diatasi.

MEV pada dasarnya merupakan hasil asimetri informasi antara pengguna pembuat transaksi dan searcher-builder yang memburu peluang MEV. Mayoritas pengguna tidak mengetahui jumlah MEV yang bisa diambil dari transaksinya. Akibatnya, meski mempool terenkripsi sempurna, tetap ada kemungkinan pengguna rela menyerahkan kunci dekripsi demi imbalan dari builder yang nilainya di bawah MEV yang diambil—fenomena ini disebut incentivized decryption.

Fenomena ini sudah terjadi dalam praktik lewat MEV Share, yaitu lelang order flow di mana pengguna dapat membagikan sebagian informasi transaksinya ke pool, searcher bersaing menawar atas peluang MEV di transaksi itu. Searcher dengan tawaran terbaik mengeksekusi MEV dan membagikan sebagian hasilnya (bid atau bagiannya) ke pengguna.

Model serupa bisa diterapkan pada mempool terenkripsi, di mana pengguna mengungkap kunci dekripsi (atau sebagian informasinya) demi partisipasi. Namun, kebanyakan pengguna tidak memahami biaya peluang partisipasi, mereka hanya melihat keuntungan langsung dan cenderung menyerahkan datanya begitu saja. Hal mirip juga terjadi di dunia keuangan tradisional—layanan trading gratis seperti Robinhood memperoleh pendapatan dengan menjual order flow pengguna ke pihak ke-3 (dikenal sebagai model bisnis “payment-for-order-flow”).

Skenario lain, builder besar memaksa pengguna membuka isi transaksi (atau sebagian informasinya) karena alasan sensor. Ketahanan sensor adalah isu penting dan sensitif di web3; bila builder/proposer besar secara hukum diwajibkan menerapkan daftar sensor (misal, OFAC), mereka bisa menolak proses transaksi terenkripsi. Secara teknis ini dapat diatasi jika pengguna mampu membuat zero-knowledge proof bahwa transaksinya sesuai aturan sensor, namun langkah ini menambah biaya dan kompleksitas. Walaupun jaringan punya ketahanan sensor tinggi dan transaksi terenkripsi tetap diproses, builder bisa tetap memprioritaskan transaksi yang sudah diketahui (plaintext) dan menaruh transaksi terenkripsi di urutan bawah. Dengan demikian, transaksi yang butuh jaminan eksekusi tetap dipaksa membuka informasinya ke builder.

Tantangan efisiensi lainnya

Mempool terenkripsi menambah overhead nyata dalam sistem: Pengguna perlu mengenkripsi transaksi, dan sistem harus mendekripsi. Ini meningkatkan kebutuhan komputasi dan bisa memperbesar ukuran transaksi. Pengelolaan metadata justru bisa memperparah overhead. Selain itu, ada “biaya tersembunyi” lain: Di dunia keuangan, pasar efisien bila harga mencerminkan seluruh informasi yang ada, dan inefisiensi muncul akibat keterlambatan atau asimetri informasi—konsekuensi wajar pada desain mempool terenkripsi.

Salah satu dampak inefisiensi adalah meningkatnya ketidakpastian harga akibat delay eksekusi. Akibatnya, kegagalan transaksi akibat slippage harga makin sering terjadi dan membuang ruang pada blockchain.

Hal serupa juga bisa menyebabkan pertumbuhan transaksi MEV spekulatif untuk mengejar arbitrase on-chain. Bahkan, peluang seperti ini makin besar pada mempool terenkripsi, karena status DEX makin tidak pasti akibat eksekusi tertunda, sehingga pasar menjadi kurang efisien dan harga beda antarplatform. Transaksi MEV spekulatif ini juga membuang ruang blok karena sering gagal bila peluang arbitrase tak ditemukan.

Meskipun tujuan artikel ini adalah menyoroti tantangan mempool terenkripsi agar komunitas fokus mengembangkan solusi alternatif, bukan berarti mempool terenkripsi tidak memiliki peran dalam solusi MEV.

Salah satu opsi adalah desain hybrid: ada transaksi yang diurutkan secara buta melalui mempool terenkripsi, sisanya melalui solusi lain. Bagi pelaku pasar besar, seperti institusi dengan kebutuhan beli/jual dan kemampuan melakukan enkripsi/padding serta siap menanggung biaya ekstra demi menghindari MEV, desain hybrid mungkin solusi tepat. Model ini juga cocok untuk transaksi sangat sensitif, misal perbaikan bug pada kontrak dengan kerentanan keamanan.

Namun, karena keterbatasan teknis, kompleksitas rekayasa tinggi, dan masalah performa, mempool terenkripsi kecil kemungkinan menjadi solusi tunggal bagi masalah MEV seperti yang kadang digembar-gemborkan. Komunitas perlu mengembangkan solusi alternatif lain, mulai dari lelang MEV, pertahanan di tingkat aplikasi, hingga mempercepat waktu finalitas. MEV akan tetap jadi tantangan, sehingga diperlukan kehati-hatian dalam memilih kombinasi solusi yang paling seimbang untuk mitigasi risiko.

Pranav Garimidi adalah Research Associate di a16z Crypto, dengan riset dalam bidang desain mekanisme dan teori permainan algoritmik pada sistem blockchain, terutama fokus pada dinamika insentif di seluruh stack blockchain. Sebelum di a16z, Pranav lulusan Computer Science dari Columbia University.

Joseph Bonneau adalah Associate Professor di Departemen Ilmu Komputer, Courant Institute NYU, serta penasihat teknis a16z crypto. Riset utamanya di kriptografi terapan dan keamanan blockchain. Ia pernah mengajar kursus cryptocurrency di University of Melbourne, NYU, Stanford, dan Princeton, meraih PhD di University of Cambridge, serta BS/MS dari Stanford.

Lioba Heimbach adalah mahasiswa Ph.D. tahun keempat di bawah bimbingan Prof. Dr. Roger Wattenhofer dalam grup Distributed Computing (Disco) ETH Zurich. Risetnya berfokus pada protokol blockchain, khususnya keuangan terdesentralisasi (DeFi), dengan visi mewujudkan ekosistem blockchain dan DeFi yang inklusif, adil, dan efisien. Pada musim panas 2024, ia menjalani magang riset di a16z crypto.

Pendapat dalam artikel ini sepenuhnya milik pribadi anggota AH Capital Management, L.L.C. (“a16z”) yang dikutip, dan bukan merupakan pandangan resmi a16z maupun afiliasinya. Beberapa informasi diambil dari sumber pihak ketiga, termasuk perusahaan portofolio dana yang dikelola a16z. Meskipun dianggap akurat, a16z tidak melakukan verifikasi independen dan tidak memberikan jaminan terkait kelengkapan atau keakuratan informasi tersebut, atau kesesuaiannya untuk situasi tertentu. Selain itu, konten ini dapat memuat iklan pihak ketiga; a16z tidak meninjau atau mendukung materi iklan apapun di dalamnya.

Konten artikel hanya untuk tujuan informasi, tidak boleh dijadikan nasihat hukum, bisnis, investasi, atau pajak. Konsultasikan kepada penasihat Anda sendiri untuk keperluan tersebut. Referensi pada sekuritas atau aset digital hanya bersifat ilustratif, tidak menjadi rekomendasi investasi atau ajakan penyediaan jasa konsultasi investasi. Artikel ini juga tidak diperuntukkan bagi investor atau calon investor mana pun dan tidak dapat digunakan sebagai dasar keputusan berinvestasi pada dana a16z. (Penawaran berinvestasi di dana a16z hanya melalui dokumen resmi: memorandum penempatan, perjanjian langganan, dan dokumen relevan lain yang harus dibaca menyeluruh.) Setiap investasi atau portofolio yang disebutkan tidak mewakili keseluruhan investasi dana a16z, dan tidak ada jaminan investasi tersebut akan untung atau investasi mendatang akan memiliki karakteristik serupa. Daftar investasi dana a16z (selain yang belum diumumkan atau belum mendapat izin publikasi dari penerbit) tersedia di https://a16z.com/investments/.

Segala pernyataan hanya berlaku pada tanggal tertera. Proyeksi, estimasi, prediksi, tujuan, prospek, dan/atau opini yang ada di artikel ini bisa berubah sewaktu-waktu tanpa pemberitahuan dan dapat berbeda atau bertentangan dengan opini pihak lain. Untuk informasi penting tambahan, silakan kunjungi https://a16z.com/disclosures.

Disclaimer:

1. Artikel ini merupakan publikasi ulang dari [a16zcrypto]. Seluruh hak cipta milik penulis asli [Pranav GarimidiJoseph BonneauLioba Heimbach]. Adanya keberatan terkait publikasi ulang ini bisa disampaikan ke tim Gate Learn untuk penanganan lebih lanjut.
2. Penafian: Seluruh pendapat dan pandangan dalam artikel ini sepenuhnya milik penulis dan sama sekali bukan merupakan saran investasi.
3. Terjemahan dilakukan oleh tim Gate Learn. Kecuali dinyatakan lain, segala bentuk penyalinan, distribusi, atau penjiplakan atas artikel terjemahan dilarang.