Tips Membaca

· Sebelum membaca artikel ini, Anda perlu memiliki pemahaman dasar tentang MEV

· Mengetahui transaksi Ethereum dan memahami apa yang terdapat dalam sebuah transaksi dan bagaimana akhirnya dimasukkan ke dalam blok

· Ketahui Pohon Merkle dan peran bukti pengetahuan nol

· klik untuk membaca: MEV (5): Ekosistem MEV yang lebih adil (Bagian 1)

Artikel sebelumnya memperkenalkan (1) desain Flashbot SGX Builder, yang meningkatkan keadilan Block Builder melalui hardware terpercaya, dan (2) desain Chainlink FSS, yang mencegah MEV dengan mendesentralisasi peran pengurutan transaksi.

Artikel ini akan membahas (3) desain Encrypted Mempools, yang bertujuan untuk mengurangi atau menghilangkan MEV dengan menyediakan privasi untuk transaksi melalui metode kriptografi.

Mempools Terenkripsi

Dua tujuan: perlindungan MEV dan ketahanan sensor

Jika ada alat yang memungkinkan pengguna mengenkripsi transaksi mereka sebelum disiarkan, dan mendekripsi hanya ketika mereka disertakan dalam blok, pengguna tidak perlu khawatir terkena MEV. Pencari MEV tidak dapat melihat konten transaksi sama sekali, dan pengguna tidak perlu khawatir transaksi mereka ditolak penghasilannya karena ditarget oleh proposer atau melanggar sanksi pemerintah. Batu penjuru membangun alat ini adalah kriptografi.

Mempools Terenkripsi menggunakan kriptografi untuk (1) mengenkripsi konten transaksi pengguna untuk melindungi privasi mereka, dan (2) memverifikasi validitas transaksi saat dienkripsi, mencegah penyerang menghasilkan sekelompok transaksi yang tidak valid namun terenkripsi. Hal ini mencegah mereka dari meluncurkan serangan DoS pada rantai, karena Penyaji akan menyia-nyiakan ruang blok dengan menyertakan sekelompok transaksi yang tidak valid yang baru ditemukan pada menit terakhir.

Petunjuk membaca: Enkripsi semata tidak dapat sepenuhnya menjamin ketahanan terhadap sensor, karena Penyaji yang ingin menyensor masih bisa menolak untuk menerima transaksi yang dienkripsi, sehingga enkripsi hanya meningkatkan biaya sensor (Penyaji menyerah pada biaya penanganan untuk semua transaksi yang dienkripsi). Untuk mencapai perlindungan anti-sensor yang lebih baik, Anda perlu menggunakan Daftar Inklusi seperti PBS.

Pastikan transaksi dapat didekripsi (Dekripsi Terjamin)

Setelah mengenkripsi transaksi, penting untuk memastikan bahwa itu dapat didekripsi. Kegagalan melakukannya dapat menciptakan kerentanan dalam serangan Denial of Service (DoS). Dalam serangan seperti itu, penyerang secara berulang mengirimkan transaksi terenkripsi yang tidak dapat didekripsi. Akibatnya, node harus menyimpan transaksi ini hingga mereka kedaluwarsa, menyebabkan penumpukan transaksi yang tidak berguna ini di dalam pool transaksi node.

Ada beberapa cara untuk memastikan bahwa transaksi dapat didekripsi:

1. Kepercayaan murni (Di udara)

2. Perangkat Keras Terpercaya, Enklaf

3. Enkripsi/Dekripsi Ambang Batas

4. Enkripsi/Dekripsi Tertunda

5. Enkripsi/Dekripsi Saksi

△ Beberapa cara untuk memastikan bahwa transaksi dapat didekripsi dan contoh-contohnya. Kompleksitas meningkat dari kiri ke kanan, dengan kepercayaan murni menjadi yang paling sederhana dan dekripsi saksi menjadi yang paling sulit.

Sumber gambar:https://www.youtube.com/watch?v=XRM0CpGY3sw

Commit-reveal

Apakah mekanisme commit-reveal juga dapat mencapai tujuan yang sama? Pengguna memulai dengan memasukkan konten transaksi mereka ke dalam fungsi hash untuk mendapatkan nilai hash, yang dikenal sebagai komitmen. Begitu penawar menjamin inklusi komitmen transaksi pengguna dalam blok, pengguna melanjutkan untuk mengungkapkan seluruh konten transaksi.

Tip membaca: Cara komitmen bisa seperti Proposer di PBS yang menjanjikan akan dimasukkan ke dalam blok Builder melalui tanda tangan. Ini adalah komitmen yang dijamin. Jika Proposer melanggar janji tersebut, maka akan dihukum.

△ Penyaji berjanji akan menerima Komitmen transaksi Alice

Meskipun Commit-reveal dan enkripsi dapat memiliki tujuan yang sama yaitu menyembunyikan konten transaksi pengguna dan mencegah ekstraksi MEV serta sensor, Commit-reveal tidak dapat menjamin dekripsi karena kekuatan berada di tangan pengguna. Pengguna memiliki pilihan untuk tidak mengungkapkan konten, baik dengan sengaja maupun tidak sengaja.

Mewajibkan pengguna untuk melampirkan deposit dan mengorbankan deposit ketika mereka tidak memiliki Reveal dapat memperburuk pengalaman pengguna yang sudah buruk dari Commit-reveal.

△ Alice tidak perlu mengungkapkan transaksinya

1. Kepercayaan murni (Di udara)

Pengguna mengenkripsi transaksi dan mengirimkannya ke peran terpusat. Peran terpusat kemudian mendekripsi transaksi dan memastikan bahwa transaksi tersebut tidak akan bocor sebelum dimasukkan ke dalam blok. Pengguna pada umumnya mempercayai peran terpusat dan menganggap transaksi sebagai terenkripsi sampai transaksi tersebut dimasukkan ke dalam blok, meskipun peran terpusat mendekripsi transaksi tersebut segera setelah menerimanya.

Tip membaca: Peran terpusat ini akan menjadi, misalnya, Builder, Proposer, atau Sequencer/Operator dari PBS atau Rollup.

2. Perangkat Keras Terpercaya, Enklave

Ini bekerja sama seperti kepercayaan murni, tetapi lebih baik daripada kepercayaan murni karena pengguna mempercayai perangkat keras terpercaya dan kode program yang dijalankannya, daripada mempercayai seseorang, sebuah organisasi, atau sebuah perusahaan.

3.Enkripsi/Dekripsi Ambang Batas

Chainlink FSS juga menggunakan enkripsi ambang batas dan dekripsi, tetapi dalam Chainlink FSS para manajer dari kunci ambang batas adalah Oracle dari Chainlink, sedangkan dalam Encrypted Mempools para manajer (yang disebut Keypers) mungkin merupakan Validator dari L1 atau L2 (asumsi L2 juga memiliki Dalam kasus Validator terdesentralisasi).

Enkripsi/dekripsi ambang memiliki beberapa kelemahan:

• Asumsi mayoritas jujur yang kuat: Harus diasumsikan bahwa lebih dari separuh Keypers adalah jujur. Jika mereka tidak jujur, mereka dapat mendekripsi dan melihat transaksi pengguna kapan pun mereka mau, meninjau transaksi, atau mengekstrak MEV dari transaksi.
• Ketidakbertanggungjawaban: Selama jumlah peserta Keyper yang cukup bekerja sama, mereka dapat mendekripsi informasi. Namun, ketika peserta Keyper bersekongkol, kita tidak tahu siapa yang terlibat dalam persekongkolan tersebut. Tanpa dapat mengidentifikasi pelaku jahat, tidak mungkin untuk merancang mekanisme hukuman untuk Keyper. Oleh karena itu, kita harus mengandalkan asumsi bahwa sebagian besar peserta Keyper adalah jujur.
• Kelambatan liveness: Jika Keyper offline berlebihan akan mengakibatkan jumlah Keyper online yang tidak mencukupi, yang akan mencegah dekripsi dan produksi blok. Hal ini akan menyebabkan rantai berhenti. Hal ini bertentangan dengan mekanisme Ethereum PoS, yang menekankan bahwa rantai akan terus memproduksi blok bahkan dalam kejadian perang dunia ketiga, dan akhirnya mencapai finalitas. Dapat disimpulkan bahwa probabilitas Ethereum PoS menggunakan dekripsi dengan ambang batas tidak tinggi.

Karena enkripsi ambang batas dan dekripsi membutuhkan banyak perubahan, L2 lebih cocok untuk pendekatan ini daripada L1.

Artikel ini mengusulkan desain dan pertimbangan untuk implementasi di L1. Proyek-proyek yang menguji desain ini dapat merujuk ke Jaringan Shutter. Untuk informasi lebih lanjut, silakan cek:https://ethresear.ch/t/shutterized-beacon-chain/12249

4. Enkripsi/Dekripsi Penundaan

Enkripsi penundaan memastikan bahwa teks sandi dapat secara otomatis didekripsi setelah jangka waktu tertentu. Namun, proses dekripsi tidak benar-benar otomatis dan memerlukan seseorang untuk bertindak sebagai dekriptor dan melakukan komputasi terus-menerus. Setelah jangka waktu tertentu, ditentukan oleh kesulitan enkripsi, komputasi dapat diselesaikan dan dekripsi dapat berhasil dicapai.

Konsep di balik enkripsi penundaan mirip dengan Verifiable Delay Function (VDF), keduanya termasuk dalam keluarga Kriptografi Pelepasan Waktu.

VDF memungkinkan kita untuk dengan cepat memverifikasi F(x): hasil dari “komputasi berurutan yang memakan waktu”. Ini mirip dengan Proof of Work (PoW), tetapi komputasi VDF adalah proses berurutan, berbeda dengan PoW, yang dapat dipercepat melalui komputasi paralel. Dekriptor VDF hanya dapat melakukan komputasi berulang langkah demi langkah.

△ Dengan VDF, Anda dapat memverifikasi hasil dari perhitungan yang saya selesaikan dalam 10 detik, misalnya, dalam 0,01 detik, dan saya tidak punya cara untuk memparallelkan perhitungan saya. Sumber gambar:https://techtelegraph.co.uk/fungsi-keterlambatan-yang-dapat-diverifikasi-di-bitcoin

Enkripsi dan dekripsi yang tertunda juga merupakan perhitungan berkelanjutan seperti VDF, dan tidak dapat dipercepat melalui operasi paralel. Namun, harus dipertimbangkan bahwa seseorang akan mempercepat proses dekripsi melalui optimisasi perangkat keras. Oleh karena itu, jika Anda ingin mengadopsi teknologi ini dan menerapkannya dalam lingkungan publik yang sebenarnya, Anda harus memastikan bahwa tidak ada yang memiliki kesenjangan perangkat keras yang besar dan dapat menyelesaikan dekripsi lebih awal (dan dekripsi dilakukan secara pribadi, sehingga sulit dideteksi).

Saat ini, Ethereum Foundation dan Protocol Labs sudah bekerja sama dalam penelitian chip ASIC VDF, dengan harapan untuk mengeluarkan perangkat keras komputasi paling canggih ke pasar, sehingga tidak ada yang bisa memiliki keunggulan perangkat keras yang berbeda dan membuka sandi secara rahasia lebih awal. Untuk informasi lebih lanjut, silakan cek: https://filecoin.io/blog/posts/kolaborasi-dengan-yayasan-ethereum-tentang-vdfs/

Tip bacaan: VDF juga dapat digunakan untuk meningkatkan ketidakmanipulasian nomor acak Ethereum.

Keuntungan enkripsi dan dekripsi tertunda dibandingkan dengan enkripsi dan dekripsi ambang adalah bahwa tidak perlu mempercayai atau mengandalkan operasi normal sekelompok Keypers, dan akan secara otomatis didekripsi ketika waktunya habis. Namun, waktu dekripsi yang diimpose juga merupakan kekurangan dari dekripsi tertunda: transaksi terenkripsi harus memerlukan waktu untuk didekripsi, yang berarti ada waktu tunda tetap agar transaksi pengguna diunggah ke rantai. Selain itu, persaingan perangkat keras juga merupakan risiko yang tidak dapat diabaikan dalam metode ini. Sulit untuk mengetahui apakah ada yang mengembangkan chip yang lebih cepat untuk mendekripsi.

5. Enkripsi/Dekripsi Saksi

Bayangkan bahwa sebuah teks sandi tidak dapat didekripsi oleh kunci atau perhitungan berurutan, tetapi hanya dapat didekripsi ketika suatu 'kondisi' tertentu terpenuhi, seperti 'ketika persamaan ini terpecahkan' atau 'ketika persamaan ini terpecahkan'. Setelah teks sandi dimasukkan ke dalam blok, teks sandi dapat didekripsi, dan seterusnya.

Tip membaca: "Mengetahui kunci untuk mendekripsi sebuah sanditext" atau "mengetahui hasil perhitungan yang berkelanjutan" sebenarnya merupakan sebuah kondisi.

Melalui enkripsi saksi, kita tidak hanya dapat mencapai efek dari enkripsi ambang batas dan enkripsi tertunda, tetapi juga dapat menggabungkan kedua metode dekripsi ini. Sebagai contoh, kita dapat menetapkan kondisi sebagai “Kondisi 1: ‘Sebuah kelompok Keypers setuju untuk mendekripsi teks sandi ini’ atau Kondisi 2: ‘Setelah lima menit’”: Jika semua Keypers online, kita dapat dengan cepat memenuhi Kondisi 1 untuk mendekripsi teks sandi. Namun, jika tidak ada cukup Keypers online, setidaknya kita dapat memastikan bahwa kita dapat memenuhi Kondisi 2 dan mendekripsi dengan membuktikan melalui VDF bahwa “lima menit telah berlalu”.

△ Cukup Keypers dapat didekripsi secara online (di atas) atau setelah cukup waktu (di bawah)

Selama kondisinya terbukti terpenuhi, dekripsi dapat dicapai. Bukti dapat dilakukan melalui metode seperti bukti pengetahuan nol, yang dapat secara efisien memverifikasi komputasi kompleks (asumsi operasi yang diperlukan untuk membuktikan kondisi tersebut kompleks) atau menyembunyikan informasi (asumsi bahwa pemberi bukti tidak ingin mengungkapkan informasi tertentu selama proses bukti). Namun, meskipun enkripsi saksi sangat kuat, teknologi saat ini tidak cukup untuk memberikan penggunaan praktis apa pun.

△ Kematangan teknologi enkripsi dan dekripsi yang berbeda. Enkripsi dan dekripsi saksi (Witness) masih belum cukup matang. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

Memanipulasi dan melakukan operasi pada teks sandi melalui enkripsi homomorfik

Paragraf sebelumnya memperkenalkan berbagai cara untuk memastikan bahwa transaksi dapat dideskripsi, tetapi kapan transaksi dapat dideskripsi? Jawabannya adalah: setelah transaksi disertakan dalam blok dan urutannya ditentukan. Tetapi bagaimana Block Builder menyusun blok dari sekelompok omong kosong, atau bahkan menyusun blok yang sangat menguntungkan secara efisien? Jawabannya adalah: Enkripsi Homomorfik (HE).

△ Contoh enkripsi homomorfik yang digunakan untuk pemungutan suara: Isi suara telah dienkripsi, tetapi teks sandi masih dapat dijumlahkan dan didekripsi setelah hasil dihitung. Sumber gambar:https://twitter.com/khushii_w/status/1660278622291210242

Petunjuk membaca: Jika enkripsi dan dekripsi dilakukan melalui kepercayaan murni (in-flight) atau perangkat keras terpercaya, sebenarnya tidak menunggu sampai transaksi dimasukkan ke dalam blok dan urutan ditentukan sebelum dekripsi. Pada dasarnya, semua orang mempercayai pihak lain, sehingga akan segera mendekripsi dan menyortir transaksi setelah menerimanya. Hal ini dapat mempercepat pembentukan blok dan tidak memerlukan sumber daya tambahan untuk melakukan operasi enkripsi homomorfik.

Melalui enkripsi homomorfik, kita dapat melakukan operasi pada teks sandi tanpa mendekripsi transaksi. Kita dapat menerapkan proses operasi penyusunan transaksi dan membentuk blok legal ke transaksi terenkripsi ini tanpa mendekripsi transaksi, dan memperoleh blok transaksi terenkripsi. Ketika blok tersebut didekripsi, kita akan mendapatkan blok lengkap dan legal, di mana transaksi telah didekripsi dan diurutkan dalam urutan sebelum enkripsi.

△ Melalui enkripsi homomorfik, Block Builder dapat menyusun blok lengkap dan legal dari transaksi yang dienkripsi

Tips membaca: Ada tingkatan enkripsi homomorfik, seperti enkripsi homomorfik parsial (Partially HE) dan enkripsi homomorfik penuh (Fully HE). Enkripsi homomorfik parsial hanya dapat menambahkan atau mengalikan teks sandi, sementara enkripsi homomorfik penuh dapat menambahkan dan mengalikan teks sandi (pada dasarnya, setiap operasi dapat dilakukan).

△ Kolom ketiga: Kematangan teknologi enkripsi dan dekripsi yang berbeda yang mendukung FHE. Kecuali untuk in-flight dan enclave, yang tidak memerlukan HE dan oleh karena itu dianggap didukung, yang lain belum tersedia. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

Di atas memperkenalkan berbagai mekanisme untuk mengenkripsi dan mendekripsi transaksi. Masing-masing dari mereka memiliki kelebihan dan kekurangan yang berbeda, tetapi pada akhirnya, yang dapat mereka lakukan hanyalah menyembunyikan konten transaksi dan memastikan bahwa konten tersebut dapat didekripsi saat kondisinya terpenuhi. Begitu konten transaksi tersembunyi, itu dapat menghindari didekripsi. Ekstraksi MEV dan risiko sensor.

Namun data transaksi itu sendiri akan memiliki metadata yang relevan, seperti inisiator transaksi, biaya transaksi atau tanda tangan, yang digunakan untuk memverifikasi validitas transaksi. Selain itu, alamat IP inisiator juga merupakan bentuk metadata, dan bahkan ukuran data transaksi. Semua metadata ini berpotensi bocor privasi pengguna, sehingga kita juga harus melindungi metadata ini.

Pastikan Metadata tidak bocor privasi

Berikut ini daftar berbagai metadata transaksi terenkripsi dan langkah-langkah perlindungan yang sesuai, yang akan memerlukan teknik kriptografi seperti enkripsi homomorfik dan bukti pengetahuan nol.

1. alamat IP

2. Tanda tangan transaksi

3. Biaya transaksi

4. Pemrakarsa transaksi dan nilai Nonce-nya

5. Ukuran transaksi

△ Metadata yang berbeda dari transaksi dapat mengungkap privasi pengguna. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

alamat IP

Jaringan yang digunakan pengguna untuk mengirim transaksi terenkripsi dapat mengungkap identitas pengguna berdasarkan alamat IP pengguna dan dapat disensor. Perlindungan privasi pada tingkat jaringan bergantung pada teknologi seperti Tor.

Tanda tangan transaksi, biaya penanganan, inisiator transaksi dan nilai Nonce-nya

Metadata ini digunakan untuk membuktikan validitas transaksi, namun akan mengungkap identitas pengguna, sehingga harus dienkripsi. Setelah dienkripsi, kita harus menggunakan alat lain untuk membuktikan validitas transaksi tanpa mengungkap informasi ini. Jika tidak, jaringan dapat diserang oleh DoS dan diisi dengan sekelompok transaksi tidak valid yang hanya terungkap setelah didekripsi.

Ketika sebuah node menerima transaksi yang dienkripsi, node harus (1) pertama-tama mengonfirmasi bahwa inisiator transaksi benar-benar menginisiasi transaksi tersebut, yaitu, memverifikasi tanda tangan transaksi, dan kemudian (2) mengonfirmasi bahwa inisiator memiliki cukup ETH untuk membayar transaksi (saldo pengguna ≥ harga gas * batas gas), dan (3) memeriksa nilai nonce pengirim untuk menghindari serangan replay transaksi.

Bukti pengetahuan nol

Kita dapat menggunakan bukti pengetahuan nol untuk membuktikan bahwa transaksi melewati pemeriksaan-pemeriksaan ini tanpa mengungkapkan informasi ini. Bukti pengetahuan nol terdiri dari informasi publik (Input Publik), informasi pribadi (Saksi Pribadi), dan pernyataan yang ingin dibuktikan (Pernyataan).

△ Sebagai contoh, informasi publik (input publik) adalah transaksi terenkripsi (teks transaksi), informasi pribadi (saksi pribadi) adalah transaksi tidak terenkripsi (teks transaksi), dan pernyataan (pernyataan zk) yang akan dibuktikan oleh bukti pengetahuan nol ini adalah "transaksi terenkripsi ini legal" (teks transaksi valid). Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

Sebagai contoh, jika Alice ingin membuktikan kepada Bob bahwa dia memiliki lebih dari 10 ETH, tetapi tidak ingin mengungkapkan alamatnya, dia dapat menggunakan bukti pengetahuan nol untuk membuktikan kepada Bob bahwa alamatnya benar-benar memiliki saldo lebih dari 10 ETH.

“Bukti bahwa alamat Alice memiliki saldo lebih dari 10 ETH” adalah pernyataan (pernyataan zk) yang akan dibuktikan oleh bukti pengetahuan nol ini. Untuk menghasilkan bukti ini, Alice harus memberikan alamatnya dan bukti bahwa dia memegang kunci pribadi dari alamat tersebut (misalnya, menggunakan Kunci pribadi menghasilkan tanda tangan), dan dia juga perlu memberikan saldo ETH dari alamat ini, misalnya, menggunakan Bukti Merkle untuk membuktikan berapa banyak ETH yang dipegang alamat ini di blok ke-1001.

Alamat, tanda tangan, dan Bukti Merkle tidak dapat diungkapkan dan merupakan informasi pribadi (saksi pribadi).

Ketika bukti ini dihasilkan, Bob dapat memverifikasi bukti ini dengan Merkle Root (yang disebut State Root) dari pohon status dari blok 1001. Siapa pun yang tahu State Root dari setiap blok, yang merupakan informasi publik (input publik).

Satu-satunya informasi yang Bob tahu adalah informasi publik dari State Root dan hasil verifikasinya. Dia tidak akan tahu informasi pribadi Alice.

△ Alice memberikan dua input pribadi: Merkle Proof dan tanda tangan; Bob memberikan input publik berupa State root. Pernyataan zk dapat memverifikasi bahwa Alice memiliki alamat dan saldo dari alamat tersebut adalah > 10 ETH

(1) Verifikasi tanda tangan transaksi

Verifikasi tanda tangan transaksi terdiri dari dua bagian: (a) pemrakarsa transaksi sah dan (b) tanda tangan transaksi ditandatangani oleh pemrakarsa transaksi.

(a) Utamanya untuk memverifikasi bahwa alamat Ethereum inisiator transaksi adalah alamat legal dan bukan angka acak. Ini akan dibuktikan melalui Merkle Proof bahwa alamat tersebut ada di pohon keadaan Ethereum.

(b) Memverifikasi bahwa tanda tangan transaksi ditandatangani oleh kunci pribadi inisiator transaksi.

△ Bukti ini memverifikasi (a) alamat pengirim transaksi (melalui bukti Merkle kunci publik pengirim) dan (b) tanda tangan dalam transaksi tersebut sah (tanda tangan akan disertakan dalam teks transaksi). Teks transaksi adalah data transaksi mentah yang tidak terenkripsi, yang merupakan informasi pribadi yang diberikan oleh inisiasi transaksi.

Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

Petunjuk membaca: Teks merah dalam gambar di atas mengacu pada apa arti sertifikat ini setelah lulus verifikasi (yaitu, "tanda tangan transaksi sah"). Ini bukan bagian dari pernyataan zk. Bagian biru adalah informasi terkait transaksi itu sendiri, termasuk data transaksi terenkripsi (publik) dan data transaksi tak terenkripsi (pribadi). Bagian hijau adalah data tambahan yang diperlukan untuk menyelesaikan bukti, baik publik maupun pribadi.

△ Buktikan bahwa alamat inisiator transaksi ada di pohon status Ethereum dan bahwa inisiator transaksi benar-benar memiliki kunci pribadi tempat tersebut

(2) Konfirmasi bahwa inisiator transaksi memiliki cukup ETH untuk membayar biaya penanganan

Sama seperti contoh sebelumnya tentang Alice dan Bob membuktikan bahwa saldo adalah > 10 ETH, inisiator transaksi perlu menyediakan Bukti Merkle dari saldo alamatnya sendiri, dan pernyataan yang akan dibuktikan adalah "saldo alamat ≥ biaya transaksi." Biaya transaksi sama dengan harga gas dikalikan dengan batas gas. Informasi harga gas dan batas gas termasuk dalam data transaksi asli yang tidak terenkripsi (teks transaksi). teks transaksi adalah informasi pribadi yang disediakan oleh inisiator transaksi.

△ Bukti ini memverifikasi bahwa saldo alamat inisiator transaksi (melalui bukti Merkle saldo pengirim) lebih besar dari atau sama dengan biaya transaksi (informasi biaya transaksi disertakan dalam teks tx). Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ Bukti saldo alamat inisiator transaksi > harga gas

(3) Verifikasi nilai Nonce dari pengirim transaksi

Karena Nonce juga dicatat dalam status Ethereum, Bukti Merkle juga digunakan untuk membuktikan nilai Nonce saat ini dari inisiator transaksi, dan kemudian membandingkannya dengan nilai Nonce yang ditentukan dalam transaksi untuk mengonfirmasi bahwa transaksi tidak diulang.

△ Bukti ini membandingkan nilai Nonce alamat inisiator transaksi (melalui bukti Merkle nonce) dan nilai Nonce yang ditentukan oleh transaksi (nilai Nonce yang ditentukan oleh transaksi disertakan dalam teks tx). Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ Buktikan nonce dari alamat inisiator transaksi = nonce tx

Namun, pemeriksaan ini tidak dapat mencegah penyerang jahat menghasilkan beberapa transaksi dengan nilai Nonce yang sama (transaksi ini semua dapat lolos pemeriksaan nilai Nonce) untuk melakukan serangan DoS, oleh karena itu kita perlu menambahkan pemeriksaan tambahan.

Kami mewajibkan inisiator transaksi untuk memberikan satu Tag Replay lagi untuk memastikan bahwa hanya akan ada satu transaksi dengan nilai Nonce yang sama. Tag Replay adalah nilai hash dari nilai Nonce dan kunci pribadi pemrakarsa transaksi: tag replay = H (nonce, private key), sehingga nilai Nonce yang berbeda dari inisiator transaksi yang sama masing-masing akan sesuai dengan Tag Replay yang unik.

Oleh karena itu, node dapat menggunakan Replay Tag untuk mengidentifikasi apakah inisiator transaksi telah memulai beberapa transaksi dengan nilai Nonce yang sama (Replay Tag dari transaksi ini akan sama), dan menolak transaksi kedua dengan Replay Tag yang sama.

△ Bukti ini akan menghitung tag replay dan membandingkannya dengan tag replay yang dilewati oleh input publik. Nilai Nonce transaksi terdapat dalam teks transaksi, dan kunci pribadi terdapat dalam saksi pribadi.

Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ Buktikan nonce alamat inisiator transaksi = nonce tx dan tag replay = H(nonce, kunci)

Atau jika kita mempertimbangkan bahwa inisiator transaksi mungkin ingin menggantikan transaksi dengan nilai Nonce yang sama dengan transaksi lain, mungkin karena dia tidak ingin menjalankan transaksi asli, atau dia ingin meningkatkan harga gas sehingga transaksi dapat dikumpulkan lebih cepat .

Pada saat ini, kita dapat memperkenalkan Nilai Slot dari PoS ke dalam perhitungan Replay Tag: replay tag = H(nonce, kunci privat, slot). Sebagai contoh, Bob mengirim transaksi dengan Nonce 5 di Slot 1001 tetapi belum diterima, jadi dia memutuskan untuk menggandakan harga gas transaksi sambil menjaga bidang lain tetap tidak berubah, dan mengirimkan transaksi yang diperbarui di Slot 1005. Transaksi, dan karena Slot telah berubah, Replay Tag berbeda, dan transaksi baru ini tidak akan ditolak karena Nilai Nonce sama.

△ Input publik akan melewati nilai slot tambahan untuk perhitungan tag ulang. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5. Ukuran transaksi

Beberapa metode enkripsi akan membuat ukuran data transaksi terenkripsi sama seperti sebelum dienkripsi. Namun, masih ada peluang untuk mendeduksi beberapa informasi melalui ukuran tersebut. Misalnya, data transaksi dari transaksi yang dilakukan di Uniswap harus lebih besar daripada data transaksi dari transfer ETH sederhana. Besar, sehingga ukuran transaksi sama seperti Metadata yang mungkin bocor privasinya.

Pendekatan intuitif adalah melakukan tindakan padding pada data transaksi sebelum mengenkripsi, seperti menambahkan sekelompok nol hingga ukuran transaksi menjadi kekuatan dua, atau bahkan menambahkannya hingga menjadi ukuran tetap. Ini mengurangi kemungkinan seorang pengamat mengidentifikasi transaksi berdasarkan ukurannya. Block Builder akan menggabungkan transaksi yang dipadatkan ke dalam blok.

△ Putih adalah Padding. Kesepakatan biru dan oranye memiliki ukuran yang sama, sehingga tidak mungkin membedakan keduanya berdasarkan ukuran. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

Namun, kerugiannya dari pendekatan ini adalah bahwa (1) itu tidak efisien karena banyak ruang di blok akan terbuang pada Padding, dan (2) mungkin tidak memberikan perlindungan privasi yang memadai. Sebagai contoh, ukuran transaksi merah pada gambar di atas (empat persegi) mungkin jarang, jadi masih bisa ditebak. Jika semua transaksi dipadatkan ke ukuran tetap (seperti 64 blok), privasi akan meningkat, namun akan menjadi pemborosan ruang blok yang relatif.

△ Kerugiannya adalah inefisiensi dan perlindungan privasi yang terbatas. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

Pendekatan yang lebih baik adalah dengan pertama-tama memasukkan transaksi ke ukuran tetap, tetapi enkripsi homomorfik dapat digunakan untuk menghapus padding.

Karena transaksi semuanya dipadatkan ke ukuran tetap, semua transaksi yang terlihat oleh pengamat akan memiliki ukuran yang sama. Pembangun Blok dapat menggabungkan transaksi terenkripsi melalui sebuah fungsi dan menghapus padding pada saat yang bersamaan.

Gunakan enkripsi homomorfik untuk menghapus Padding saat menggabungkan transaksi terenkripsi. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

Tips membaca: Block Builder dengan kepercayaan murni atau perangkat keras yang dipercayai dapat mencapai efek yang sama tanpa enkripsi homomorfik (akhirnya, semua orang mempercayainya).

Bagaimana Block Builder membangun blok-blok yang efisien

Meskipun kita dapat menggabungkan transaksi terenkripsi secara efisien ke dalam sebuah blok melalui enkripsi homomorfik, masih ada beberapa masalah yang harus dipecahkan, seperti (1) transaksi yang berbeda dapat membaca dan menulis keadaan yang sama (misalnya, semuanya melakukan perdagangan di Uniswap), yang dapat menyebabkan transaksi berperingkat lebih rendah lebih mungkin gagal, dan (2) Pembangun Blok tidak dapat mengumpulkan transaksi berdasarkan tingkat biaya penanganan.

Solusi ideal adalah menjalankan EVM dalam enkripsi homomorfik, sama seperti memasukkan EVM ke dalam kotak hitam untuk dieksekusi, sehingga Block Builder dapat mensimulasikan eksekusi transaksi melalui EVM untuk membentuk blok yang paling efisien dan Blok dengan pendapatan tertinggi. Namun, kompleksitas teknis teknologi ini terlalu tinggi, dan akan memerlukan waktu yang lama untuk mewujudkannya.

Alternatifnya adalah menambahkan biaya penanganan terenkripsi dan Daftar Akses terenkripsi ke transaksi (Daftar Akses digunakan untuk menunjukkan negara bagian mana transaksi akan membaca dan menulis), dan menggunakan enkripsi homomorfik untuk memverifikasi validitasnya. Dengan cara ini, Block Builder dapat menentukan urutan pendapatan transaksi melalui biaya penanganan, dan menggunakan Daftar Akses untuk mencegah transaksi saling memengaruhi dan mengakibatkan efisiensi pelaksanaan transaksi yang berkurang.

△ Ini ditentukan oleh biaya penanganan dan Daftar Akses mana transaksi yang akan dikumpulkan dan urutan di mana mereka dikumpulkan. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

Waktu ketika transaksi terjadi

Jika kami khawatir bahwa waktu pengiriman transaksi terenkripsi ke jaringan p2p dapat membocorkan privasi (misalnya, Alice melakukan transaksi pada UTC+8 00:00–04:00), kami dapat meminta Validator untuk mengirim banyak Transaksi Dummy terenkripsi secara teratur. untuk membingungkan pengamat.

Transaksi Dummy akan perlu dilampirkan dengan bukti pengetahuan nol untuk membuktikan bahwa itu dikirim oleh Validator dan membatasi frekuensi untuk mencegah jaringan dari diisi dengan Transaksi Dummy (pengamat tidak akan tahu bahwa ini adalah Transaksi Dummy, hanya bahwa itu “legal dan valid”).

Transaksi palsu akan diidentifikasi dan dibuang selama operasi enkripsi homomorfik dari blok grup.

△ Validator secara rutin mengirimkan Transaksi Palsu (abu-abu) untuk membingungkan pengamat, namun hal ini akan meningkatkan beban pada jaringan dan node. Sumber gambar:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Mempools Terenkripsi vs. FSS

FSS dalam artikel sebelumnya juga memperkenalkan bahwa FSS juga akan mengenkripsi transaksi terlebih dahulu dan kemudian menyerahkannya ke Chainlink Oracle untuk diurutkan. Proses FSS mengenkripsi transaksi dan memverifikasi kevalidan transaksi yang terenkripsi sebenarnya sama dengan Encrypted Mempools, kecuali:

• Enkripsi transaksi FSS tidak menyebut perlindungan Metadata, sementara Encrypted Mempools menyembunyikan Metadata dan menggunakan bukti pengetahuan nol untuk membuktikan validitas transaksi.
• FSS saat ini menggunakan Enkripsi/Dekripsi Ambang dan secara bersama-sama didekripsi oleh Chainlink Oracle, yang berarti Anda harus mempercayai Chainlink Oracle. Mempool Terenkripsi tidak menentukan cara pengurutan, tetapi hanya fokus pada mengenkripsi transaksi dan membuktikan validitasnya dengan bukti pengetahuan nol.
• Dibandingkan dengan FSS yang hanya menekankan "keadilan", Encrypted Mempools lebih menekankan "bagaimana cara merakit konten blok secara efisien dan bagaimana mengizinkan Penyusun untuk merakit blok yang paling menguntungkan daripada hanya memutuskan secara acak urutan transaksi.

Di masa depan, FSS juga dapat menggunakan teknologi di Encrypted Mempools untuk meningkatkan atau menggantikan transaksi enkripsi dan dekripsi-nya.

Menangani MEV dengan Kriptografi

Pembicaraan ini membahas Mempools Terenkripsi, di mana penulis membagikan bagaimana teknik kriptografi dan peningkatan dalam lapisan konsensus Ethereum dapat membantu melawan masalah yang disebabkan oleh MEV. Untuk detail, silakan cek:https://www.youtube.com/watch?v=mpRq-WFihz8

Ringkasan dan sorotan

1. Tujuan dari Mempools Terenkripsi adalah untuk melindungi terhadap MEV dan sensor dengan mengenkripsi transaksi. Orang lain hanya dapat mengetahui bahwa transaksi Anda valid, tetapi mereka tidak dapat mengetahui tindakan apa yang Anda lakukan dalam transaksi Anda.

2. Namun, untuk benar-benar mencapai resistensi yang efektif terhadap sensor, mekanisme seperti Daftar Inklusi PBS harus digunakan. Jika tidak, Builder masih dapat melakukan sensor dengan menolak menerima transaksi terenkripsi.

3. Tidak mudah untuk membuktikan bahwa transaksi terenkripsi valid. Anda memerlukan beberapa bukti pengetahuan nol untuk membuktikan tanda tangan transaksi, nilai Nonce inisiator transaksi, biaya penanganan yang memadai, dan lain-lain.

4. Selain itu, perlu dihindari metadata seperti IP, ukuran data transaksi, atau waktu pengiriman transaksi bocor dan mengungkapkan privasi transaksi.

5. Terakhir, hal terpenting adalah memastikan bahwa transaksi dapat dienkripsi —— Enkripsi Terjamin. Ada lima metode berbeda: Kepercayaan Murni (Di udara), Ruang Keras yang Dipercayai, Ambang Batas Enkripsi/Dekripsi, Enkripsi/Dekripsi Tunda, dan Saksi Enkripsi/Dekripsi. Setiap metode memiliki kelebihan dan kekurangannya masing-masing.

Data referensi dan bacaan lanjutan yang direkomendasikan

Mempool Terenkripsi

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• Bagaimana kriptografi membantu menyelesaikan masalah yang disebabkan oleh MEV dari lapisan aplikasi dan lapisan konsensus:https://youtu.be/jLHf6yw7b5Y?t=4139

Terima kasih khusus kepada Steven Wu, Kimi Wu, Kevin Mai-Hsuan Chia, dan Anton Cheng atas meninjau dan meningkatkan pos ini.

Disclaimer：

1. Artikel ini dicetak ulang dari [techflowpost]. Semua hak cipta milik penulis asli [Will 阿望；Diane Cheung]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan segera.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang telah diterjemahkan dilarang.