Di batas-batas mempool terenkripsi

Nilai yang dapat diekstrak dengan menyertakan, mengecualikan, atau mengubah urutan transaksi dalam sebuah blok dikenal sebagai "nilai ekstraksi maksimal, atau MEV. MEV umum di sebagian besar blockchain, dan telah menjadi topik yang menarik dan dibahas secara luas di komunitas.

Catatan: Postingan blog ini mengasumsikan pemahaman dasar tentang MEV. Beberapa pembaca mungkin ingin memulai dengan membaca kami Penjelasan MEV.

Banyak peneliti, yang mengamati situasi MEV, telah mengajukan pertanyaan yang jelas: Bisakah kriptografi menyelesaikan masalah ini? Salah satu pendekatan adalah mempool terenkripsi, di mana pengguna menyiarkan transaksi terenkripsi yang hanya diungkapkan setelah mereka diurutkan. Oleh karena itu, protokol konsensus harus berkomitmen untuk mengurutkan transaksi secara buta, tampaknya mencegah kemampuan untuk memanfaatkan peluang MEV selama proses pengurutan.

Sayangnya, karena alasan praktis dan teoritis, kami tidak melihat mempool terenkripsi memberikan solusi universal untuk MEV. Kami menguraikan kesulitan-kesulitan dan mengeksplorasi bagaimana mempool terenkripsi dapat dirancang.

Bagaimana cara kerja mempool terenkripsi

Telah ada banyak proposal untuk mempool terenkripsi, tetapi kerangka umum untuk mempool terenkripsi adalah sebagai berikut:

1. Pengguna menyiarkan transaksi terenkripsi mereka.
2. Transaksi terenkripsi dikomitmenkan di rantai (dalam beberapa proposal setelah disecara provabel diacak secara acak)
3. Setelah blok yang dikomit final, transaksi didekripsi.
4. Akhirnya, transaksi dieksekusi.

Perhatikan bahwa langkah 3 (dekripsi transaksi) merupakan tantangan penting: Siapa yang mendekripsi, dan bagaimana jika dekripsi tidak terjadi? Solusi yang naif adalah mengatakan bahwa pengguna sendiri mendekripsi transaksi mereka (dalam hal ini, tidak perlu enkripsi, tetapi bisa saja hanya menyembunyikan komitmen). Namun, pendekatan ini rentan: Seorang penyerang dapat melakukan MEV spekulatif.

Dengan MEV spekulatif, seorang penyerang berusaha menebak bahwa transaksi terenkripsi tertentu menghasilkan beberapa MEV. Mereka mengenkripsi transaksi mereka sendiri yang semoga akan muncul di tempat yang tepat (misalnya, tepat sebelum atau setelah transaksi target). Jika transaksi tersebut diurutkan dalam urutan yang diharapkan, penyerang mendekripsi dan transaksi mereka mengekstrak MEV. Jika tidak, mereka menolak untuk mendekripsi dan transaksi mereka tidak termasuk dalam rantai akhir.

Mungkin pengguna dapat menghadapi beberapa penalti karena gagal untuk mendekripsi, tetapi ini sulit untuk diimplementasikan. Penalti harus sama untuk semua transaksi yang dienkripsi (karena mereka dienkripsi dan karenanya tidak dapat dibedakan), tetapi juga cukup besar untuk mencegah MEV spekulatif bahkan terhadap target bernilai tinggi. Ini akan membutuhkan penguncian banyak modal, yang harus anonim (untuk menghindari kebocoran informasi tentang transaksi mana yang diposting oleh pengguna mana). Dan itu akan mengakibatkan biaya bagi pengguna yang jujur dalam kasus bug atau kegagalan jaringan yang mencegah upaya sah mereka untuk mendekripsi.

Oleh karena itu, sebagian besar proposal menyarankan agar transaksi dienkripsi sedemikian rupa sehingga dekripsi dijamin dapat dilakukan pada suatu saat di masa depan — bahkan jika pengguna yang memposting pergi offline atau tidak berkooperasi. Ini dapat dicapai dengan beberapa cara:

TEEs: Pengguna dapat mengenkripsi transaksi mereka ke sebuah kunci yang dipegang oleh Trusted Execution Environment (TEE) enclave. Dalam beberapa versi sederhana, TEE hanya digunakan untuk mendekripsi transaksi setelah batas waktu tertentu (yang memerlukan pengertian waktu dalam TEE). Pendekatan yang lebih maju menggunakan TEE untuk mendekripsi transaksi dan membangun blok, mengurutkannya berdasarkan kriteria tertentu seperti waktu kedatangan atau biaya. Salah satu keuntungan TEE dibandingkan dengan pendekatan mempool terenkripsi lainnya adalah kemampuannya untuk beroperasi pada transaksi plaintext, sehingga mengurangi spam onchain dengan menyaring transaksi yang akan dibatalkan. Namun, metode ini memerlukan kepercayaan pada perangkat keras.

Pembagian rahasia dan enkripsi ambang: Dengan pendekatan ini, pengguna mengenkripsi transaksi ke kunci yang dibagikan oleh beberapa komite, biasanya subset dari validator. Beberapa ambang (misalnya, dua pertiga dari komite) diperlukan untuk dekripsi.

Pendekatan yang paling sederhana menggunakan kunci dekripsi bersama yang baru di setiap putaran (misalnya, setiap blok atau epoch di Ethereum), yang direkonstruksi dan diterbitkan oleh komite setelah transaksi diurutkan dalam blok yang sudah final. Pendekatan ini dapat menggunakan pembagian rahasia yang sederhana. Kerugiannya adalah ini mengungkapkan semua transaksi dari mempool, bahkan yang tidak termasuk dalam blok. Pendekatan ini juga memerlukan generasi kunci terdistribusi (DKG) yang baru di setiap putaran.

Pendekatan yang lebih baik untuk privasi adalah dengan mendekripsi hanya transaksi yang sebenarnya termasuk. Ini dapat direalisasikan menggunakan dekripsi ambang. Pendekatan ini juga memungkinkan untuk mengamortisasi biaya protokol DKG tetapi menggunakan kunci yang sama untuk beberapa blok dengan komite yang mendekripsi transaksi setelah mereka diurutkan dalam blok yang telah difinalisasi. Tantangannya adalah bahwa komite harus melakukan lebih banyak pekerjaan. Secara naif, pekerjaan komite bersifat linier dalam jumlah transaksi yang harus didekripsi, meskipun barukerjamengusulkan dekripsi ambang batch yang dapat meningkatkan hal ini secara signifikan.

Dengan dekripsi ambang, kepercayaan beralih dari sepotong perangkat keras ke sebuah komite. Klaimnya adalah bahwa, karena sebagian besar protokol sudah membuat asumsi mayoritas yang jujur tentang validator untuk protokol konsensus, kita dapat membuat asumsi serupa bahwa mayoritas validator adalah jujur dan tidak akan mendekripsi transaksi lebih awal. Namun, perlu dicatat bahwa ini bukan asumsi kepercayaan yang sama. Kegagalan konsensus seperti bercabangnya rantai terlihat secara publik (disebut asumsi kepercayaan lemah), sementara komite jahat yang secara pribadi mendekripsi transaksi lebih awal tidak akan menghasilkan bukti publik dan oleh karena itu serangan semacam itu tidak dapat dideteksi atau dihukum (asumsi kepercayaan yang kuat). Jadi, meskipun, dari luar, asumsi keamanan untuk konsensus dan komite enkripsi mungkin terlihat sama, pertimbangan praktis membuat asumsi bahwa sebuah komite tidak akan berkolusi lebih rapuh.

Enkripsi dengan kunci waktu dan penundaan: Sebuah alternatif untuk enkripsi ambang datang dalam bentuk enkripsi penundaan. Pengguna mengenkripsi transaksi mereka ke kunci publik yang kunci rahasianya tersembunyi dalam teka-teki terkunci waktu. Teka-teki terkunci waktu adalah teka-teki kriptografi yang mengenkapsulasi sebuah rahasia, yang hanya dapat diungkap setelah sejumlah waktu tertentu telah berlalu - lebih spesifiknya, teka-teki ini dapat didekripsi dengan melakukan beberapa perhitungan yang tidak dapat diparalelkan secara berulang. Dalam hal ini, teka-teki ini dapat dibuka oleh siapa saja untuk memulihkan kunci dan mendekripsi transaksi, tetapi hanya setelah perhitungan yang lambat (secara inheren berurutan) yang dirancang untuk memakan waktu cukup lama sehingga transaksi tidak dapat didekripsi sebelum mereka diselesaikan. Versi terkuat dari primer ini menggunakan enkripsi penundaan untuk secara publik menghasilkan teka-teki semacam itu. Ini juga dapat didekati dengan menggunakan komite tepercaya untuk menghitung teka-teki melalui enkripsi kunci waktu, meskipun pada saat itu keuntungan dibandingkan enkripsi ambang dipertanyakan.

Baik melalui enkripsi penundaan atau komputasi oleh komite tepercaya, ada sejumlah tantangan praktis. Pertama, lebih sulit untuk memastikan waktu dekripsi yang tepat, karena penundaan bersifat komputasional. Kedua, skema ini bergantung pada entitas yang menjalankan perangkat keras canggih untuk menyelesaikan teka-teki dengan efisien. Sementara siapa pun dapat memenuhi peran ini, tidak jelas bagaimana cara memberi insentif kepada pihak ini. Akhirnya, dalam desain ini, semua transaksi siaran akan didekripsi, termasuk yang tidak pernah difinalisasi dalam sebuah blok. Solusi berbasis ambang (atau enkripsi saksi) berpotensi hanya dapat mendekripsi transaksi yang berhasil disertakan.

Enkripsi saksi. Akhirnya, pendekatan kriptografi yang paling canggih menggunakan alat yang disebut enkripsi saksi. Secara teoretis, enkripsi saksi memungkinkan untuk mengenkripsi informasi kepada siapa pun yang mengetahui saksi untuk hubungan NP tertentu. Misalnya, seseorang dapat mengenkripsi sehingga siapa pun yang memiliki solusi untuk teka-teki Sudoku tertentu, atau siapa pun yang memiliki preimage hash dari nilai tertentu, dapat mendekripsi.

SNARK juga memungkinkan untuk setiap relasi NP. Seseorang dapat menganggap enkripsi saksi sebagai mengenkripsi data kepada siapa saja yang dapat menghitung SNARK yang membuktikan kondisi yang diinginkan. Untuk mempool terenkripsi, satu contoh untuk kondisi semacam itu adalah bahwa transaksi hanya dapat didekripsi ketika sebuah blok telah difinalisasi.

Ini adalah sebuah primitif teoretis yang sangat kuat. Faktanya, ini adalah generalisasi di mana pendekatan berbasis komite dan pendekatan berbasis penundaan adalah kasus spesifik. Sayangnya, kami tidak memiliki konstruksi praktis dari enkripsi berbasis saksi. Lebih lanjut, bahkan jika kami memilikinya, tidak jelas bagaimana ini merupakan perbaikan dibandingkan dengan pendekatan berbasis komite untuk rantai bukti kepemilikan. Bahkan jika enkripsi saksi diatur sehingga transaksi hanya dapat didekripsi setelah mereka diurutkan dalam blok yang telah diselesaikan, sebuah komite yang jahat masih dapat secara pribadi mensimulasikan protokol konsensus sehingga transaksi diselesaikan, dan kemudian menggunakan rantai pribadi ini sebagai saksi untuk mendekripsi transaksi. Pada saat itu, menggunakan dekripsi ambang oleh komite yang sama memberikan keamanan yang setara dan jauh lebih sederhana.

Enkripsi saksi menawarkan keunggulan yang lebih pasti dalam protokol konsensus bukti kerja, karena bahkan komite yang sepenuhnya jahat tidak dapat menambang beberapa blok baru di atas kepala saat ini secara pribadi untuk mensimulasikan finalitas.

Tantangan teknis untuk mempool terenkripsi

Beberapa tantangan praktis penting membatasi kemampuan mempool terenkripsi untuk mencegah MEV. Secara umum, menjaga informasi tetap rahasia itu sulit. Menariknya, enkripsi adalah alat yang jarang digunakan di ruang web3. Namun, kami memiliki pengalaman praktis selama beberapa dekade yang menunjukkan tantangan dalam menerapkan enkripsi di web (TLS/HTTPS) dan untuk komunikasi pribadi (dari PGP hingga platform pesan terenkripsi modern seperti Signal atau Whatsapp). Meskipun enkripsi adalah alat untuk menjaga kerahasiaan, itu tidak menjamin kerahasiaan tersebut.

Pertama, mungkin ada pihak yang memiliki akses langsung ke teks asli dari transaksi pengguna. Dalam kasus yang umum, pengguna mungkin tidak mengenkripsi transaksi mereka sendiri tetapi menyerahkannya kepada penyedia dompet mereka. Akibatnya, penyedia dompet memiliki akses ke transaksi teks asli dan dapat menggunakan atau menjual informasi ini untuk mengekstrak MEV. Enkripsi tidak pernah lebih kuat daripada sekumpulan pihak yang memiliki akses ke kunci.

Selain itu, masalah terbesar adalah metadata, yaitu data yang mengelilingi payload terenkripsi (transaksi), yang tidak terenkripsi. Pencari dapat menggunakan metadata ini untuk menebak maksud dari sebuah transaksi dan kemudian mencoba MEV spekulatif. Ingat, pencari tidak harus sepenuhnya memahami sebuah transaksi, atau benar setiap kali. Cukup jika mereka tahu, misalnya, bahwa dengan probabilitas yang masuk akal, sebuah transaksi mewakili pesanan beli dari DEX tertentu.

Kita dapat mempertimbangkan beberapa jenis metadata, beberapa di antaranya adalah tantangan klasik dengan enkripsi dan beberapa di antaranya adalah unik untuk mempool terenkripsi.

• Ukuran transaksi: Enkripsi itu sendiri tidak menyembunyikan ukuran plaintext yang terenkripsi. (Ada, secara terkenal, pengecualian spesifik yang dibuat dalam definisi formal keamanan semantik untuk mengecualikan penyembunyian ukuran plaintext yang sedang dienkripsi.) Ini adalah vektor serangan klasik pada komunikasi terenkripsi. (Dalam contoh terkenal, bahkan dengan enkripsi, seorang penyadapdapat menentukan video apa sedang disiarkan di Netflix secara real-time dari ukuran setiap paket dalam aliran video.) Dalam konteks mempool yang terenkripsi, jenis transaksi tertentu mungkin memiliki ukuran spesifik yang membocorkan informasi.

• Waktu siaran: Enkripsi juga tidak menyembunyikan informasi waktu (lainnyavektor serangan klasik). Dalam konteks web3, pengirim tertentu — misalnya, dalam penjualan terstruktur — mungkin melakukan transaksi pada interval reguler. Waktu transaksi juga mungkin terkait dengan informasi lain, seperti aktivitas di bursa eksternal atau peristiwa berita. Cara yang lebih halus untuk mengeksploitasi informasi waktu adalah arbitrase CEX/DEX. Seorang sequencer dapat mengambil keuntungan dengan menyisipkan transaksi yang dibuat sedapat mungkin, memanfaatkan informasi yang lebih baru tentang harga CEX. Sequencer yang sama dapat mengecualikan transaksi lain (bahkan jika terenkripsi) yang disiarkan setelah titik waktu tertentu, memastikan bahwa transaksinya sendiri memiliki keuntungan informasi harga paling terkini.

• Alamat IP asal: Para pencari mungkin menyimpulkan identitas pengirim transaksi dengan memantau jaringan peer-to-peer dan mengamati alamat IP asal. Masalah ini sebenarnyadiidentifikasi lebih dari sepuluh tahun yang lalu di hari-hari awal Bitcoin. Ini bisa berguna bagi pencari jika pengirim tertentu memiliki pola tertentu — misalnya, mengetahui pengirim mungkin memungkinkan menghubungkan transaksi terenkripsi dengan transaksi sebelumnya yang sudah didekripsi.

• Informasi pengirim transaksi dan biaya/gas: Akhirnya, biaya transaksi mewakili sejenis metadata yang spesifik untuk mempool terenkripsi. Di Ethereum, transaksi secara klasik mencakup alamat pengirim (onchain), yang digunakan untuk membayar biaya, serta anggaran gas maksimum dan biaya per unit gas yang bersedia dibayar oleh pengirim. Alamat pengirim, seperti alamat jaringan asal, dapat digunakan untuk menghubungkan transaksi satu sama lain dan dengan entitas dunia nyata. Anggaran gas dapat digunakan untuk memperkirakan apa yang ingin dilakukan transaksi. Misalnya, berinteraksi dengan DEX tertentu mungkin memerlukan jumlah gas tertentu yang dapat dikenali.

Pencari yang canggih mungkin menggunakan kombinasi dari jenis metadata di atas untuk memprediksi isi transaksi.

Semua informasi ini bisa saja disembunyikan, tetapi dengan biaya kinerja dan kompleksitas. Misalnya, menambahkan padding pada transaksi hingga batas standar menyembunyikan ukuran transaksi, tetapi membuang bandwidth dan ruang di onchain. Menambahkan penundaan sebelum mengirim pesan menyembunyikan waktu transaksi, tetapi merugikan latensi. Mengirimkan transaksi melalui jaringan anonimitas seperti Tor bisa menyembunyikan alamat IP pengirim, tetapi ini memiliki tantangannya sendiri.

Metadata yang paling sulit untuk disembunyikan adalah data biaya transaksi. Mengenkripsi data ini menimbulkan sejumlah tantangan bagi pembangun. Masalah pertama adalah spam. Jika data pembayaran biaya transaksi dienkripsi, maka siapa pun dapat menyiarkan transaksi terenkripsi yang tidak teratur yang akan diurutkan tetapi tidak memiliki kemampuan untuk membayar biaya. Oleh karena itu, setelah dekripsi, mereka tidak akan dapat dieksekusi tetapi tidak ada pihak yang dapat dihukum. Ini mungkin dapat diatasi dengan SNARKs yang membuktikan bahwa transaksi tersebut terstruktur dengan baik dan didanai, tetapi ini akan sangat meningkatkan overhead.

Masalah kedua adalah pembangunan blok yang efisien dan lelang biaya. Pembuat blok menggunakan biaya untuk membangun blok yang paling menguntungkan dan menetapkan harga pasar saat ini untuk sumber daya onchain. Mengenkripsi data ini mengganggu proses ini. Ini dapat diatasi dengan menetapkan biaya tetap di setiap blok, tetapi ini tidak efisien secara ekonomi dan mungkin mendorong pasar sekunder untuk inklusi transaksi yang akan merusak tujuan dari memiliki mempool yang terenkripsi. Melakukan lelang biaya menggunakan komputasi multi-pihak yang aman atau perangkat keras tepercaya adalah mungkin, tetapi kedua langkah ini mahal.

Akhirnya, mempool yang aman dan terenkripsi menambah beban pada sistem dengan berbagai cara. Enkripsi menambah latensi, overhead komputasi, dan bandwidth pada rantai. Cara menggabungkannya dengan dukungan untuk sharding atau eksekusi paralel — yang merupakan tujuan masa depan yang penting — tidaklah jelas. Ini mungkin menambah titik kegagalan tambahan untuk kelangsungan hidup (misalnya, komite dekripsi untuk solusi ambang atau penyelesai fungsi penundaan). Dan ini tentu saja menambah kompleksitas desain dan implementasi.

Banyak masalah dari mempool terenkripsi juga dialami oleh blockchain yang bertujuan untuk memastikan privasi transaksi (misalnya, Zcash, Monero). Jika ada sisi positifnya, adalah bahwa menyelesaikan semua tantangan enkripsi untuk pengurangan MEV akan secara tidak langsung membuka jalan untuk privasi transaksi.

Tantangan ekonomi untuk mempool terenkripsi

Akhirnya, mempool terenkripsi menghadapi tantangan ekonomi. Berbeda dengan tantangan teknis, yang mungkin dapat diatasi dengan upaya rekayasa yang cukup, ini adalah batasan dasar yang tampaknya sulit untuk dipecahkan.

Masalah dasar dari MEV berasal dari asimetri informasi antara pengguna yang membuat transaksi, dan pencari serta pembangun yang menemukan peluang MEV. Pengguna biasanya tidak tahu berapa banyak MEV yang dapat diekstraksi dari transaksi mereka. Akibatnya, bahkan dengan mempool terenkripsi yang sempurna, pengguna mungkin terdorong untuk menyerahkan kunci dekripsi mereka sebagai imbalan untuk pembayaran dari pembangun yang kurang dari nilai yang diekstraksi. Kita dapat menyebut ini sebagai dekripsi yang diinsentifkan.

Tidak sulit untuk membayangkan bagaimana ini akan terlihat karena versi dari itu, yang disebut MEV Share, sudah ada saat ini. MEV Share adalah lelang aliran pesanan yang memungkinkan pengguna untuk secara selektif mengirimkan informasi tentang transaksi mereka ke suatu pool di mana para pencari bersaing untuk kesempatan mengeksploitasi peluang MEV yang dihadirkan oleh transaksi tersebut. Pencari dengan tawaran yang menang mengekstrak MEV dan mengembalikan sebagian dari keuntungan mereka (yaitu, tawaran atau sebagian dari tawaran) kepada pengguna.

Model ini dapat langsung diadaptasi dalam ruang mempool terenkripsi, yang mengharuskan pengguna untuk mengungkapkan kunci dekripsi mereka (atau mungkin hanya beberapa informasi partial) untuk berpartisipasi. Namun, sebagian besar pengguna tidak akan memahami biaya peluang untuk berpartisipasi dalam skema semacam itu, hanya melihat imbalan yang kembali kepada mereka dan senang untuk memberikan informasi mereka. Ada juga contoh dari keuangan tradisional (misalnya, layanan perdagangan tanpa biaya seperti Robinhood) yang mendapatkan keuntungan dari menjual aliran pesanan pengguna mereka kepada pihak ketiga dalam istilah yang disebut " pembayaran-untuk-aliran-pesananmodel bisnis.

Skenario lain yang mungkin termasuk pembangun besar yang memaksa pengguna untuk mengungkapkan transaksi mereka (atau beberapa informasi tentangnya) karena alasan sensor. Ketahanan terhadap sensor adalah topik penting dan kontroversial dalam web3, tetapi jika pengusul dan/atau pembangun besar secara hukum wajib untuk menegakkan daftar sensor (misalnya, dengan OFAC), mereka mungkin menolak untuk mengurutkan transaksi terenkripsi. Mungkin secara teknis masalah ini bisa dipecahkan, jika pengguna dapat menghasilkan bukti tanpa pengetahuan bahwa transaksi terenkripsi mereka mematuhi daftar sensor, tetapi ini juga akan menambah biaya dan kompleksitas. Bahkan jika rantai memiliki ketahanan sensor yang kuat, di mana transaksi terenkripsi dijamin akan dimasukkan, pembangun blok mungkin tetap memprioritaskan menempatkan transaksi yang mereka ketahui dalam format plaintext di bagian atas blok dan menurunkan transaksi terenkripsi ke bagian bawah blok. Dengan demikian, transaksi yang menginginkan jaminan eksekusi tertentu mungkin terpaksa mengungkapkan isinya kepada pembangun.

Tantangan efisiensi lainnya

Mempool terenkripsi menambah beban pada sistem dengan beberapa cara yang jelas. Pengguna harus mengenkripsi transaksi dan sistem harus entah bagaimana mendekripsinya. Ini menambah biaya komputasi dan mungkin meningkatkan ukuran transaksi. Seperti yang dibahas di atas, menangani metadata dapat membuat beban ini semakin parah. Namun, beberapa biaya efisiensi lainnya kurang jelas. Dalam keuangan, pasar dianggap efisien jika harga mencerminkan semua informasi yang tersedia, dan ketidakefisienan muncul dari keterlambatan dan asimetri informasi — konsekuensi alami dari mempool terenkripsi.

Salah satu konsekuensi dari ketidakefisienan ini adalah meningkatnya ketidakpastian harga, yang merupakan hasil dari penundaan tambahan yang diperkenalkan oleh mempool terenkripsi. Dengan demikian, jumlah kegagalan perdagangan karena melebihi toleransi selip harga kemungkinan akan meningkat dan membuang ruang rantai.

Demikian pula, ketidakpastian harga ini mungkin juga mengarah pada transaksi MEV spekulatif yang mencoba mendapatkan keuntungan dari arbitrase onchain. Yang penting, peluang ini mungkin lebih tersebar luas dengan mempool terenkripsi karena ketidakpastian yang meningkat seputar kondisi terkini DEX, mengingat penundaan eksekusi, kemungkinan besar akan menghasilkan pasar yang kurang efisien dengan perbedaan harga di berbagai tempat. Jenis transaksi MEV spekulatif ini juga akan membuang ruang blok karena sering kali akan dibatalkan jika tidak ada peluang semacam itu yang ditemukan.

Sementara tujuan kami di sini adalah untuk menggarisbawahi tantangan dalam mempool terenkripsi, sehingga orang dapat fokus pada membangun dan menyelesaikan hal-hal dengan cara lain, mereka mungkin masih menjadi bagian dari solusi untuk MEV.

Salah satu solusi yang mungkin adalah desain hibrida, di mana beberapa transaksi diatur secara buta melalui mempool yang terenkripsi dan beberapa diatur melalui solusi lain. Untuk jenis transaksi tertentu — misalnya, order beli/jual dari peserta pasar besar yang dapat dengan hati-hati mengenkripsi/mengisi dan bersedia membayar lebih untuk menghindari MEV — desain hibrida mungkin menjadi solusi yang tepat. Desain ini juga mungkin masuk akal untuk transaksi yang sangat sensitif, seperti perbaikan bug pada kontrak keamanan dengan kerentanan.

Namun, karena keterbatasan teknologinya, serta kompleksitas rekayasa yang signifikan dan beban kinerja yang tinggi, mempool terenkripsi kemungkinan besar tidak akan menjadi solusi jitu untuk MEV seperti yang sering digambarkan. Komunitas perlu mengembangkan solusi lain, termasuk lelang MEV, pertahanan lapisan aplikasi dan meminimalkan waktu finalitas. MEV akan menjadi tantangan untuk sementara waktu, dan investigasi yang cermat diperlukan untuk menemukan keseimbangan yang tepat dari solusi untuk mengelola sisi buruknya.

Pranav Garimidi adalah Peneliti Asosiasi di a16z Crypto. Dia melakukan penelitian tentang masalah dalam desain mekanisme dan teori permainan algoritmik yang berkaitan dengan sistem blockchain. Dia terutama fokus pada bagaimana insentif berinteraksi di seluruh tumpukan blockchain. Sebelum bergabung dengan a16z, Pranav adalah mahasiswa di Universitas Columbia di mana ia lulus dengan gelar dalam Ilmu Komputer.

Joseph Bonneau adalah Profesor Madya di Departemen Ilmu Komputer di Courant Institute, Universitas New York, dan penasihat teknis untuk a16z crypto. Penelitiannya berfokus pada kriptografi terapan dan keamanan blockchain. Ia telah mengajar kursus cryptocurrency di Universitas Melbourne, NYU, Stanford, dan Princeton, serta meraih gelar PhD dalam ilmu komputer dari Universitas Cambridge dan gelar BS/MS dari Stanford.

Lioba Heimbach adalah mahasiswa Ph.D. tahun keempat yang dibimbing oleh Prof. Dr. Roger Wattenhofer di Komputasi Terdistribusi (Disco) kelompok di ETH Zurich. Penelitiannya berfokus pada protokol blockchain dengan penekanan pada keuangan terdesentralisasi (DeFi). Secara khusus, penelitiannya berfokus pada memungkinkan ekosistem blockchain dan DeFi yang dapat diakses, terdesentralisasi, adil, dan efisien. Dia adalah intern penelitian di a16z crypto selama musim panas 2024.

Pandangan yang diungkapkan di sini adalah milik individu dari AH Capital Management, L.L.C. (“a16z”) yang dikutip dan bukan pandangan dari a16z atau afiliasinya. Informasi tertentu yang terdapat di sini telah diperoleh dari sumber pihak ketiga, termasuk dari perusahaan portofolio dana yang dikelola oleh a16z. Meskipun diambil dari sumber yang dianggap dapat diandalkan, a16z tidak secara independen memverifikasi informasi tersebut dan tidak membuat pernyataan tentang akurasi informasi saat ini atau yang bersifat abadi, atau kesesuaiannya untuk situasi tertentu. Selain itu, konten ini mungkin termasuk iklan pihak ketiga; a16z tidak meninjau iklan tersebut dan tidak mendukung konten iklan yang terdapat di dalamnya.

Konten ini disediakan hanya untuk tujuan informasi dan tidak boleh dianggap sebagai nasihat hukum, bisnis, investasi, atau pajak. Anda harus berkonsultasi dengan penasihat Anda sendiri mengenai hal-hal tersebut. Referensi kepada sekuritas atau aset digital apa pun hanya untuk tujuan ilustratif dan tidak merupakan rekomendasi investasi atau tawaran untuk menyediakan layanan nasihat investasi. Selain itu, konten ini tidak ditujukan maupun dimaksudkan untuk digunakan oleh investor atau calon investor mana pun, dan tidak boleh dalam keadaan apa pun dijadikan acuan saat membuat keputusan untuk berinvestasi dalam dana yang dikelola oleh a16z. (Tawaran untuk berinvestasi dalam dana a16z hanya akan dibuat melalui memorandum penempatan pribadi, perjanjian langganan, dan dokumentasi relevan lainnya dari dana tersebut dan harus dibaca secara keseluruhan.) Setiap investasi atau perusahaan portofolio yang disebutkan, dirujuk, atau dijelaskan tidak mewakili semua investasi dalam kendaraan yang dikelola oleh a16z, dan tidak ada jaminan bahwa investasi tersebut akan menguntungkan atau bahwa investasi lain yang dilakukan di masa depan akan memiliki karakteristik atau hasil yang serupa. Daftar investasi yang dilakukan oleh dana yang dikelola oleh Andreessen Horowitz (tidak termasuk investasi di mana penerbit tidak memberikan izin untuk a16z untuk mengungkapkan secara publik serta investasi yang belum diumumkan dalam aset digital yang diperdagangkan secara publik) tersedia di https://a16z.com/investments/.

Konten hanya berbicara sesuai dengan tanggal yang ditunjukkan. Proyeksi, estimasi, ramalan, target, prospek, dan/atau pendapat yang diungkapkan dalam materi ini dapat berubah tanpa pemberitahuan dan mungkin berbeda atau bertentangan dengan pendapat yang diungkapkan oleh orang lain. Silakan lihat https://a16z.com/disclosures untuk informasi tambahan yang penting.

Penafian:

1. Artikel ini diterbitkan kembali dari [a16zcrypto]. Semua hak cipta milik penulis asli [Pranav GarimidiJoseph Bonneauandy Lioba Heimbach]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gate Learn tim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang diungkapkan dalam artikel ini semata-mata merupakan pendapat penulis dan tidak merupakan saran investasi.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan adalah dilarang.