บทความต้นฉบับจาก a16z crypto
เรียบเรียงโดย Odaily Planet Daily Golem ( @web3_golem )
zkVM (เครื่องเสมือนที่ไม่ต้องมีความรู้) สัญญาว่าจะ ทำให้ SNARK เป็นประชาธิปไตย โดยอนุญาตให้ทุกคน (แม้กระทั่งผู้ที่ไม่มีความเชี่ยวชาญเฉพาะด้าน SNARK) พิสูจน์ได้ว่าตนได้รันโปรแกรมใดๆ ได้อย่างถูกต้องบนอินพุตที่กำหนด (หรือเป็นพยาน) จุดแข็งหลักของพวกเขาอยู่ที่ประสบการณ์ของนักพัฒนา แต่ในปัจจุบันพวกเขาเผชิญกับความท้าทายมากมายทั้งในด้านความปลอดภัยและประสิทธิภาพการทำงาน เพื่อให้วิสัยทัศน์ของ zkVM บรรลุตามคำสัญญา นักออกแบบจะต้องเอาชนะความท้าทายเหล่านี้ ในโพสต์นี้ ฉันได้สรุปขั้นตอนที่เป็นไปได้ของการพัฒนา zkVM ที่อาจใช้เวลาหลายปีจึงจะเสร็จสมบูรณ์
ท้าทาย
ในแง่ของความปลอดภัย zkVM เป็นโครงการซอฟต์แวร์ที่มีความซับซ้อนสูงซึ่งยังคง เต็มไปด้วย ช่องโหว่มากมาย เมื่อพิจารณาถึงประสิทธิภาพการทำงาน การพิสูจน์ว่าโปรแกรมทำงานได้อย่างถูกต้องอาจจะช้ากว่าการรันโปรแกรมแบบดั้งเดิมหลายแสนเท่า ทำให้ปัจจุบันไม่สามารถนำแอปพลิเคชันส่วนใหญ่ไปใช้งานในโลกแห่งความเป็นจริงได้
แม้ว่าจะมีความท้าทายในทางปฏิบัติเหล่านี้ บริษัทส่วนใหญ่ในอุตสาหกรรมบล็อคเชนยังคงแสดงให้เห็นว่า zkVM พร้อมที่จะใช้งานได้ทันที ในความเป็นจริง โครงการบางส่วนได้จ่ายค่าใช้จ่ายด้านการคำนวณจำนวนมากเพื่อสร้างหลักฐานของกิจกรรมบนเครือข่ายไปแล้ว แต่เนื่องจาก zkVM ยังคงไม่สมบูรณ์แบบ นี่จึงเป็นเพียงวิธีที่มีราคาแพงในการแสร้งทำเป็นว่าระบบได้รับการปกป้องโดย SNARKs ในขณะที่ในความเป็นจริงแล้วระบบได้รับการปกป้องโดยการอนุญาต หรือแย่กว่านั้นคือเสี่ยงต่อการถูกโจมตี
เรายังต้องใช้เวลาหลายปีกว่าที่จะมี zkVM ที่ปลอดภัยและทำงานได้ดี โพสต์นี้เสนอเป้าหมายที่เป็นรูปธรรมและแบ่งระยะชุดหนึ่งเพื่อติดตามความคืบหน้าของ zkVM — เป้าหมายที่ทะลุกระแสและช่วยให้ชุมชนมุ่งเน้นไปที่ความคืบหน้าที่แท้จริง
ขั้นตอนการรักษาความปลอดภัย
โดยทั่วไป zkVM ที่ใช้ SNARK ประกอบด้วยส่วนประกอบหลักสองส่วน:
การพิสูจน์เหนือพหุนามแบบโต้ตอบ (PIOP) กรอบการพิสูจน์แบบโต้ตอบสำหรับการพิสูจน์ข้อความเกี่ยวกับพหุนาม (หรือข้อจำกัดที่ได้มาจากพหุนาม)
Polynomial Commitment Scheme (PCS): รับรองว่าผู้พิสูจน์ไม่สามารถโกหกเกี่ยวกับการประเมินพหุนามโดยไม่ถูกค้นพบ
โดยพื้นฐานแล้ว zkVM จะเข้ารหัสการติดตามการดำเนินการที่ถูกต้องเป็นระบบของข้อจำกัด ซึ่งหมายความว่าระบบจะบังคับใช้รีจิสเตอร์และหน่วยความจำที่ถูกต้องโดยเครื่องเสมือน และจากนั้นจึงใช้ SNARK เพื่อพิสูจน์ว่าข้อจำกัดเหล่านี้ได้รับการตอบสนอง
วิธีเดียวที่จะแน่ใจได้ว่าระบบที่ซับซ้อนเช่น zkVM ไม่มีข้อบกพร่องก็คือ การตรวจสอบอย่างเป็นทางการ ต่อไปนี้เป็นรายละเอียดของขั้นตอนการรักษาความปลอดภัย เฟสที่ 1 มุ่งเน้นไปที่โปรโตคอลที่ถูกต้อง ในขณะที่เฟสที่ 2 และ 3 มุ่งเน้นไปที่การใช้งานที่ถูกต้อง
ขั้นตอนการรักษาความปลอดภัย 1: โปรโตคอลที่ถูกต้อง
หลักฐานการตรวจสอบอย่างเป็นทางการของความน่าเชื่อถือของ PIOP
PCS มีการพิสูจน์ยืนยันทางการผูกมัดภายใต้สมมติฐานการเข้ารหัสบางประการหรือแบบจำลองในอุดมคติ
ถ้ามีการใช้ Fiat-Shamir ข้อโต้แย้งสั้น ๆ ที่ได้จากการรวม PIOP และ PCS เข้าด้วยกันจะได้รับการยืนยันอย่างเป็นทางการว่าปลอดภัยในแบบจำลองโอราเคิลสุ่ม (โดยเสริมด้วยสมมติฐานการเข้ารหัสอื่น ๆ ตามต้องการ)
ระบบข้อจำกัดที่ใช้โดย PIOP เทียบเท่ากับหลักฐานการตรวจสอบอย่างเป็นทางการของความหมายของ VM
ชิ้นส่วนทั้งหมดเหล่านี้ถูก ติดกาว เข้าด้วยกันอย่างสมบูรณ์เป็นหลักฐาน 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 จึงขึ้นอยู่กับวิธีการในการสร้างไบต์โค้ดที่ได้รับการตรวจยืนยันอย่างเป็นทางการ ซึ่งเป็นความท้าทายครั้งใหญ่ที่เกินขอบเขตของเอกสารฉบับนี้
ด้านความปลอดภัยในยุคหลังควอนตัม
คอมพิวเตอร์ควอนตัมจะไม่ก่อให้เกิดภัยคุกคามร้ายแรงในช่วงอย่างน้อย 5 ปีข้างหน้า ( และอาจจะนานกว่านั้น ) ในขณะที่ช่องโหว่ต่างๆ ยังคงเป็นความเสี่ยงต่อการดำรงอยู่ ดังนั้น ตอนนี้ประเด็นหลักควรอยู่ที่การบรรลุเป้าหมายด้านความปลอดภัยและประสิทธิภาพการทำงานตามที่กล่าวถึงในบทความนี้ หากเราสามารถปฏิบัติตามข้อกำหนดด้านความปลอดภัยเหล่านี้ได้เร็วขึ้นโดยใช้ SNARK ที่ไม่ปลอดภัยต่อควอนตัม เราก็ควรทำอย่างนั้นจนกว่า SNARK หลังควอนตัมจะตามทัน หรือจนกว่าผู้คนจะเริ่มกังวลอย่างจริงจังเกี่ยวกับคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับการเข้ารหัส ก่อนที่จะพิจารณาทางเลือกอื่น
ประสิทธิภาพปัจจุบันของ zkVM
ในปัจจุบัน ปัจจัยค่าใช้จ่ายที่เกิดขึ้นจากการพิสูจน์ zkVM อยู่ที่ประมาณ 1 ล้านเท่าของต้นทุนการดำเนินการดั้งเดิม หากโปรแกรมใช้เวลาทำงาน X รอบ ค่าใช้จ่ายในการพิสูจน์การทำงานที่ถูกต้องจะอยู่ที่ประมาณ X เท่าของ 1 ล้านรอบ CPU นี่เป็นกรณีเดียวกัน เมื่อปีที่แล้ว และยังคงเป็นกรณีเดียวกันจนถึงทุกวันนี้
เรื่องเล่าที่เป็นที่นิยมมักอธิบายถึงการใช้จ่ายนี้ในลักษณะที่ฟังดูเป็นที่ยอมรับได้ ตัวอย่างเช่น:
“การสร้างหลักฐานสำหรับเครือข่ายหลัก Ethereum ทั้งหมดมีค่าใช้จ่ายน้อยกว่าหนึ่งล้านดอลลาร์ต่อปี”
“เราสามารถสร้างบล็อกพิสูจน์ Ethereum ได้แทบจะเรียลไทม์ด้วยการใช้คลัสเตอร์ GPU หลายสิบตัว”
“zkVM รุ่นล่าสุดของเราเร็วกว่ารุ่นก่อนหน้าถึง 1,000 เท่า”
แม้ในทางเทคนิคแล้วข้อกล่าวอ้างเหล่านี้จะถูกต้อง แต่ก็อาจทำให้เกิดความเข้าใจผิดได้หากไม่มีบริบทที่เหมาะสม ตัวอย่างเช่น:
เร็วกว่า zkVM รุ่นเก่าถึง 1,000 เท่า แต่ยังคงช้ามากเมื่อพิจารณาจากค่าพื้นฐาน นั่นบ่งบอกได้มากกว่าว่าสิ่งต่างๆ แย่แค่ไหน มากกว่าจะดีแค่ไหน
มี ข้อเสนอที่จะ เพิ่มปริมาณการคำนวณที่ Ethereum mainnet สามารถจัดการได้ 10 เท่า ซึ่งจะทำให้ประสิทธิภาพของ zkVM ในปัจจุบันช้าลงไปอีก
สิ่งที่ผู้คนเรียกว่า การพิสูจน์การถือครองแบบเกือบเรียลไทม์สำหรับบล็อค Ethereum ยังคงช้ากว่าที่แอปพลิเคชันบล็อคเชนจำนวนมากต้องการมาก (ตัวอย่างเช่น เวลาบล็อค 2 วินาทีของ Optimism เร็วกว่าเวลาบล็อค 12 วินาทีของ Ethereum มาก)
“GPU หลายสิบตัวทำงานตลอดเวลาโดยไม่เคยล้มเหลว” ไม่สามารถรับประกันความพร้อมใช้งานที่ยอมรับได้
ความจริงที่ว่ามีค่าใช้จ่ายน้อยกว่าหนึ่งล้านเหรียญสหรัฐต่อปีในการพิสูจน์กิจกรรมทั้งหมดบนเครือข่ายหลักของ Ethereum สะท้อนให้เห็นถึงความจริงที่ว่าโหนดเต็มของ Ethereum มีค่าใช้จ่ายเพียงประมาณ 25 เหรียญสหรัฐต่อปีในการดำเนินการคำนวณเท่านั้น
สำหรับแอปพลิเคชันอื่นนอกเหนือจากบล็อคเชน ค่าใช้จ่ายเบื้องต้นถือว่าสูงเกินไปอย่างเห็นได้ชัด ไม่ว่าจะใช้การประมวลผลแบบคู่ขนานหรือวิศวกรรมใดๆ ก็ไม่สามารถชดเชยค่าใช้จ่ายมหาศาลเช่นนี้ได้ เราควรตั้งเป้าหมายให้ zkVM อยู่ในเกณฑ์พื้นฐานที่ไม่ช้ากว่า 100,000 เท่าเมื่อเทียบกับการทำงานแบบเนทีฟ แม้ว่านี่จะเป็นเพียงขั้นตอนแรกก็ตาม การนำไปใช้อย่างกระแสหลักอย่างแท้จริงอาจต้องใช้ค่าใช้จ่ายเบื้องต้นที่ใกล้เคียง 10,000 เท่าหรือต่ำกว่านั้น
วิธีการวัดประสิทธิภาพ
ประสิทธิภาพของ SNARK มีองค์ประกอบหลัก 3 ประการ:
ประสิทธิภาพโดยธรรมชาติของระบบพิสูจน์พื้นฐาน
การเพิ่มประสิทธิภาพเฉพาะแอปพลิเคชั่น (เช่น การคอมไพล์ล่วงหน้า)
การวิศวกรรมและการเร่งความเร็วด้วยฮาร์ดแวร์ (เช่น GPU, FPGA หรือ CPU แบบหลายคอร์)
แม้ว่าสองสิ่งหลังจะมีความสำคัญต่อการใช้งานจริง แต่ก็สามารถนำไปใช้กับระบบพิสูจน์ใดๆ ก็ได้ ดังนั้นจึงอาจไม่สะท้อน ค่าใช้จ่ายเบื้องต้น ตัวอย่างเช่น การเพิ่มการเร่งความเร็ว GPU และการคอมไพล์ล่วงหน้าให้กับ zkEVM สามารถเพิ่มประสิทธิภาพได้ถึง 50 เท่าเมื่อเทียบกับวิธีการที่ใช้ CPU เพียงอย่างเดียวโดยไม่ต้องคอมไพล์ล่วงหน้า ซึ่งเพียงพอที่จะทำให้ระบบที่มีประสิทธิภาพน้อยกว่าโดยเนื้อแท้ดูดีกว่าระบบที่ไม่ได้รับการปรับแต่งในลักษณะเดียวกัน
ดังนั้น ต่อไปนี้จึงมุ่งเน้นไปที่ประสิทธิภาพของ SNARKs โดยไม่ต้องใช้ฮาร์ดแวร์เฉพาะและการคอมไพล์ล่วงหน้า วิธีนี้จะแตกต่างจากวิธีการประเมินประสิทธิภาพในปัจจุบัน ซึ่งโดยทั่วไปจะรวบรวมปัจจัยทั้งสามประการเข้าเป็น ตัวเลขหลัก ตัวเดียว สิ่งนี้เทียบเท่ากับการตัดสินมูลค่าของเพชรโดยดูจากระยะเวลาในการขัดมากกว่าความใสตามธรรมชาติ เป้าหมายของเราคือการลบค่าใช้จ่ายโดยธรรมชาติของระบบพิสูจน์วัตถุประสงค์ทั่วไป ช่วยให้ชุมชนลบความยุ่งยากและมุ่งเน้นไปที่ความคืบหน้าที่แท้จริงในการออกแบบระบบพิสูจน์
ระยะการแสดง
นี่คือเป้าหมายด้านประสิทธิภาพ 5 ประการที่บรรลุผล ประการแรก เราต้องลดค่าใช้จ่ายการพิสูจน์บน CPU ลงให้ได้มากที่สุด จากนั้นจึงควรเน้นไปที่การลดค่าใช้จ่ายเพิ่มเติมผ่านฮาร์ดแวร์ การใช้หน่วยความจำยังต้องได้รับการปรับปรุงด้วย
ในขั้นตอนต่อไปนี้ทั้งหมด นักพัฒนาไม่จำเป็นต้องตั้งค่าโค้ดที่กำหนดเองตาม zkVM เพื่อให้ได้ประสิทธิภาพที่จำเป็น ประสบการณ์ของนักพัฒนาเป็นข้อได้เปรียบหลักของ zkVM การเสียสละ DevEx เพื่อให้ตรงตามเกณฑ์ประสิทธิภาพจะขัดต่อจุดประสงค์ของ zkVM เอง
ตัวชี้วัดเหล่านี้มุ่งเน้นไปที่ต้นทุนการพิสูจน์ อย่างไรก็ตาม หากอนุญาตให้มีค่าใช้จ่ายของผู้ตรวจสอบที่ไม่จำกัด (นั่นคือ ไม่มีขอบเขตบนของขนาดการพิสูจน์หรือเวลาในการตรวจสอบ) ก็สามารถบรรลุเกณฑ์ผู้พิสูจน์ใดๆ ได้อย่างง่ายดาย ดังนั้นเพื่อให้ระบบปฏิบัติตามขั้นตอนที่ได้อธิบายไว้ จำเป็นต้องระบุค่าสูงสุดสำหรับขนาดการพิสูจน์และเวลาในการตรวจสอบ
ข้อกำหนดด้านประสิทธิภาพ
ข้อกำหนดในเฟสที่ 1: “ต้นทุนการตรวจสอบที่สมเหตุสมผลและไม่สำคัญ”:
ขนาดการพิสูจน์: ขนาดการพิสูจน์จะต้องมีขนาดเล็กกว่าขนาดของพยาน
เวลาตรวจสอบ: การตรวจสอบการพิสูจน์จะต้องไม่ช้าไปกว่าการรันโปรแกรมแบบดั้งเดิม (นั่นคือ การดำเนินการคำนวณโดยไม่มีการพิสูจน์ความถูกต้อง)
เหล่านี้เป็นข้อกำหนดขั้นต่ำ พวกเขาจะมั่นใจว่าขนาดของหลักฐานและระยะเวลาในการตรวจสอบไม่เลวร้ายไปกว่าการส่งพยานไปยังผู้ตรวจสอบและให้ผู้ตรวจสอบตรวจสอบความถูกต้องโดยตรง
ข้อกำหนดขั้นที่ 2 และขั้นถัดไป:
ขนาดหลักฐานสูงสุด: 256 KB.
เวลาตรวจสอบสูงสุด: 16 มิลลิวินาที
เกณฑ์ตัดสินเหล่านี้มีไว้เพื่อให้มีขนาดใหญ่ขึ้นโดยตั้งใจเพื่อรองรับเทคนิคการพิสูจน์อย่างรวดเร็วแบบใหม่ซึ่งอาจมีต้นทุนการตรวจสอบที่สูงขึ้น ในเวลาเดียวกัน พวกเขายังยกเว้นหลักฐานที่มีราคาแพงมากจนมีเพียงไม่กี่โครงการที่ยินดีจะรวมไว้ในบล็อคเชนของพวกเขา
ระดับความเร็ว 1
การพิสูจน์แบบเธรดเดียวต้องช้ากว่าการดำเนินการแบบเนทีฟมากถึงหนึ่งแสนเท่า โดยวัดจากแอพพลิเคชั่นต่างๆ (ไม่ใช่แค่พิสูจน์บล็อก 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 ทำได้โดยใช้หน่วยความจำน้อยกว่า 200 MB (ดีกว่าเฟส 1 ในหน่วยความจำถึง 10 เท่า)
เหตุใดจึงดันต่ำกว่า 2GB? ลองพิจารณาตัวอย่างที่ไม่ใช่บล็อคเชน: ทุกครั้งที่คุณเข้าถึงเว็บไซต์ผ่าน HTTPS คุณจะดาวน์โหลดใบรับรองสำหรับการรับรองความถูกต้องและการเข้ารหัส เว็บไซต์สามารถส่งหลักฐาน zk เพื่อแสดงว่าพวกเขาเป็นเจ้าของใบรับรองเหล่านี้ได้ เว็บไซต์ขนาดใหญ่อาจออกหลักฐานเหล่านี้หลายล้านฉบับต่อวินาที หากการพิสูจน์แต่ละครั้งต้องใช้หน่วยความจำ 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 มีศักยภาพในการทำให้การพิสูจน์ความรู้เป็นศูนย์แพร่หลายอย่างแท้จริง แต่การพิสูจน์เหล่านี้ยังอยู่ในช่วงเริ่มต้น ซึ่งเต็มไปด้วยความท้าทายด้านความปลอดภัยและค่าใช้จ่ายด้านประสิทธิภาพที่สำคัญ การสร้างกระแสและการโฆษณาชวนเชื่อทางการตลาดทำให้การประเมินความคืบหน้าที่แท้จริงเป็นเรื่องยาก เราหวังว่าจะจัดทำแผนงานเพื่อขจัดสิ่งรบกวน โดยการกำหนดหลักชัยด้านความปลอดภัยและประสิทธิภาพที่ชัดเจน เราจะไปถึงที่นั่นได้ แต่ต้องใช้เวลาและความพยายามอย่างต่อเนื่อง
