แอปพลิเคชัน ZK ที่ยอดเยี่ยม: Tornado Cash

มือใหม่2/28/2024, 5:40:33 AM
บทความนี้นำเสนอโครงการความเป็นส่วนตัวที่ถูกแทนด้วย Tornado ซึ่งใช้คุณสมบัติศูนย์ศูนย์ของอัลกอริทึม ZK-SNARK อย่างแท้จริง ในขณะที่โครงการส่วนใหญ่ภายใต้แบนเนอร์ ZK เพียงแค่ใช้ความกระชับของ ZK-SNARK เท่านั้น บ่อยครั้ง คนสับสนกับความแตกต่างระหว่างการพิสูจน์ความถูกต้องและ ZK และ Tornado ให้เป็นตัวอย่างที่ยอดเยี่ยมในการเข้าใจการประยุกต์ ZK

บทนํา: เมื่อเร็ว ๆ นี้ Vitalik และนักวิชาการบางคนร่วมตีพิมพ์บทความใหม่โดยกล่าวถึงวิธีที่ Tornado Cash ใช้โครงการต่อต้านการฟอกเงิน (โดยพื้นฐานแล้วอนุญาตให้ผู้ถอนเงินพิสูจน์ว่าบันทึกเงินฝากของพวกเขาเป็นของชุดที่ไม่มีเงินสกปรก) แต่กระดาษขาดการตีความโดยละเอียดเกี่ยวกับตรรกะทางธุรกิจและหลักการของ Tornado Cash ทําให้ผู้อ่านบางคนงวย

ควรกล่าวถึงว่าโครงการเกี่ยวกับความเป็นส่วนตัวที่มี Tornado เป็นโครงการที่ใช้คุณสมบัติศูนย์ซีโรคของอัลกอริทึม ZK-SNARK อย่างแท้จริง ในขณะที่โครงการส่วนใหญ่ที่มีป้ายชื่อ ZK เพียงใช้ความกระชับของ ZK-SNARK คนมักสับสนระหว่างการตรวจสอบความถูกต้องและ ZK และ Tornado เป็นตัวอย่างที่ยอดเยี่ยมในการเข้าใจการใช้ ZK ผู้เขียนบทความนี้ได้เขียนเกี่ยวกับกฎหมายของ Tornado ในปี 2022 สำหรับ Web3Caff Research และวันนี้เลือกและขยายเฉพาะบางส่วนจากบทความนั้น ๆ ขึ้นมา เพื่อเข้าใจ Tornado Cash อย่างเป็นระบบ

ลิงก์บทความเดิม: https://research.web3caff.com/th/archives/2663?ref=157

หลักการของ “Tornado”

Tornado Cash ใช้โปรโตคอลการผสมเหรียญตามหลักฐานที่ไม่มีความรู้ โดยเวอร์ชันเก่าเปิดตัวในปี 2019 และเวอร์ชันเบต้าใหม่ที่เปิดตัวในช่วงปลายปี 2021 Tornado เวอร์ชันเก่าประสบความสําเร็จในการกระจายอํานาจในระดับสูงโดยสัญญาแบบ on-chain เป็นโอเพ่นซอร์สและไม่ได้ควบคุมโดยกลไกหลายลายเซ็นใด ๆ และรหัสส่วนหน้ายังเป็นโอเพ่นซอร์สและสํารองข้อมูลบนเครือข่าย IPFS เนื่องจากโครงสร้างที่เรียบง่ายและเข้าใจได้มากขึ้นของ Tornado เวอร์ชันเก่าบทความนี้จึงมุ่งเน้นไปที่การอธิบาย แนวคิดหลักที่อยู่เบื้องหลัง Tornado คือการผสมผสานการดําเนินการฝากและถอนเงินจํานวนมากเข้าด้วยกัน หลังจากฝากโทเค็นใน Tornado ผู้ฝากเงินจะแสดงหลักฐาน ZK เพื่อพิสูจน์ว่าพวกเขาได้ทําการฝากเงินแล้วถอนไปยังที่อยู่ใหม่ซึ่งจะตัดการเชื่อมโยงระหว่างที่อยู่ฝากและถอน


โดยเฉพาะอย่างยิ่ง Tornado ทำหน้าที่เหมือนกล่องแก้วที่เต็มไปด้วยเหรียญที่ฝากโดยผู้คนหลายคน เราสามารถเห็นใครฝากเหรียญได้ แต่เนื่องจากเหรียญถูกผสมกันอย่างสูง การติดตามไปยังเหรียญที่ถูกฝากโดยใครหากมีคนไม่รู้จักถอนเหรียญ จะยากมาก


(ที่มา: rareskills)สถานการณ์นี้ค่อนข้างธรรมดา ตัวอย่างเช่นเมื่อเราแลกเปลี่ยน ETH ในพูล Uniswap เราไม่สามารถรู้ได้ว่าเราได้รับ ETH จากใครเพราะหลายคนให้สภาพคล่องแก่ Uniswap อย่างไรก็ตามความแตกต่างคือทุกครั้งที่คุณแลกเปลี่ยนโทเค็นบน Uniswap คุณต้องใช้โทเค็นอื่นเป็นต้นทุนที่เท่ากันและคุณไม่สามารถโอนเงินให้คนอื่นได้ ในขณะที่ด้วยเครื่องผสมคุณจะต้องแสดงหลักฐานการฝากเงินเพื่อถอน เพื่อให้การดําเนินการฝากและถอนเงินดูเป็นเนื้อเดียวกันทุกการฝากลงในกลุ่มทอร์นาโดและการถอนเงินทุกครั้งจะถูกเก็บไว้ในจํานวนที่สม่ําเสมอ ตัวอย่างเช่นหากมีผู้ฝาก 100 คนและผู้ถอน 100 คนในพูลแม้ว่าจะมองเห็นได้ แต่ก็ดูเหมือนจะไม่เชื่อมโยงและจํานวนเงินที่ฝากและถอนโดยแต่ละคนจะเหมือนกัน


นี่อาจทำให้การติดตามการโอนเงินถูกซ่อนเร้น ให้ความสะดวกในการประนีตโอนเงินแบบไม่ระบุชื่อ คำถามสำคัญคือ: วิธีที่คนทำรายการถอนเงินพิสูจน์ว่าพวกเขาได้ฝากเงินไว้หรือเปล่า?

ที่อยู่ที่ทำการถอนเงินไม่ได้เชื่อมโยงกับที่อยู่ฝากเงินใด ดังนั้นจะสามารถกำหนดสิทธิในการถอนเงินได้อย่างไร? วิธีที่ตรงไปตรงมาที่สุดคือให้ผู้ถอนเปิดเผยว่าบันทึกการฝากเงินที่ใดเป็นของตน แต่นี่จะเปิดเผยตัวตนของพวกเขาโดยตรง นี่คือจุดที่ Zero-knowledge proofs มีบทบาทมาเล่น เมื่อนำ ZK Proof มาแสดงว่าพวกเขามีบันทึกการฝากเงินในสัญญา Tornado ที่ยังไม่ได้ถอนเงินออก ผู้ถอนสามารถเริ่มต้นการถอนเงินได้อย่างประสบความสำเร็จ การ Zero-knowledge proofs ปกป้องความเป็นส่วนตัวโดยธรรมชาติ โดยเปิดเผยเพียงแค่ว่าบุคคลนั้นได้ฝากเงินเข้าสู่กองทุน โดยไม่เปิดเผยว่าเป็นของผู้ฝากเงินคนไหน


เพื่อพิสูจน์ว่า "ฉันได้ฝากเงินในกลุ่มกองทุนทอร์นาโด" สามารถแปลเป็น "บันทึกเงินฝากของฉันสามารถพบได้ในสัญญาทอร์นาโด" หากเราใช้ Cn เพื่อแสดงบันทึกการฝากเงินปัญหาจะกลายเป็น: เนื่องจากชุดบันทึกการฝากเงินของ Tornado คือ {C1, C2, ... C100...} ผู้ถอน Bob พิสูจน์ว่าเขาใช้คีย์ของเขาเพื่อสร้าง Cn ในบันทึกการฝากเงินโดยไม่เปิดเผยว่า Cn เป็น Cn ใด สิ่งนี้เกี่ยวข้องกับคุณสมบัติพิเศษของ Merkle Proof บันทึกการฝากทั้งหมดของทอร์นาโดรวมอยู่ใน Merkle Tree ที่สร้างขึ้นบนโซ่ โดยมีบันทึกเหล่านี้เป็นโหนดใบระดับล่างสุด จํานวนใบทั้งหมดประมาณ 2 ^ 20 > 1 ล้านซึ่งส่วนใหญ่อยู่ในสถานะว่าง (กําหนดค่าเริ่มต้น) เมื่อใดก็ตามที่มีเงินฝากใหม่เกิดขึ้นสัญญาจะบันทึกมูลค่าที่เป็นเอกลักษณ์ความมุ่งมั่นลงในใบไม้จากนั้นอัปเดตรากของ Merkle Tree


ตัวอย่างเช่น หากเงินฝากของโบบเป็นเงินฝากลำดับที่ 10,000 ในประวัติของ Tornado ค่าลักษณะ Cn ที่เกี่ยวข้องกับเงินฝากนี้จะถูกป้อนเข้าไปในโหนดใบที่ 10,000 ของ Merkle Tree คือ C10000 = Cn สัญญาจะคำนวณรากใหม่โดยอัตโนมัติและอัปเดตไปยังการบันทึก เพื่อประหยัดทรัพยากรคำนวณ สัญญา Tornado จัดเก็บข้อมูลจากชุดของโหนดที่เปลี่ยนแปลงไปก่อนหน้านี้ เช่น Fs1, Fs2 และ Fs0 ในแผนภาพด้านล่าง


(ที่มา: RareSkills)

Merkle Proof, โดยลัทธิธรรม มีลักษณะที่กระชับและเบา ใช้ประโยชน์จากความเรียบง่ายของโครงสร้างข้อมูลต้นไม้ในกระบวนการค้นหา/ติดตาม ในการพิสูจน์จากภายนอกว่าธุรกรรม TD มีอยู่ในต้นไม้ Merkle ผู้เชื่อถือจะต้องให้ Merkle Proof ที่สอดคล้องกับ Root เท่านั้น ซึ่งเป็นเรื่องง่ายดาย หากต้นไม้ Merkle มีขนาดใหญ่โดยเฉพาะ มีใบรายการด้านล่างอยู่ที่ระดับล่างลึกถึง 2^20 (เช่น 1 ล้านรายการฝาก) Merkle Proof จะต้องรวมถึงค่าของโหนด 21 ค่าเท่านั้น ซึ่งเป็นเรื่องสั้นมาก


เพื่อพิสูจน์ว่าธุรกรรม H3 นั้นจริงๆ แล้วถูกห่อหุ้มอยู่ภายใน Merkle Tree ผู้ใดจำเป็นต้องแสดงให้เห็นว่าโดยใช้ H3 และส่วนอื่น ๆ ของข้อมูลบน Merkle Tree สามารถสร้าง Root และข้อมูลที่จำเป็นในการสร้าง Root (รวมถึง Td) เป็นส่วนประกอบของ Merkle Proof ขณะที่บ็อบถอนเงินเขาจำเป็นต้องพิสูจน์ว่าใบรับรองของเขาสอดคล้องกับการบันทึกแฮชฝาน Cn บน Merkle Tree ในบัญชีของ Tornado กล่าวคือเขาต้องพิสูจน์สองสิ่ง: Cn อยู่ใน On-chain Tornado’s fictional Merkle Tree โดยเฉพาะโดยการสร้าง Merkle Proof ที่ประกอบด้วย Cn; Cn เชื่อมโยงกับใบรับรองการฝากของบ็อบ

การตรวจสอบตราบาปของ Tornado อธิบาย

ในโค้ดส่วนหน้าของอินเทอร์เฟซผู้ใช้ Tornado ฟังก์ชันการทํางานหลายอย่างถูกนําไปใช้ล่วงหน้า เมื่อผู้ฝากเปิดหน้าเว็บ Tornado Cash และคลิกปุ่มฝากเงินรหัสส่วนหน้าประกอบจะสร้างตัวเลขสุ่มสองตัวคือ K และ r ในเครื่อง จากนั้นจะคํานวณค่าของ Cn = Hash (K, r) และส่ง Cn (เรียกว่าความมุ่งมั่นในแผนภาพด้านล่าง) ไปยังสัญญา Tornado ซึ่งแทรกลงใน Merkle Tree ที่บันทึกโดยหลัง โดยพื้นฐานแล้ว K และ r ทําหน้าที่เป็นคีย์ส่วนตัว พวกเขามีความสําคัญและระบบแจ้งให้ผู้ใช้บันทึกไว้อย่างปลอดภัย ต้องใช้ K และ r อีกครั้งในระหว่างการถอน


(ตัวเลือกของ encryptedNote ช่วยให้ผู้ใช้สามารถเข้ารหัสข้อมูลประจําตัว K และ r ด้วยคีย์ส่วนตัวและเก็บไว้ในบล็อกเชนเพื่อป้องกันการลืม) ที่สําคัญการดําเนินการทั้งหมดเหล่านี้เกิดขึ้นนอกห่วงโซ่ซึ่งหมายความว่าสัญญาทอร์นาโดและผู้สังเกตการณ์ภายนอกไม่รู้จัก K และ r หาก K และ r รั่วไหลก็คล้ายกับการขโมยกุญแจส่วนตัวของกระเป๋าเงิน


เมื่อได้รับเงินมัดจําจากผู้ใช้และการส่ง Cn = Hash (K, r) สัญญา Tornado จะบันทึก Cn ที่ชั้นล่างสุดของ Merkle Tree เป็นโหนดใบใหม่และยังอัปเดตค่า Root ดังนั้น Cn จึงเชื่อมโยงโดยตรงกับการดําเนินการฝากเงินของผู้ใช้ทําให้บุคคลภายนอกทราบว่าผู้ใช้รายใดสอดคล้องกับ Cn แต่ละรายที่ฝากโทเค็นลงในมิกเซอร์และบันทึกการฝาก Cn ของผู้ฝากแต่ละราย

ในระหว่างกระบวนการถอนเงินผู้ถอนจะป้อนคีย์ข้อมูลประจําตัว / ส่วนตัว (ตัวเลขสุ่ม K และ r ที่สร้างขึ้นระหว่างการฝากเงิน) บนหน้าเว็บส่วนหน้า โปรแกรมในรหัสส่วนหน้าของ Tornado Cash ใช้ K และ r, Cn = Hash (K, r) และ Merkle Proof ที่สอดคล้องกับ Cn เป็นพารามิเตอร์อินพุตเพื่อสร้าง ZK Proof สิ่งนี้พิสูจน์ได้ว่า Cn มีอยู่ใน Merkle Tree เป็นบันทึกการฝากเงิน และ K และ r เป็นข้อมูลประจําตัวที่สอดคล้องกับ Cn ขั้นตอนนี้พิสูจน์ได้เป็นหลัก: ฉันรู้กุญแจที่สอดคล้องกับบันทึกการฝากเงินบน Merkle Tree เมื่อ ZK Proof ถูกส่งไปยังสัญญา Tornado พารามิเตอร์ทั้งสี่นี้จะถูกปกปิดเพื่อปกป้องความเป็นส่วนตัว การสร้าง ZK Proof เกี่ยวข้องกับพารามิเตอร์เพิ่มเติมรวมถึงราก Merkle ที่บันทึกไว้ในสัญญา Tornado ในขณะที่ถอนตัวที่อยู่ผู้รับที่กําหนดเอง A และตัวระบุ nf เพื่อป้องกันการโจมตีซ้ํา พารามิเตอร์ทั้งสามนี้ถูกโพสต์ต่อสาธารณะบนบล็อกเชนซึ่งไม่กระทบต่อความเป็นส่วนตัว


รายละเอียดที่ควรทราบคือการใช้ตัวเลขสุ่มสองตัวคือ K และ r เพื่อสร้าง Cn แทนที่จะเป็นตัวเลขสุ่มเดียวซึ่งช่วยเพิ่มความปลอดภัยจากการชนกัน A หมายถึงที่อยู่ผู้รับการถอนเงินซึ่งเลือกโดยผู้ถอน ตัวระบุ nf ที่ออกแบบมาเพื่อป้องกันการโจมตีซ้ําจะคํานวณเป็น nf=Hash(K) โดยที่ K เป็นหนึ่งในสองตัวเลขสุ่มที่ใช้ในขั้นตอนการฝากเงินเพื่อสร้าง Cn สิ่งนี้เชื่อมโยง nf โดยตรงกับ Cn โดยสร้างความสัมพันธ์แบบหนึ่งต่อหนึ่งระหว่างแต่ละ Cn และ nf ที่สอดคล้องกัน วัตถุประสงค์ของการป้องกันการโจมตีซ้ําเกิดจากคุณสมบัติการออกแบบของมิกเซอร์ซึ่งทําให้ความสัมพันธ์ระหว่างจํานวนเงินที่ถอนและใบต้นไม้ Merkle ที่เฉพาะเจาะจง (Cn) ไม่ทราบทําให้สามารถละเมิดการถอนเงินซ้ําได้จนกว่ายอดเงินกองทุนจะหมดลง


ตัวระบุ nf ทำหน้าที่เช่นเดียวกับ nonce ที่เชื่อมโยงกับแต่ละที่อยู่ Ethereum ซึ่งมีประโยชน์ในการป้องกันการทำรายการซ้ำ ขณะที่การถอนเงินเกิดขึ้น มีการตรวจสอบเพื่อให้แน่ใจว่า nf ที่ส่งมายังไม่เคยใช้มาก่อน หากยังไม่เคยใช้ การถอนเงินถือว่าถูกต้อง และ nf จะถูกบันทึกไว้ การพยายามในการสร้าง nf ที่ไม่เกี่ยวข้องกับการฝาก Cn ที่ถูกบันทึกไว้จะล้มเหลวในการสร้าง ZK Proof ที่ถูกต้อง ทำให้การถอนเงินไม่สำเร็จ

หากมีคนสุ่มสร้างสัญญาที่ไม่สามารถเปลี่ยนได้ (nf) ที่ไม่ได้บันทึกไว้มันจะใช้งานได้หรือไม่? ไม่แน่นอน เมื่อผู้ถอนสร้าง Zero-Knowledge Proof (ZK Proof) พวกเขาจะต้องตรวจสอบให้แน่ใจว่า nf เท่ากับ Hash (K) โดยที่หมายเลขสุ่ม K เชื่อมโยงกับบันทึกการฝากเงิน Cn ซึ่งหมายความว่า NF เชื่อมโยงกับเงินฝากที่บันทึกไว้ Cn หากมีคนประดิษฐ์ NF โดยพลการ NF นี้จะไม่ตรงกับบันทึกการฝากเงินใด ๆ ทําให้ไม่สามารถสร้าง ZK Proof ที่ถูกต้องได้ ดังนั้นกระบวนการถอนเงินจึงไม่เสร็จสมบูรณ์และการดําเนินการถอนเงินจะล้มเหลว บางคนอาจถามว่า: เป็นไปได้ไหมที่จะดําเนินการโดยไม่มี nf? เนื่องจากผู้ถอนจําเป็นต้องส่งหลักฐาน ZK ในระหว่างการถอนเพื่อพิสูจน์ความเกี่ยวข้องกับ Cn บางอย่างทําไมไม่เพียงแค่ตรวจสอบว่า ZK Proof ที่เกี่ยวข้องถูกส่งไปยังบล็อกเชนทุกครั้งที่มีการถอนเงินหรือไม่? อย่างไรก็ตามวิธีการนี้มีค่าใช้จ่ายสูงเนื่องจากสัญญา Tornado Cash ไม่ได้จัดเก็บ ZK Proofs ที่ผ่านมาอย่างถาวรเนื่องจากการสูญเสียพื้นที่จัดเก็บจํานวนมาก การเปรียบเทียบ ZK Proof ใหม่ทุกรายการที่ส่งไปยังบล็อกเชนกับหลักฐานที่มีอยู่นั้นมีประสิทธิภาพน้อยกว่าการตั้งค่าตัวระบุขนาดเล็กเช่น nf และจัดเก็บอย่างถาวร

ตามตัวอย่างโค้ดของฟังก์ชันการถอนเงิน พารามิเตอร์ที่จำเป็นและตรรกะการดำเนินธุรกิจคือ ผู้ใช้ส่ง ZK Proof และ nf (NullifierHash) = Hash (K), ระบุที่อยู่ผู้รับสำหรับการถอนเงิน และ ZK Proof ซ่อนค่าของ Cn, K, และ r, ทำให้เป็นไปไม่ได้สำหรับบุคคลภายนอกที่จะกำหนดตัวตนของผู้ใช้ ผู้รับมักใช้ที่อยู่ใหม่และสะอาดซึ่งไม่เปิดเผยข้อมูลส่วนตัว


อย่างไรก็ตาม มีปัญหาเล็กน้อย: เมื่อผู้ใช้ถอนเงินเพื่อให้คงสภาพไว้ซึ่งไม่สามารถติดตามได้ พวกเขามักเริ่มต้นธุรกรรมการถอนจากที่อยู่ที่สร้างขึ้นใหม่ ในขณะนี้ ที่อยู่ใหม่นั้นขาด ETH เพื่อชำระค่าธรรมเนียมในการใช้ gas ดังนั้น เมื่อเริ่มต้นการถอน ที่อยู่ถอนจะต้องประกาศให้ relayer เพื่อชำระค่า gas ให้แทน ต่อมา สัญญาผสมผสานจะหักส่วนหนึ่งจากการถอนของผู้ใช้เพื่อชดเชย relayer

สรุป Tornado Cash สามารถทำให้ความเชื่อมโยงระหว่างผู้ถอนเงินและผู้ฝากเงินเป็นสิ่งที่มัวหมองได้ ในสถานการณ์ที่มีจำนวนผู้ใช้มากมาย มันเหมือนกับอาชญากรที่ผสมตัวในฝูงชนในพื้นที่ที่คนคับคั่ง ทำให้ยากสำหรับตำรวจที่จะติดตาม กระบวนการถอนเงินนี้เกี่ยวข้องกับการใช้งาน ZK-SNARKs โดยส่วนของพยานที่ซ่อนอยู่มีข้อมูลสำคัญเกี่ยวกับผู้ถอนเงิน เป็นส่วนสำคัญของตัวผสมทั้งหมด ในปัจจุบัน Tornado ดูเหมือนจะเป็นหนึ่งในโครงการชั้นแอปพลิเคชั่นที่เกี่ยวข้องกับ ZK ที่ทรงคุณค่าที่สุด

คำประกาศ:

  1. บทความนี้ถูกพิมพ์ใหม่จาก [Geek Web3], All copyrights belong to the original author [Faust, geek web3]. If there are objections to this reprint, please contact the Gate Learnทีม และพวกเขาจะจัดการกับมันโดยรวดเร็ว
  2. คำประกาศความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางการลงทุนใด ๆ
  3. การแปลบทความเป็นภาษาอื่นๆ นำมาทำโดยทีม Gate Learn หากไม่ได้กล่าวถึงการคัดลอก การกระจายหรือการลอกเลียนบทความที่ถูกแปล จะถูกห้าม

แอปพลิเคชัน ZK ที่ยอดเยี่ยม: Tornado Cash

มือใหม่2/28/2024, 5:40:33 AM
บทความนี้นำเสนอโครงการความเป็นส่วนตัวที่ถูกแทนด้วย Tornado ซึ่งใช้คุณสมบัติศูนย์ศูนย์ของอัลกอริทึม ZK-SNARK อย่างแท้จริง ในขณะที่โครงการส่วนใหญ่ภายใต้แบนเนอร์ ZK เพียงแค่ใช้ความกระชับของ ZK-SNARK เท่านั้น บ่อยครั้ง คนสับสนกับความแตกต่างระหว่างการพิสูจน์ความถูกต้องและ ZK และ Tornado ให้เป็นตัวอย่างที่ยอดเยี่ยมในการเข้าใจการประยุกต์ ZK

บทนํา: เมื่อเร็ว ๆ นี้ Vitalik และนักวิชาการบางคนร่วมตีพิมพ์บทความใหม่โดยกล่าวถึงวิธีที่ Tornado Cash ใช้โครงการต่อต้านการฟอกเงิน (โดยพื้นฐานแล้วอนุญาตให้ผู้ถอนเงินพิสูจน์ว่าบันทึกเงินฝากของพวกเขาเป็นของชุดที่ไม่มีเงินสกปรก) แต่กระดาษขาดการตีความโดยละเอียดเกี่ยวกับตรรกะทางธุรกิจและหลักการของ Tornado Cash ทําให้ผู้อ่านบางคนงวย

ควรกล่าวถึงว่าโครงการเกี่ยวกับความเป็นส่วนตัวที่มี Tornado เป็นโครงการที่ใช้คุณสมบัติศูนย์ซีโรคของอัลกอริทึม ZK-SNARK อย่างแท้จริง ในขณะที่โครงการส่วนใหญ่ที่มีป้ายชื่อ ZK เพียงใช้ความกระชับของ ZK-SNARK คนมักสับสนระหว่างการตรวจสอบความถูกต้องและ ZK และ Tornado เป็นตัวอย่างที่ยอดเยี่ยมในการเข้าใจการใช้ ZK ผู้เขียนบทความนี้ได้เขียนเกี่ยวกับกฎหมายของ Tornado ในปี 2022 สำหรับ Web3Caff Research และวันนี้เลือกและขยายเฉพาะบางส่วนจากบทความนั้น ๆ ขึ้นมา เพื่อเข้าใจ Tornado Cash อย่างเป็นระบบ

ลิงก์บทความเดิม: https://research.web3caff.com/th/archives/2663?ref=157

หลักการของ “Tornado”

Tornado Cash ใช้โปรโตคอลการผสมเหรียญตามหลักฐานที่ไม่มีความรู้ โดยเวอร์ชันเก่าเปิดตัวในปี 2019 และเวอร์ชันเบต้าใหม่ที่เปิดตัวในช่วงปลายปี 2021 Tornado เวอร์ชันเก่าประสบความสําเร็จในการกระจายอํานาจในระดับสูงโดยสัญญาแบบ on-chain เป็นโอเพ่นซอร์สและไม่ได้ควบคุมโดยกลไกหลายลายเซ็นใด ๆ และรหัสส่วนหน้ายังเป็นโอเพ่นซอร์สและสํารองข้อมูลบนเครือข่าย IPFS เนื่องจากโครงสร้างที่เรียบง่ายและเข้าใจได้มากขึ้นของ Tornado เวอร์ชันเก่าบทความนี้จึงมุ่งเน้นไปที่การอธิบาย แนวคิดหลักที่อยู่เบื้องหลัง Tornado คือการผสมผสานการดําเนินการฝากและถอนเงินจํานวนมากเข้าด้วยกัน หลังจากฝากโทเค็นใน Tornado ผู้ฝากเงินจะแสดงหลักฐาน ZK เพื่อพิสูจน์ว่าพวกเขาได้ทําการฝากเงินแล้วถอนไปยังที่อยู่ใหม่ซึ่งจะตัดการเชื่อมโยงระหว่างที่อยู่ฝากและถอน


โดยเฉพาะอย่างยิ่ง Tornado ทำหน้าที่เหมือนกล่องแก้วที่เต็มไปด้วยเหรียญที่ฝากโดยผู้คนหลายคน เราสามารถเห็นใครฝากเหรียญได้ แต่เนื่องจากเหรียญถูกผสมกันอย่างสูง การติดตามไปยังเหรียญที่ถูกฝากโดยใครหากมีคนไม่รู้จักถอนเหรียญ จะยากมาก


(ที่มา: rareskills)สถานการณ์นี้ค่อนข้างธรรมดา ตัวอย่างเช่นเมื่อเราแลกเปลี่ยน ETH ในพูล Uniswap เราไม่สามารถรู้ได้ว่าเราได้รับ ETH จากใครเพราะหลายคนให้สภาพคล่องแก่ Uniswap อย่างไรก็ตามความแตกต่างคือทุกครั้งที่คุณแลกเปลี่ยนโทเค็นบน Uniswap คุณต้องใช้โทเค็นอื่นเป็นต้นทุนที่เท่ากันและคุณไม่สามารถโอนเงินให้คนอื่นได้ ในขณะที่ด้วยเครื่องผสมคุณจะต้องแสดงหลักฐานการฝากเงินเพื่อถอน เพื่อให้การดําเนินการฝากและถอนเงินดูเป็นเนื้อเดียวกันทุกการฝากลงในกลุ่มทอร์นาโดและการถอนเงินทุกครั้งจะถูกเก็บไว้ในจํานวนที่สม่ําเสมอ ตัวอย่างเช่นหากมีผู้ฝาก 100 คนและผู้ถอน 100 คนในพูลแม้ว่าจะมองเห็นได้ แต่ก็ดูเหมือนจะไม่เชื่อมโยงและจํานวนเงินที่ฝากและถอนโดยแต่ละคนจะเหมือนกัน


นี่อาจทำให้การติดตามการโอนเงินถูกซ่อนเร้น ให้ความสะดวกในการประนีตโอนเงินแบบไม่ระบุชื่อ คำถามสำคัญคือ: วิธีที่คนทำรายการถอนเงินพิสูจน์ว่าพวกเขาได้ฝากเงินไว้หรือเปล่า?

ที่อยู่ที่ทำการถอนเงินไม่ได้เชื่อมโยงกับที่อยู่ฝากเงินใด ดังนั้นจะสามารถกำหนดสิทธิในการถอนเงินได้อย่างไร? วิธีที่ตรงไปตรงมาที่สุดคือให้ผู้ถอนเปิดเผยว่าบันทึกการฝากเงินที่ใดเป็นของตน แต่นี่จะเปิดเผยตัวตนของพวกเขาโดยตรง นี่คือจุดที่ Zero-knowledge proofs มีบทบาทมาเล่น เมื่อนำ ZK Proof มาแสดงว่าพวกเขามีบันทึกการฝากเงินในสัญญา Tornado ที่ยังไม่ได้ถอนเงินออก ผู้ถอนสามารถเริ่มต้นการถอนเงินได้อย่างประสบความสำเร็จ การ Zero-knowledge proofs ปกป้องความเป็นส่วนตัวโดยธรรมชาติ โดยเปิดเผยเพียงแค่ว่าบุคคลนั้นได้ฝากเงินเข้าสู่กองทุน โดยไม่เปิดเผยว่าเป็นของผู้ฝากเงินคนไหน


เพื่อพิสูจน์ว่า "ฉันได้ฝากเงินในกลุ่มกองทุนทอร์นาโด" สามารถแปลเป็น "บันทึกเงินฝากของฉันสามารถพบได้ในสัญญาทอร์นาโด" หากเราใช้ Cn เพื่อแสดงบันทึกการฝากเงินปัญหาจะกลายเป็น: เนื่องจากชุดบันทึกการฝากเงินของ Tornado คือ {C1, C2, ... C100...} ผู้ถอน Bob พิสูจน์ว่าเขาใช้คีย์ของเขาเพื่อสร้าง Cn ในบันทึกการฝากเงินโดยไม่เปิดเผยว่า Cn เป็น Cn ใด สิ่งนี้เกี่ยวข้องกับคุณสมบัติพิเศษของ Merkle Proof บันทึกการฝากทั้งหมดของทอร์นาโดรวมอยู่ใน Merkle Tree ที่สร้างขึ้นบนโซ่ โดยมีบันทึกเหล่านี้เป็นโหนดใบระดับล่างสุด จํานวนใบทั้งหมดประมาณ 2 ^ 20 > 1 ล้านซึ่งส่วนใหญ่อยู่ในสถานะว่าง (กําหนดค่าเริ่มต้น) เมื่อใดก็ตามที่มีเงินฝากใหม่เกิดขึ้นสัญญาจะบันทึกมูลค่าที่เป็นเอกลักษณ์ความมุ่งมั่นลงในใบไม้จากนั้นอัปเดตรากของ Merkle Tree


ตัวอย่างเช่น หากเงินฝากของโบบเป็นเงินฝากลำดับที่ 10,000 ในประวัติของ Tornado ค่าลักษณะ Cn ที่เกี่ยวข้องกับเงินฝากนี้จะถูกป้อนเข้าไปในโหนดใบที่ 10,000 ของ Merkle Tree คือ C10000 = Cn สัญญาจะคำนวณรากใหม่โดยอัตโนมัติและอัปเดตไปยังการบันทึก เพื่อประหยัดทรัพยากรคำนวณ สัญญา Tornado จัดเก็บข้อมูลจากชุดของโหนดที่เปลี่ยนแปลงไปก่อนหน้านี้ เช่น Fs1, Fs2 และ Fs0 ในแผนภาพด้านล่าง


(ที่มา: RareSkills)

Merkle Proof, โดยลัทธิธรรม มีลักษณะที่กระชับและเบา ใช้ประโยชน์จากความเรียบง่ายของโครงสร้างข้อมูลต้นไม้ในกระบวนการค้นหา/ติดตาม ในการพิสูจน์จากภายนอกว่าธุรกรรม TD มีอยู่ในต้นไม้ Merkle ผู้เชื่อถือจะต้องให้ Merkle Proof ที่สอดคล้องกับ Root เท่านั้น ซึ่งเป็นเรื่องง่ายดาย หากต้นไม้ Merkle มีขนาดใหญ่โดยเฉพาะ มีใบรายการด้านล่างอยู่ที่ระดับล่างลึกถึง 2^20 (เช่น 1 ล้านรายการฝาก) Merkle Proof จะต้องรวมถึงค่าของโหนด 21 ค่าเท่านั้น ซึ่งเป็นเรื่องสั้นมาก


เพื่อพิสูจน์ว่าธุรกรรม H3 นั้นจริงๆ แล้วถูกห่อหุ้มอยู่ภายใน Merkle Tree ผู้ใดจำเป็นต้องแสดงให้เห็นว่าโดยใช้ H3 และส่วนอื่น ๆ ของข้อมูลบน Merkle Tree สามารถสร้าง Root และข้อมูลที่จำเป็นในการสร้าง Root (รวมถึง Td) เป็นส่วนประกอบของ Merkle Proof ขณะที่บ็อบถอนเงินเขาจำเป็นต้องพิสูจน์ว่าใบรับรองของเขาสอดคล้องกับการบันทึกแฮชฝาน Cn บน Merkle Tree ในบัญชีของ Tornado กล่าวคือเขาต้องพิสูจน์สองสิ่ง: Cn อยู่ใน On-chain Tornado’s fictional Merkle Tree โดยเฉพาะโดยการสร้าง Merkle Proof ที่ประกอบด้วย Cn; Cn เชื่อมโยงกับใบรับรองการฝากของบ็อบ

การตรวจสอบตราบาปของ Tornado อธิบาย

ในโค้ดส่วนหน้าของอินเทอร์เฟซผู้ใช้ Tornado ฟังก์ชันการทํางานหลายอย่างถูกนําไปใช้ล่วงหน้า เมื่อผู้ฝากเปิดหน้าเว็บ Tornado Cash และคลิกปุ่มฝากเงินรหัสส่วนหน้าประกอบจะสร้างตัวเลขสุ่มสองตัวคือ K และ r ในเครื่อง จากนั้นจะคํานวณค่าของ Cn = Hash (K, r) และส่ง Cn (เรียกว่าความมุ่งมั่นในแผนภาพด้านล่าง) ไปยังสัญญา Tornado ซึ่งแทรกลงใน Merkle Tree ที่บันทึกโดยหลัง โดยพื้นฐานแล้ว K และ r ทําหน้าที่เป็นคีย์ส่วนตัว พวกเขามีความสําคัญและระบบแจ้งให้ผู้ใช้บันทึกไว้อย่างปลอดภัย ต้องใช้ K และ r อีกครั้งในระหว่างการถอน


(ตัวเลือกของ encryptedNote ช่วยให้ผู้ใช้สามารถเข้ารหัสข้อมูลประจําตัว K และ r ด้วยคีย์ส่วนตัวและเก็บไว้ในบล็อกเชนเพื่อป้องกันการลืม) ที่สําคัญการดําเนินการทั้งหมดเหล่านี้เกิดขึ้นนอกห่วงโซ่ซึ่งหมายความว่าสัญญาทอร์นาโดและผู้สังเกตการณ์ภายนอกไม่รู้จัก K และ r หาก K และ r รั่วไหลก็คล้ายกับการขโมยกุญแจส่วนตัวของกระเป๋าเงิน


เมื่อได้รับเงินมัดจําจากผู้ใช้และการส่ง Cn = Hash (K, r) สัญญา Tornado จะบันทึก Cn ที่ชั้นล่างสุดของ Merkle Tree เป็นโหนดใบใหม่และยังอัปเดตค่า Root ดังนั้น Cn จึงเชื่อมโยงโดยตรงกับการดําเนินการฝากเงินของผู้ใช้ทําให้บุคคลภายนอกทราบว่าผู้ใช้รายใดสอดคล้องกับ Cn แต่ละรายที่ฝากโทเค็นลงในมิกเซอร์และบันทึกการฝาก Cn ของผู้ฝากแต่ละราย

ในระหว่างกระบวนการถอนเงินผู้ถอนจะป้อนคีย์ข้อมูลประจําตัว / ส่วนตัว (ตัวเลขสุ่ม K และ r ที่สร้างขึ้นระหว่างการฝากเงิน) บนหน้าเว็บส่วนหน้า โปรแกรมในรหัสส่วนหน้าของ Tornado Cash ใช้ K และ r, Cn = Hash (K, r) และ Merkle Proof ที่สอดคล้องกับ Cn เป็นพารามิเตอร์อินพุตเพื่อสร้าง ZK Proof สิ่งนี้พิสูจน์ได้ว่า Cn มีอยู่ใน Merkle Tree เป็นบันทึกการฝากเงิน และ K และ r เป็นข้อมูลประจําตัวที่สอดคล้องกับ Cn ขั้นตอนนี้พิสูจน์ได้เป็นหลัก: ฉันรู้กุญแจที่สอดคล้องกับบันทึกการฝากเงินบน Merkle Tree เมื่อ ZK Proof ถูกส่งไปยังสัญญา Tornado พารามิเตอร์ทั้งสี่นี้จะถูกปกปิดเพื่อปกป้องความเป็นส่วนตัว การสร้าง ZK Proof เกี่ยวข้องกับพารามิเตอร์เพิ่มเติมรวมถึงราก Merkle ที่บันทึกไว้ในสัญญา Tornado ในขณะที่ถอนตัวที่อยู่ผู้รับที่กําหนดเอง A และตัวระบุ nf เพื่อป้องกันการโจมตีซ้ํา พารามิเตอร์ทั้งสามนี้ถูกโพสต์ต่อสาธารณะบนบล็อกเชนซึ่งไม่กระทบต่อความเป็นส่วนตัว


รายละเอียดที่ควรทราบคือการใช้ตัวเลขสุ่มสองตัวคือ K และ r เพื่อสร้าง Cn แทนที่จะเป็นตัวเลขสุ่มเดียวซึ่งช่วยเพิ่มความปลอดภัยจากการชนกัน A หมายถึงที่อยู่ผู้รับการถอนเงินซึ่งเลือกโดยผู้ถอน ตัวระบุ nf ที่ออกแบบมาเพื่อป้องกันการโจมตีซ้ําจะคํานวณเป็น nf=Hash(K) โดยที่ K เป็นหนึ่งในสองตัวเลขสุ่มที่ใช้ในขั้นตอนการฝากเงินเพื่อสร้าง Cn สิ่งนี้เชื่อมโยง nf โดยตรงกับ Cn โดยสร้างความสัมพันธ์แบบหนึ่งต่อหนึ่งระหว่างแต่ละ Cn และ nf ที่สอดคล้องกัน วัตถุประสงค์ของการป้องกันการโจมตีซ้ําเกิดจากคุณสมบัติการออกแบบของมิกเซอร์ซึ่งทําให้ความสัมพันธ์ระหว่างจํานวนเงินที่ถอนและใบต้นไม้ Merkle ที่เฉพาะเจาะจง (Cn) ไม่ทราบทําให้สามารถละเมิดการถอนเงินซ้ําได้จนกว่ายอดเงินกองทุนจะหมดลง


ตัวระบุ nf ทำหน้าที่เช่นเดียวกับ nonce ที่เชื่อมโยงกับแต่ละที่อยู่ Ethereum ซึ่งมีประโยชน์ในการป้องกันการทำรายการซ้ำ ขณะที่การถอนเงินเกิดขึ้น มีการตรวจสอบเพื่อให้แน่ใจว่า nf ที่ส่งมายังไม่เคยใช้มาก่อน หากยังไม่เคยใช้ การถอนเงินถือว่าถูกต้อง และ nf จะถูกบันทึกไว้ การพยายามในการสร้าง nf ที่ไม่เกี่ยวข้องกับการฝาก Cn ที่ถูกบันทึกไว้จะล้มเหลวในการสร้าง ZK Proof ที่ถูกต้อง ทำให้การถอนเงินไม่สำเร็จ

หากมีคนสุ่มสร้างสัญญาที่ไม่สามารถเปลี่ยนได้ (nf) ที่ไม่ได้บันทึกไว้มันจะใช้งานได้หรือไม่? ไม่แน่นอน เมื่อผู้ถอนสร้าง Zero-Knowledge Proof (ZK Proof) พวกเขาจะต้องตรวจสอบให้แน่ใจว่า nf เท่ากับ Hash (K) โดยที่หมายเลขสุ่ม K เชื่อมโยงกับบันทึกการฝากเงิน Cn ซึ่งหมายความว่า NF เชื่อมโยงกับเงินฝากที่บันทึกไว้ Cn หากมีคนประดิษฐ์ NF โดยพลการ NF นี้จะไม่ตรงกับบันทึกการฝากเงินใด ๆ ทําให้ไม่สามารถสร้าง ZK Proof ที่ถูกต้องได้ ดังนั้นกระบวนการถอนเงินจึงไม่เสร็จสมบูรณ์และการดําเนินการถอนเงินจะล้มเหลว บางคนอาจถามว่า: เป็นไปได้ไหมที่จะดําเนินการโดยไม่มี nf? เนื่องจากผู้ถอนจําเป็นต้องส่งหลักฐาน ZK ในระหว่างการถอนเพื่อพิสูจน์ความเกี่ยวข้องกับ Cn บางอย่างทําไมไม่เพียงแค่ตรวจสอบว่า ZK Proof ที่เกี่ยวข้องถูกส่งไปยังบล็อกเชนทุกครั้งที่มีการถอนเงินหรือไม่? อย่างไรก็ตามวิธีการนี้มีค่าใช้จ่ายสูงเนื่องจากสัญญา Tornado Cash ไม่ได้จัดเก็บ ZK Proofs ที่ผ่านมาอย่างถาวรเนื่องจากการสูญเสียพื้นที่จัดเก็บจํานวนมาก การเปรียบเทียบ ZK Proof ใหม่ทุกรายการที่ส่งไปยังบล็อกเชนกับหลักฐานที่มีอยู่นั้นมีประสิทธิภาพน้อยกว่าการตั้งค่าตัวระบุขนาดเล็กเช่น nf และจัดเก็บอย่างถาวร

ตามตัวอย่างโค้ดของฟังก์ชันการถอนเงิน พารามิเตอร์ที่จำเป็นและตรรกะการดำเนินธุรกิจคือ ผู้ใช้ส่ง ZK Proof และ nf (NullifierHash) = Hash (K), ระบุที่อยู่ผู้รับสำหรับการถอนเงิน และ ZK Proof ซ่อนค่าของ Cn, K, และ r, ทำให้เป็นไปไม่ได้สำหรับบุคคลภายนอกที่จะกำหนดตัวตนของผู้ใช้ ผู้รับมักใช้ที่อยู่ใหม่และสะอาดซึ่งไม่เปิดเผยข้อมูลส่วนตัว


อย่างไรก็ตาม มีปัญหาเล็กน้อย: เมื่อผู้ใช้ถอนเงินเพื่อให้คงสภาพไว้ซึ่งไม่สามารถติดตามได้ พวกเขามักเริ่มต้นธุรกรรมการถอนจากที่อยู่ที่สร้างขึ้นใหม่ ในขณะนี้ ที่อยู่ใหม่นั้นขาด ETH เพื่อชำระค่าธรรมเนียมในการใช้ gas ดังนั้น เมื่อเริ่มต้นการถอน ที่อยู่ถอนจะต้องประกาศให้ relayer เพื่อชำระค่า gas ให้แทน ต่อมา สัญญาผสมผสานจะหักส่วนหนึ่งจากการถอนของผู้ใช้เพื่อชดเชย relayer

สรุป Tornado Cash สามารถทำให้ความเชื่อมโยงระหว่างผู้ถอนเงินและผู้ฝากเงินเป็นสิ่งที่มัวหมองได้ ในสถานการณ์ที่มีจำนวนผู้ใช้มากมาย มันเหมือนกับอาชญากรที่ผสมตัวในฝูงชนในพื้นที่ที่คนคับคั่ง ทำให้ยากสำหรับตำรวจที่จะติดตาม กระบวนการถอนเงินนี้เกี่ยวข้องกับการใช้งาน ZK-SNARKs โดยส่วนของพยานที่ซ่อนอยู่มีข้อมูลสำคัญเกี่ยวกับผู้ถอนเงิน เป็นส่วนสำคัญของตัวผสมทั้งหมด ในปัจจุบัน Tornado ดูเหมือนจะเป็นหนึ่งในโครงการชั้นแอปพลิเคชั่นที่เกี่ยวข้องกับ ZK ที่ทรงคุณค่าที่สุด

คำประกาศ:

  1. บทความนี้ถูกพิมพ์ใหม่จาก [Geek Web3], All copyrights belong to the original author [Faust, geek web3]. If there are objections to this reprint, please contact the Gate Learnทีม และพวกเขาจะจัดการกับมันโดยรวดเร็ว
  2. คำประกาศความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางการลงทุนใด ๆ
  3. การแปลบทความเป็นภาษาอื่นๆ นำมาทำโดยทีม Gate Learn หากไม่ได้กล่าวถึงการคัดลอก การกระจายหรือการลอกเลียนบทความที่ถูกแปล จะถูกห้าม
Empieza ahora
¡Registrarse y recibe un bono de
$100
!