บทความใหม่ของ V God: หลังจากที่ Ethereum มี ZK ในตัวแล้ว Layer 2 จะไปไหน?
ผลิตโดย - Odaily
เรียบเรียง - Loopy Lu
วันนี้ Vitalik Buterin เผยแพร่บทความในชุมชน Ethereum ในหัวข้อ ZK-EVM ในตัวอาจมีหน้าตาเป็นอย่างไร 》บทความใหม่. บทความนี้จะสำรวจว่า Ethereum จะมี ZK-EVM ของตัวเองในการอัปเกรดเครือข่ายในอนาคตอย่างไร
ดังที่เราทุกคนทราบกันดีว่าในบริบทของการพัฒนา Ethereum อย่างช้าๆ ในปัจจุบัน Mainstream Layer 2 เกือบทั้งหมดมี ZK-EVM เมื่อ Ethereum mainnet สรุป ZK-EVM ของตัวเอง mainnet และ Layer 2 จะมีการกำหนดบทบาทหรือไม่ แล้วความขัดแย้งล่ะ ? Layer 1 และ Layer 2 สามารถแบ่งและทำงานร่วมกันได้อย่างมีประสิทธิภาพได้อย่างไร?
ในบทความนี้ Vitalik Buterin เน้นย้ำถึงความสำคัญของความเข้ากันได้ ความพร้อมใช้งานของข้อมูล และความสามารถในการตรวจสอบ และสำรวจความเป็นไปได้ของการนำข้อพิสูจน์ที่มีประสิทธิภาพและสถานะไปใช้ นอกจากนี้ บทความนี้ยังสำรวจความเป็นไปได้ของการนำเครื่องพิสูจน์สถานะไปใช้เพื่อเพิ่มประสิทธิภาพ และอภิปรายถึงบทบาทของโครงการเลเยอร์ 2 ในการให้การยืนยันล่วงหน้าอย่างรวดเร็วและกลยุทธ์การลดผลกระทบ MEV บทความนี้สะท้อนให้เห็นถึงความสมดุลของการรักษาความยืดหยุ่นของเครือข่าย Ethereum ในขณะเดียวกันก็พัฒนาการพัฒนาผ่าน ZK-EVM
Odaily ได้รวบรวมข้อความต้นฉบับไว้ดังนี้:
เนื่องจากโปรโตคอล Layer-2 EVM อยู่เหนือ Ethereum การโรลอัพในแง่ดีและโรลอัพ ZK ทั้งคู่จึงอาศัยการตรวจสอบ EVM อย่างไรก็ตาม สิ่งนี้กำหนดให้พวกเขาต้องเชื่อถือฐานโค้ดขนาดใหญ่ และหากมีจุดบกพร่องในฐานโค้ดนี้ เครื่องเสมือนเหล่านี้ก็มีความเสี่ยงที่จะถูกแฮ็ก นอกจากนี้ยังหมายความว่า ZK-EVM แม้ว่าหวังว่าจะยังคงเทียบเท่า L1 EVM อย่างสมบูรณ์ แต่ก็จำเป็นต้องมีรูปแบบการกำกับดูแลบางอย่างเพื่อคัดลอกการเปลี่ยนแปลง L1 EVM ไปเป็นการใช้งาน EVM ของตนเอง
นี่ไม่ใช่สถานการณ์ในอุดมคติ เนื่องจากโปรเจ็กต์เหล่านี้กำลังคัดลอกฟังก์ชันการทำงานที่มีอยู่แล้วในโปรโตคอล Ethereum เข้าไปในตัวมันเอง - การกำกับดูแล Ethereum มีหน้าที่รับผิดชอบในการอัพเกรดและแก้ไขข้อบกพร่องอยู่แล้ว และโดยพื้นฐานแล้ว ZK-EVM จะทำหน้าที่ตรวจสอบความถูกต้องของบล็อก Ethereum ของเลเยอร์ 1 ในอีกไม่กี่ปีข้างหน้า เราคาดว่าไคลเอ็นต์แบบ light จะมีประสิทธิภาพเพิ่มมากขึ้น และในไม่ช้าจะสามารถใช้ ZK-SNARK เพื่อตรวจสอบความถูกต้องของการดำเนินการ L1 EVM ได้อย่างสมบูรณ์ ณ จุดนั้น เครือข่าย Ethereum จะมี ZK-EVM แบบห่อหุ้มจริงๆ ดังนั้นคำถามจึงเกิดขึ้น: ทำไมไม่ทำให้ ZK-EVM นี้พร้อมใช้งานสำหรับการยกเลิกด้วยเช่นกัน
บทความนี้จะอธิบาย ZK-EVM ในแพ็คเกจ หลายเวอร์ชัน และวิเคราะห์ข้อดีข้อเสีย ความท้าทายในการออกแบบ และเหตุผลที่จะไม่ไปในทิศทางใดทิศทางหนึ่ง ควรเปรียบเทียบประโยชน์ของการใช้ฟังก์ชันโปรโตคอลกับประโยชน์ของการปล่อยให้ระบบนิเวศจัดการธุรกรรมและทำให้โปรโตคอลพื้นฐานเรียบง่าย
คุณสมบัติหลักที่เราต้องการได้รับจากแพ็คเกจ ZK-EVM คืออะไร
ฟังก์ชั่นพื้นฐาน: ตรวจสอบบล็อก Ethereum ฟังก์ชั่นโปรโตคอล (ยังไม่ได้พิจารณาว่าเป็น opcode, คอมไพล์ล่วงหน้าหรือกลไกอื่น ๆ ) ควรจะยอมรับอย่างน้อยรูทพรีสเตต บล็อก และรูทหลังสเตทเป็นอินพุต และตรวจสอบว่าโพสต์- state root จริงๆ แล้วอยู่ด้านบนของ pre-state root ผลลัพธ์ของการดำเนินการบล็อกนี้ เข้ากันได้กับไคลเอนต์หลายตัวของ Ethereum ซึ่งหมายความว่าเราต้องการหลีกเลี่ยงการมีระบบพิสูจน์อักษรเดียวในตัว และอนุญาตให้ไคลเอนต์ที่แตกต่างกันใช้ระบบพิสูจน์ที่แตกต่างกันแทน
นอกจากนี้ยังหมายถึงบางสิ่ง:
ข้อกำหนดด้านความพร้อมใช้งานของข้อมูล:สำหรับการดำเนินการ EVM ใดๆ ที่ใช้การพิสูจน์ ZK-EVM แบบห่อหุ้ม เราต้องการให้แน่ใจว่าข้อมูลพื้นฐานพร้อมใช้งาน เพื่อให้ผู้พิสูจน์ที่ใช้ระบบการพิสูจน์ที่แตกต่างกันสามารถรับรองการดำเนินการอีกครั้งได้ และไคลเอนต์ที่ใช้ระบบการพิสูจน์นั้นสามารถตรวจสอบการพิสูจน์ที่สร้างขึ้นใหม่เหล่านี้ได้ .
การพิสูจน์อยู่นอก EVM และบล็อกโครงสร้างข้อมูล：ฟังก์ชัน ZK-EVM ไม่ยอมรับ SNARK เป็นอินพุตภายใน EVM จริงๆ เนื่องจากไคลเอนต์ที่แตกต่างกันจะคาดหวัง SNARK ประเภทที่แตกต่างกัน แต่อาจคล้ายกับการตรวจสอบความถูกต้องของ Blob แทน: ธุรกรรมสามารถรวมถึงการอ้างสิทธิ์ที่ต้องได้รับการพิสูจน์ (ก่อนสถานะ เนื้อหาบล็อก หลังสถานะ) เนื้อหาของการอ้างสิทธิ์เหล่านี้สามารถเข้าถึงได้โดย opcodes หรือการคอมไพล์ล่วงหน้า และกฎที่เป็นเอกฉันท์ของลูกค้าจะ ตรวจสอบความพร้อมของข้อมูลและหลักฐานการเรียกร้องที่เกิดขึ้นในบล็อก
ความสามารถในการตรวจสอบ:หากการดำเนินการใดๆ ได้รับการพิสูจน์แล้ว เราต้องการให้ข้อมูลพื้นฐานพร้อมใช้งาน เพื่อให้ทั้งผู้ใช้และนักพัฒนาสามารถตรวจสอบได้หากมีปัญหาใดๆ เกิดขึ้น นี่เป็นการเพิ่มเหตุผลอีกประการหนึ่งว่าทำไมข้อกำหนดด้านความพร้อมใช้งานของข้อมูลจึงมีความสำคัญ
ความสามารถในการอัพเกรด:หากพบจุดบกพร่องในโซลูชัน ZK-EVM เราต้องการที่จะแก้ไขได้อย่างรวดเร็ว ซึ่งหมายความว่าไม่จำเป็นต้องใช้ฮาร์ดฟอร์กในการแก้ไขปัญหา นี่เป็นอีกเหตุผลหนึ่งว่าทำไมการพิสูจน์ภายนอก EVM และโครงสร้างข้อมูลบล็อกจึงมีความสำคัญ
รองรับ EVM โดยประมาณ:สิ่งที่น่าสนใจอย่างหนึ่งของ L2 คือความสามารถในการสร้างสรรค์นวัตกรรมที่เลเยอร์การดำเนินการและขยาย EVM หาก VM ของ L2 บางตัวแตกต่างจาก EVM เพียงเล็กน้อย ก็คงจะดีถ้า L2 สามารถใช้ ZK-EVM ในโปรโตคอลดั้งเดิมสำหรับชิ้นส่วนเดียวกันกับ EVM และอาศัยโค้ดของตัวเองเท่านั้นในการจัดการส่วนต่างๆ ซึ่งสามารถทำได้โดยการออกแบบฟังก์ชัน ZK-EVM เพื่อให้ผู้เรียกสามารถระบุบิตฟิลด์หรือ opcode หรือรายการที่อยู่ ซึ่งจะถูกประมวลผลโดยตารางที่จัดเตรียมไว้ภายนอก แทนที่จะเป็นโดย EVM เอง เรายังสามารถปรับแต่งค่าน้ำมันได้ในระดับหนึ่งอีกด้วย
ระบบหลายไคลเอนต์ เปิด และ ปิด
แนวคิดแบบหลายลูกค้า อาจเป็นข้อกำหนดที่มีการถกเถียงกันมากที่สุดในรายการนี้ ทางเลือกหนึ่งคือการละทิ้งลูกค้าหลายรายและมุ่งเน้นไปที่รูปแบบ ZK-SNARK ซึ่งจะทำให้การออกแบบง่ายขึ้น แต่ราคาถือเป็น การเปลี่ยนแปลงทางปรัชญา ที่ใหญ่กว่าสำหรับ Ethereum (เพราะนี่คือการละทิ้งความคิดแบบหลายลูกค้าที่มีมายาวนานของ Ethereum) และก่อให้เกิดความเสี่ยงที่มากขึ้น ในอนาคตระยะยาว เช่น เมื่อเทคโนโลยีการตรวจสอบอย่างเป็นทางการดีขึ้น ก็อาจดีกว่าหากไปทางนี้ แต่ตอนนี้กลับดูเสี่ยงเกินไป
อีกทางเลือกหนึ่งคือระบบหลายไคลเอนต์แบบปิด ซึ่งมีชุดระบบการรับรองคงที่ซึ่งเป็นที่รู้จักภายในโปรโตคอล ตัวอย่างเช่น เราอาจตัดสินใจใช้ ZK-EVM สามรายการ ได้แก่ PSE ZK-EVM, Polygon ZK-EVM และ Kakarot บล็อกต้องมีการพิสูจน์อย่างน้อยสองในสามข้อนี้จึงจะมีผล สิ่งนี้ดีกว่าระบบพิสูจน์อักษรตัวเดียว แต่มันทำให้ระบบปรับตัวได้น้อยลง เนื่องจากผู้ใช้ต้องรักษาเครื่องมือตรวจสอบความถูกต้องสำหรับระบบพิสูจน์ทุกระบบที่มีอยู่ จะมีกระบวนการกำกับดูแลที่หลีกเลี่ยงไม่ได้ในการรวมระบบพิสูจน์ใหม่ ฯลฯ
สิ่งนี้ทำให้ฉันชอบระบบหลายลูกค้าแบบเปิด โดยที่การพิสูจน์จะถูกวางไว้ นอกกลุ่ม และตรวจสอบทีละรายโดยลูกค้า ผู้ใช้แต่ละรายจะใช้ไคลเอนต์อะไรก็ตามที่พวกเขาต้องการตรวจสอบความถูกต้องของบล็อก และพวกเขาสามารถทำเช่นนี้ได้ตราบใดที่มีผู้พิสูจน์อย่างน้อยหนึ่งรายที่สร้างการพิสูจน์สำหรับระบบพิสูจน์นั้น ระบบพิสูจน์จะได้รับอิทธิพลจากการโน้มน้าวให้ผู้ใช้เรียกใช้ ไม่ใช่โดยการโน้มน้าวกระบวนการกำกับดูแลโปรโตคอล อย่างไรก็ตาม วิธีการนี้มีค่าใช้จ่ายที่ซับซ้อนมากขึ้น ดังที่เราจะได้เห็น
เราต้องการคุณสมบัติหลักอะไรบ้างในการใช้งาน ZK-EVM
นอกจากความถูกต้องพื้นฐานและการรับประกันความปลอดภัยแล้ว คุณลักษณะที่สำคัญที่สุดก็คือความเร็ว แม้ว่าจะสามารถออกแบบโปรโตคอลอะซิงโครนัสที่มีฟังก์ชัน ZK-EVM ในตัวได้ และแต่ละคำสั่งจะส่งคืนผลลัพธ์หลังจากช่อง N เท่านั้น ปัญหาจะง่ายขึ้นหากเราสามารถรับประกันได้อย่างน่าเชื่อถือว่าสามารถสร้างการพิสูจน์ได้ภายในไม่กี่วินาที มากมายจนสิ่งที่เกิดขึ้นในแต่ละบล็อกนั้นพึ่งตนเองได้
แม้ว่าการสร้างการพิสูจน์สำหรับบล็อก Ethereum ในปัจจุบันจะใช้เวลาไม่กี่นาทีหรือหลายชั่วโมง แต่เราไม่ทราบเหตุผลทางทฤษฎีที่จะป้องกันการขนานกันจำนวนมาก: เราสามารถรวบรวม GPU ได้เพียงพอที่จะพิสูจน์การดำเนินการของบล็อกทีละส่วน ส่วนต่างๆ จากนั้นใช้ SNARK แบบเรียกซ้ำเพื่อรวมการพิสูจน์เหล่านี้เข้าด้วยกัน . นอกจากนี้ กระบวนการพิสูจน์ยังสามารถปรับให้เหมาะสมเพิ่มเติมได้ผ่านการเร่งด้วยฮาร์ดแวร์ผ่าน FPGA และ ASIC อย่างไรก็ตาม การบรรลุเป้าหมายนี้เป็นความท้าทายทางวิศวกรรมที่ไม่ควรมองข้าม
ฟังก์ชั่น ZK-EVM ภายในโปรโตคอลมีลักษณะอย่างไร
เช่นเดียวกับธุรกรรม Blob EIP-4844 เราได้แนะนำประเภทธุรกรรมใหม่ที่มีการอ้างสิทธิ์ ZK-EVM:
class ZKEVMClaimTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
transaction_and_witness_blob_pointers: List[VersionedHash]
...
เช่นเดียวกับ EIP-4844 อ็อบเจ็กต์ที่ส่งผ่านใน mempool เป็นเวอร์ชันที่แก้ไขของธุรกรรม:
class ZKEvmClaimNetworkTransaction(Container):
pre_state_root: bytes 32
post_state_root: bytes 32
proof: bytes
transaction_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]
หลังสามารถแปลงเป็นอดีตได้ แต่ไม่ใช่ในทางกลับกัน นอกจากนี้ เรายังขยายออบเจ็กต์ Sidecar ของบล็อก (แนะนำใน EIP-4844) เพื่อรวมรายการข้อพิสูจน์ที่ประกาศไว้ในบล็อกด้วย
โปรดทราบว่าในทางปฏิบัติ เราอาจต้องการแยก sidecar ออกเป็นสอง sidecar แยกกัน ตัวแรกสำหรับ blob และอีกอันสำหรับการพิสูจน์ และมีซับเน็ตแยกกันสำหรับการพิสูจน์แต่ละประเภท (และอีกอันสำหรับซับเน็ตเพิ่มเติมของ blob)
ที่ชั้นฉันทามติ เราได้เพิ่มกฎการตรวจสอบที่ลูกค้าจะยอมรับการบล็อกก็ต่อเมื่อเห็นหลักฐานที่ถูกต้องของการอ้างสิทธิ์แต่ละรายการในบล็อก การพิสูจน์จะต้องเป็นการต่อกันของการพิสูจน์ ZK-SNARK คู่ของ Transaction_and_witness_blobs ที่ต่อเนื่องกัน และ pre_state_root โดยใช้ (i) valid และ Witness (ii) แสดงผล post_state_root ที่ถูกต้อง (Block, Witness) อาจเป็นไปได้ที่ลูกค้าสามารถเลือกที่จะรอได้ การพิสูจน์ประเภท M-of-N หลายรายการ
หมายเหตุประการหนึ่งที่นี่คือการดำเนินการบล็อกนั้นสามารถดูได้ว่าเป็นแฝด (σpre, σpost, Proof) ที่จำเป็นต้องตรวจสอบพร้อมกับแฝดที่ให้ไว้ในออบเจ็กต์ ZKEVMClaimTransaction
ดังนั้น การใช้งาน ZK-EVM ของผู้ใช้จึงสามารถแทนที่ไคลเอ็นต์การดำเนินการได้ โดยไคลเอ็นต์การดำเนินการจะยังคงถูกใช้โดย (i) ผู้พิสูจน์และผู้สร้างบล็อก และ (ii) โหนดที่สนใจเกี่ยวกับการจัดทำดัชนีและการจัดเก็บข้อมูลสำหรับการใช้งานในเครื่อง
ตรวจสอบและตรวจสอบอีกครั้ง
สมมติว่ามีไคลเอนต์ Ethereum สองเครื่อง เครื่องหนึ่งใช้ PSE ZK-EVM และอีกเครื่องหนึ่งใช้ Polygon ZK-EVM สมมติว่า ณ จุดนี้ การใช้งานทั้งสองได้พัฒนาจนถึงจุดที่สามารถพิสูจน์การดำเนินการของบล็อก Ethereum ได้ภายใน 5 วินาที และสำหรับแต่ละระบบการพิสูจน์ จะมีอาสาสมัครอิสระเพียงพอที่จะรันฮาร์ดแวร์เพื่อสร้างการพิสูจน์
น่าเสียดายที่เนื่องจากไม่มีระบบพิสูจน์อิสระในตัว จึงไม่สามารถจูงใจในโปรโตคอลได้ อย่างไรก็ตาม เราคาดว่าค่าใช้จ่ายในการใช้งานเครื่องพิสูจน์จะต่ำเมื่อเทียบกับต้นทุนด้าน RD ดังนั้นเราจึงสามารถใช้อำนาจร่วมกันสำหรับเครื่องพิสูจน์ได้ จัดหาเงินทุนสำหรับสินค้าสาธารณะ
สมมติว่ามีคนเผยแพร่ ZKEvmClaimNetworkTransaction แต่พวกเขาเผยแพร่เฉพาะเวอร์ชันของการพิสูจน์ PSE ZK-EVM เท่านั้น โหนดพิสูจน์ของ Polygon ZK-EVM มองเห็นสิ่งนี้ และใช้การพิสูจน์ของ Polygon ZK-EVM เพื่อคำนวณและเผยแพร่ออบเจ็กต์อีกครั้ง
สิ่งนี้จะเพิ่มการหน่วงเวลาสูงสุดโดยรวมระหว่างโหนดซื่อสัตย์แรกสุดที่ยอมรับบล็อกและโหนดซื่อสัตย์ล่าสุดที่ยอมรับบล็อกเดียวกัน δ: 2 δ + Tprove (สมมติว่า Tprove<5 s ）。
อย่างไรก็ตาม ข่าวดีก็คือ หากเราใช้จุดสิ้นสุดของช่องเดียว เราก็จะสามารถ ไปป์ไลน์ เวลาแฝงเพิ่มเติมนี้ได้อย่างแน่นอน ควบคู่ไปกับเวลาแฝงที่เป็นเอกฉันท์แบบหลายรอบโดยธรรมชาติของ SSF ตัวอย่างเช่น ในข้อเสนอแบบ 4 ช่องย่อย ขั้นตอน การโหวตหลัก อาจต้องการเพียงการตรวจสอบความถูกต้องของบล็อกฐานเท่านั้น แต่ขั้นตอน หยุดและยืนยัน จะต้องมีการพิสูจน์การมีอยู่
ส่วนขยาย: รองรับ EVM โดยประมาณ
เป้าหมายในอุดมคติของคุณสมบัติ ZK-EVM คือการสนับสนุน near-EVM: EVM ที่มีฟังก์ชันพิเศษบางอย่างในตัว ซึ่งอาจรวมถึงการคอมไพล์ล่วงหน้าใหม่ opcode ใหม่ หรือแม้แต่ตัวเลือกที่สามารถเขียนสัญญาใน EVM หรือเครื่องเสมือนที่แตกต่างไปจากเดิมอย่างสิ้นเชิง (เช่น เช่นใน Arbitrum Stylus) หรือแม้แต่หลายแนวขนานกับ EVM การสื่อสารข้ามที่ซิงโครไนซ์
การแก้ไขบางอย่างสามารถรองรับด้วยวิธีง่ายๆ: เราสามารถกำหนดภาษาที่อนุญาตให้ ZKEVMClaimTransaction ส่งคำอธิบายที่สมบูรณ์ของกฎ EVM ที่ถูกแก้ไข ซึ่งสามารถทำได้:
ตารางแก๊สแบบกำหนดเอง (ผู้ใช้ไม่สามารถลดต้นทุนค่าแก๊สได้ แต่สามารถเพิ่มได้)
ปิดการใช้งาน opcodes บางอย่าง
ตั้งค่าหมายเลขบล็อก (ซึ่งจะหมายถึงกฎที่แตกต่างกันขึ้นอยู่กับฮาร์ดฟอร์ก)
ตั้งค่าสถานะที่เปิดใช้งานชุดการเปลี่ยนแปลง EVM ที่เป็นมาตรฐานสำหรับการใช้ L2 แทนการใช้ L1 หรือการเปลี่ยนแปลงอื่น ๆ ที่ง่ายกว่า
เพื่อให้ผู้ใช้สามารถเพิ่มคุณสมบัติใหม่ในลักษณะที่เปิดกว้างมากขึ้น โดยการแนะนำการคอมไพล์ล่วงหน้าใหม่ (หรือ opcodes) เราสามารถเพิ่มบันทึกอินพุต/เอาท์พุตที่คอมไพล์แล้วลงใน blob ของ ZKEVMClaimNetworkTransaction:
class PrecompileInputOutputTranscript(Container):
used_precompile_addresses: List[Address]
inputs_commitments: List[VersionedHash]
outputs: List[Bytes]
การดำเนินการ EVM จะได้รับการแก้ไขดังนี้ เริ่มต้นอาร์เรย์อินพุตว่าง เมื่อใดก็ตามที่มีการเรียกที่อยู่ใน used_precompile_addresses เราจะเพิ่มออบเจ็กต์ InputsRecord(callee_address, gas, input_calldata) ให้กับอินพุตและตั้งค่า RETURNDATA ของการเรียกเป็นเอาต์พุต [i] สุดท้ายนี้ เราตรวจสอบว่า used_precompile_addresses ถูกเรียกเป็นจำนวนครั้งของ len(outputs) และ inputs_commitments ตรงกับผลลัพธ์ของการทำให้เป็นอนุกรม SSZ ของอินพุตที่สร้างข้อผูกพัน blob วัตถุประสงค์ของการเปิดเผย inputs_commitments คือเพื่อให้ SNARK ภายนอกสามารถพิสูจน์ความสัมพันธ์ระหว่างอินพุตและเอาต์พุตได้ง่ายขึ้น
สังเกตความไม่สมดุลระหว่างอินพุตและเอาต์พุต อินพุตจะถูกเก็บไว้ในแฮช และเอาต์พุตจะถูกเก็บไว้ในไบต์ที่ต้องระบุ เนื่องจากการดำเนินการจะต้องดำเนินการโดยไคลเอนต์ที่เห็นเฉพาะอินพุตและเข้าใจ EVM การดำเนินการ EVM ได้สร้างอินพุตสำหรับพวกเขาแล้ว ดังนั้นพวกเขาเพียงต้องตรวจสอบว่าอินพุตที่สร้างขึ้นตรงกับอินพุตที่อ้างสิทธิ์ ซึ่งต้องใช้เพียงการตรวจสอบแฮชเท่านั้น อย่างไรก็ตาม จะต้องจัดเตรียมเอาต์พุตให้กับพวกเขาอย่างครบถ้วน ดังนั้นจึงต้องเป็นข้อมูลที่ใช้งานได้
คุณสมบัติที่มีประโยชน์อีกอย่างหนึ่งคือการอนุญาต ธุรกรรมที่ได้รับสิทธิพิเศษ ซึ่งสามารถเรียกจากบัญชีผู้ส่งใดก็ได้ ธุรกรรมเหล่านี้สามารถรันระหว่างธุรกรรมอื่นสองรายการ หรือเมื่อมีการเรียกการคอมไพล์ล่วงหน้า โดยเป็นส่วนหนึ่งของธุรกรรมอื่น (อาจมีสิทธิพิเศษด้วย) ซึ่งสามารถใช้เพื่ออนุญาตให้กลไกที่ไม่ใช่ EVM โทรกลับเข้าสู่ EVM
การออกแบบนี้อาจได้รับการแก้ไขเพื่อรองรับ opcode ใหม่หรือที่แก้ไข นอกเหนือจากการคอมไพล์ล่วงหน้าใหม่หรือที่แก้ไข แม้จะเป็นเพียงการคอมไพล์ล่วงหน้า แต่การออกแบบนี้ก็ค่อนข้างทรงพลัง ตัวอย่างเช่น:
ด้วยการตั้งค่า used_precompile_addresses ให้รวมรายการที่อยู่บัญชีปกติพร้อมแฟล็กบางอย่างในสถานะ และการสร้าง SNARK เพื่อพิสูจน์ว่ามันถูกสร้างขึ้นอย่างถูกต้อง คุณสามารถรองรับฟังก์ชันสไตล์ Arbitrum Stylus ซึ่งสามารถเขียนสัญญาได้โดยใช้ EVM หรือ WASM (หรืออื่น ๆ วีเอ็ม) ธุรกรรมที่มีสิทธิพิเศษสามารถใช้เพื่ออนุญาตให้บัญชี WASM โทรกลับเข้าสู่ EVM
คุณสามารถพิสูจน์ระบบคู่ขนานของ EVM หลายตัวที่พูดคุยกันผ่านช่องทางที่ซิงโครไนซ์โดยการเพิ่มการตรวจสอบภายนอกเพื่อให้แน่ใจว่าบันทึกอินพุต/เอาท์พุตและธุรกรรมสิทธิพิเศษที่ดำเนินการโดย EVM หลายตัวตรงกันในวิธีที่ถูกต้อง
ZK-EVM ประเภท 4 สามารถทำงานได้โดยมีการใช้งานหลายแบบ: แบบหนึ่งที่แปลง Solidity หรือภาษาระดับสูงอื่นๆ โดยตรงให้เป็น VM ที่เป็นมิตรกับ SNARK และอีกแบบหนึ่งจะคอมไพล์เป็นโค้ด EVM และสร้างลงใน ZK-EVM Implement การใช้งานครั้งที่สอง (ช้ากว่าอย่างหลีกเลี่ยงไม่ได้) สามารถทำงานได้ก็ต่อเมื่อตัวพิสูจน์ข้อบกพร่องส่งธุรกรรมที่ยืนยันจุดบกพร่อง และรวบรวมเงินรางวัลหากพวกเขาสามารถให้ทั้งสองจัดการธุรกรรมต่างกันได้
VM แบบอะซิงก์ล้วนๆ สามารถนำมาใช้ได้โดยทำให้การโทรทั้งหมดคืนค่าศูนย์ และแมปการโทรไปยังธุรกรรมที่ได้รับสิทธิพิเศษที่เพิ่มไว้ที่จุดสิ้นสุดของบล็อก
ส่วนขยาย: การสนับสนุนผู้พิสูจน์สถานะ
ความท้าทายประการหนึ่งของการออกแบบข้างต้นคือไม่มีสถานะโดยสิ้นเชิง ซึ่งทำให้ข้อมูลไม่มีประสิทธิภาพ ภายใต้การบีบอัดข้อมูลในอุดมคติ การส่ง ERC 20 พร้อมการบีบอัดแบบ stateful จะสามารถประหยัดพื้นที่ได้มากกว่าการบีบอัดแบบ stateful เพียงอย่างเดียวถึง 3 เท่า
นอกจากนี้ EVM แบบมีสถานะไม่จำเป็นต้องให้ข้อมูลพยาน ในทั้งสองกรณี หลักการจะเหมือนกัน: การกำหนดให้ข้อมูลพร้อมใช้งานเมื่อเรารู้แล้วว่าข้อมูลนั้นพร้อมใช้งาน เนื่องจากข้อมูลดังกล่าวถูกป้อนหรือสร้างขึ้นในการดำเนินการ EVM ก่อนหน้านี้ถือเป็นการสิ้นเปลือง
หากเราต้องการให้ฟีเจอร์ ZK-EVM มีการเก็บสถานะ เราก็มีสองตัวเลือก:
1) กำหนดให้ σpre ว่างเปล่า รายการข้อมูลที่มีอยู่พร้อมคีย์และค่าที่ประกาศ หรือ σpost ดำเนินการก่อนหน้านี้
2) เพิ่มข้อผูกพันหยดลงในใบเสร็จรับเงินที่สร้างโดยบล็อก R ให้กับกลุ่มแฝด (σpre, σpost, Proof) ข้อผูกพัน Blob ที่สร้างขึ้นหรือใช้ก่อนหน้านี้ รวมถึงที่เป็นตัวแทนของบล็อก พยาน ใบเสร็จรับเงิน หรือแม้แต่ธุรกรรม Blob EIP-4844 ธรรมดา อาจมีข้อจำกัดด้านเวลาและอาจอ้างอิงใน ZKEVMLaimTransaction และเข้าถึงได้ระหว่างการดำเนินการ (อาจเป็นไปได้ผ่านชุดคำสั่ง: แทรกไบต์ N...N+k-1 ของความมุ่งมั่น i ลงในตำแหน่ง j ของบล็อก + ข้อมูลพยาน)
ตัวเลือกที่หนึ่งหมายถึง: แทนที่จะใช้การตรวจสอบ EVM ไร้สถานะในตัว ให้สร้างในเครือข่ายย่อย EVM ตัวเลือกที่สองโดยพื้นฐานแล้วคือการสร้างอัลกอริธึมการบีบอัด stateful ในตัวขั้นต่ำที่ใช้ blobs ที่ใช้ก่อนหน้านี้หรือสร้างขึ้นเป็นพจนานุกรม ทั้งสองวิธีจะสร้างภาระให้กับโหนดพิสูจน์เพียงโหนดพิสูจน์เท่านั้นที่ต้องเก็บข้อมูลเพิ่มเติม ในกรณีที่สอง จะเป็นการง่ายกว่าที่จะทำให้ภาระนี้จำกัดเวลามากกว่ากรณีที่หนึ่ง
พารามิเตอร์สำหรับโปรเวอร์หลายตัวที่ปิดและข้อมูลออฟเชน
ระบบหลายผู้พิสูจน์แบบปิด ซึ่งมีจำนวนผู้พิสูจน์แบบคงที่ในโครงสร้าง M-of-N จะช่วยหลีกเลี่ยงความซับซ้อนข้างต้นหลายประการ โดยเฉพาะอย่างยิ่ง ระบบผู้รับรองหลายรายแบบปิดไม่จำเป็นต้องกังวลเกี่ยวกับการรับรองว่าข้อมูลอยู่ในเครือข่ายออนไลน์ นอกจากนี้ ระบบ multi-prover แบบปิดจะช่วยให้สามารถดำเนินการพิสูจน์ ZK-EVM แบบออฟไลน์ได้ ทำให้สามารถทำงานร่วมกับโซลูชัน EVM Plasma ได้
อย่างไรก็ตาม ระบบผู้รับรองหลายรายแบบปิดจะเพิ่มความซับซ้อนในการกำกับดูแลและขจัดความสามารถในการตรวจสอบ ซึ่งเป็นค่าใช้จ่ายสูงที่ต้องนำมาชั่งน้ำหนักเทียบกับผลประโยชน์เหล่านี้
หากเราสร้าง ZK-EVM และทำให้เป็นฟีเจอร์โปรโตคอล บทบาทของ โปรเจ็กต์ Layer 2 คืออะไร
ฟังก์ชันการตรวจสอบ EVM ที่ทีมเลเยอร์ 2 ใช้งานในปัจจุบันนั้นจะได้รับการจัดการโดยโปรโตคอล แต่โครงการเลเยอร์ 2 ยังคงรับผิดชอบหน้าที่ที่สำคัญหลายประการ:
การยืนยันล่วงหน้าที่รวดเร็ว: การสิ้นสุดของสล็อตเดียวอาจทำให้สล็อตของเลเยอร์ 1 ช้าลง และโปรเจ็กต์ของเลเยอร์ 2 กำลังให้ การยืนยันล่วงหน้า แก่ผู้ใช้แล้ว ซึ่งได้รับการสนับสนุนโดยความปลอดภัยของเลเยอร์ 2 เอง โดยมีเวลาแฝงที่ต่ำกว่ามากในช่องเดียว บริการนี้จะยังคงได้รับการจัดการเต็มรูปแบบโดยเลเยอร์ 2
กลยุทธ์การลดทอน MEV (ค่าที่สกัดได้จากการขุด): ซึ่งอาจรวมถึง mempool ที่เข้ารหัส การเลือกผู้สั่งซื้อตามชื่อเสียง และคุณสมบัติอื่น ๆ ที่เลเยอร์ 1 ไม่เต็มใจที่จะนำไปใช้
ส่วนขยายไปยัง EVM: โปรเจ็กต์เลเยอร์ 2 สามารถให้ส่วนขยายที่สำคัญแก่ EVM แก่ผู้ใช้ได้ ซึ่งรวมถึง EVM โดยประมาณ และแนวทางที่แตกต่างกันโดยพื้นฐาน เช่น การรองรับ WASM ของ Arbitrum Stylus และภาษาไคโรที่เป็นมิตรกับ SNARK
ความสะดวกสบายสำหรับผู้ใช้และนักพัฒนา: ทีมงาน Layer 2 ทำงานมากมายเพื่อดึงดูดผู้ใช้และโครงการเข้าสู่ระบบนิเวศของพวกเขา และทำให้พวกเขารู้สึกเป็นที่ต้อนรับ พวกเขาได้รับการชดเชยด้วยการเก็บ MEV และค่าธรรมเนียมความแออัดภายในเครือข่ายของพวกเขา ความสัมพันธ์นี้จะยังคงอยู่ต่อไป
