ผู้เขียนต้นฉบับ -Lisa Akselrod
คอมไพล์ - Odaily 0xAyA
หมายเหตุบรรณาธิการ: ผู้เขียนเรียบเรียงโดยอ้างอิงจากบทความแนะนำ ZK-EVM ที่เขียนโดย Vitalik ก่อนหน้านี้ และแนะนำโดยละเอียดเกี่ยวกับ ZK-EVM ประเภทต่างๆ และความแตกต่างระหว่างทั้งสองประเภท
ประมาณหนึ่งปีที่ผ่านมา กลุ่ม ZK-EVM ได้ประกาศเปิดตัวเครือข่ายทดสอบที่กำลังจะมีขึ้น การเคลื่อนไหวเหล่านี้กระตุ้นความอยากรู้อยากเห็นของชุมชน Ethereum และจุดประกายให้เกิดการอภิปรายเกี่ยวกับความแตกต่างเบื้องหลังคำต่างๆ เช่น ความเท่าเทียมกันของ Ethereum และ ความเท่าเทียมกันของ EVM
เพื่อชี้แจงให้กระจ่าง Vitalik ได้เขียนบทความสำคัญเรื่องZK-EVM ประเภทต่างๆแบ่ง ZK-EVM ต่างๆ ออกเป็นสี่ประเภทและอธิบายความแตกต่าง
แนวคิดหลักคือ: ประเภท 1 (เช่น Taiko) เทียบเท่ากับ Ethereum โดยสมบูรณ์ ในขณะที่ประเภท 4 (เช่น zkSync) เป็นเลิศในการสร้างหลักฐานที่มีประสิทธิภาพ ประเภทอื่นๆ ทั้งหมด ประเภท 2, ประเภท 2.5 และประเภท 3 อยู่ระหว่างนั้น (เช่น Polygon zkEVM, Scroll, Linea)
ZK-EVM ส่วนใหญ่เป็น Type 2.5 และ Type 3 ในตอนแรก โดยมีการเปิดเผยความตั้งใจบางประการในการก้าวไปสู่ Type 1 หรือ Type 2 แม้ว่าโครงการเหล่านี้จะไม่ได้ระบุกำหนดเวลาหรือข้อผูกพันที่เฉพาะเจาะจงสำหรับสิ่งนี้
บทความนี้มุ่งเน้นไปที่ความแตกต่างระหว่างประเภท 1 และประเภท 2/ประเภท 2.5 และอธิบายผลที่ตามมาที่เป็นไปได้ของการทำลายความเท่าเทียมกันของ Ethereum เราจะกล่าวถึงประเภทอื่นๆ สั้นๆ ด้วย
เป้าหมายหลักของ ZK-EVM คือการปรับขนาด Ethereum กล่าวคือ เพิ่มปริมาณงานของ Ethereum ในขณะที่ยังคงคุณสมบัติอื่นๆ ไว้ (ความปลอดภัย ประสบการณ์ของนักพัฒนา ฯลฯ) ตามหลักการแล้ว ZK-EVM ควรสามารถ:
การดำเนินการที่ได้รับการพิสูจน์แล้วของโค้ดไบต์ดั้งเดิมที่ยังไม่ได้แก้ไข (ครอบคลุม 100% ของ opcode ของ Ethereum) ตามข้อกำหนด Ethereum Virtual Machine ใน Yellow Book
สร้างการพิสูจน์อย่างรวดเร็วและราคาถูก
อนุญาตให้นำเครื่องมือและโครงสร้างพื้นฐานที่พัฒนาขึ้นสำหรับ Ethereum มาใช้ซ้ำได้ 100%
อนุญาตให้ปรับใช้ Ethereum dApp ใดๆ บน ZK-EVM “ตามที่เป็น” (“ตามสภาพ” หมายความว่าไม่จำเป็นต้องเปลี่ยนแปลง ไม่มีการประนีประนอม)
ความแตกต่างระหว่างประเภท ZK-EVM
ในพื้นที่ ZK-EVM ความแตกต่างส่วนใหญ่มาจากระดับความเท่าเทียมกันของ Ethereum/EVM ผลกระทบขององค์ประกอบที่ไม่เป็นมิตรกับ ZK ต่อต้นทุนและความเร็วในการสร้างการพิสูจน์ และความซับซ้อนของการใช้งานวงจร (เช่น การสร้าง VM หรือแผนผังสถานะ) .
มาวิเคราะห์ความแตกต่างเหล่านี้ โดยเฉพาะการแยกประเภท 1 จากประเภท 2/ประเภท 2.5 นอกจากนี้ เราจะพูดถึงกรณีการใช้งานที่เกี่ยวข้องกับแต่ละประเภทมากที่สุด
เมื่อเปรียบเทียบประเภทต่างๆ มักใช้แผนภูมิต่อไปนี้:
สำหรับผู้ที่ไม่ได้ทำงานเต็มเวลาในสาขา ZK-EVM ตารางนี้อาจดูสับสน ดังนั้นลองแปลคำศัพท์เหล่านี้เป็นคำศัพท์ของคนทั่วไปแล้วลองดู:
แผนภาพนี้ให้ภาพที่ชัดเจนว่าแท้จริงแล้วแต่ละประเภทเป็นอย่างไร แต่ก็ยังอาจคลุมเครืออยู่บ้าง ดังนั้น มาสำรวจโลกของ ZK-EVM กันอย่างเต็มที่ด้วยการอธิบายแต่ละประเภทแยกกัน
ประเภทที่ 1: เทียบเท่ากับ Ethereum
“ZK-EVM ประเภท 1 คือสิ่งที่เราต้องการในที่สุดเพื่อทำให้ Ethereum Layer 1 สามารถปรับขนาดได้มากขึ้น”
ประเภทที่ 1 หมายถึง การไม่เปลี่ยนแปลงส่วนใดๆ ของระบบ Ethereum เพื่อให้สร้างการพิสูจน์ได้ง่ายขึ้น การไม่มีการเปลี่ยนแปลงใน Ethereum หมายความว่าไม่มีการประนีประนอมด้านความปลอดภัย เนื่องจากการเข้ารหัสแบบดั้งเดิมส่วนใหญ่ (เช่น ฟังก์ชันแฮช) โครงสร้างพื้นฐานของนักพัฒนา (เช่น ดีบักเกอร์) หรือโครงสร้างพื้นฐานของลูกโซ่ (เช่น ไคลเอนต์การดำเนินการ) ได้ทำการทดสอบภาคสนามเป็นเวลา 9 ปีแล้ว
Type 1 ZK-EVM ไม่ได้แทนที่สิ่งใดเลย: แฮช, แผนผังสถานะ, แผนผังธุรกรรม, การคอมไพล์ล่วงหน้า หรือตรรกะที่เป็นเอกฉันท์อื่น ๆ ทุกอย่างจะเหมือนกับ EVM ของ mainnet ทุกประการ
ประเภทที่ 1 เป็นประเภทเดียวที่สามารถตรวจสอบห่วงโซ่ Ethereum ได้ ตั้งแต่บล็อกทั้งหมดไปจนถึงการดำเนินการธุรกรรม สัญญาอัจฉริยะ และตรรกะของบัญชี
ประเภทที่ 2: เทียบเท่ากับ EVM
ประเภทที่ 2 ทำให้การสร้างหลักฐานเร็วขึ้นและการพัฒนาวงจรง่ายขึ้นโดยการถอดชิ้นส่วนบางส่วนที่ไม่เอื้อต่อ ZK ออก อย่างไรก็ตาม เนื่องจากผลที่ตามมา อาจทำให้การพัฒนาส่วนอื่นๆ ของ ZK-rollup (เช่น ซอฟต์แวร์โหนด) มีความซับซ้อนมากขึ้น ความซับซ้อนเหล่านี้อาจเกิดจากความไม่เข้ากันระหว่างแนวทางปฏิบัติที่ดีที่สุดและเครื่องมือทดสอบที่กำหนดไว้กับการเปลี่ยนแปลงที่กำลังดำเนินการ (เช่น แผนผังสถานะที่เปลี่ยนแปลง)
หมายเหตุ: เทียบเท่ากับ Ethereum และเทียบเท่ากับ EVM นั้นไม่เหมือนกัน แม้ว่าความเท่าเทียมกันกับ Ethereum หมายความว่าไม่มีการเปลี่ยนแปลงส่วนใดส่วนหนึ่งของ Ethereum กล่าวคือ เข้ากันได้กับ Ethereum dApps ทั้งหมดอย่างสมบูรณ์ ความเท่าเทียมกันกับ EVM ช่วยให้สามารถเปลี่ยนแปลงโครงสร้างข้อมูลได้ (เช่น โครงสร้างบล็อกหรือแผนผังสถานะ)
แม้ว่าการปรับเปลี่ยนเหล่านี้อาจดูเล็กน้อย แต่ก็ส่งผลต่อความเข้ากันได้ของ Ethereum การเปลี่ยนแปลงโครงสร้างข้อมูลอาจทำให้ Ethereum dApps เข้ากันไม่ได้กับ Type 2 ZK-EVM โดยเฉพาะอย่างยิ่งเมื่อตรวจสอบการพิสูจน์ Merkle เกี่ยวกับธุรกรรม ใบเสร็จรับเงิน หรือสถานะในอดีต (เช่น สะพานข้ามสายโซ่)
ลบองค์ประกอบที่ไม่เป็นมิตรของ ZK
การปรับเปลี่ยน Ethereum มีจุดมุ่งหมายเพื่อทำให้การพัฒนาง่ายขึ้นและเพิ่มความเร็วในการสร้างหลักฐาน เป้าหมายคือการตัดส่วนของ Ethereum ที่ต้องอาศัยการเข้ารหัสที่ไม่มีความรู้ที่ไม่เป็นมิตร ในแง่เทคนิคมากขึ้น ส่วนที่ต้องใช้เกตจำนวนมาก (การดำเนินการบวกและการคูณ) เนื่องจากไม่ใช่โดเมนภายในเครื่อง (เช่น ฟังก์ชันแฮช) การคูณแบบหลายสเกลาร์จำนวนมาก และ/หรือการแปลงฟูเรียร์แบบเร็ว (FFT) หรือเพียงส่วนที่ต้องใช้การยักย้ายมาก
ตัวอย่างเฉพาะขององค์ประกอบความรู้เป็นศูนย์ที่ไม่เป็นมิตรซึ่ง ZK-EVM ประเภท 2 อาจแก้ไขได้:
ฟังก์ชันแฮช: แม้ว่า Ethereum จะใช้ฟังก์ชันแฮช Keccak แต่ ZK-EVM จำนวนมากใช้ฟังก์ชันแฮชของ Poseidon ซึ่งต้องใช้เกตน้อยกว่ามาก ตัวอย่างเช่น ลองประมาณจำนวนฟังก์ชันแฮชของแต่ละประเภทที่สามารถคำนวณได้ต่อวินาที (เช่น การเปรียบเทียบที่แสดงให้เห็นถึงความเร็วของการสร้าง)
ฟังก์ชันแฮชของโพไซดอนมีข้อดีด้านความเร็วอย่างมากในการสร้างการพิสูจน์
อย่างไรก็ตาม สิ่งสำคัญคือต้องทราบว่าการเข้ารหัสลับแบบดั้งเดิมที่ใหม่กว่านั้นไม่ได้รับความนิยมเมื่อเทียบกับการเข้ารหัสแบบดั้งเดิมที่ได้รับการยอมรับอย่างกว้างขวางจากชุมชน แม้ว่าโพไซดอนอาจให้ความเร็ว แต่คุณสมบัติที่ผ่านการทดสอบการต่อสู้ของ Keccak ทำให้มีความแข็งแกร่งและปลอดภัยมากขึ้น เมื่อมีการใช้กันอย่างแพร่หลายมากขึ้น
นี่คือสาเหตุที่ Keccak แม้จะอายุมากขึ้นและได้รับการยอมรับจากชุมชนในวงกว้าง (ในอุตสาหกรรมอื่น ๆ เช่นระบบรักษาความปลอดภัยหรือเซ็นเซอร์ในอุปกรณ์อัจฉริยะ) ก็ถือว่าได้รับการทดสอบและทดสอบมากกว่า Poseidon ซึ่งท้ายที่สุดแล้วอยู่ในชุมชน ZK แฮชใหม่ ฟังก์ชั่นในการสร้างและใช้งาน
แผนผังสถานะสำหรับการจัดเก็บข้อมูล: เช่น ในขณะที่ Ethereum ใช้ต้นแมร์เคิล แพทริเซีย(ใช้แฮช Keccak) แต่มีตัวเลือก Type 2 ZK-EVM บางตัวต้นไม้ Merkle กระจัดกระจาย(ใช้การแฮชของโพไซดอน) การเปลี่ยนแผนผังสถานะอาจทำให้เกิดความไม่เข้ากันบางอย่าง ตัวอย่างเช่น Merkle tree ของ Ethereum มีประเภทโหนดที่แตกต่างกัน และใช้ RLP เพื่อเข้ารหัสข้อมูล ซึ่งเป็นเรื่องยากที่จะทำใน ZK
โครงสร้างบล็อก: บล็อกประกอบด้วยข้อมูลจำนวนมาก อย่างไรก็ตาม เมื่อสำรวจ L2 เราสนใจเฉพาะการดำเนินการ_payload_header เท่านั้น (นั่นคือ แฮชของบล็อก) ในภาพด้านล่าง มีโครงสร้าง (บล็อกแฮช) ของข้อมูลทั้งหมดที่อยู่ในExecution_payload_header
โปรดทราบ: การเปลี่ยนแปลงส่วนประกอบใด ๆ เหล่านี้จะทำลายความเท่าเทียมกันของ Ethereum
ประเภท 2.5: เทียบเท่ากับ EVM โดยพิจารณาจากต้นทุนก๊าซ
ประเภท 2.5 ZK-EVM เพิ่มต้นทุนก๊าซสำหรับการดำเนินงานบางอย่างซึ่งยากต่อการพิสูจน์โดยใช้เทคโนโลยี ZK ใน EVM
เมื่อพิจารณาจากขีดจำกัดก๊าซของ Ethereum ต่อบล็อก (ก๊าซ 30 M) การเพิ่มต้นทุนก๊าซต่อ opcode ส่งผลให้ opcodes ต่อบล็อกน้อยลง ดังนั้นจึงสามารถรวม opcodes ที่ซับซ้อนน้อยกว่าไว้ในบล็อกได้ opcode ที่ง่ายกว่าช่วยให้วงจรมีขนาดเล็กลงและสร้างการพิสูจน์ได้เร็วขึ้น
แก๊สเป็นหน่วยวัดการทำงาน
ราคา Opcode คำนวณเป็นแก๊ส
Opcodes ระบุการดำเนินการภายในคำสั่งภาษาเครื่อง
โปรแกรมคือรายการ opcode แบบคงที่ การทำงานของโปรแกรมคือการติดตามการดำเนินการ
การติดตามการดำเนินการคือรายการลำดับเฉพาะของ opcodes ที่ดำเนินการโดยโปรแกรม
ชิ้นส่วนที่พิสูจน์ ZK ได้ยาก ได้แก่:
Keccak opcodes และ opcodes อื่น ๆ ที่ขึ้นอยู่กับ Keccak
พรีคอมไพล์แล้ว: ฟังก์ชั่นที่ EVM เข้าถึงได้ บางส่วนมีงานที่ซับซ้อนหรือซับซ้อนทางคณิตศาสตร์ เช่น ฟังก์ชันการเข้ารหัส (เช่น blake 2 f หรือ sha 256) พวกเขาไม่ได้ดำเนินการภายใน EVM แต่เป็นฟังก์ชันที่ฮาร์ดโค้ดในไคลเอนต์การดำเนินการและเปิดเผยต่อ EVM โดยใช้ CALL ไปยังที่อยู่พิเศษ
การเข้าถึงหน่วยความจำ: เช่น การเพิ่มขนาดสล็อตหน่วยความจำ (เช่น การใช้ Ethereumการจัดตำแหน่งไบต์ของหน่วยความจำ ในขณะที่ Polygon zkEVM ใช้สล็อตหน่วยความจำ 32 ไบต์) เพื่อให้การเปลี่ยนแปลงนี้เป็นไปได้ จะต้องเปลี่ยนตรรกะภายในของ opcode บางอย่าง (เช่น MLOAD)
ที่เก็บข้อมูล (เช่น การเปลี่ยนฟังก์ชันแฮชหรือแผนผังสถานะตามที่อธิบายไว้ข้างต้น)
การเปลี่ยนแปลงต้นทุนก๊าซอาจลดความเข้ากันได้ของเครื่องมือสำหรับนักพัฒนาและทำให้ dApps บางตัวเสียหาย ตัวอย่างเช่น สัญญาอัจฉริยะที่ดำเนินการ opcodes บ่อยครั้งโดยมีต้นทุนก๊าซเพิ่มขึ้นอาจเกินขีดจำกัดของบล็อกก๊าซและไม่สามารถดำเนินการได้
ประเภทที่ 3: เกือบจะเทียบเท่ากับ EVM
Type 3 ZK-EVM ละเว้นการคอมไพล์ล่วงหน้าที่ไม่สามารถใช้ได้กับ ZK และอาจปรับการเข้าถึงหน่วยความจำและที่เก็บข้อมูล
dApps ที่ต้องอาศัยแอปที่คอมไพล์แล้วที่ถูกลบออกไปจะต้องถูกเขียนใหม่ ในกรณีที่ไม่ปกติ ความแตกต่างระหว่าง Type 3 ZK-EVM และ EVM handle edge case ดั้งเดิมอาจจำเป็นต้องปรับเปลี่ยน dApp
แบบที่ 4 (เทียบเท่าภาษาระดับสูง)
ประเภทที่ 4 อยู่ไกลจาก EVM อยู่แล้ว
ซอร์สโค้ดสัญญาอัจฉริยะที่เขียนด้วยภาษาระดับสูง (เช่น Solidity, Zinc) จะถูกรวบรวมเป็นการนำเสนอระดับกลาง สร้าง opcodes ที่เหมาะสำหรับเครื่องเสมือนที่เป็นมิตรกับ ZK
วิธีการนี้จะหลีกเลี่ยงการสร้างการพิสูจน์ ZK สำหรับแต่ละขั้นตอนการดำเนินการ EVM ซึ่งช่วยลดความพยายามในการพิสูจน์ได้อย่างมาก
แม้ว่าสัญญาจะสามารถคอมไพล์ได้ แต่หาก dApp ใช้โค้ดไบต์ที่เขียนด้วยลายมือของ EVM ก็จำเป็นต้องมีการทำงานเพิ่มเติม
ZK-EVM ประเภท 4 ยังต้องการเครื่องมือสำหรับนักพัฒนาของตัวเอง (ระดับ opcode เท่านั้น) เช่น ดีบักเกอร์และตัวติดตาม
ในวงจร ZK ที่พิสูจน์วิถีการดำเนินการ แต่ละขั้นตอนจะใช้ข้อจำกัด และต้นทุนของแต่ละขั้นตอนคือผลรวมของ opcode ทั้งหมด ดังนั้น Type 4 ZK-EVM จึงได้รับการออกแบบให้ใช้ opcode ที่ซับซ้อนน้อยที่สุดเท่าที่จะทำได้เพื่อเพิ่มประสิทธิภาพ
เป็นที่น่าสังเกตว่า opcodes ที่กำหนดเอง (opcodes ที่ไม่ครอบคลุมใน Ethereum) ทำให้สามารถส่งผ่านคุณสมบัติใหม่ๆ ที่ไม่สามารถทำได้บน Ethereum ตามค่าเริ่มต้น ตัวอย่างเช่น ทำการเรียกหลายครั้งเพื่อดำเนินการผ่านฟีเจอร์สรุปบัญชี หรือเปิดตัวกระเป๋าเงินสัญญาอัจฉริยะโดยใช้โซลูชันที่พร้อมใช้งานทันทีเช่น Argent
สรุป
ประเภท ZK-EVM ที่แตกต่างกันจะให้ความสำคัญกับเป้าหมายและคุณลักษณะที่แตกต่างกัน ประเภทที่ 1 มุ่งเน้นไปที่ความเท่าเทียมกันของ Ethereum ในขณะที่ประเภทที่ 4 จัดลำดับความสำคัญในการสร้างหลักฐานที่มีประสิทธิภาพ ประเภทอื่นๆ ตกอยู่ในระหว่างความสุดขั้วเหล่านี้ และโปรโตคอล Type 2 และ 3 ZK-EVM จำนวนมากได้ประกาศความตั้งใจที่จะเปลี่ยนไปใช้ Ethereum ที่เทียบเท่ากัน
การจำแนกประเภททั้งสี่ประเภทนี้อาจไม่ใช่สถานะสุดท้ายของการรวม ZK และอาจต้องมีการแก้ไขเพิ่มเติมในอนาคต ตัวอย่างเช่น ZK-EVM บางตัวอาจกลายเป็นไฮบริด Type 1/2 อาจพัฒนาโซลูชัน Type 4 (ด้วยประสิทธิภาพสูงสุดที่เป็นไปได้) และจัดเตรียม dApps ด้วยตัวเลือกทั้งสอง ในขณะที่ ZK-EVM ประเภท 3 และ 4 อาจเพิ่มตัวเลือกที่เทียบเท่ากับ Ethereum
IOS
Android