a16z：การสำรวจเส้นทางปลอดภัยและมีประสิทธิภาพของ zkVM

ผู้เขียน: Justin Thaler ที่มา: a16z แปล: ชายชาวดี, ทองคำเศรษฐกิจ

เครื่องเสมือนองค์กรทราบเพียงมีความรู้ศิลปะ (zkVMs) มีจุดมุ่งหมายที่จะ "ทำให้ SNARKs เข้าถึงกับคนทั่วไป" ทำให้คุณสามารถพิสูจน์ได้ว่าพวกเขาได้เริ่มทำงานโปรแกรมบางอย่างในข้อมูลเข้า (หรือพิสูจน์) ที่เฉพาะเจาะจง แม้แต่คนที่ไม่มีความรู้เฉพาะเรื่อง SNARK ก็สามารถทำได้ ข้อได้เปรียบหลักคือประสบการณ์ในการพัฒนา แต่ตอนนี้ zkVMs ยังต้องเผชิญกับการทดลองในด้านความปลอดภัยและประสิทธิภาพ ถ้า zkVMs ต้องการทำตามสัญญา ผู้ออกแบบจะต้องเอาชนะอุปสรรคเหล่านี้ บทความนี้จะสำรวจระยะเวลาที่เป็นไปได้ของการพัฒนา zkVM ทั้งหมดอาจใช้เวลา หลายปี เพื่อสมบูรณ์ - อย่าไว้วางใจใครว่าสิ่งนี้สามารถทำได้อย่างรวดเร็ว

เผชิญกับความท้าทาย

ในด้านความปลอดภัย zkVMs เป็นโครงการซอฟต์แวร์ที่ซับซ้อนมาก ยังคงมีช่องโหว่อยู่

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

แม้ว่าเสียงจากอุตสาหกรรมบล็อกเชนจะระบุว่า zkVMs สามารถนำไปใช้งานได้ทันที และบางโครงการได้จ่ายค่าใช้จ่ายสูงสำหรับการสร้างศูนย์พิสูจน์ที่ไม่รู้อะไรเกิดขึ้นบนเชื่อมโยง อย่างไรก็ตามเนื่องจาก zkVMs ยังมีช่องโหว่อยู่เป็นจำนวนมาก วิธีการนี้จริง ๆ แล้วเป็นแค่ การปกปิดที่มีค่าใช้จ่ายสูง ทำให้ระบบดูเหมือนมีการป้องกันด้วย SNARK แต่ในความเป็นจริงมันจะขึ้นอยู่กับ การควบคุมสิทธิ หรือแย่ลงกว่านั้น——เผชิญต่อความเสี่ยงจากการโจมตี

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

ขั้นตอนการพัฒนาความปลอดภัย

พื้นหลัง

โดยทั่วไป zkVMs ที่ใช้ SNARK ประกอบด้วยสองส่วนหลัก

1. PIOP (Polynomial Interactive Oracle Proof): เป็นกรอบการพิสูจน์แบบโปลินอเมียล (หรือข้อจำกัดที่ได้มาจากโปลินอเมียล) ที่ใช้ในการพิสูจน์โปลินอเมียล (หรือข้อจำกัดที่ได้มาจากโปลินอเมียล) แบบโต้ตอบ

2. โครงการคุมพร้อมตัวหลายรายการ (Polynomial Commitment Scheme, PCS): ให้ความมั่นใจว่าผู้พิสูจน์ไม่สามารถปลอมแปลงผลการประเมินของหลายรายการได้โดยที่ไม่ถูกตรวจพบ

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

ในระบบที่ซับซ้อนเช่นนี้ วิธีเดียวที่จะให้ความมั่นใจได้ว่า zkVM ไม่มีช่องโหว่คือ การตรวจสอบแบบฟอร์ม ด้านล่างคือขั้นตอนต่าง ๆ ของความปลอดภัยของ zkVM โดย** ขั้นตอนแรกเน้นความถูกต้องของโปรโตคอล** ขั้นตอนสองและสามเน้นความถูกต้องของการปฏิบัติ

ข้ามขั้นตอนความปลอดภัย 1: โปรโตคอลที่ถูกต้อง

1. การยืนยันความเชื่อถือของ PIOP;
2. PCS การพิสูจน์รูปแบบที่มีผลอยู่ในบางกรณีหรือแบบจำลองที่สมมติในยุคสมัครเล่น;
3. หากใช้ Fiat-Shamir โดยการรวม PIOP และ PCS ในการรับรองอย่างกระชับที่ได้รับการยืนยันในโมเดลพยากรณ์สุ่ม (อาจจำเป็นต้องใช้สมมติการเข้ารหัสเพิ่มเติม)
4. ระบบข้อจำกัดที่ใช้ใน PIOP เทียบเท่ากับการพิสูจน์รูปแบบของความหมายของ VM;
5. นำส่วนทั้งหมดที่กล่าวถึงมารวมกันให้เป็นหนึ่งเดียว ซึ่งเป็นการพิสูจน์ SNARK ที่ปลอดภัยที่ผ่านการตรวจสอบรูปแบบ สำหรับการเรียกใช้โปรแกรมใดๆ ที่ระบุโดย bytecode VM หากโปรโตคอลต้องการให้มีความลับ จะต้องมีการตรวจสอบรูปแบบเพื่อป้องกันการรั่วของข้อมูลที่เป็นความลับเกี่ยวกับพยาน

หาก zkVM ใช้ การวนเกิด ต้องมีการตรวจสอบ PIOP、สัญญาและระบบข้อจำกัด ในกระบวนการวนเกิด มิฉะนั้น ไม่สามารถพิจารณาว่าขั้นตอนย่อยนั้นเสร็จสิ้น

ขั้นตอนความปลอดภัย 2: การดำเนินการของตัวตรวจสอบที่ถูกต้อง

ในข้างต้น จำเป็นต้องทำการตรวจสอบรูปแบบของ zkVM ตัวตรวจสอบ (เช่น Rust, Solidity, เป็นต้น) เพื่อให้แน่ใจว่ามันเป็นไปตามข้อตกลงที่ถูกตรวจสอบไว้แล้วในข้างต้น การทำข้างต้นจะหมายความว่าการดำเนินการของ zkVM นั้นเป็นไปตามการออกแบบทฤษฎี และไม่ใช่แค่เป็นข้อตกลงความปลอดภัยบนกระดาษ หรือข้อกำหนดที่ไม่มีประสิทธิภาพที่เขียนขึ้นโดยใช้ภาษา Lean เป็นต้น

ทำไมให้ความสนใจเฉพาะตัวตรวจสอบ ไม่ให้ความสนใจผู้พิสูจน์ มีสองเหตุผลหลัก: ในที่สุด, การตรวจสอบถูกต้องหมายความว่าระบบพิสูจน์ zkVM เป็นระบบที่สมบูรณ์ (กล่าวคือ: ให้ความมั่นใจว่าตัวตรวจสอบไม่ได้ถูกหลอกลวงให้ยอมรับพิสูจน์ที่ไม่ถูกต้อง) นอกจากนี้, การปฏิบัติตัวตรวจสอบของ zkVM ง่ายกว่าการปฏิบัติตัวพิสูจน์อย่างมาก ความถูกต้องของตัวตรวจสอบจะได้รับการคุ้มครองไว้ในช่วงเวลาสั้นๆ

ขั้นตอนการรักษาความปลอดภัย 3: ผู้พิสูจน์ที่ถูกต้อง

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

ตารางเวลาโดยประมาณ

ขั้นตอนที่ 1 ของความก้าวหน้า：เราสามารถคาดหวังว่าปีหน้าจะมีความก้าวหน้าบางอย่าง (เช่น ZKLib คือความพยายามเช่นนี้) แต่อย่างน้อย 2 ปีหลังจากนั้นไม่มี zkVM ใดที่สามารถตอบสนองต่อความต้องการขั้นตอนที่ 1 อย่างสมบูรณ์แบบ

ระยะ 2 และ 3：ขั้นตอนเหล่านี้สามารถดำเนินไปพร้อมกับบางด้านของขั้นตอนที่ 1 ตัวอย่างเช่น บางทีมได้แสดงให้เห็นว่าการประกัน Plonk ทำตามโปรโตคอลในเอกสารเหมือนกัน (แม้ว่าโปรโตคอลในเอกสารอาจไม่ได้รับการตรวจสอบอย่างสมบูรณ์) อย่างไรก็ตาม ฉันคาดว่า zkVM ใดๆ ก็จะไม่สามารถเข้าถึงระยะ 3 ในไม่กี่ปีเต็ม 4 และบางทีอาจนานกว่านั้น

ข้อควรระวัง: ความปลอดภัยของ Fiat-Shamir และ bytecode ที่ถูกตรวจสอบ

ภาวะแทรกซ้อนที่สําคัญคือยังมีคําถามที่ยังไม่มีคําตอบเกี่ยวกับความปลอดภัยของการแปลง Fiat-Shamir ขั้นตอนการรักษาความปลอดภัยทั้งสามถือว่า Fiat-Shamir และ oracles แบบสุ่มปลอดภัยอย่างยิ่ง แต่ในความเป็นจริงกระบวนทัศน์ทั้งหมดอาจมีความเสี่ยง นี่เป็นเพราะความแตกต่างระหว่างแบบจําลองในอุดมคติของ oracle แบบสุ่มและฟังก์ชันแฮชที่ใช้จริง

ในกรณีที่เลวร้ายที่สุด ระบบที่ได้รับระดับความปลอดภัย 2 อาจพบว่าไม่ปลอดภัยเลยเนื่องจากปัญหาที่เกี่ยวข้องกับ Fiat-Shamir นั้นคุ้มค่าที่เราให้ความสนใจอย่างสูงและทำการวิจัยอย่างต่อเนื่อง เราอาจจะต้องปรับเปลี่ยนการแปลง Fiat-Shamir เองเพื่อป้องกันช่องโหว่ของประเภทนี้ได้ดีขึ้น

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

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

เกี่ยวกับความปลอดภัยที่ต้านทายออก

ในอนาคตอย่างน้อย 5 ปี (หรือนานกว่านั้น) คอมพิวเตอร์ควอนตัมจะไม่เป็นอันตรายอย่างมาก ในขณะที่ช่องโหว่ของซอฟต์แวร์ก็เป็นปัญหาที่สำคัญ ดังนั้น ภารกิจสำคัญในขณะนี้คือการปฏิบัติตามเป้าหมายที่เกี่ยวกับความปลอดภัยและประสิทธิภาพตามที่ได้กล่าวถึงในบทความนี้ หาก SNARKs ที่ไม่ต้านทานต่อคอมพิวเตอร์ควอนตัมสามารถตอบสนองต่อเป้าหมายเหล่านี้ได้เร็วขึ้น เราควรให้ลำดับความสำคัญกับพวกเขา รอจนกระทั่ง SNARKs ที่ต้านทานต่อคอมพิวเตอร์ควอนตัมพัฒนาขึ้น หรือมีภาวะบ่งชัดว่าคอมพิวเตอร์ควอนตัมที่เป็นอันตรายจริงจะเริ่มเกิดขึ้น จึงค่อยพิจารณาการเปลี่ยนแปลง

ระดับความปลอดภัยที่เฉพาะเจาะจง

100-bit ความปลอดภัยคลาสสิก เป็นมาตรฐานต่ำสุด ที่ใช้สำหรับ SNARK เพื่อป้องกันทรัพย์สินมูลค่า (แต่ก็ยังมีระบบบางระบบที่ยังไม่ได้ตรงตามมาตรฐานต่ำสุด) อย่างไรก็ตาม นี่ก็ยังไม่ควรได้รับการยอมรับ โดยทั่วไปการปฏิบัติทางคริปโตกระดิกมักต้องการความปลอดภัยที่มี 128 บิตขึ้นไป หากประสิทธิภาพของ SNARK ตรงตามมาตรฐานจริง ๆ เราไม่ควรลดความปลอดภัยเพื่อเพิ่มประสิทธิภาพ

ข้ามเวที

สถานการณ์ปัจจุบัน

ในปัจจุบัน, ความต้องการในการคำนวณของ ** ตัวพิสูจน์ zkVM ** ประมาณ 100 ล้านเท่าของการดำเนินการเชิงพื้นเมือง。 กล่าวอีกนัยหนึ่ง, หากการดำเนินการเชิงพื้นเมืองของโปรแกรมต้องการ ** X รอบ CPU **, การ ** สร้างหลักฐานที่ดำเนินการถูกต้อง ** จำเป็นต้องใช้ ** X × 1,000,000 รอบ CPU ** โดยประมาณ. สถานการณ์นี้เป็นอย่างนั้น ** เมื่อหนึ่งปีก่อน และยังคงเป็นเช่นนี้ในปัจจุบัน ** (หมั่นเพราะข้อความบางอย่าง)

บางคำพูดที่ได้รับความนิยมในวงการอาจทำให้สับสน เช่น:

1. ต้นทุนในการสร้างพิสูจน์สำหรับเครือข่ายหลักอีเธอเรียลทั้งหมดต่ำกว่า 1 ล้านเหดต่อปี

2. เราเกือบทำให้การสร้างพิสูจน์ในบล็อกของอีเธอเรียลได้แบบเรียลไทม์แค่หลายสิบแผ่น GPU เท่านั้น

3. “zkVM ของเราเร็วขึ้น 1000 เท่า

อย่างไรก็ตาม การพูดเช่นนี้อาจมีความสับสนในกรณีที่ไม่มีบริบท

• zkVM เร็วกว่าเวอร์ชันก่อนหน้า 1000 เท่า แต่ก็ยังอาจจะช้ามาก สิ่งนี้ชัดเจนว่าสมัยที่ผ่านมามีปัญหามากน้อยเท่าไร ไม่ใช่มีปัญหามากน้อยเท่าไรในปัจจุบัน

• ประสิทธิภาพของ zkVM ในปัจจุบันอาจไม่สามารถทำงานรอบด้านตามความต้องการเมื่อปริมาณการคำนวณบนเครือข่ายหลัก Ethereum เพิ่มขึ้น 10 เท่า

การสร้างพิสูจน์อันใกล้เคียงกับเรียลไทม์ ในบางกรณีของแอปพลิเคชันบล็อกเชนยังคงช้าเกินไป (เช่น เวลาบล็อกของ Optimism คือ 2 วินาที ซึ่งเร็วกว่าเวลาของอีเธอเรียม 12 วินาทีมาก)

• “การเรียกใช้ GPU จำนวนหลายสิบในระยะเวลานาน 24/7” ไม่สามารถให้การรับรองความเป็นอยู่ที่เพียงพอ

• บางครั้งเวลาที่ใช้ในการสร้างพิสูจน์เชิงธุรกิจระบบยินดีกับขนาดของพิสูจน์ที่มากกว่า 1MB ทำให้มันใหญ่เกินไปสำหรับแอปพลิเคชันมากมาย

• "ค่าใช้จ่ายน้อยกว่า 1 ล้านดอลลาร์ต่อปี" เพียงเพราะโหนดเต็มของ Ethereum ทําการคํานวณได้เพียงประมาณ 25 ดอลลาร์ต่อปี

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

เป้าหมายพื้นฐานที่เราควรตั้งคือ: ค่าใช้จ่ายในการดำเนินการไม่เกิน 100,000 เท่าของการดำเนินการธรรมดา อย่างไรก็ตาม นี่เพียงเพียงเส้นทางแรก หากต้องการให้มันเป็นไปได้กับการใช้งานขนาดใหญ่ที่แท้จริง เราอาจจำเป็นต้องลดค่าใช้จ่ายลงไปถึง 10,000 เท่าของการดำเนินการธรรมดา หรือน้อยกว่านั้น

การวัดประสิทธิภาพ

SNARK ประสิทธิภาพประกอบด้วยส่วนประกอบหลัก 3 ส่วน

1. ประสิทธิภาพที่มั่นคงของระบบพิสูจน์ฐาน

2. การปรับแต่งสำหรับแอพพลิเคชั่นที่เฉพาะเจาะจง（เช่นการคอมไพล์ล่วงหน้า）

3. การเร่งเครื่องและฮาร์ดแวร์ (เช่น GPU、FPGA หรือ CPU หลายคอร์)

แม้ว่า (2) และ (3) จะสำคัญอย่างมากในการใช้งานจริง แต่พวกเขาเหมาะสำหรับระบบพิสูจน์อะไรก็ตาม ดังนั้น อาจจะไม่สามารถสะท้อนการปรับปรุงค่าใช้จ่ายพื้นฐาน ตัวอย่างเช่น การเพิ่ม GPU และการเตรียมรหัสล่วงหน้าใน zkEVM สามารถทำให้ความเร็วเพิ่มขึ้นถึง 50 เท่าโดยง่ายดายเมื่อเปรียบเทียบกับการพึ่ง CPU เท่านั้น - ซึ่งอาจทำให้ระบบที่มีประสิทธิภาพต่ำดูดีกว่าระบบอื่นที่ไม่ได้รับการปรับปรุงเดียวกัน

ดังนั้นบทความนี้มุ่งเน้นไปที่การวัดประสิทธิภาพพื้นฐานของ SNARKs โดยไม่ต้องใช้ฮาร์ดแวร์เฉพาะและ precompilation สิ่งนี้ตรงกันข้ามกับวิธีการเปรียบเทียบในปัจจุบันซึ่งโดยทั่วไปจะรวมปัจจัยทั้งสามเข้าด้วยกันเป็น "ค่าประชากร" เดียว มันเหมือนกับการตัดสินเพชรด้วยการขัดเงาเวลาแทนที่จะประเมินความชัดเจนโดยธรรมชาติ

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

ระยะสำคัญของประสิทธิภาพ

นี่คือขั้นตอนห้าขั้นตอนที่ฉันวางไว้ ต้องเริ่มแรก ลดค่าใช้จ่ายของผู้พิสูจน์บน CPU มากขึ้น ก่อนจึงสามารถพึ่งฮาร์ดแวร์เพิ่มเติม เช่นกัน การใช้หน่วยความจำต้องปรับปรุง

ในทุกขั้นตอน นักพัฒนาต้องไม่ปรับโค้ดเพื่อประสิทธิภาพของ zkVM ประสบการณ์ของนักพัฒนาเป็นข้อได้เปรียบหลักของ zkVM หากเสีย DevEx เพื่อทำให้ประสิทธิภาพตามเกณฑ์ ไม่เพียงเสียความหมายของการทดสอบเกณฑ์ แต่ยังล้มเลิกความตั้งใจแรกของ zkVM

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

ข้อกำหนดขั้นที่ 1: "ต้นทุนการตรวจสอบที่สมเหตุสมผลและไม่ธรรมดา"

• ขนาดพิสูจน์：ต้องเล็กกว่าขนาดพิสูจน์

• เวลาการยืนยัน：ความเร็วในการยืนยันการพิสูจน์ต้องไม่ช้ากว่าการปฏิบัติตามโปรแกรมเดิม (กล่าวคือ ไม่ควรช้ากว่าการดำเนินการคำนวณโดยตรง)

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

ขั้นตอน 2 ขึ้นไป

• ขนาดพิสูจน์สูงสุด：256 KB。

• เวลายืนยันสูงสุด：16 มิลลิวินาที。

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

ระยะทาง 1

การพิสูจน์ด้วยเส้นเดียวต้องไม่ช้ากว่าการดำเนินการธรรมชาติมากกว่า 100,000 เท่า (สำหรับหลายๆ แอปพลิเคชัน ไม่ใช่เฉพาะในการพิสูจน์บล็อกของอีเธอเรียน) และไม่ควรขึ้นอยู่กับการเตรียมรหัสล่วงหน้า

โดยเฉพาะในกรณีที่มีโปรเซสเซอร์ RISC-V บนโน๊ตบุ๊ครุ่นใหม่ทำงานด้วยความเร็วประมาณ 30 000 ล้านวงจรต่อวินาที การเข้าสู่ขั้นตอน 1 หมายความว่าโน๊ตบุ๊คนั้นสามารถสร้างการพิสูจน์ด้วยความเร็ว 30,000 รอบ RISC-V ต่อวินาที (เดี่ยว)

ต้นทุนของตัวตรวจสอบจะต้องตรงตามมาตรฐาน 'ต้นทุนการตรวจสอบที่เหมาะสมและไม่ธรรมดา' ที่กำหนดไว้ก่อนหน้านี้

ระยะทาง 2

การพิสูจน์แบบเฉพาะเส้นความเร็วต้องไม่ช้ากว่าการดำเนินการเชิงพื้นฐานมากกว่า 10,000 เท่า。

หรือเนื่องจากมีวิธี SNARK บางวิธีที่มีโอกาสสำคัญ (โดยเฉพาะ SNARK ในเขตบิต) ถูก CPU และ GPU ปัจจุบัน จำกัด อาจจะใช้ FPGA (และอาจจะ ASIC) ในช่วงนี้:

1. คำนวณจำนวนของเว็บ RISC-V ที่จำลองความเร็วของ FPGA

2. คำนวณการจำลองและการพิสูจน์จำนวน FPGA ที่จำเป็นสำหรับการดำเนินการ RISC-V (เกือบเรียลไทม์)

3. หากปริมาณของ (2) ไม่เกิน 10,000 เท่าของ (1) ให้ทำการอนุมัติขั้นตอนที่ 2

• ขนาดการพิสูจน์：ขนาดสูงสุด 256 KB。

• เวลาการยืนยัน：สูงสุด 16 มิลลิวินาทีบน CPU มาตรฐาน

ระยะ 3

บนพื้นฐานของขั้นตอนการเร่งความเร็ว 2 ให้เกิด ค่าใช้จ่ายในการพิสูจน์ในช่วง 1000× (สำหรับการใช้งานหลายรูปแบบ) และต้องใช้การสังเคราะห์และการตรวจสอบฟอร์มัลล์ล่วงหน้า โดยพื้นฐานแล้วเป็นการปรับแก้คำสั่งของแต่ละโปรแกรมเพื่อเพิ่มความเร็วในการสร้างพิสูจน์ แต่ต้องรักษาความง่ายในการใช้งานและการตรวจสอบฟอร์มัลล์ (เกี่ยวกับเหมืองซี้เป็นดาบสองคม และเหตุผลที่การเขียนล่วงหน้าเองไม่ใช่วิธีที่ยั่งยืน โปรดดูในส่วนถัดไป)

ขั้นตอนหน่วยความจำ 1

ในเชิงไว้ใจ 2 GB อย่างน้อย ระยะทาง 1 และตรงไปตามความต้องการที่เป็น ศึกษาศาสตร์ที่สำคัญ ขั้นนี้สำคัญอย่างยิ่งสำหรับอุปกรณ์เคลื่อนที่หรือเบราว์เซอร์ และเปิดโอกาสให้กับสถานการณ์มากมาย zkVM ของ client เช่น ใช้สมาร์ทโฟนเพื่อความเป็นส่วนตัวของตำแหน่ง รูปแบบการรับรองตัวตน ถ้าการสร้างสิ่งพิสูจน์ต้องการเกิน 1-2 GB หน่วยความจำ ส่วนมากของอุปกรณ์เคลื่อนที่จะไม่สามารถใช้งานได้

สองข้อความสำคัญ:

1. แม้จะเป็นการคำนวณขนาดใหญ่ (ที่ต้องใช้รอบ CPU หลายล้านล้านรอบ) ระบบพิสูจน์จำเป็นต้องรักษาขีดจำกัดหน่วยความจำที่ 2 GB มิฉะนั้นความเหมาะสมจะถูกจำกัด

2. หากพิสูจน์ได้ว่าความเร็วช้ามาก ควรรักษาขีดจำกัดหน่วยความจำที่ 2 GB ได้ง่ายมาก ดังนั้น เพื่อให้ขั้นตอนหน่วยความจำ 1 เป็นสาระ จำเป็นต้องใช้เวลาขั้นตอน 1 อยู่ภายในขีดจำกัดหน่วยความจำ 2 GB

ขั้นตอนหน่วยความจำ 2

ในเคสของหน่วยความจำน้อยกว่า 200 MB ในขั้นตอนความเร็ว 1 (เพิ่มขึ้น 10 เท่าในขั้นตอนหน่วยความจำ 1)

ทำไมต้องลดลงเหลือ 200 MB? พิจารณาสถานการณ์ที่ไม่ใช่บล็อกเชน : เมื่อคุณเข้าชมเว็บไซต์ที่ใช้ HTTPS คุณจะดาวน์โหลดใบรับรองและใบรับรองการเข้ารหัส หากเว็บไซต์เปลี่ยนเป็นการส่ง zk พิสูจน์ของใบรับรองเหล่านี้ อาจจำเป็นต้องสร้างพรู่พร้อมล้านใบรับรอง ต่อวินาทีสำหรับเว็บไซต์ขนาดใหญ่ หากแต่ละใบรับรองต้องใช้หน่วยความจำ 2 GB ความต้องการทรัพยากรสำหรับการคำนวณจะถึงระดับ PB ซึ่งเห็นได้ว่าไม่เป็นไปได้ ดังนั้น การลดการใช้หน่วยความจำต่อไปนั้นสำคัญมากสำหรับแอปพลิเคชันที่ไม่ใช่บล็อกเชน

การคอมไพล์ล่วงหน้า: จากด้านหลังไปยังขั้วสุดท้ายหรือไม่?

คอมไพล์ หมายถึง ระบบจำกัด SNARK ที่ถูกปรับแต่งอย่างเฉพาะเพื่อฟังก์ชันที่ระบุ (เช่นฮาช์ ลายนวมและลายเซ็นเวียนเข็ม) ในเอเธอเรี่ยม คอมไพล์สามารถลดค่าใช้จ่ายในการตรวจสอบ Merkle และการตรวจสอบลายเซ็น แต่การขึ้นอยู่กับคอมไพล์อย่างเสียนทนไม่สามารถเพิ่มประสิทธิภาพหลักของ SNARK ในที่สุด

ปัญหาการคอมไพล์ล่วงหน้า

1.ยังช้า：แม้ว่าจะใช้การเข้ารหัสแฮชและลายเซ็นก่อนคอมไพล์ ยังมีปัญหาประสิทธิภาพต่ำของระบบพิสูจน์แก้ไขในและนอกเหนือจากระบบบล็อกเชน

2. ช่องโหว่ในด้านความปลอดภัย：การเขียนล่วงหน้าด้วยมือหากไม่ได้รับการตรวจสอบแบบเชิงรูปแบบ ก็เป็นสิ่งที่แทบจะแน่ในการมีช่องโหว่ ซึ่งอาจส่งผลให้เกิดความล้มเหลวทางด้านความปลอดภัยที่มีลักษณะภัยร้าย****

3.ประสบการณ์นักพัฒนาไม่ดี：ในปัจจุบันมีการใช้ zkVM มากมายที่ต้องการนักพัฒนาเขียนระบบข้อจำกัดด้วยตนเอง คล้ายกับวิธีการเขียนโปรแกรมในยุค 1960 ที่ส่งผลกระทบอย่างร้ายแรงต่อประสบการณ์ในการพัฒนา

4.การทดสอบเบื้องต้นที่สร้างความสับสน: หากการทดสอบเบื้องต้นขึ้นอยู่กับการปรับแต่งพรีคอมไพล์ที่เฉพาะเจาะจง อาจสร้างความสับสนให้คนเน้นระบบจำกัดการปรับแต่งมือ ไม่ใช่การเพิ่มประสิทธิภาพของการออกแบบ SNARK ตัวเอง

5. ค่าใช้จ่ายในการเขียน/อ่านข้อมูลและการเข้าถึง RAM ขาดหาย การคอมไพล์ล่วงหน้าอาจเสริมประสิทธิภาพของงานเข้ารหัสที่มีน้ำหนักมาก แต่อาจไม่สามารถเพิ่มความเร็วได้สำหรับภาระงานที่หลากหลายมากขึ้น เนื่องจากมันสร้างค่าใช้จ่ายมากเมื่อมีข้อมูลนำเข้า/เอาออก และไม่สามารถใช้ RAM ได้

แม้จะอยู่ในสภาพแวดล้อมบล็อกเชน แต่เมื่อคุณเหนือระดับเช่นเอทีเธอเหมือน L1 เดียวกัน (เช่น คุณต้องการสร้างสะพาน跨ลายโซน) คุณจะพบกับฟังก์ชันแฮชและโครงการลายเซ็นต่างกัน ในการแก้ปัญหานี้โดยไม่ต้องคอมไพล์อย่างต่อเนื่อง สิ่งนี้ไม่สามารถขยายได้และมีความเสี่ยงด้านความปลอดภัยอย่างมาก

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

ตารางเวลาที่คาดหวัง

ฉันคาดว่า zkVM จะเข้าสู่ขั้นตอนความเร็ว 1 และขั้นตอนหน่วยความจำ 1 ในภายหลังปีนี้ ฉันเชื่อว่าเราสามารถทำให้ขั้นตอนความเร็ว 2 เกิดขึ้นในอีกสองปีข้างหน้า แต่ขณะนี้ยังไม่ชัดเจนว่าเราจะสามารถทำได้โดยไม่มีแนวคิดวิจัยใหม่

ฉันคาดว่าขั้นตอนที่เหลือ (** ขั้นตอนความเร็ว 3 ** และ ** ขั้นตอนหน่วยความจำ 2 **) จะใช้เวลาหลายปีในการประสบความสำเร็จ

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

zkVM มีศักยภาพที่มากในการทำให้การพิสูจน์ที่ไม่รู้เรื่องเป็นสิ่งที่แพร่หลายจริงๆ แต่ขณะนี้ยังอยู่ในช่วงเริ่มต้น - เต็มไปด้วยความท้าทายทางด้านความปลอดภัยและมีปัญหาด้านประสิทธิภาพอย่างมาก การตลาดและการโฆษณาทำให้มันยากต่อการวัดความคืบหน้าจริง ๆ ผ่านเกณฑ์ความปลอดภัยและประสิทธิภาพที่ชัดเจน ฉันหวังว่าจะสร้างแผนที่ที่ชัดเจนสามารถทำให้เราเข้าใจได้ดีขึ้น วันหนึ่งเราจะถึงเป้าหมาย แต่มันต้องใช้เวลาและความพยายามอย่างต่อเนื่องในการวิจัยและวิศวกรรม