Vitalik: อนาคตของ ZK-EVM ประเภทต่างๆ
ชื่อเรื่องเดิม: "The different types of ZK-EVMs》
ผู้เขียนต้นฉบับ: Vitalik
การรวบรวมต้นฉบับ: บล็อกยูนิคอร์น
ชื่อเรื่องเดิม: "
ผู้เขียนต้นฉบับ: Vitalik
การรวบรวมต้นฉบับ: บล็อกยูนิคอร์น
เมื่อเร็ว ๆ นี้มีการประกาศรายละเอียดสูงมากมายจากโครงการ "ZK-EVM" Polygon เปิดซอร์สโครงการ ZK-EVM ของพวกเขา ZKSync เปิดตัวแผน ZKSync 2.0 และ Scroll ที่ค่อนข้างใหม่เพิ่งเปิดตัว ZK-EVM ของพวกเขา นอกจากนี้ยังมีความพยายามอย่างต่อเนื่องจากทีม Privacy and Extended Exploration ทีมงานของ Nicolas Liochon และคณะ ตั้งแต่ EVM ไปจนถึงอัลฟ่าคอมไพเลอร์สำหรับภาษาไคโรที่เป็นมิตรกับ zk ของ Starkware และแน่นอนว่ามีบางโปรเจ็กต์ที่ฉันพลาดไป
เป้าหมายหลักของโครงการทั้งหมดเหล่านี้เหมือนกัน: ใช้เทคโนโลยี ZK-SNARK เพื่อพิสูจน์การทำธุรกรรมที่คล้ายกับ Ethereum แบบเข้ารหัส ทำให้ง่ายต่อการตรวจสอบห่วงโซ่ Ethereum หรือสร้างเนื้อหาที่คล้ายกับที่ Ethereum ให้บริการ (ใกล้เคียง) เหมือนกันแต่มากกว่า การยกเลิก zk ที่ปรับขนาดได้ แต่มีความแตกต่างเล็กน้อยระหว่างโครงการเหล่านี้ และการประนีประนอมระหว่างประโยชน์ใช้สอยและความเร็ว โพสต์นี้จะพยายามอธิบายอนุกรมวิธานของ "ประเภท" ต่างๆ ของความเท่าเทียมกันของ EVM และประโยชน์และต้นทุนของการพยายามใช้แต่ละอย่าง
ภาพรวม (รูปแบบไดอะแกรม)
ประเภท 1 (เทียบเท่ากับ Ethereum อย่างสมบูรณ์)
ZK-EVM ประเภทแรกมุ่งมั่นที่จะเทียบเท่ากับ Ethereum อย่างสมบูรณ์และแน่วแน่ พวกเขาไม่เปลี่ยนแปลงส่วนใด ๆ ของระบบ Ethereum เพื่อทำให้การพิสูจน์ง่ายขึ้น พวกเขาไม่ได้แทนที่แฮช ต้นไม้สถานะ ต้นไม้ธุรกรรม การคอมไพล์ล่วงหน้า หรือตรรกะที่สอดคล้องกันอื่นใด ไม่ว่ามันจะเป็นอุปกรณ์ต่อพ่วงแค่ไหนก็ตาม
ข้อได้เปรียบ: ความเข้ากันได้ที่สมบูรณ์แบบ
เป้าหมายของเราคือสามารถตรวจสอบบล็อก Ethereum ได้เหมือนที่เราทำอยู่ในขณะนี้ หรืออย่างน้อยก็ในชั้นของการดำเนินการ (ดังนั้นจึงไม่รวมตรรกะฉันทามติของห่วงโซ่บีคอน แต่รวมการดำเนินการธุรกรรมและสัญญาอัจฉริยะและตรรกะของบัญชีทั้งหมดไว้ด้วย)
ประเภทที่ 1: ZK-EVM คือสิ่งที่เราต้องการในท้ายที่สุดเพื่อทำให้อีเธอร์เน็ตเลเยอร์ 1 สามารถปรับขนาดได้มากขึ้น ในระยะยาว การดัดแปลงอีเทอร์ที่ทดสอบใน ZK-EVM ประเภท 2 หรือประเภท 3 อาจถูกนำมาใช้ในอีเทอร์เอง แต่การออกแบบใหม่ดังกล่าวมาพร้อมกับความซับซ้อนในตัวของมันเอง
ประเภทที่ 1: ZK-EVM ยังเหมาะสำหรับการโรลอัพ เนื่องจากช่วยให้การโรลอัพสามารถนำโครงสร้างพื้นฐานจำนวนมากกลับมาใช้ใหม่ได้ ตัวอย่างเช่น ไคลเอนต์ Etherum Execution สามารถใช้ตามที่เป็นอยู่เพื่อสร้างและประมวลผลบล็อก ROLLUP (หรืออย่างน้อย ก็สามารถนำมาใช้ซ้ำได้เมื่อมีการเรียกใช้งาน และฟังก์ชันนั้นสามารถนำมาใช้ซ้ำได้เพื่อรองรับการฝาก ETH ลงใน ROLLUP) ดังนั้นบล็อกทรัพยากร เครื่องมือต่างๆ เช่น ผู้จัดการ บล็อกการผลิต ฯลฯ นั้นง่ายต่อการนำกลับมาใช้ใหม่
ข้อเสีย: เวลาตรวจสอบ
เดิมที Ethereum ไม่ได้ออกแบบมาให้เป็นมิตรกับ zk ดังนั้นหลายส่วนของโปรโตคอล ethereum จึงต้องการการคำนวณจำนวนมากเพื่อตรวจสอบ zk ประเภทที่ 1 มีจุดมุ่งหมายเพื่อจำลอง Ethereum ทุกประการ ดังนั้นจึงไม่มีทางที่จะลดความไร้ประสิทธิภาพเหล่านี้ได้ ปัจจุบัน การพิสูจน์บล็อก Ethereum ต้องใช้เวลาหลายชั่วโมงในการสร้าง สถานการณ์นี้สามารถบรรเทาลงได้ด้วยวิศวกรรมที่ชาญฉลาดเพื่อทำให้เครื่องตรวจสอบขนานขนานกันอย่างมาก หรือในระยะยาวด้วย ZK-SNARK ASICs
ใครเป็นคนสร้าง?
ทีมสำรวจความเป็นส่วนตัวและการปรับขนาด ZK-EVM กำลังสร้าง Type 1 ZK-EVM
ประเภท 2 (เทียบเท่า EVM อย่างสมบูรณ์)
ประเภทที่สองของ ZK - EVM มุ่งมั่นที่จะเทียบเท่ากับ EVM อย่างสมบูรณ์ แต่ไม่เทียบเท่ากับ Ethereum โดยสมบูรณ์ นั่นคือ พวกมันดูเหมือน Ethereum "จากภายใน" ทุกประการ แต่พวกมันมีความแตกต่างบางอย่างจากภายนอก โดยเฉพาะอย่างยิ่งในโครงสร้างข้อมูล เช่น โครงสร้างบล็อกและแผนผังสถานะ
เป้าหมายคือการเข้ากันได้กับแอปพลิเคชันที่มีอยู่อย่างสมบูรณ์ แต่มีการดัดแปลงเล็กน้อยสำหรับ Ethereum เพื่อให้การพัฒนาง่ายขึ้นและสร้างการพิสูจน์ได้เร็วขึ้น
ข้อได้เปรียบ: เพียร์ทูเพียร์เต็มรูปแบบในระดับเครื่องเสมือน
ประเภทที่ 2 ZK-EVM ทำการเปลี่ยนแปลงโครงสร้างข้อมูลที่เก็บสิ่งต่างๆ เช่น สถานะของอีเทอร์ โชคดีที่ EVM ไม่สามารถเข้าถึงโครงสร้างเหล่านี้ได้โดยตรง ดังนั้นแอปพลิเคชันที่ทำงานบน Ethereum มักจะทำงานกับการเลิกใช้ ZK-EVM ประเภท 2 คุณจะไม่สามารถใช้ไคลเอ็นต์ Etherum Execution ได้ตามที่เป็นอยู่ แต่คุณสามารถใช้ไคลเอนต์เหล่านี้กับการแก้ไขบางอย่างได้ และคุณจะยังสามารถเข้าถึงเครื่องมือแก้ไขจุดบกพร่อง EVM และโครงสร้างพื้นฐานส่วนใหญ่ของนักพัฒนาอื่นๆ ได้
แต่มีข้อยกเว้นบางประการ ความเข้ากันไม่ได้เกิดขึ้นกับแอปพลิเคชันที่ตรวจสอบการพิสูจน์ Merkle ของบล็อกอีเธอร์ในอดีตเพื่อตรวจสอบการอ้างสิทธิ์เกี่ยวกับธุรกรรมในอดีต ใบเสร็จรับเงิน หรือสถานะ (เช่น บางครั้งสะพานก็ทำเช่นนี้) การแทนที่ ZK-EVM ของ Keccak ด้วยฟังก์ชันแฮชอื่นจะทำให้ข้อพิสูจน์เหล่านี้เสียหาย อย่างไรก็ตาม โดยทั่วไปแล้วฉันไม่แนะนำให้สร้างแอปพลิเคชันด้วยวิธีนี้ เนื่องจากการเปลี่ยนแปลงของอีเทอร์ในอนาคต (เช่น Verkle Trees) อาจทำให้แอปพลิเคชันดังกล่าวเสียหายได้แม้กระทั่งบนอีเทอร์เอง ทางเลือกที่ดีกว่าสำหรับ Ethereum ก็คือการเพิ่มการรวบรวมประวัติการเข้าถึงประวัติที่เชื่อถือได้ในอนาคต
จุดด้อย: ปรับปรุงเวลาการตรวจสอบ แต่ก็ยังช้า
ZK-EVM ประเภท 2 ให้เวลาในการตรวจสอบที่เร็วกว่าประเภท 1 โดยหลักแล้วโดยการลบส่วนของ Ethereum stack ที่ต้องใช้การเข้ารหัส ZK ที่ซับซ้อนโดยไม่จำเป็นและไม่เป็นมิตร โดยเฉพาะอย่างยิ่ง พวกเขาอาจเปลี่ยน Keccak ของ Ethereum และ Merkle Patricia tree ที่ใช้ RLP และอาจบล็อกและรับโครงสร้าง ZK-EVM ประเภท 2 อาจใช้ฟังก์ชันแฮชอื่น เช่น โพไซดอน การดัดแปลงตามธรรมชาติอีกอย่างคือการแก้ไขแผนผังสถานะเพื่อเก็บรหัสแฮชและ keccak ดังนั้นแฮชการตรวจสอบจึงไม่จำเป็นอีกต่อไปในการจัดการ EXTCODEHASH และ EXTCODECOPY opcodes
การแก้ไขเหล่านี้ช่วยปรับปรุงเวลาการตรวจสอบอย่างมีนัยสำคัญ แต่ไม่สามารถแก้ปัญหาทั้งหมดได้ เนื่องจากความไร้ประสิทธิภาพโดยธรรมชาติและความไม่เป็นมิตรของ EVM กระบวนการพิสูจน์ EVM ตามที่เป็นอยู่จึงยังช้าอยู่ ตัวอย่างง่ายๆ เช่น หน่วยความจำ: เนื่องจาก MLOAD สามารถอ่านบล็อกขนาด 32 ไบต์ใดๆ ก็ได้ รวมถึงบล็อกที่ "ไม่จัดแนว" (โดยที่จุดเริ่มต้นและจุดสิ้นสุดไม่ใช่จำนวนทวีคูณของ 32) จึงไม่สามารถตีความ MLOAD ง่ายๆ ว่าอ่านบล็อกได้ แต่อาจต้อง อ่านสองบล็อกติดต่อกันและดำเนินการบิตเพื่อรวมผลลัพธ์
ใครเป็นคนสร้าง?
โครงการ ZK-EVM ของ Scroll กำลังมุ่งสู่ Type 2 ZK-EVM เช่นเดียวกับ Polygon Hermez ที่กล่าวว่า โครงการยังไม่เสร็จสิ้น (งาน ZKEVM ยังไม่เสร็จสิ้น) โดยเฉพาะอย่างยิ่ง การคอมไพล์ล่วงหน้าที่ซับซ้อนกว่าจำนวนมากยังไม่ได้ดำเนินการ ดังนั้น แบบที่ 3 ถือว่าดีที่สุดสำหรับทั้งสองโครงการในเวลานี้
ประเภท 2.5 (เทียบได้กับ EVM ไม่รวมค่าแก๊ส)
วิธีหนึ่งที่จะปรับปรุงเวลาการตรวจสอบกรณีเลวร้ายที่สุดได้อย่างมีนัยสำคัญคือการเพิ่มค่าใช้จ่ายอย่างมากสำหรับการดำเนินการบางอย่างใน EVM ที่พิสูจน์ได้ยาก ซึ่งอาจเกี่ยวข้องกับการคอมไพล์ล่วงหน้า KECCAK opcodes แต่ยังรวมถึงการเรียกแบบแผนหรือโหมดเฉพาะของการเข้าถึงหน่วยความจำ ที่เก็บข้อมูล หรือการคืนค่า
การเปลี่ยนแปลงต้นทุนก๊าซอาจลดความเข้ากันได้ของเครื่องมือสำหรับนักพัฒนาและทำให้แอปพลิเคชันบางตัวเสียหาย แต่โดยทั่วไปถือว่ามีความเสี่ยงน้อยกว่าการเปลี่ยนแปลง EVM ที่ "ลึกกว่า" นักพัฒนาควรดูแลไม่ให้ต้องใช้น้ำมันในการทำธุรกรรมมากเกินความจุของบล็อก และอย่าโทรด้วยค่าน้ำมันที่ฮาร์ดโค้ด (นี่เป็นคำแนะนำมาตรฐานสำหรับนักพัฒนามาเป็นเวลานาน)
ประเภท 3 (เกือบเทียบเท่ากับ EVM)
Type 3 ZK-EVM เกือบจะเทียบเท่ากับ EVM แต่เพื่อให้บรรลุผลเช่นเดียวกัน จำเป็นต้องเสียสละบางอย่างเพื่อปรับปรุงเวลาในการตรวจสอบให้ดียิ่งขึ้น และทำให้ EVM พัฒนาได้ง่ายขึ้น
ข้อดี: สร้างได้ง่ายกว่า เวลาตรวจสอบเร็วขึ้น
ประเภทที่ 3 ZK-EVM อาจลบคุณสมบัติบางอย่างที่ยากเป็นพิเศษในการปรับใช้ ZK-EVM ที่นี่ การคอมไพล์ล่วงหน้ามักจะอยู่ด้านบนสุดของรายการ ยิ่งกว่านั้น ZK-EVM ประเภท 3 บางครั้งมีความแตกต่างเล็กน้อยในวิธีจัดการกับรหัสสัญญา หน่วยความจำ หรือสแต็ก
จุดด้อย: ความเข้ากันไม่ได้มากขึ้น
Type 3 ZK-EVM มีจุดมุ่งหมายเพื่อให้เข้ากันได้กับแอพพลิเคชั่นส่วนใหญ่และต้องการการเขียนซ้ำส่วนที่เหลือให้น้อยที่สุด ที่กล่าวว่า บางแอปพลิเคชันจำเป็นต้องเขียนใหม่ เนื่องจากใช้การคอมไพล์ล่วงหน้าที่ Type 3 ZK-EVM ลบออก หรือเนื่องจากการพึ่งพาเล็กน้อยบนเคสขอบที่ EVM จัดการแตกต่างกัน
ใครเป็นคนสร้าง?
Scroll และ Polygon เป็นทั้งประเภทที่ 3 ในรูปแบบปัจจุบัน แม้ว่าพวกเขาคาดว่าจะปรับปรุงความเข้ากันได้เมื่อเวลาผ่านไป Polygon มีการออกแบบที่ไม่เหมือนใคร พวกเขาใช้ ZK เพื่อตรวจสอบภาษาภายในของตนเอง zkASM และใช้ zkASM เพื่อตีความโค้ด ZK-EVM แม้จะมีรายละเอียดการใช้งานนี้ แต่ฉันก็ยังเรียกมันว่า Type3ZK-EVM ที่แท้จริง มันยังสามารถตรวจสอบรหัส EVM ได้ เพียงแค่ใช้ตรรกะภายในที่แตกต่างกันในการดำเนินการดังกล่าว
วันนี้ไม่มีทีม ZK-EVM ที่ต้องการเป็น Type 3 Type 3 เป็นเพียงช่วงเปลี่ยนผ่านจนกว่างานที่ซับซ้อนในการเพิ่มการคอมไพล์ล่วงหน้าจะเสร็จสมบูรณ์และโปรเจ็กต์สามารถย้ายไป Type 2.5 ได้ อย่างไรก็ตาม ในอนาคต Type 1 หรือ Type 2 ZK-EVM อาจกลายเป็น Type 3 ZK-EVM โดยสมัครใจโดยการเพิ่มคอมไพเลอร์ใหม่ที่เป็นมิตรต่อ ZK-SNARK ซึ่งช่วยให้นักพัฒนามีเวลาตรวจสอบต่ำและคุณสมบัติค่าน้ำมัน
แบบที่ 4 (เทียบเท่าภาษาระดับสูง)
ระบบ Type 4 ทำงานโดยใช้ซอร์สโค้ดสัญญาอัจฉริยะที่เขียนด้วยภาษาระดับสูง (เช่น SOLIDITY, VYPER หรือภาษากลางบางภาษาที่คอมไพล์ทั้งสอง) และคอมไพล์เป็นภาษาบางประเภทที่ออกแบบมาอย่างชัดเจนให้เป็นภาษาที่เป็นมิตรกับ ZK-snark
ข้อดี: เวลาในการตรวจสอบรวดเร็วมาก
ด้วยการไม่ใช้ ZK เพื่อพิสูจน์ส่วนต่างๆ ของขั้นตอนการดำเนินการ EVM แต่ละขั้นตอน และเริ่มต้นโดยตรงจากโค้ดระดับที่สูงกว่า จึงสามารถหลีกเลี่ยงค่าใช้จ่ายจำนวนมากได้
ฉันอธิบายข้อดีนี้ในประโยคเดียวในโพสต์นี้ (เทียบกับรายการหัวข้อย่อยขนาดใหญ่เกี่ยวกับข้อเสียที่เกี่ยวข้องกับความเข้ากันได้ด้านล่าง) แต่สิ่งนี้ไม่ควรตีความว่าเป็นการตัดสินคุณค่า! การคอมไพล์โดยตรงจากภาษาระดับสูงสามารถลดต้นทุนได้อย่างมากและช่วยการกระจายอำนาจโดยทำให้ง่ายต่อการพิสูจน์
จุดด้อย: ความเข้ากันไม่ได้มากขึ้น
แอปพลิเคชัน "ปกติ" ที่เขียนด้วย Vyper หรือ Solidity สามารถคอมไพล์ได้ และจะ "ใช้งานได้" แต่มีประเด็นสำคัญบางประการที่แอปพลิเคชันจำนวนมากไม่ "ใช้งานได้":
ที่อยู่ของสัญญาในระบบประเภท 4 อาจแตกต่างจากที่อยู่ใน EVM เนื่องจากที่อยู่ของสัญญา CREATE2 ขึ้นอยู่กับรหัสไบต์ที่แน่นอน ซึ่งจะทำลายแอปพลิเคชันที่ขึ้นอยู่กับ "สัญญาต่อต้านข้อเท็จจริง" กระเป๋าเงิน ERC-4337 ซิงเกิลตัน EIP-2470 และแอปพลิเคชันอื่นๆ อีกมากมายที่ยังไม่ได้ใช้งาน
โค้ดไบต์ EVM ที่เขียนด้วยลายมือนั้นใช้งานยากกว่า เพื่อประสิทธิภาพ แอปพลิเคชันจำนวนมากใช้ EVM bytecode ที่เขียนด้วยมือสำหรับบางส่วน ระบบ Type 4 อาจไม่รองรับ แม้ว่าจะมีหลายวิธีในการปรับใช้การรองรับ EVM bytecode แบบจำกัดเพื่อตอบสนองกรณีการใช้งานเหล่านี้ โดยไม่ต้องพยายามเป็น Type3 ZK-EVM เต็มรูปแบบ
โครงสร้างพื้นฐานการดีบักส่วนใหญ่ไม่สามารถดำเนินการต่อได้เนื่องจากทำงานบน EVM bytecode ที่กล่าวว่าข้อบกพร่องนี้จะลดลงโดยการเข้าถึงโครงสร้างพื้นฐานการดีบักเพิ่มเติมจากภาษาระดับสูงหรือระดับกลาง "ดั้งเดิม" (เช่น LLVM)
นักพัฒนาควรตระหนักถึงปัญหาเหล่านี้
ใครเป็นคนสร้าง?
ZKSync เป็นระบบประเภท 4 แม้ว่าเมื่อเวลาผ่านไปอาจเพิ่มความเข้ากันได้กับ EVM bytecode โครงการ Warp ของ NetherMind กำลังสร้างคอมไพเลอร์ Cairo จาก Solidity ไปยัง Starkware ซึ่งจะเปลี่ยน StarkNet ให้เป็นระบบ Type 4 โดยพฤตินัย
อนาคตของ ZK-EVM หลายประเภท
ประเภทเหล่านี้ไม่ได้ "ดีกว่า" หรือ "แย่กว่า" อย่างชัดเจนกว่าประเภทอื่นๆ ค่อนข้างจะเป็นจุดแตกต่างในพื้นที่ที่ต้องแลก: ประเภทที่โค้ดยากน้อยกว่าจะเข้ากันได้กับโครงสร้างพื้นฐานที่มีอยู่มากกว่า แต่ช้ากว่า ประเภทที่โค้ดยากกว่าจะเข้ากันได้กับโครงสร้างพื้นฐานที่มีอยู่น้อยกว่า แต่เร็วกว่า โดยรวมแล้ว คนประเภทนี้กำลังสำรวจ ซึ่งเป็นประโยชน์ต่อภาคสนาม
ZK-EVM สามารถเริ่มต้นด้วยประเภทที่ 3 โดยตัดสินใจไม่รวมคุณสมบัติบางอย่างที่พิสูจน์ ZK ได้ยากเป็นพิเศษ ในภายหลัง พวกเขาสามารถเพิ่มคุณสมบัติเหล่านี้เมื่อเวลาผ่านไปและย้ายไปที่ประเภท 2
ZK-EVM สามารถเริ่มต้นเป็น Type 2 จากนั้นจึงกลายเป็น ZK-EVM Type 2/Type 1 แบบไฮบริดโดยให้ความเป็นไปได้ในการทำงานในโหมดความเข้ากันได้ของอีเธอร์เน็ตเต็มรูปแบบหรือใช้แผนผังสถานะที่แก้ไขซึ่งสามารถพิสูจน์ได้เร็วกว่า Sroll กำลังพิจารณาที่จะย้ายไปในทิศทางนี้
ระบบที่ขึ้นต้นด้วย Type 4 อาจกลายเป็น Type 3 เมื่อเวลาผ่านไปเนื่องจากมีการเพิ่มความสามารถในการจัดการโค้ด EVM ในภายหลัง (แม้ว่านักพัฒนายังคงได้รับการสนับสนุนให้คอมไพล์โดยตรงจากภาษาระดับสูงเพื่อลดค่าใช้จ่ายและเวลาในการตรวจสอบ)
โดยส่วนตัวแล้ว ฉันหวังว่าเมื่อเวลาผ่านไป ทุกอย่างจะกลายเป็น Type 1 โดยการปรับปรุง ZK-EVM และปรับปรุง Ethereum เองเพื่อให้เหมาะกับ ZK-Snark มากขึ้น ในอนาคตเช่นนี้ เราจะมีการปรับใช้ ZK-EVM หลายแบบ ทั้งสำหรับการสั่งสม ZK และการตรวจสอบความถูกต้องของ Ethereum เอง ตามทฤษฎีแล้ว Ethereum ไม่จำเป็นต้องสร้างมาตรฐานในการใช้งาน ZK-EVM เดียวที่ใช้โดย L1 ไคลเอนต์ที่แตกต่างกันสามารถใช้การพิสูจน์ที่แตกต่างกันได้ ดังนั้นเรายังคงได้รับประโยชน์จากความซ้ำซ้อนของรหัส
