บทความรวบรวมลักษณะทางเทคนิคของโครงร่างการใช้งานกระแสหลักของ ZKP

แหล่งที่มาดั้งเดิม:ชื่อเรื่องรอง

ภาพรวม

ภาพรวม

เมื่อศึกษาหลักการทำงานของระบบ blockchain เราต้องเข้าใจความรู้ด้านการเข้ารหัสต่างๆ เช่น secp 256 k 1 ซึ่งเป็นอัลกอริทึมลายเซ็นแบบโค้งและอสมมาตรที่ใช้สำหรับลายเซ็นในระบบ bitcoin และ ethereum และตรวจสอบบัญชี ตัวอย่างเช่น sha 256 เป็นอัลกอริทึมแฮชที่ใช้ในการบีบอัดข้อมูลที่มีความยาวผันแปรเป็นรหัสที่มีความยาวคงที่ เช่น ฐาน 58 ซึ่งสามารถแปลงการเข้ารหัสข้อมูลเป็นสตริงที่แสดงด้วยอักขระที่พิมพ์ได้ ตัวอย่างเช่น ECDH ซึ่งเป็นอัลกอริทึมการแลกเปลี่ยนคีย์ Diffie-Hellman ใช้เพื่อแลกเปลี่ยนคีย์การสื่อสารอย่างปลอดภัยระหว่างโหนด P2P

ZKP ถูกเสนอครั้งแรกในปี 1985 อย่างไรก็ตาม เป็นเวลานานแล้วที่ไม่พบสถานการณ์การใช้งานขนาดใหญ่ ดังนั้นการพัฒนาเทคโนโลยีจึงช้ามาก จนกระทั่งเกิด Bitcoin ในปี 2009 ผู้คนพบว่ามันเหมาะสมมากสำหรับการแก้ปัญหาความเป็นส่วนตัวและความสามารถในการปรับขนาดใน blockchain ตั้งแต่นั้นมา เงินทุนและความสามารถจำนวนมากได้ลงทุนในการพัฒนาและการประยุกต์ใช้ทางวิศวกรรมของเทคโนโลยีนี้ มีการใช้งาน ZKP มากมาย เช่น: Groth 16, PlonK, STARK เป็นต้น และยังไม่มีมาตรฐานอุตสาหกรรมที่แท้จริงใด ๆ เกิดขึ้น บทความนี้จะรวบรวมคุณลักษณะทางเทคนิคของการใช้งาน ZKP ต่าง ๆ โดยหวังว่าจะช่วยเหลือคุณได้ ศึกษา วิจัย และ พัฒนา ด้าน วิศวกรรม .

ฟิลด์แอปพลิเคชัน ZKP

ชื่อเรื่องรอง

1. ใบรับรองความเป็นส่วนตัว

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

ชื่อเรื่องรอง

2. การเอาท์ซอร์สคอมพิวเตอร์

zksync 1.0 เป็นตัวอย่างที่ดี ดำเนินการโอนโทเค็น Ethereum และธุรกรรมนอกเครือข่าย แล้วส่งผลลัพธ์ไปยังโหนด โดยการตรวจสอบการพิสูจน์ ZKP โหนดสามารถทราบได้ว่ามีการคำนวณตามวิธีที่อ้างหรือไม่

ชื่อเรื่องรอง

3. การบีบอัดข้อมูล

Mina เป็นอีกตัวอย่างหนึ่ง ในระบบบล็อกเชนความเร็วสูงหลายระบบ ข้อมูลธุรกรรมมีขนาดใหญ่มาก ระบบจำเป็นต้องเก็บบล็อกทั้งหมดไว้เพื่อการตรวจสอบโปรโตคอลที่สอดคล้องกัน ดังนั้นระบบจึงมีความต้องการฮาร์ดแวร์และการจัดเก็บถาวรสูงมาก หมายความว่าบล็อกเชนโหนดจะต้องเพิ่มพื้นที่ดิสก์และความสามารถในการจัดทำดัชนีข้อมูลอย่างต่อเนื่อง ขณะนี้สามารถใช้ ZKP เพื่อบีบอัดข้อมูลการยืนยันได้ Mina บีบอัดบัญชีแยกประเภทเป็น 11 KB ผ่านการพิสูจน์ความรู้ที่ไม่มีความรู้ซ้ำแบบเรียกซ้ำ

ชื่อระดับแรก

ระบบพิสูจน์คือการใช้อัลกอริทึมพื้นฐานของ ZKP ซึ่งสามารถแบ่งออกเป็นสองประเภท: แบบโต้ตอบและไม่โต้ตอบ:

ชื่อเรื่องรอง

1. ระบบพิสูจน์แบบโต้ตอบ

ระบบพิสูจน์แบบโต้ตอบประกอบด้วยสองฝ่าย เรียกว่า Prover (เรียกสั้นๆ ว่า P) และ Verifier (เรียกสั้นๆ ว่า V) โดยที่ P รู้ความลับบางอย่าง (เช่น คีย์ลับของระบบเข้ารหัสคีย์สาธารณะ หรือรากที่สองของสมการกำลังสอง สารตกค้าง x), P หวังที่จะโน้มน้าว V ว่าเขากุมความลับนี้ไว้ การพิสูจน์เชิงโต้ตอบประกอบด้วยหลายรอบ ในแต่ละรอบ P และ V อาจต้องส่งข้อความหากันตามข้อความที่ได้รับจากกันและกันและคำนวณผลลัพธ์ด้วยตัวเอง วิธีทั่วไปคือ V ส่งข้อความค้นหาไปยัง P ในแต่ละรอบ และ P ตอบกลับไปยัง V หลังจากดำเนินการทุกรอบแล้ว V ตัดสินใจว่าจะยอมรับการพิสูจน์ของ P หรือไม่ โดยพิจารณาว่า P สามารถตอบคำถามที่ส่งด้วยตัวเองในแต่ละรอบได้อย่างถูกต้องหรือไม่

2. ระบบพิสูจน์แบบไม่โต้ตอบ

ในระบบการพิสูจน์แบบโต้ตอบที่กล่าวถึงข้างต้น P และ V ไม่โต้ตอบ และการพิสูจน์ถูกสร้างขึ้นโดย P โดยตรงไปยัง V และ V ยืนยันการพิสูจน์โดยตรง ระบบพิสูจน์แบบนี้เรียกว่า non-interactive proof system (NIZK)

ระบบพิสูจน์ที่เราใช้ในบล็อกเชนโดยทั่วไปคือ NIZK โหนดในบล็อกเชนคือตัวตรวจสอบ V และผู้ใช้ปลายทางหรือเครือข่ายสองชั้น (เลเยอร์ 2) คือตัวพิสูจน์ P

ลิงค์อ้างอิง [ 1 ] ที่ส่วนท้ายของบทความอธิบายโครงร่างและคุณลักษณะของ NIZK ที่ได้รับการเผยแพร่สู่สาธารณะในช่วงสิบปีที่ผ่านมา

• Bulletproofs

  ในการใช้งานด้านวิศวกรรมเชิงปฏิบัติ เรามุ่งเน้นที่ประสิทธิภาพและความอเนกประสงค์เป็นหลัก ดังนั้นเราจึงจัดประเภทและเปรียบเทียบระบบพิสูจน์ทั่วไปอย่างละเอียดมากขึ้น โปรดดูลิงก์อ้างอิงที่ส่วนท้ายของบทความ [2]:

  คุณสมบัติ: ขนาดการพิสูจน์ที่กระชับ ไม่จำเป็นต้องตั้งค่าที่เชื่อถือได้ แต่การสร้างการพิสูจน์และการตรวจสอบใช้เวลานาน

• SNARKs (Succinct Non-interactive ARguments of Knowledge)

  โครงการตัวแทน: Bulletproofs, Halo, Halo 2

  คุณสมบัติ: ขนาดของการพิสูจน์นั้นกระชับและเวลาในการตรวจสอบการพิสูจน์ค่อนข้างสั้น แต่แต่ละวงจรจำเป็นต้องเชื่อถือได้

• SNORKs (Succinct Non-interactive Oecumenical (Universal) aRguments of Knowledge)

  โครงการตัวแทน: Groth 16

  คุณลักษณะเด่น: การพิสูจน์ขนาดที่กระทัดรัด จำเป็นต้องมีการตั้งค่าที่เชื่อถือได้เพียงครั้งเดียวสำหรับวงจรทั้งหมด

• STARKs (Succinct (Scalable) Transparent ARguments of Knowledge)

  โครงการตัวแทน: Sonic, PlonK, Marlin, Plonky 2

  คุณสมบัติ: หลักฐานมีขนาดใหญ่มาก ไม่ต้องการการตั้งค่าที่เชื่อถือได้ และมีความสามารถในการปรับขนาดได้ดี

การจำแนกประเภทข้างต้นนั้นไม่แน่นอน ตัวอย่างเช่น โครงการ Halo/Halo 2 พวกเขายังยืมแนวคิดมากมายจาก Plonk ในการออกแบบ นอกจากนี้ SNORK มักจะถูกจัดประเภทเป็น SNARK เนื่องจากพวกมันทั้งหมดต้องการการตั้งค่าที่เชื่อถือได้

3. การเปรียบเทียบประสิทธิภาพ

(ดูลิงค์อ้างอิงท้ายบทความ [3])

ชื่อระดับแรก

การเขียนโปรแกรมวงจร

• วงจรคือการใช้ตรรกะทางธุรกิจของระบบ ZKP และการพัฒนาแอปพลิเคชัน ZKP จำเป็นต้องมีการเขียนโปรแกรมวงจร เหตุใดรหัสตรรกะ ZKP จึงเรียกว่า วงจร มีสาเหตุหลักดังต่อไปนี้:

• รหัสของการพิสูจน์ ZKP จะถูกแปลงเป็นชุดของนิพจน์ R 1 CS ที่มีข้อจำกัดอย่างง่าย จากนั้นจึงแปลงเป็น QAP พหุนามขนาดใหญ่โดยใช้วิธีแก้ไข Lagrange ซึ่งสุดท้ายแล้วจะถูกจำกัดในรูปแบบของวงจรเกท

• เช่นเดียวกับวงจรฮาร์ดแวร์ รหัสสาขาทั้งหมดจะถูกดำเนินการพร้อมกัน

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

ชื่อเรื่องรอง

• libsnark

1. ไลบรารีการพัฒนาที่ใช้กันทั่วไป

ระบบพิสูจน์ทั่วไป ไลบรารีวงจรพื้นฐาน และตัวอย่างการใช้งานถูกนำไปใช้ในภาษา C++

ระบบพิสูจน์อักษร: BBFR 15, BCCT 12, BCCT 13, BCGT V1 3, BCIOP 13, BCT V1 4 a, BCT V1 4 b, CT V1 5, DFGK 14, Groth 16, GM 17, GGPR 13, PGHR 13

• gnark

ลิงค์: https://github.com/scipr-lab/libsnark

ระบบพิสูจน์การใช้งานใน Go ให้ API ระดับสูงในการออกแบบวงจร

ระบบพิสูจน์: Groth 16, PlonK

• bellman

ลิงค์: https://github.com/consensys/gnark

ระบบพิสูจน์การใช้งานใน Rust ซึ่งมีอินเทอร์เฟซวงจร โครงสร้างพื้นฐาน และการใช้งานวงจรพื้นฐานบางอย่าง เช่น บูลีนและนามธรรมที่เป็นตัวเลข

ระบบพิสูจน์: Groth 16.

• snarkjs

ลิงค์: https://github.com/zkcrypto/bellman

ระบบพิสูจน์การใช้งานใน Javascript และ WASM ที่สามารถใช้เพื่อเชื่อถือการตั้งค่า สร้างการพิสูจน์ และตรวจสอบการพิสูจน์ snarkjs ใช้คอมไพเลอร์ circom ของ iden 3 เพื่อรวบรวมวงจรที่กำหนดโดย DSL

ระบบพิสูจน์: Groth 16, PlonK

• ethsnarks

ลิงค์: https://github.com/iden3/snarkjs

ดำเนินการใน Python สามารถสร้างการพิสูจน์ได้ในเบราว์เซอร์ของผู้ใช้ โดยใช้ Ethereum smart contracts เป็นตัวตรวจสอบความถูกต้อง ในปัจจุบัน การพัฒนาโครงการไม่ได้ใช้งาน และอาจเป็นทางเลือกที่ดีกว่าในการใช้ Circom ในสถานการณ์เดียวกัน

ระบบพิสูจน์: Groth 16.

• bulletproofs

ลิงค์: https://github.com/HarryR/ethsnarks

ระบบพิสูจน์การใช้งานใน Rust พร้อมการพิสูจน์ช่วงเดียวและรวม การคำนวณแบบหลายฝ่ายที่พิมพ์อย่างเข้มงวด และ API ระบบข้อจำกัดที่ตั้งโปรแกรมได้สำหรับการพิสูจน์ข้อความโดยพลการกำลังอยู่ในระหว่างการพัฒนา

ระบบพิสูจน์: กันกระสุน

• halo 2 

ลิงค์: https://github.com/dalek-cryptography/bulletproofs

ระบบพิสูจน์ตามการใช้งาน Rust ซึ่งดูแลโดยทีม ZCash Halo 2 เป็นแบบเฉพาะสำหรับ PLONKish ช่วยให้สามารถควบคุมวิธีการแสดงวงจรในการดำเนินการทางคณิตศาสตร์ได้โดยตรง ทำให้เหมาะอย่างยิ่งสำหรับการเขียนวงจรที่ปรับให้เหมาะสมที่สุด

ลิงค์: https://github.com/zcash/halo 2.

ชื่อเรื่องรอง

2. กระบวนการพัฒนา

ยกตัวอย่าง gnark เวิร์กโฟลว์ทั่วไปมีดังนี้:

1) ใช้รหัสเพื่ออธิบายปัญหาที่จะแก้ไข

2) รวบรวมเป็นระบบข้อ จำกัด R 1 CS

3) ทำการตั้งค่าที่น่าเชื่อถือใน R 1 CS เพื่อรับรหัสพิสูจน์และรหัสยืนยัน

5) ผู้ตรวจสอบใช้ปุ่มยืนยันเพื่อตรวจสอบหลักฐาน

ภาษาพิเศษสำหรับการเขียนโปรแกรมวงจร

ชื่อเรื่องรอง

• Cairo

1. ขึ้นอยู่กับแพลตฟอร์ม Ethereum

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

ระบบพิสูจน์: STARK

• Zokrates

ลิงค์: https://www.cairo-lang.org/docs/

ZoKrates ใช้ DSL เพื่ออธิบายวงจรและจัดเตรียมไลบรารีวงจรที่ใช้กันทั่วไป ซึ่งสามารถช่วยคุณใช้การคำนวณที่ตรวจสอบได้ใน DApps ตั้งแต่การกำหนดมาตรฐานโปรแกรมของคุณในภาษาระดับสูงไปจนถึงการสร้างหลักฐานการคำนวณ จากนั้นตรวจสอบหลักฐานเหล่านี้ใน Solidity

ระบบพิสูจน์: GM 17, Groth 16, Marlin

• Circom

ลิงค์: https://zokrates.github.io/

ภาษา Circom ใช้ DSL เพื่ออธิบายวงจร และสามารถร่วมมือกับ snarkjs เพื่อสร้างการพิสูจน์ในเบราว์เซอร์ของผู้ใช้ โดยใช้ Ethereum smart contract เป็นตัวตรวจสอบ

ระบบพิสูจน์: Groth 16, PlonK

• Noir

ลิงค์: https://iden 3.io/circom.

ภาษาการเขียนโปรแกรมเพื่อความเป็นส่วนตัวแบบ Rust-based ของ Aztec ใช้ DSL เพื่ออธิบายวงจร ทำให้สามารถสร้างวงจรที่ไม่มีความรู้เป็นศูนย์ได้อย่างปลอดภัยและไร้รอยต่อ

ระบบพิสูจน์อักษร: PlonK.

• zkEVM

ลิงค์: https://noir-lang.org/index.html

ปัจจุบัน zkSync, Polygon, Scroll, Starkware และทีมอื่น ๆ กำลังดำเนินการเพื่อใช้งาน zkEVM และมีความคืบหน้าอย่างมาก

ชื่อเรื่องรอง

• zkApp (Mina)

2. ขึ้นอยู่กับแพลตฟอร์มเชนสาธารณะ

zkApps เป็นสัญญาอัจฉริยะของ Mina Protocol ที่ขับเคลื่อนโดยการพิสูจน์ที่ไม่มีความรู้ zkApps สามารถดำเนินการคำนวณที่ซับซ้อนได้ตามอำเภอใจนอกเชน ในขณะที่เรียกเก็บค่าธรรมเนียมคงที่เพื่อส่งการพิสูจน์ที่ไม่มีความรู้ที่สร้างขึ้นไปยังเชนเพื่อตรวจสอบการคำนวณนี้ ซึ่งแตกต่างจากบล็อกเชนอื่น ๆ ที่เรียกใช้การคำนวณบนเชนและใช้ค่าธรรมเนียมก๊าซผันแปรในรูปแบบที่ตรงกันข้าม zkApps เขียนด้วย Typescript

ระบบพิสูจน์อักษร: PlonK.

• LEO (Aleo)

ลิงค์: https://docs.minaprotocol.com/zkapps

Leo เป็นภาษาการเขียนโปรแกรมแบบสแตติกที่ใช้งานได้จริงซึ่งสร้างขึ้นโดยมีวัตถุประสงค์เพื่อเขียนแอปพลิเคชันส่วนตัว ออกแบบมาสำหรับนักพัฒนาซอฟต์แวร์ โดยสามารถสร้างบน Aleo blockchain ได้โดยสัญชาตญาณ ซึ่งเป็นรากฐานสำหรับระบบนิเวศส่วนตัวที่มีการกระจายอำนาจ

ลิงค์: https://leo-lang.org/

ชื่อระดับแรก

ปัญหาด้านความปลอดภัยทั่วไปของ ZKP

• ในช่วงไม่กี่ปีที่ผ่านมา ทีมรักษาความปลอดภัยของ SlowMist ได้ทำการตรวจสอบความปลอดภัยของวงจรและแอปพลิเคชันสำหรับผลิตภัณฑ์ ZKP ที่มีชื่อเสียงมากมาย รวมถึง ZKSwap, Zkdex, Zksafe เป็นต้น และพบช่องโหว่ที่มีความเสี่ยงปานกลางและสูงจำนวนมาก แอปพลิเคชันมี ความเข้าใจที่ลึกซึ้งยิ่งขึ้น ปัญหาด้านความปลอดภัยทั่วไปที่ทีมรักษาความปลอดภัย SlowMist พบในการตรวจสอบแอปพลิเคชัน ZKP คือ:

ความเสี่ยงของพารามิเตอร์ความน่าเชื่อถือ
ในการใช้ zk-SNARK จำเป็นต้องมีชุดพารามิเตอร์ทั่วไปที่เรียกว่า Common Reference String (CRS) แต่การสร้างพารามิเตอร์เหล่านี้ยังสร้างพารามิเตอร์ส่วนตัวบางอย่าง และหากฝ่ายใดฝ่ายหนึ่งได้รับพารามิเตอร์ส่วนตัวเหล่านี้ ก็จะสามารถปลอมแปลงหลักฐานได้

นอกจากนี้ กระบวนการสร้าง CRS จำเป็นต้องได้รับการตรวจสอบเพื่อให้แน่ใจว่าไม่มีแบ็คดอร์หมายเลขสุ่ม หรือพารามิเตอร์ส่วนตัวไม่ได้ถูกรักษาไว้โดยเจตนา การใช้ zk-SNORK จำเป็นต้องตรวจสอบให้แน่ใจว่าสตริงอ้างอิงที่มีโครงสร้าง (SRS) นั้นเชื่อถือได้

• ความเสี่ยงด้านความปลอดภัยในขั้นตอนการกำหนดค่าที่เชื่อถือได้สามารถแก้ไขได้โดยใช้การประมวลผลหลายฝ่ายที่ปลอดภัย (MPC) คุณลักษณะของ MPC คือตราบใดที่ผู้เข้าร่วมรายใดสามารถเข้าร่วมได้อย่างตรงไปตรงมาผลการคำนวณขั้นสุดท้ายที่ได้รับผ่านระบบคอมพิวเตอร์หลายฝ่ายนี้คือ น่าเชื่อถือ

ความปลอดภัยของรหัสคงที่

• ส่วนนี้มีสาเหตุหลักมาจากปัญหาด้านความปลอดภัยที่เกิดจากการเข้ารหัสที่ไม่ได้มาตรฐาน เช่น: พารามิเตอร์ที่ไม่ได้ตรวจสอบ ค่าส่งกลับที่ยังไม่ได้ประมวลผล ตัวเลขล้น ขอบเขตที่ไม่ได้ตรวจสอบ ฯลฯ หากภาษาสำหรับเขียนวงจรคือ C/C++ ก็จะมีความเสี่ยงเช่นกัน หน่วยความจำล้น

ความเสี่ยงจากการโจมตีของซัพพลายเชน

• ความเสี่ยงด้านห่วงโซ่อุปทานส่วนใหญ่มาจากการใช้ฐานรหัสที่มีช่องโหว่ เช่น คลังสินค้าเวอร์ชันเก่า โดยปกติแล้ว แอปพลิเคชัน ZKP จำเป็นต้องใช้ร่วมกับไคลเอนต์หรือส่วนหน้าของเว็บ และส่วนนี้มีความเสี่ยงต่อแฮ็กเกอร์ในรูปแบบต่างๆ

ข้อผิดพลาดเชิงตรรกะ

• ข้อผิดพลาดทางลอจิกเป็นข้อผิดพลาดที่เป็นไปได้มากที่สุดในการนำวงจรไปใช้จำเป็นต้องตรวจสอบว่าการออกแบบวงจรเป็นไปตามข้อกำหนดร่วมกับเอกสารข้อกำหนดหรือไม่

โจมตีการใช้จ่ายสองเท่า

• การออกแบบที่ไม่ถูกต้องอาจนำไปสู่การโจมตีแบบใช้จ่ายซ้ำซ้อน ตัวอย่างเช่น ไลบรารี ZKP บางแห่งมีความเสี่ยงด้านการขยายขนาด ผู้โจมตีสามารถใช้ Proofs ที่รู้จักเพื่อสร้าง Proofs ต่างๆ ได้ หากการออกแบบไม่เหมาะสมจะนำไปสู่การโจมตีแบบใช้จ่ายซ้ำซ้อน

พิสูจน์การปลอมแปลง

• การพิสูจน์ที่มีประสิทธิภาพเป็นปัญหาหลักที่ ZKP ต้องแก้ไข เพื่อให้มั่นใจถึงความสมบูรณ์และความน่าเชื่อถือ นั่นคือ เท็จไม่สามารถเป็นจริงได้ จริงไม่สามารถเป็นเท็จได้ ดังนั้นหากวงจรสามารถสร้างการพิสูจน์ที่ผิดพลาดได้ ก็มักจะเกิดจากช่องโหว่ใน ไลบรารีพื้นฐาน โดยปกติแล้ว เราขอแนะนำให้ฝ่ายโครงการใช้ไลบรารี ZKP ที่ตรวจสอบโดยสาธารณะและใช้เวอร์ชันที่เสถียร

การโจมตีช่องทางด้านข้าง

• หากวงจรได้รับการออกแบบไม่ถูกต้อง ข้อมูลส่วนตัวที่แตกต่างกันอาจมีลักษณะการคำนวณที่แตกต่างกัน และผู้โจมตีอาจเดาข้อมูลอินพุตส่วนตัวผ่านการป้อนข้อมูลสาธารณะหรือการพิสูจน์

ความล้มเหลวของข้อ จำกัด ของวงจร

• การแสดงออกของวงจรที่ไม่เหมาะสมอาจส่งผลให้เกิดตัวแปรที่ไม่มีข้อจำกัด

การโจมตีด้วยค่าพิเศษ

• ค่าอินพุตพิเศษบางค่าอาจข้ามตรรกะการตรวจสอบความถูกต้องของระบบ เช่น 0, null เป็นต้น

การคาดเดาความเป็นส่วนตัว

• สำหรับแอปพลิเคชันเช่น Tornado Cash หากสามารถคาดเดาข้อมูลที่ป้อนเข้าได้จะนำไปสู่ปัญหาความเป็นส่วนตัวที่ร้ายแรงรั่วไหล ในขณะนี้ จำเป็นต้องมีการตรวจสอบอย่างเข้มงวดของข้อมูลที่ป้อนเพื่อให้แน่ใจว่าไม่สามารถเดาได้

บางโครงการอาจมีสิทธิ์พิเศษของผู้ดูแลระบบ เมื่อใช้สิทธิ์อย่างผิดกฎหมาย เงินโครงการและทรัพย์สินของผู้ใช้จะถูกขโมย

• ความเสี่ยงของสัญญาอัจฉริยะ

ความเสี่ยงของสัญญาอัจฉริยะ

ชื่อระดับแรก

สรุป

สรุป

สุดท้ายนี้ ขอขอบคุณ Safeheron ผู้ให้บริการดูแลทรัพย์สินดิจิทัลแบบครบวงจรชั้นนำสำหรับคำแนะนำทางเทคนิคระดับมืออาชีพ

ลิงค์อ้างอิง:

[ 1 ]. https://en.wikipedia.org/wiki/Zero-knowledge_proof

[ 2 ]. https://github.com/matter-labs/awesome-zero-knowledge-proofs

[ 3 ].https://docs.google.com/presentation/d/1gfB6WZMvM9mmDKofFibIgsyYShdf0RV_Y8TLz3k1Ls0/edit