Pengantar:

Baru-baru ini, Vitalik dan beberapa sarjana bersama-sama menerbitkan makalah baru yang membahas bagaimana Tornado Cash menerapkan skema anti pencucian uangnya (pada dasarnya memungkinkan penarik untuk membuktikan bahwa riwayat setoran mereka milik sebuah set yang tidak termasuk dana tercemar). Namun, makalah tersebut kurang memberikan penjelasan rinci tentang logika bisnis dan prinsip Tornado Cash, sehingga membuat beberapa pembaca hanya memiliki pemahaman yang dangkal.

Perlu dicatat bahwa proyek-proyek seperti Tornado, yang mewakili usaha privasi, benar-benar memanfaatkan aspek pengetahuan nol dari algoritma ZK-SNARK. Sementara itu, sebagian besar solusi yang membawa bendera ZK, seperti Rollups, hanya memanfaatkan kekompakan dari ZK-SNARK. Seringkali, orang cenderung menggabungkan Bukti Validitas dengan ZK, dan Tornado bertindak sebagai contoh yang sangat baik untuk menjelaskan aplikasi dunia nyata dari ZK.

Penulis artikel ini pernah menulis sebuah tulisan tentang prinsip-prinsip Tornado pada tahun 2022 untuk Penelitian Web3Caff. Hari ini, kami telah mengekstrak dan memperluas bagian-bagian tertentu dari karya asli tersebut untuk memberikan pemahaman sistematis tentang Tornado Cash.

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

Prinsip dari “Tornado”

Tornado Cash menggunakan bukti pengetahuan nol sebagai protokol pencampurannya. Sementara versi lama diluncurkan pada tahun 2019, versi beta model yang diperbarui diluncurkan pada akhir 2021. Versi sebelumnya dari Tornado mencapai tingkat desentralisasi yang baik dengan kontrak on-chain yang bersifat open-source dan bebas dari kontrol multi-tanda tangan. Selain itu, kode frontend adalah open-source dan di-backup di jaringan IPFS. Karena kesederhanaan versi Tornado sebelumnya, artikel ini difokuskan pada menjelaskannya.

Pendekatan utama Tornado adalah dengan mencampur berbagai tindakan deposit dan penarikan bersama-sama. Setelah mendepositokan Token ke Tornado, pihak deposito menyajikan Bukti ZK untuk memverifikasi deposit sebelumnya mereka dan kemudian menarik menggunakan alamat baru, dengan demikian memutus hubungan antara alamat deposit dan penarikan.

Lebih singkatnya lagi, bayangkan Tornado sebagai kotak kaca yang diisi dengan koin (Koin) yang disimpan oleh banyak individu. Kita bisa melihat siapa yang menyimpan Koin, tapi koin-koin ini sangat homogen. Jika seseorang yang tidak dikenal mengambil koin dari kotak tersebut, akan sulit melacak siapa yang awalnya meletakkan koin tersebut di sana.

（Sumber gambar: rareskills）

Skenario seperti itu tampaknya biasa terjadi. Ketika kita SWAP beberapa ETH dari kolam Uniswap, tidak mungkin untuk menentukan siapa ETH yang kita terima, mengingat banyak penyedia likuiditas untuk Uniswap. Namun, perbedaannya terletak pada prosesnya. Dengan Uniswap, pertukaran Token memerlukan Token lain sebagai nilai yang setara, dan dana tidak dapat ditransfer secara 'pribadi'. Sebaliknya, mixer hanya memerlukan penarik untuk menunjukkan tanda terima deposit mereka.

Untuk membuat tindakan deposit dan penarikan terlihat homogen, kolam Tornado menjaga konsistensi dalam jumlah deposit dan penarikan. Misalnya, jika sebuah kolam memiliki 100 penyimpan dan 100 penarik, meskipun tindakan tersebut terlihat secara publik, tidak ada hubungan antara mereka. Semua orang melakukan deposit dan penarikan dengan jumlah yang sama, sehingga sulit dilacak pergerakan dana. Jelas, hal ini memberikan keunggulan bawaan untuk pencucian uang.

Pertanyaan kunci muncul: ketika menarik dana, bagaimana seseorang membuktikan deposit sebelumnya? Alamat yang memulai penarikan tidak terhubung ke alamat deposit manapun, jadi bagaimana seseorang memverifikasi hak untuk menarik dana? Metode paling langsung adalah dengan penarik dana mengungkapkan catatan deposit mereka, tetapi itu akan mengekspos identitas mereka. Di sinilah bukti pengetahuan nol masuk ke dalam permainan.

Dengan Bukti ZK, penarik dapat mengonfirmasi bahwa mereka memiliki catatan deposit dalam kontrak Tornado dan bahwa deposit ini belum ditarik. Keindahan bukti pengetahuan nol adalah bahwa mereka menjaga privasi. Publik hanya tahu bahwa penarik memang melakukan deposit tetapi tidak dapat menentukan identitas spesifik mereka.

Untuk membuktikan “saya telah melakukan deposit di kolam Tornado” dapat diterjemahkan menjadi “Catatan deposit saya dapat ditemukan dalam kontrak Tornado.” Jika Cn menunjukkan catatan deposit, maka mengingat himpunan catatan deposit Tornado sebagai {C1, C2,…C100…}, Bob perlu membuktikan bahwa dia menggunakan kunci privatnya untuk menghasilkan catatan dalam himpunan ini tanpa mengungkapkan Cn spesifik mana itu. Ini memanfaatkan properti unik dari Bukti Merkle.

Semua catatan deposit Tornado diagregasikan menjadi Pohon Merkle yang dibangun di rantai. Sebagian besar daun ini (sekitar 2^20, lebih dari 1 juta) tetap kosong (dengan nilai awal). Setiap deposit baru memperbarui daun komitmen yang sesuai dan kemudian akar pohon.

Sebagai contoh, jika deposit Bob adalah yang ke-10.000 dalam sejarah Tornado, nilai terkait Cn akan menjadi daun ke-10.000 pohon tersebut, yaitu C10000 = Cn. Kontrak kemudian akan secara otomatis menghitung Root baru.

（Sumber gambar: RareSkills）

Bukti Merkle itu sendiri singkat dan efisien. Untuk membuktikan transaksi TD ada dalam Pohon Merkle, seseorang hanya perlu menyediakan Bukti Merkle yang terkait, yang tetap kompak bahkan jika Pohon Merkle itu luas.

Untuk memvalidasi bahwa suatu transaksi, katakanlah H3, benar-benar disertakan dalam Pohon Merkle, seseorang harus membuktikan bahwa menggunakan H3 dan data lain dari Pohon Merkle dapat menghasilkan Root. Data ini (termasuk Td) merupakan Bukti Merkle. Ketika Bob ingin menarik, ia perlu memverifikasi dua hal:

·Cn berada di Pohon Merkle yang dibangun on-chain oleh Tornado, di mana dia dapat membuat Bukti Merkle yang berisi Cn;

·Cn terkait dengan voucher deposit Bob.

Penjelasan Logika Bisnis Tornado

Dalam kode frontend antarmuka pengguna Tornado, banyak fungsionalitas telah diimplementasikan sebelumnya. Ketika penyimpan membuka halaman web Tornado Cash dan mengklik tombol deposit, kode frontend terlampir menghasilkan dua angka acak, K dan r, secara lokal. Kemudian menghitung nilai Cn=Hash(K, r), meneruskan Cn (disebut komitmen dalam diagram di bawah) ke kontrak Tornado untuk dimasukkan ke dalam Pohon Merkle-nya. Singkatnya, K dan r bertindak seperti kunci privat. Mereka sangat penting, dan pengguna disarankan untuk menyimpannya dengan aman, karena nantinya akan diperlukan lagi selama proses penarikan.

Sebuah 'encryptedNote' adalah fitur opsional yang memungkinkan pengguna mengenkripsi kredensial K dan r dengan kunci pribadi dan menyimpannya di rantai untuk mencegah lupa.

Perlu dicatat bahwa semua operasi di atas dilakukan di luar rantai, artinya kontrak Tornado maupun pengamat eksternal tidak mengetahui K dan r. Jika K dan r terbongkar, itu sama halnya dengan memiliki kunci privat dompet dicuri.

Setelah menerima deposit pengguna dan Cn yang dihitung=Hash(K, r), kontrak Tornado menempatkan Cn pada tingkat dasar Pohon Merkle, mengubahnya menjadi simpul daun baru dan kemudian memperbarui nilai root. Namun, penting untuk memahami bahwa daun-daun Pohon Merkle ini tidak dicatat dalam status kontrak tetapi hanya dicatat sebagai parameter acara dalam blok-blok sebelumnya. Kontrak Tornado hanya mencatat root Merkle. Selama penarikan, pengguna dapat membuktikan, melalui Bukti Merkle, bahwa catatan deposit sesuai dengan root Merkle saat ini, sebuah konsep yang agak mirip dengan penarikan jembatan lintas rantai klien ringan. Desain ini mengungkap kejeniusan Tornado: untuk menghemat biaya gas, pohon Merkle lengkap tidak dicatat dalam status kontrak, hanya rootnya. Daun-daun pohon tersebut hanya dicatat dalam catatan blok historis, mekanisme yang agak analog dengan prinsip penghematan gas Rollup (meskipun detailnya berbeda).

Selama proses penarikan, penarik memasukkan kredensial/kunci privat (nomor acak K dan r yang dihasilkan selama deposit) di halaman web frontend. Kode frontend Tornado Cash menggunakan K dan r, Cn=Hash(K, r), dan Bukti Merkle yang sesuai dengan Cn untuk menghasilkan Bukti ZK, dengan demikian mengonfirmasi bahwa Cn sesuai dengan catatan deposit pada Pohon Merkle dan bahwa K dan r adalah kredensial valid untuk Cn. Langkah ini pada dasarnya membuktikan pengetahuan kunci catatan deposit pada Pohon Merkle. Ketika Bukti ZK diserahkan ke kontrak Tornado, keempat parameter tersebut disembunyikan, memastikan pihak luar, termasuk kontrak Tornado itu sendiri, tetap tidak menyadari, sehingga menjaga privasi pengguna.

Sebuah detail menarik adalah bahwa operasi deposit menggunakan dua bilangan acak, K dan r, untuk menghasilkan Cn daripada hanya satu karena satu bilangan acak mungkin tidak cukup aman dan berpotensi dapat dibobol.

Terkait dengan simbol “A” dalam ilustrasi, itu mewakili alamat penerima penarikan dan disediakan oleh penarik. Sementara itu, “nf” adalah pengenal yang ditetapkan untuk mencegah serangan pengulangan, nilainya ditentukan sebagai nf=Hash(K), di mana K adalah salah satu dari dua nomor acak (K dan r) yang digunakan selama deposit untuk menghasilkan Cn. Dengan demikian, setiap Cn memiliki nf yang sesuai, dan keduanya saling terkait secara unik.

Mengapa perlu mencegah serangan replay? Berkat fitur desain mixer, saat penarikan, tidak jelas deposit mana di Pohon Merkle yang sesuai dengan dana yang ditarik. Karena hubungan antara penyimpan dan jumlah yang ditarik tetap samar, pengguna jahat mungkin mengeksploitasi ini dan berulang kali menarik dana dari mixer, menguras kolam token.

Di sini, pengenal nf berfungsi secara mirip dengan penghitung transaksi "nonce" yang melekat pada setiap alamat Ethereum, yang dibuat untuk mencegah pengulangan transaksi. Saat permintaan penarikan diajukan, pengguna harus mengirimkan nf. Sistem memeriksa apakah nf ini telah digunakan sebelumnya: jika iya, penarikan dibatalkan; jika tidak, penarikan dilanjutkan, dan nf tersebut dicatat, memastikan penggunaan berikutnya akan mengakibatkan pembatalan.

Beberapa orang mungkin bertanya-tanya: Bisakah seseorang membuat sebuah nf yang kontraknya tidak mencatat? Itu tidak mungkin. Selama pembuatan Bukti ZK, sangat penting untuk memastikan nf=Hash(K), dan nomor acak K terkait dengan catatan deposit Cn. Jika seseorang sembarangan membuat nf, itu tidak akan cocok dengan salah satu deposit yang dicatat, membuat pembuatan Bukti ZK yang valid menjadi tidak mungkin, dan akhirnya menghentikan proses penarikan.

Orang lain mungkin bertanya: Apakah ada cara lain selain menggunakan nf? Mengingat bahwa penarik harus mengirimkan Bukti ZK, yang menegaskan koneksi mereka ke Cn tertentu, tidakkah sudah cukup untuk memeriksa apakah Bukti ZK yang sesuai sudah tercatat di rantai? Namun, biaya yang terkait dengan pendekatan tersebut sangat mahal karena kontrak Tornado Cash tidak secara permanen menyimpan Bukti ZK yang sudah diajukan sebelumnya untuk menghindari pemborosan penyimpanan. Membandingkan setiap Bukti ZK baru dengan yang sudah ada untuk memastikan konsistensi jauh lebih membutuhkan sumber daya daripada hanya mencatat pengidentifikasi ringkas seperti nf.

Sesuai contoh kode fungsi penarikan, parameter yang diperlukan dan logika bisnisnya adalah sebagai berikut: Pengguna mengirimkan Bukti ZK, nf (NullifierHash) = Hash(K), dan menetapkan alamat penerima untuk penarikan. Bukti ZK menyembunyikan nilai Cn, K, dan r, memastikan dunia luar tidak dapat menentukan identitas pengguna. Biasanya, penerima akan menentukan alamat baru yang bersih untuk mencegah pengungkapan informasi pribadi.

Namun, ada tantangan kecil muncul: ketika pengguna menarik, untuk alasan ketidak dapat dilacakannya, mereka sering menggunakan alamat yang baru dibuat untuk memulai transaksi penarikan. Pada saat-saat seperti itu, alamat baru tersebut tidak memiliki ETH untuk menutupi biaya gas. Oleh karena itu, selama penarikan, alamat harus secara eksplisit menyatakan relay untuk menutupi biaya gas. Selanjutnya, kontrak mixer mengurangi sebagian dari penarikan pengguna untuk mengganti relay.

Kesimpulannya, Tornado Cash dapat mengaburkan hubungan antara deposan dan penarikan. Ketika ada basis pengguna yang besar, itu mirip dengan penjahat yang berbaur dengan kerumunan yang ramai, sehingga sulit bagi pihak berwenang untuk melacak. Proses penarikan menggunakan ZK-SNARK, dengan bagian "saksi" tersembunyi yang berisi informasi penting tentang penarikan. Ini bisa dibilang fitur mixer yang paling vital. Saat ini, Tornado mungkin salah satu aplikasi paling pintar yang terkait dengan ZK.

Disclaimer：

1. Artikel ini diambil dari [medium]. Semua hak cipta dimiliki oleh pengarang asli [Faust, web3 geekJika ada keberatan terhadap cetak ulang ini, silakan hubungi tim Gate Learn（gatelearn@gate.io），dan mereka akan segera menanganinya.
2. Penolakan 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-artikel yang diterjemahkan dilarang.