ชื่อเรื่องเดิม: เส้นทางสู่ zkVMs ที่ปลอดภัยและมีประสิทธิภาพ: วิธีการติดตามความคืบหน้า

ผู้เขียนเดิม: a16z crypto

การแปลเดิม: Golem, Odaily Planet Daily

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

ความท้าทาย

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

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

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

เฟสการรักษาความปลอดภัย

zkVM ที่ใช้ SNARK มักประกอบด้วยส่วนประกอบหลักสองส่วน:

· Interactive Oracle Proofs over Polynomials (PIOP): กรอบงานการพิสูจน์แบบโต้ตอบสำหรับการพิสูจน์ข้อความเกี่ยวกับพหุนาม (หรือข้อจำกัดที่ได้มาจากพหุนาม)

· โครงการมุ่งมั่นพหุนาม (PCS): ช่วยให้แน่ใจว่าผู้พิสูจน์ไม่สามารถโกหกเกี่ยวกับการประเมินพหุนามโดยไม่ถูกค้นพบ

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

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

1. หลักฐานการตรวจสอบอย่างเป็นทางการของความถูกต้องของ PIOP;

2. หลักฐานการตรวจสอบอย่างเป็นทางการว่า PCS มีผลผูกพันภายใต้สมมติฐานการเข้ารหัสบางอย่างหรือรูปแบบในอุดมคติ;

3. หลักฐานการตรวจสอบอย่างเป็นทางการว่าอาร์กิวเมนต์สั้น ๆ ที่ได้จากการรวม PIOP และ PCS เข้าด้วยกันนั้นปลอดภัยในแบบจำลองโอราเคิลแบบสุ่มหากใช้ Fiat-Shamir (เสริมด้วยสมมติฐานการเข้ารหัสอื่น ๆ ตามความจำเป็น);

4. หลักฐานการตรวจสอบอย่างเป็นทางการว่าระบบข้อจำกัดที่ใช้โดย PIOP นั้นเทียบเท่ากับความหมายของ VM;

5. การ "เชื่อม" ส่วนทั้งหมดข้างต้นเข้าด้วยกันอย่างครอบคลุมเป็นหลักฐาน SNARK ที่ปลอดภัยซึ่งได้รับการตรวจสอบอย่างเป็นทางการเพียงชิ้นเดียว ซึ่งสามารถใช้เพื่อเรียกใช้โปรแกรมใด ๆ ที่ระบุโดยไบต์โค้ดของ VM หากโปรโตคอลตั้งใจที่จะบรรลุถึงความรู้เป็นศูนย์ คุณสมบัติจะต้องได้รับการตรวจยืนยันอย่างเป็นทางการด้วยเพื่อให้มั่นใจว่าข้อมูลที่ละเอียดอ่อนเกี่ยวกับพยานจะไม่รั่วไหล

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

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

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

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

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

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

· ความคืบหน้าในเฟส 1:เราคาดว่าจะเห็นถึงความสำเร็จที่เพิ่มขึ้น (เช่น ZKLib) ภายในปีหน้า แต่ไม่มี zkVM ใดที่จะตอบสนองข้อกำหนดของเฟส 1 ได้อย่างสมบูรณ์เป็นเวลาอย่างน้อยสองปี;

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

หมายเหตุสำคัญ: ความปลอดภัยของ Fiat-Shamir และไบต์โค้ดที่ได้รับการตรวจสอบ

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

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

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

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

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

สถานะประสิทธิภาพของ ZkVM

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

เรื่องเล่าที่เป็นที่นิยมมักจะพรรณนาถึงการใช้จ่ายนี้ในลักษณะที่ฟังดูเป็นที่ยอมรับได้ ตัวอย่าง: · “การสร้างหลักฐานสำหรับเครือข่ายหลัก Ethereum ทั้งหมดมีค่าใช้จ่ายน้อยกว่าหนึ่งล้านเหรียญสหรัฐต่อปี” · “เราสามารถสร้างหลักฐานบล็อก Ethereum ได้ในเวลาจริงโดยใช้คลัสเตอร์ GPU หลายสิบตัว” · “zkVM รุ่นล่าสุดของเราเร็วกว่ารุ่นก่อนถึง 1,000 เท่า” · ถึงแม้ในทางเทคนิคจะแม่นยำ แต่ข้อกล่าวอ้างเหล่านี้อาจทำให้เข้าใจผิดได้หากไม่มีบริบทที่เหมาะสม ตัวอย่าง:

· เร็วกว่า zkVM รุ่นเก่าถึง 1,000 เท่า แต่ยังคงช้ามากเมื่อพิจารณาจากค่าสัมบูรณ์ นั่นบ่งบอกได้มากกว่าว่าสิ่งต่างๆ แย่แค่ไหน มากกว่าจะดีแค่ไหน

· มีข้อเสนอที่จะเพิ่มปริมาณการคำนวณที่ Ethereum mainnet สามารถจัดการได้เป็น 10 เท่า ซึ่งจะทำให้ประสิทธิภาพของ zkVM ในปัจจุบันช้าลงไปอีก

· สิ่งที่ผู้คนเรียกว่า “การพิสูจน์การถือครองแบบเกือบเรียลไทม์สำหรับบล็อค Ethereum” ยังคงช้ากว่าที่แอปพลิเคชันบล็อคเชนจำนวนมากต้องการมาก (ตัวอย่างเช่น เวลาบล็อคของ Optimism ที่ 2 วินาทีนั้นเร็วกว่าเวลาบล็อคของ Ethereum ที่ 12 วินาทีมาก)

· “GPU หลายสิบตัวทำงานตลอดเวลาโดยไม่มีข้อผิดพลาด” ไม่สามารถรับประกันความมีชีวิตที่ยอมรับได้

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

สำหรับแอปพลิเคชันอื่นนอกเหนือจากบล็อคเชน ค่าใช้จ่ายเบื้องต้นถือว่าสูงเกินไปอย่างเห็นได้ชัด ไม่ว่าจะใช้การประมวลผลแบบคู่ขนานหรือวิศวกรรมใดๆ ก็ไม่สามารถชดเชยค่าใช้จ่ายมหาศาลเช่นนี้ได้ เราควรตั้งเป้าหมายให้ zkVM อยู่ในเกณฑ์พื้นฐานที่ไม่ช้ากว่า 100,000 เท่าเมื่อเทียบกับการทำงานแบบเนทีฟ แม้ว่านี่จะเป็นเพียงขั้นตอนแรกก็ตาม การนำไปใช้อย่างกระแสหลักอย่างแท้จริงอาจต้องใช้ค่าใช้จ่ายเบื้องต้นที่ใกล้เคียง 10,000 เท่าหรือต่ำกว่านั้น

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

ประสิทธิภาพของ SNARK มีองค์ประกอบหลักสามประการ:

· ประสิทธิภาพโดยธรรมชาติของระบบพิสูจน์พื้นฐาน

· การเพิ่มประสิทธิภาพเฉพาะแอปพลิเคชั่น (เช่น การคอมไพล์ล่วงหน้า)

· การเร่งความเร็วทางวิศวกรรมและฮาร์ดแวร์ (เช่น GPU, FPGA หรือ CPU แบบหลายคอร์)

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

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

ขั้นตอนการดำเนินงาน

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

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

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

ข้อกำหนดด้านประสิทธิภาพ

ข้อกำหนดในเฟสที่ 1: “ต้นทุนการตรวจสอบที่สมเหตุสมผลและไม่ใช่เรื่องเล็กน้อย”:

· ขนาดการพิสูจน์: ขนาดการพิสูจน์จะต้องมีขนาดเล็กกว่าขนาดของพยาน

· เวลาในการตรวจสอบ: การตรวจสอบการพิสูจน์จะต้องไม่ช้าไปกว่าการรันโปรแกรมดั้งเดิม (นั่นคือ การดำเนินการคำนวณโดยไม่มีการพิสูจน์ความถูกต้อง)

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

ข้อกำหนดเฟส 2 และต่อๆ ไป:

· ขนาดหลักฐานสูงสุด: 256 KB

· เวลาตรวจสอบสูงสุด: 16 มิลลิวินาที

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

ความเร็ว เฟสที่ 1

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

เพื่อให้เข้าใจในบริบทนี้ ลองนึกถึงกระบวนการ RISC-V ที่ทำงานด้วยความเร็วประมาณ 3 พันล้านรอบต่อวินาทีบนแล็ปท็อปสมัยใหม่ การบรรลุระยะที่ 1 หมายความว่าคุณสามารถสาธิตรอบ RISC-V ได้ประมาณ 30,000 รอบต่อวินาที (เธรดเดี่ยว) บนแล็ปท็อปเครื่องเดียวกันได้ แต่ต้นทุนการตรวจสอบจะต้อง "สมเหตุสมผลและไม่แพง" ดังที่กล่าวมาข้างต้น

ความเร็ว เฟสที่ 2

การพิสูจน์แบบเธรดเดียวต้องช้ากว่าการดำเนินการแบบเนทีฟถึงหนึ่งหมื่นเท่า

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

จำนวนคอร์ RISC-V ที่ FPGA สามารถเลียนแบบได้ด้วยความเร็วเนทีฟ;

จำนวน FPGA ที่จำเป็นในการจำลองและพิสูจน์การทำงาน (เกือบ) เรียลไทม์ของ RISC-V

หากอย่างหลังมากกว่าอย่างแรกไม่เกิน 10,000 เท่า คุณจะมีสิทธิ์เข้าร่วมเฟส 2 บน CPU มาตรฐาน ขนาดการพิสูจน์ต้องมีขนาดไม่เกิน 256 KB และระยะเวลาการตรวจสอบต้องมีขนาดไม่เกิน 16 มิลลิวินาที

ความเร็วขั้นที่ 3

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

หน่วยความจำเฟสที่ 1

ความเร็วของเฟสที่ 1 ทำได้ในขณะที่ต้องใช้หน่วยความจำน้อยกว่า 2 GB สำหรับผู้พิสูจน์ (ขณะที่ยังได้รับความรู้เป็นศูนย์)

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

· ข้อจำกัดพื้นที่ 2 GB นั้นใช้กับคำสั่งขนาดใหญ่ (คำสั่งที่ต้องใช้รอบ CPU หลายล้านล้านรอบในการรันภายในเครื่อง) ระบบพิสูจน์ที่ใช้ขอบเขตของพื้นที่สำหรับข้อความขนาดเล็กเท่านั้นขาดการบังคับใช้อย่างกว้างขวาง

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

หน่วยความจำขั้นที่ 2

ความเร็วของขั้นที่ 1 ทำได้โดยใช้หน่วยความจำน้อยกว่า 200MB (ดีกว่าหน่วยความจำขั้นที่ 1 ถึง 10 เท่า)

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

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

· ความล้มเหลวด้านความปลอดภัย:การคอมไพล์ล่วงหน้าที่เขียนด้วยลายมือซึ่งยังไม่ผ่านการตรวจสอบอย่างเป็นทางการนั้นแทบจะแน่นอนว่าเต็มไปด้วยจุดบกพร่องที่อาจนำไปสู่ความล้มเหลวด้านความปลอดภัยที่ร้ายแรงได้

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

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

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

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

ฉันคาดหวังว่า zkVM จำนวนหนึ่งจะเข้าถึงเฟส 1 ด้านความเร็วและเฟส 1 ด้านหน่วยความจำในช่วงปลายปีนี้ ฉันคิดว่าเราจะไปถึง Speed Phase 2 ได้ในอีกสองปีข้างหน้านี้เช่นกัน แต่ยังไม่ชัดเจนว่าเราจะไปถึงจุดนั้นได้หรือไม่หากไม่มีไอเดียใหม่ๆ ที่ยังไม่ได้เกิดขึ้น คาดว่าเฟสที่เหลือ (เฟส 3 ความเร็ว และเฟส 2 หน่วยความจำ) จะใช้เวลาหลายปีจึงจะบรรลุเป้าหมาย

สรุป

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

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

ลิงก์ต้นฉบับ

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia