Pengantar: Baru-baru ini, Vitalik dan beberapa sarjana bersama-sama menerbitkan makalah baru, menyebutkan bagaimana Tornado Cash menerapkan skema anti pencucian uang (mengizinkan penarik untuk membuktikan bahwa catatan deposit mereka berasal dari himpunan yang tidak mengandung uang kotor), namun makalah tersebut kurang dalam interpretasi rinci tentang logika bisnis dan prinsip-prinsip Tornado Cash, membuat beberapa pembaca bingung.

Perlu dicatat bahwa proyek-proyek privasi yang diwakili oleh Tornado adalah proyek-proyek yang benar-benar memanfaatkan sifat pengetahuan nol dari algoritma ZK-SNARK, sementara sebagian besar proyek yang diberi label ZK hanya menggunakan kesingkatan dari ZK-SNARK. Orang sering bingung antara Bukti Validitas dan ZK, dan Tornado berperan sebagai kasus yang sangat baik untuk memahami aplikasi ZK. Penulis artikel ini telah menulis tentang prinsip-prinsip Tornado pada tahun 2022 untuk Penelitian Web3Caff, dan hari ini memilih dan mengembangkan beberapa bagian dari artikel tersebut, mengorganisirnya ke dalam bagian ini untuk memahami Tornado Cash secara sistematis.

Tautan Artikel Asli: https://research.web3caff.com/zh/archives/2663?ref=157

Prinsip dari 'Tornado'

Tornado Cash menggunakan protokol pencampuran koin berdasarkan bukti nol pengetahuan, dengan versi lamanya diluncurkan pada tahun 2019 dan versi beta baru dirilis menjelang akhir 2021. Versi lama Tornado mencapai tingkat desentralisasi yang tinggi, dengan kontrak on-chain-nya bersifat open source dan tidak dikontrol oleh mekanisme multisignature manapun, serta kode frontend-nya juga bersifat open source dan disimpan di jaringan IPFS. Karena struktur versi lama Tornado yang lebih sederhana dan dapat dimengerti, artikel ini difokuskan pada penjelasan mengenainya. Ide utama di balik Tornado adalah mencampurkan sejumlah besar tindakan deposit dan penarikan bersama-sama. Setelah mendepositokan token di Tornado, deposan menyajikan Bukti ZK untuk membuktikan bahwa mereka telah melakukan deposit dan kemudian menarik ke alamat baru, dengan demikian memutuskan hubungan antara alamat deposit dan penarikan.

Lebih spesifiknya, Tornado bertindak seperti kotak kaca yang diisi dengan koin yang disetor oleh banyak orang. Kita bisa melihat siapa yang menyetor koin, tetapi karena koin tersebut sangat homogen, sulit untuk melacak kembali koin mana yang disetor oleh siapa jika seseorang yang tidak dikenal menarik sebuah koin.

(Sumber: rareskills) Skenario ini agak umum; misalnya, ketika kita menukar ETH di kolam Uniswap, kita tidak dapat mengetahui ETH dari siapa yang kita dapatkan karena banyak yang telah menyediakan likuiditas ke Uniswap. Namun, perbedaannya adalah bahwa setiap kali Anda menukar token di Uniswap, Anda perlu menggunakan token lain sebagai biaya setara, dan Anda tidak dapat mentransfer dana secara "pribadi" ke orang lain; sedangkan, dengan mixer, Anda hanya perlu menunjukkan bukti deposit untuk menarik. Untuk membuat tindakan deposit dan penarikan terlihat homogen, setiap deposit ke kolam Tornado dan setiap penarikan dari kolam tersebut tetap konsisten dalam jumlahnya. Misalnya, jika ada 100 penyimpan dan 100 penarik dalam kolam, meskipun terlihat, mereka terlihat tidak terhubung, dan jumlah yang disimpan dan ditarik oleh masing-masing sama.

Ini dapat mengaburkan keterlacakan transfer dana, menawarkan kenyamanan alami untuk menganonimkan transaksi. Pertanyaan kuncinya adalah: bagaimana seorang penarik membuktikan bahwa mereka telah melakukan deposit?

Alamat penarikan tidak terhubung ke alamat deposit manapun, jadi bagaimana dapat ditentukan kelayakan penarikan mereka? Metode paling langsung tampaknya adalah bagi penarik untuk mengungkapkan catatan deposit mana yang milik mereka, tetapi ini akan langsung mengungkapkan identitas mereka. Di sinilah bukti pengetahuan nol berperan. Dengan menyajikan Bukti ZK bahwa mereka memiliki catatan deposit dalam kontrak Tornado yang belum ditarik, seorang penarik dapat berhasil memulai penarikan. Bukti pengetahuan nol secara inheren melindungi privasi, hanya mengungkapkan bahwa orang tersebut memang melakukan deposit ke dalam kolam dana, tanpa mengungkapkan deposan mana yang mereka miliki.

Untuk membuktikan bahwa “Saya telah melakukan deposit di kolam dana Tornado” dapat diterjemahkan menjadi “Catatan deposit saya dapat ditemukan di kontrak Tornado.” Jika kita menggunakan Cn untuk mewakili catatan deposit, masalahnya menjadi: diberikan bahwa set catatan deposit Tornado adalah {C1, C2, …C100…}, si penarik, Bob, membuktikan bahwa dia menggunakan kuncinya untuk menghasilkan beberapa Cn dalam catatan deposit tanpa mengungkapkan Cn spesifik mana itu. Ini melibatkan properti khusus dari Merkle Proof. Semua catatan deposit Tornado diinkorporasikan ke dalam Pohon Merkle yang dibangun on-chain, dengan catatan tersebut sebagai simpul daun level bawahnya. Jumlah total daun adalah sekitar 2^20 > 1 juta, dimana sebagian besar dalam keadaan kosong (diberikan nilai awal). Setiap kali deposit baru terjadi, kontrak mencatat nilai uniknya, Commitment, ke dalam sebuah daun, dan kemudian memperbarui root Pohon Merkle.

Sebagai contoh, jika deposito Bob adalah yang ke-10.000 dalam sejarah Tornado, nilai karakteristik Cn yang terkait dengan deposito ini akan dimasukkan ke dalam simpul daun ke-10.000 dari Pohon Merkle, yaitu, C10000 = Cn. Kontrak kemudian secara otomatis menghitung Root baru dan memperbarui Root tersebut. Untuk menghemat sumber daya komputasi, kontrak Tornado menyimpan data dari sekelompok simpul yang telah berubah sebelumnya, seperti Fs1, Fs2, dan Fs0 dalam diagram di bawah ini.

(Sumber: RareSkills)

Bukti Merkle, menurut sifatnya, ringkas dan ringan, memanfaatkan kesederhanaan struktur data pohon dalam proses pencarian/pelacakan. Untuk membuktikan secara eksternal bahwa transaksi TD ada di Pohon Merkle, seseorang hanya perlu menyediakan Bukti Merkle yang sesuai dengan Root, yang cukup mudah. Jika Pohon Merkle terutama besar, dengan 2^20 kekuatan daun level bawah (yaitu 1 juta catatan deposit), Bukti Merkle hanya perlu mencakup nilai dari 21 node, yang sangat singkat.

Untuk membuktikan bahwa transaksi H3 memang terdapat dalam Pohon Merkle, seseorang harus menunjukkan bahwa dengan menggunakan H3 dan bagian lain dari data pada Pohon Merkle, Root dapat dihasilkan, dan data yang diperlukan untuk menghasilkan Root (termasuk Td) merupakan Bukti Merkle. Ketika Bob menarik, dia perlu membuktikan bahwa sertifikatnya sesuai dengan hash deposit Cn yang tercatat pada Pohon Merkle di buku besar Tornado. Dengan kata lain, dia harus membuktikan dua hal: Cn ada dalam Pohon Merkle fiktif Tornado on-chain, khususnya dengan membangun Bukti Merkle yang berisi Cn; Cn terkait dengan sertifikat deposit Bob.

Logika Bisnis Tornado Dijelaskan

Dalam kode frontend antarmuka pengguna Tornado, banyak fungsi yang telah diimplementasikan sebelumnya. Ketika deposan membuka halaman web Tornado Cash dan mengklik tombol setoran, kode frontend yang menyertainya menghasilkan dua angka acak, K dan r, secara lokal. Kemudian menghitung nilai Cn = Hash (K, r) dan melewati Cn (disebut sebagai komitmen dalam diagram di bawah) ke kontrak Tornado, yang memasukkannya ke dalam Pohon Merkle yang dicatat oleh yang terakhir. Pada dasarnya, K dan r bertindak sebagai kunci pribadi. Mereka sangat penting, dan sistem meminta pengguna untuk menyimpannya dengan aman. K dan r diperlukan lagi selama penarikan.

(Opsi encryptedNote memungkinkan pengguna mengenkripsi kredensial K dan r dengan kunci pribadi dan menyimpannya di blockchain untuk mencegah lupa) Yang penting, semua operasi ini terjadi di luar rantai, artinya kontrak Tornado dan pengamat eksternal tidak menyadari K dan r. Jika K dan r bocor, itu sama dengan pencurian kunci pribadi dompet.

Setelah menerima deposit dari seorang pengguna dan pengiriman Cn=Hash(K, r), kontrak Tornado mencatat Cn di lapisan paling bawah Pohon Merkle sebagai simpul daun baru, juga memperbarui nilai Root. Oleh karena itu, Cn terhubung langsung ke tindakan deposit pengguna, memungkinkan pihak luar untuk mengetahui pengguna mana yang sesuai dengan setiap Cn, siapa yang telah mendepositkan token ke dalam mixer, dan catatan deposit Cn dari setiap depositor.

Selama proses penarikan, penarik memasukkan credential / private key (angka acak K dan r yang dihasilkan selama deposit) di halaman web frontend. Program dalam kode frontend Tornado Cash menggunakan K dan r, Cn = Hash (K, r), dan Merkle Proof yang sesuai dengan Cn sebagai parameter input untuk menghasilkan ZK Proof. Ini membuktikan bahwa Cn ada di Pohon Merkle sebagai catatan deposit, dan K dan r adalah kredensial yang sesuai dengan Cn. Langkah ini pada dasarnya membuktikan: Saya tahu kunci yang sesuai dengan catatan deposit di Merkle Tree. Ketika Bukti ZK diserahkan ke kontrak Tornado, keempat parameter ini disembunyikan, melindungi privasi. Generasi ZK Proof melibatkan parameter tambahan, termasuk root Merkle yang dicatat dalam kontrak Tornado pada saat penarikan, alamat penerima kustom A, dan pengidentifikasi nf untuk mencegah serangan replay. Ketiga parameter ini diposting secara publik di blockchain, yang tidak membahayakan privasi.

Sebuah detail penting yang perlu diperhatikan adalah penggunaan dua angka acak, K dan r, untuk menghasilkan Cn bukannya hanya satu angka acak, memberikan keamanan yang lebih tinggi terhadap tabrakan. A mewakili alamat penerima penarikan, dipilih oleh penarik. Pengidentifikasi nf, dirancang untuk mencegah serangan replay, dihitung sebagai nf=Hash(K), di mana K adalah salah satu dari dua angka acak yang digunakan dalam langkah deposit untuk menghasilkan Cn. Ini menghubungkan nf secara langsung ke Cn, membentuk korelasi satu lawan satu antara setiap Cn dan nf yang sesuai. Tujuan mencegah serangan replay adalah karena fitur desain mixer, yang menjaga asosiasi antara jumlah penarikan dan daun pohon Merkle tertentu (Cn) tidak diketahui, memungkinkan penyalahgunaan penarikan ulang berulang hingga dana habis.

nf identifier berfungsi secara mirip dengan nonce yang terkait dengan setiap alamat Ethereum, mencegah pengulangan transaksi. Ketika penarikan terjadi, pemeriksaan memastikan nf yang diajukan belum pernah digunakan sebelumnya; jika belum digunakan, penarikan tersebut valid, dan nf tersebut dicatat. Setiap upaya untuk menghasilkan nf yang tidak terkait dengan setoran tercatat Cn akan gagal menghasilkan Bukti ZK yang valid, membuat penarikan menjadi tidak berhasil.

Jika seseorang secara acak menghasilkan kontrak non-fungible (nf) yang tidak tercatat, apakah itu akan berhasil? Tentu saja tidak. Ketika penarik menghasilkan Bukti Pengetahuan Nol (ZK Proof), mereka harus memastikan bahwa nf sama dengan Hash (K), di mana nomor acak K terkait dengan catatan deposit Cn. Ini berarti bahwa nf terhubung dengan catatan deposit Cn yang tercatat. Jika seseorang membuat nf secara sembarangan, nf ini tidak akan cocok dengan catatan deposit apa pun, sehingga tidak mungkin menghasilkan ZK Proof yang valid. Akibatnya, proses penarikan tidak dapat diselesaikan dengan sukses, dan operasi penarikan akan gagal. Beberapa orang mungkin bertanya: Apakah mungkin untuk melanjutkan tanpa nf? Karena penarik perlu mengirim bukti ZK selama penarikan untuk membuktikan asosiasinya dengan Cn tertentu, mengapa tidak hanya memeriksa apakah Bukti ZK yang sesuai telah dikirimkan ke blockchain setiap kali penarikan terjadi? Namun, pendekatan ini sangat mahal karena kontrak Tornado Cash tidak menyimpan secara permanen Bukti ZK sebelumnya karena pemborosan ruang penyimpanan yang signifikan. Membandingkan setiap Bukti ZK baru yang dikirimkan ke blockchain dengan bukti yang ada kurang efisien daripada menetapkan pengidentifikasi kecil seperti nf dan menyimpannya secara permanen.

Menurut contoh kode fungsi penarikan, parameter yang diperlukan dan logika bisnisnya adalah sebagai berikut: Pengguna mengirimkan Bukti ZK dan nf (NullifierHash) = Hash (K), menentukan alamat penerima untuk penarikan, dan Bukti ZK menyembunyikan nilai-nilai Cn, K, dan r, sehingga tidak mungkin bagi pihak luar untuk mengetahui identitas pengguna. Penerima sering menggunakan alamat baru dan bersih, yang tidak mengungkapkan informasi pribadi.

Namun, ada masalah kecil: ketika pengguna menarik dana untuk tetap tidak terlacak, mereka sering memulai transaksi penarikan dari alamat yang baru dibuat. Pada saat ini, alamat baru tidak memiliki ETH untuk membayar biaya gas. Oleh karena itu, saat memulai penarikan, alamat penarikan harus secara eksplisit menyatakan pemancar untuk membayar biaya gas atas namanya. Setelah itu, kontrak mixer mengurangi sebagian dari penarikan pengguna untuk mengganti pemancar.

Secara ringkas, Tornado Cash dapat menyembunyikan hubungan antara penarik dan penyimpan. Dalam situasi dengan basis pengguna yang besar, itu seperti seorang penjahat menyamar di tengah kerumunan di area sibuk, sehingga sulit bagi polisi untuk melacaknya. Proses penarikan melibatkan penggunaan ZK-SNARKs, dengan bagian saksi tersembunyi yang mengandung informasi kritis tentang penarik, yang merupakan aspek kunci dari seluruh mixer. Saat ini, Tornado tampaknya menjadi salah satu proyek lapisan aplikasi paling jenius yang terkait dengan ZK.

Penafian：

1. Artikel ini dicetak ulang dari [ Geek Web3], Semua hak cipta dimiliki oleh penulis asli [Faust, web3 keahlian]. Jika ada keberatan terhadap cetakan ulang ini, harap hubungiGate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.