ผู้เขียน: Ye Zhang@Scroll

ขอขอบคุณ Vitalik Buterin, Barry Whitehat, Chih-Cheng Liang, Kobi Gurkan และ Georgios Konstantopoulos สำหรับคำวิจารณ์และข้อมูลเชิงลึก

นานเกินไป

เราเชื่อว่า zk-Rollup จะกลายเป็น "จุดที่น่าสนใจ" - ความได้เปรียบด้านต้นทุนและความปลอดภัยที่สูงมากจะทำให้โซลูชันการปรับขยายเลเยอร์ 2 หลายตัวด้อยประสิทธิภาพเมื่อเปรียบเทียบกัน อย่างไรก็ตาม การใช้งาน zk-Rollup ที่มีอยู่นั้นเป็นแบบเฉพาะแอปพลิเคชันทั้งหมด ดังนั้นจึงเป็นเรื่องยากสำหรับเราที่จะสร้าง dApp สำหรับวัตถุประสงค์ทั่วไปที่ประกอบได้ภายใน zk-Rollup บางตัว และเป็นไปไม่ได้ที่จะย้ายแอปพลิเคชันที่มีอยู่ เราแนะนำ zkEVM เพื่อสร้างการพิสูจน์ที่ไม่มีความรู้สำหรับการตรวจสอบ EVM ทั่วไป ด้วยวิธีนี้ เราสามารถสร้าง zk-Rollup ที่เข้ากันได้กับ EVM อย่างสมบูรณ์ เพื่อให้สามารถย้ายแอปพลิเคชัน Ethereum ที่มีอยู่ไปยัง zk-Rollup นี้ได้อย่างง่ายดาย

พื้นหลัง

พื้นหลัง

zk-Rollup ได้รับการยอมรับว่าเป็นโซลูชันการปรับขนาด Ethereum ที่ดีที่สุด ไม่เพียงแต่เทียบได้กับ Ethereum Layer 1 ในแง่ของความปลอดภัย แต่ยังเป็นผู้นำของโซลูชัน Layer 2 ในแง่ของความเร็วในการสรุปการทำธุรกรรม (คลิกที่นี่เพื่อดูการวิเคราะห์เปรียบเทียบโดยละเอียด (ข้อความต้นฉบับ การแปล))

ในระยะกลางและระยะยาว ด้วยการพัฒนาเทคโนโลยี ZK-SNARK อย่างต่อเนื่อง zk-rollup จะเป็นผู้นำในทุกสถานการณ์การใช้งาน —— ไวตาลิค บิวเทอรีน

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

แม้ว่า zk-Rollup จะปลอดภัยและมีประสิทธิภาพ แต่แอปพลิเคชันยังคงจำกัดเฉพาะการชำระเงินและการแลกเปลี่ยน dApps สำหรับวัตถุประสงค์ทั่วไปนั้นสร้างได้ยากด้วยเหตุผลหลักสองประการ:

• อันดับแรก หากคุณต้องการพัฒนา dApp ภายใน zk-Rollup คุณต้องใช้ภาษาพิเศษ (เช่น R1CS) เพื่อเขียนตรรกะของสัญญาอัจฉริยะทั้งหมดของคุณ ภาษานี้มีไวยากรณ์ที่ซับซ้อนและต้องการให้ผู้ใช้มีความเชี่ยวชาญในการพิสูจน์ที่ไม่มีความรู้

• ประการที่สอง การใช้งาน zk-Rollup ที่มีอยู่ไม่รองรับความสามารถในการเรียบเรียง1 ดังนั้นในเลเยอร์ 2 แอปพลิเคชัน zk-Rollup ที่แตกต่างกันจึงไม่สามารถโต้ตอบซึ่งกันและกันได้ ซึ่งสร้างความเสียหายอย่างร้ายแรงต่อความสามารถในการทำงานร่วมกันของแอปพลิเคชัน DeFi

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

สร้าง Universal dApps ใน zk-Rollup

เราสามารถสร้าง dApps สำหรับวัตถุประสงค์ทั่วไปภายใน zk-Rollup ได้สองวิธี:

• หนึ่งคือการสร้างวงจรเฉพาะแอปพลิเคชัน (“ASIC”) สำหรับ dApps ที่แตกต่างกัน

• อีกวิธีหนึ่งคือการสร้างวงจร "EVM" ที่ใช้งานทั่วไปสำหรับการดำเนินการตามสัญญาอัจฉริยะ

"วงจร" หมายถึงการแสดงโปรแกรมที่ใช้ในการพิสูจน์ที่ไม่มีความรู้ ตัวอย่างเช่น ถ้าคุณต้องการพิสูจน์ว่าแฮช(x) = y คุณต้องเขียนฟังก์ชันแฮชใหม่ในรูปแบบวงจร รูปแบบวงจรรองรับเฉพาะการแสดงที่จำกัดมากเท่านั้น (เช่น R1CS รองรับเฉพาะการบวกและการคูณ) ดังนั้น การเขียนโปรแกรมด้วยภาษาวงจรจึงเป็นเรื่องยากมาก - คุณสามารถใช้การบวกและการคูณเพื่อสร้างลอจิกของโปรแกรมทั้งหมดเท่านั้น (รวมถึง if else, loops เป็นต้น)

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

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

เมื่อเร็ว ๆ นี้ มีการวิจัยจำนวนมากที่ทุ่มเทให้กับการปรับ ZKP ให้เหมาะสมโดยใช้สองวิธีนี้ รวมถึง (i) เสนอการแฮชโพไซดอนดั้งเดิมที่เป็นมิตรต่อ ZKP ใหม่ (การแฮชของโพไซดอนมีประสิทธิภาพในวงจรมากกว่า SHA256 ถึง 100 เท่า) (ii) การปรับปรุงอย่างต่อเนื่องใน ประสิทธิภาพของเครื่องเสมือนที่ตรวจสอบได้สำหรับวัตถุประสงค์ทั่วไป เช่น TinyRAM; (iii) เทคนิคการเพิ่มประสิทธิภาพสำหรับวัตถุประสงค์ทั่วไปมากขึ้นเรื่อยๆ เช่น Plookup และไลบรารีการเข้ารหัสที่ทำงานเร็วขึ้น

ในบทความที่แล้ว เราเสนอการออกแบบวงจร "ASIC" สำหรับแต่ละ dApp และให้สื่อสารผ่านการเข้ารหัสลับ อย่างไรก็ตาม จากความคิดเห็นของชุมชน เราได้เปลี่ยนจุดเน้นการวิจัยของเรา และจะมุ่งเน้นไปที่การใช้แนวทางที่สองในการสร้างวงจร EVM ที่ใช้งานทั่วไป (เรียกว่า "zkEVM") zkEVM จะมอบประสบการณ์การพัฒนาแบบเดียวกับ Layer 1 แทนที่จะปล่อยให้ความซับซ้อนของการออกแบบเป็นหน้าที่ของนักพัฒนา เราแทนที่ด้วยการออกแบบวงจร EVM แบบกำหนดเองเพื่อแก้ไขปัญหาด้านประสิทธิภาพ

ความท้าทายในการออกแบบของ zkEVM

zkEVM สร้างได้ยาก แม้ว่าสัญชาตญาณนี้จะชัดเจนมาหลายปีแล้ว แต่ก็ยังไม่มีใครประสบความสำเร็จในการสร้างวงจร EVM ดั้งเดิม ซึ่งแตกต่างจาก TinyRAM ตรงที่ zkEVM นั้นท้าทายในการออกแบบและใช้งานมากกว่าด้วยเหตุผลดังต่อไปนี้:

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

• ประการที่สอง ขนาดคำของ EVM คือ 256 บิต EVM ทำงานบนจำนวนเต็ม 256 บิต (เช่นเดียวกับเครื่องเสมือนทั่วไปส่วนใหญ่ทำงานบนจำนวนเต็ม 32-64 บิต) และการพิสูจน์ความรู้ที่ไม่มีความรู้ "โดยธรรมชาติ" จะทำงานบนฟิลด์สำคัญ การทำ "เลขคณิตของโดเมนที่ไม่ตรงกัน" ในวงจรจำเป็นต้องมีการพิสูจน์ช่วง ซึ่งจะเพิ่มข้อจำกัดประมาณ 100 ข้อให้กับการดำเนินการ EVM แต่ละครั้ง สิ่งนี้จะเพิ่มขนาดวงจร EVM สองลำดับความสำคัญ

• ประการที่สาม EVM มีรหัสพิเศษมากมาย ซึ่งแตกต่างจากเครื่องเสมือนแบบดั้งเดิม EVM มี opcodes พิเศษมากมาย เช่น CALL และประเภทข้อผิดพลาดที่เกี่ยวข้องกับสภาพแวดล้อมการดำเนินการและแก๊ส สิ่งนี้จะนำความท้าทายใหม่มาสู่การออกแบบวงจร

• ประการที่สี่ EVM เป็นเครื่องเสมือนแบบสแต็ก สถาปัตยกรรม SyncVM (zksync) และ Cario (starkware) กำหนด IR/AIR ของตนเองในรูปแบบที่ใช้การลงทะเบียน พวกเขาสร้างคอมไพเลอร์พิเศษเพื่อรวบรวมรหัสสัญญาอัจฉริยะเป็น IR ที่เป็นมิตรต่อการพิสูจน์โดยปราศจากความรู้ วิธีนี้รองรับภาษา ไม่รองรับ EVM ดั้งเดิม ไม่ว่าจะเป็นการพิสูจน์โมเดลแบบสแต็กหรือการสนับสนุน toolchains แบบเนทีฟโดยตรง กลายเป็นเรื่องยากขึ้น

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

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

ทำไม zkEVM ถึงเป็นไปได้ในวันนี้

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

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

• ลักษณะที่ปรากฏของพารามิเตอร์ตารางการค้นหาและวิดเจ็ตแบบกำหนดเอง การเพิ่มประสิทธิภาพที่สำคัญอีกประการหนึ่งคือการใช้ตารางการค้นหา การเพิ่มประสิทธิภาพนี้ได้รับการเสนอครั้งแรกใน Arya จากนั้นนำไปใช้ใน Plookup สำหรับพื้นฐานที่ไม่เป็นมิตรกับการพิสูจน์ความรู้เป็นศูนย์ (เช่น การดำเนินการในระดับบิต เช่น AND และ XOR) ตารางการค้นหาสามารถช่วยประหยัดงานได้มาก วิดเจ็ตแบบกำหนดเองสามารถใช้ข้อจำกัดระดับสูงได้อย่างมีประสิทธิภาพ TurboPlonk และ UltraPlonk กำหนดไวยากรณ์โปรแกรมที่สวยงามซึ่งช่วยลดความยุ่งยากในการใช้ตารางค้นหาและกำหนดวิดเจ็ตแบบกำหนดเอง สิ่งนี้ช่วยลดต้นทุนของวงจร EVM ได้อย่างมาก

• ความเป็นไปได้ของ recursive proofs นั้นสูงขึ้นเรื่อยๆ ในอดีต การพิสูจน์แบบเรียกซ้ำมีค่าใช้จ่ายสูงเนื่องจากใช้เส้นโค้งวงรีแบบวงกลมที่จับคู่แบบพิเศษ (เช่น โครงสร้างตามเส้นโค้ง MNT) ทำให้เสียค่าใช้จ่ายในการคำนวณสูง อย่างไรก็ตาม เทคนิคจำนวนมากขึ้นช่วยให้สามารถพิสูจน์ซ้ำได้โดยไม่สูญเสียประสิทธิภาพ ตัวอย่างเช่น Halo ไม่ต้องการเส้นโค้งที่จับคู่ได้ และยังสามารถใช้พารามิเตอร์ผลิตภัณฑ์ภายในแบบพิเศษเพื่อตัดจำหน่ายต้นทุนการเรียกซ้ำ Aztec พิสูจน์ข้อพิสูจน์ที่สามารถรวบรวมได้โดยตรงจากโปรโตคอลที่มีอยู่ (ตารางการค้นหาสามารถลดค่าใช้จ่ายในการดำเนินการโดเมนที่ไม่ใช่เจ้าของภาษา ซึ่งจะเป็นการลดขนาดของวงจรการตรวจสอบ) ขนาดวงจรเท่าเดิมสามารถทำหน้าที่ได้มากขึ้น

• การเร่งฮาร์ดแวร์กำลังปรับปรุงประสิทธิภาพการพิสูจน์ เท่าที่ทราบ เราได้สร้างตัวเร่งความเร็ว GPU และ ASIC/FPGA ที่เร็วที่สุดสำหรับโปรแกรมพิสูจน์ กระดาษของเราเกี่ยวกับขั้นตอนการพิสูจน์ ASIC ได้รับการยอมรับในปีนี้โดย ISCA ซึ่งเป็นการประชุมวิชาการด้านคอมพิวเตอร์ชั้นนำ เครื่องพิสูจน์ GPU ของเราเร็วกว่าการติดตั้ง Filecoin ประมาณ 5 ถึง 10 เท่า ซึ่งสามารถปรับปรุงประสิทธิภาพการคำนวณของเครื่องพิสูจน์ได้อย่างมาก

zkEVM ทำงานและสร้างอย่างไร

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

เวิร์กโฟลว์สำหรับนักพัฒนาและผู้ใช้

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

ขั้นตอนการทำงานของ zkEVM

แม้ว่าเวิร์กโฟลว์ภายนอกจะยังคงเหมือนเดิม แต่การประมวลผลพื้นฐานของเลเยอร์ 1 และเลเยอร์ 2 นั้นแตกต่างกันอย่างสิ้นเชิง:

• เลเยอร์ 1 อาศัยการดำเนินการตามสัญญาอัจฉริยะอีกครั้ง
• เลเยอร์ 2 ขึ้นอยู่กับการพิสูจน์ความถูกต้องของวงจร zkEVM

เรามาอธิบายรายละเอียดว่าการทำธุรกรรมใน Layer 1 และ Layer 2 แตกต่างกันอย่างไร

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

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

มาเจาะลึกการดำเนินการและดูว่า zkEVM จำเป็นต้องพิสูจน์อะไรในท้ายที่สุด ในการดำเนินการแบบเนทีฟ EVM จะโหลด bytecode และดำเนินการ opcodes ใน bytecode ทีละตัวตั้งแต่เริ่มต้น opcode แต่ละอันสามารถดำเนินการได้สามขั้นตอนต่อไปนี้: (i) อ่านองค์ประกอบจากสแต็ก (สแต็ก) หน่วยความจำหรือรายการที่เก็บข้อมูล (ii) ทำการคำนวณตามองค์ประกอบเหล่านี้ (iii) เขียนผลลัพธ์ไปยังสแต็ก หน่วยความจำหรือรายการที่เก็บข้อมูล5. ตัวอย่างเช่น add opcode จำเป็นต้องอ่านสององค์ประกอบจากสแต็ก เพิ่ม และเขียนผลลัพธ์ลงในสแต็ก

ดังนั้นจึงเห็นได้ชัดว่าการพิสูจน์ zkEVM จำเป็นต้องมีประเด็นต่อไปนี้ (สอดคล้องกับขั้นตอนการดำเนินการ):

• โหลด Bytecode อย่างถูกต้องจากที่เก็บข้อมูลถาวร (คุณกำลังเรียกใช้ opcode ที่ถูกต้องที่โหลดจากที่อยู่)
• Opcodes ใน bytecode จะถูกดำเนินการทีละตัวเสมอ (bytecodes จะถูกดำเนินการตามลำดับ ไม่มี opcodes ที่พลาดหรือข้ามไป)
• ทุก opcode ดำเนินการอย่างถูกต้อง (สาม ops ย่อยในแต่ละ opcode ดำเนินการอย่างถูกต้อง, R/W + คำนวณ)

จุดเด่นของการออกแบบ zkEVM

เมื่อออกแบบสถาปัตยกรรมสำหรับ zkEVM เราจำเป็นต้องใช้มาตรการเพื่อให้เป็นไปตามข้อกำหนดสามข้อข้างต้นตามลำดับ

1. เราจำเป็นต้องออกแบบวงจรสำหรับตัวสะสมการเข้ารหัส

นี่คือการทำหน้าที่เป็น "หน่วยความจำที่ตรวจสอบได้" เราต้องการเทคโนโลยีบางอย่างเพื่อพิสูจน์ว่ากระบวนการอ่านนั้นถูกต้อง ตัวสะสมการเข้ารหัสสามารถทำได้อย่างมีประสิทธิภาพมากขึ้น6 ลองมาดูต้นไม้ Merkle เป็นตัวอย่าง bytecodes ปรับใช้จะถูกเก็บไว้เป็นโหนดปลายบนต้นไม้ Merkle จากนั้นผู้ตรวจสอบสามารถใช้หลักฐานรวบรัดเพื่อตรวจสอบว่ารหัสไบต์นี้โหลดอย่างถูกต้องจากที่อยู่ (เช่น ตรวจสอบเส้นทาง Merkle ในวงจร) สำหรับการจัดเก็บ Ethereum เราต้องการให้วงจรนี้เข้ากันได้กับทั้ง Merkle-Patricia tree และ Keccak hash functions

2. เราจำเป็นต้องออกแบบวงจรเพื่อเชื่อมโยง bytecode กับการติดตามการดำเนินการจริง

การย้าย bytecode ไปยังวงจรคงที่ทำให้เกิดปัญหา: opcodes แบบมีเงื่อนไข เช่น การกระโดด (ตรงข้ามกับคำสั่ง loop, if else ในสัญญาอัจฉริยะ) อาจข้ามไปที่ใดก็ได้ ปลายทางการข้ามไม่ได้กำหนดจนกว่าจะมีคนรัน bytecode นั้นด้วยอินพุตเฉพาะ นั่นเป็นเหตุผลที่เราต้องตรวจสอบการติดตามการดำเนินการจริง การติดตามการดำเนินการอาจถือเป็น "unrolled bytecode" ที่มี opcodes ตามลำดับที่ดำเนินการจริง (เช่น หากคุณข้ามไปยังตำแหน่งอื่น opcode เป้าหมายและตำแหน่งนั้นจะรวมอยู่ในการติดตาม)

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

3. เราต้องออกแบบวงจรสำหรับแต่ละ opcode (เพื่อพิสูจน์ว่าการอ่าน เขียน และคำนวณในแต่ละ opcode นั้นถูกต้อง)

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

• เราสามารถแยก R/W และการคำนวณออกเป็นสองการพิสูจน์ การพิสูจน์ทำให้องค์ประกอบทั้งหมดที่ใช้โดย opcode บน "บัส" หลักฐานอื่นจะพิสูจน์ได้ว่าการคำนวณองค์ประกอบบน "บัส" นั้นดำเนินการอย่างถูกต้อง สิ่งนี้ช่วยลดต้นทุนต่อชิ้นส่วนได้อย่างมาก (เช่น คุณไม่จำเป็นต้องพิจารณาพื้นที่จัดเก็บ EVM ทั้งหมดเมื่อสร้างหลักฐานการคำนวณ) ในข้อกำหนดโดยละเอียดเพิ่มเติม แบบแรกเรียกว่า "หลักฐานของรัฐ" และแบบหลังเรียกว่า "หลักฐานของ EVM" การค้นพบอีกประการหนึ่งคือคำสั่งการค้นหาสามารถจัดการ "การแมปบัส" ได้อย่างมีประสิทธิภาพ

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

เดิมเสนอโดย Ethereum Foundation สถาปัตยกรรมนี้ยังอยู่ในช่วงเริ่มต้นและอยู่ระหว่างการพัฒนาอย่างแข็งขัน เรากำลังทำงานอย่างใกล้ชิดกับ Ethereum Foundation เพื่อหาวิธีที่ดีที่สุดในการนำวงจร EVM นี้ไปใช้ จนถึงตอนนี้เราได้กำหนดคุณสมบัติที่สำคัญที่สุดของวงจร EVM และนำไปใช้ (โดยใช้ไวยากรณ์ UltraPlonk จากไลบรารี Halo2) opcodes บางตัว (คลิกที่นี่เพื่อดู) เนื้อหาที่มีรายละเอียดเพิ่มเติมจะแนะนำในบทความต่อๆ ไป เราขอแนะนำให้ผู้อ่านที่สนใจอ่านเอกสารนี้ กระบวนการพัฒนาจะเป็นไปอย่างโปร่งใส นี่จะเป็นการออกแบบโอเพ่นซอร์สอย่างสมบูรณ์ที่รวบรวมโดยชุมชนทั้งหมด ฉันหวังว่าผู้คนจะเข้าร่วมและมีส่วนร่วมมากขึ้น

zkEVM ให้อะไรเราอีกบ้าง?

zkEVM เป็นมากกว่าการปรับขนาดเลเยอร์ 2 เราสามารถเข้าใจได้ว่าเป็นวิธีที่ตรงไปตรงมาในการปรับขนาดการพิสูจน์ความถูกต้องของ Ethereum Layer 1 ถึง Layer 1 ซึ่งหมายความว่าสามารถขยายเลเยอร์ 1 ที่มีอยู่ได้โดยไม่ต้องมีเลเยอร์ 2 พิเศษใดๆ

สรุปแล้ว

สรุปแล้ว

เกี่ยวกับเรา

เกี่ยวกับเรา

บันทึก:

บันทึก:

1. ความสามารถในการจัดองค์ประกอบสำเร็จในการประกาศของ Starkware เมื่อวันที่ 1 กันยายน 2021 (คลิกที่นี่เพื่อดูประกาศ)

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

3. เพื่อความสะดวกของผู้อ่าน เราจะให้รายละเอียดค่าใช้จ่ายของวงจร EVM ที่นี่ ตามที่ระบุไว้ก่อนหน้านี้ วงจรคงที่และคงที่ ดังนั้นวงจร EVM จึงจำเป็นต้องมีลอจิกที่เป็นไปได้ทั้งหมด (ปริมาตรนี้ใหญ่กว่าวงจรที่มีแต่การบวกเท่านั้น 10,000 เท่า) ซึ่งหมายความว่าแม้ว่าคุณจะต้องการพิสูจน์เพิ่ม แต่คุณยังต้องแบกรับต้นทุนของลอจิกทั้งหมดที่อาจมีอยู่ในวงจร EVM นี้ นั่นคือค่าใช้จ่ายจะเพิ่มขึ้น 10,000 เท่า ในการติดตามการดำเนินการ คุณจำเป็นต้องพิสูจน์ห่วงโซ่ของ opcodes และแต่ละ opcode มาพร้อมกับค่าใช้จ่ายที่สูง

4. EVM เองไม่ได้ผูกมัดอย่างแน่นหนากับ Merkle-Patricia Trees (MPTs) ปัจจุบัน MPT ใช้เพื่อจัดเก็บสถานะ Ethereum เท่านั้น ง่ายต่อการเปลี่ยน (บางคนเสนอให้ใช้ Verkle tree เพื่อแทนที่ MPT)

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

6. เนื่องจากพื้นที่จัดเก็บมีขนาดใหญ่ เราจึงใช้ตัวสะสมเพื่อจัดเก็บ หน่วยความจำและสแต็คสามารถแก้ไขได้โดยใช้ Plookup (เราสามารถใช้ "RAM" ได้อย่างมีประสิทธิภาพด้วยวิธีนี้)

7. ลิงค์ต้นฉบับ:

ลิงค์ต้นฉบับ:

https://hackmd.io/@yezhang/S1_KMMbGt