ผู้เขียนข้อความต้นฉบับ: s การรวบรวมข้อความต้นฉบับ: Deep Tide TechFlow
บทความนี้จะสำรวจรายละเอียด ZK-EVM ห้าประเภท แต่ละประเภทมีสถาปัตยกรรมเฉพาะ ข้อดีและข้อเสีย และแนวทางแก้ไขที่เป็นไปได้
นอกจากนี้ บทความนี้ยังแสดงตัวอย่างโครงการที่ใช้งานได้จริงเพื่อให้ผู้อ่านเข้าใจประสิทธิภาพของประเภทเหล่านี้ในการใช้งานจริงได้ดียิ่งขึ้น ไม่ว่าคุณจะเป็นนักพัฒนาบล็อกเชนหรือผู้อ่านที่สนใจในเทคโนโลยีบล็อกเชน บทความนี้จะให้ข้อมูลเชิงลึกเชิงลึกและกระชับแก่คุณ
มาสำรวจประเภทของ ZK-EVM ข้อดีและข้อเสียกัน
-
ประเภทที่ 1: เทียบเท่ากับ Ethereum อย่างสมบูรณ์
-
ประเภท 2: เทียบเท่ากับ EVM อย่างสมบูรณ์
-
ประเภท 2.5: เทียบเท่าบางส่วนกับ EVM;
-
ประเภท 3: เกือบเทียบเท่ากับ EVM;
-
แบบที่ 4 เทียบเท่าภาษาระดับสูง
ประเภทที่ 1: เทียบเท่ากับ Ethereum อย่างสมบูรณ์
สถาปัตยกรรม: เหมือนกับ Ethereum ทุกประการ และไม่เปลี่ยนแปลงส่วนใด ๆ ของระบบ Ethereum
ข้อได้เปรียบ
ความเข้ากันได้ที่สมบูรณ์แบบ:
- ความสามารถในการตรวจสอบบล็อก Ethereum;
- ช่วยทำให้ Ethereum L1 ปรับขนาดได้มากขึ้น
- เหมาะสำหรับ Rollups เนื่องจากสามารถใช้โครงสร้างพื้นฐานจำนวนมากซ้ำได้
ข้อบกพร่อง
ความเข้ากันได้ที่สมบูรณ์แบบ:
- Ethereum ไม่ได้ออกแบบมาสำหรับการทำงานของ ZK แต่เดิม
- ส่วนประกอบจำนวนมากของ Ethereum ต้องการการคำนวณจำนวนมากเพื่อสร้างการพิสูจน์ ZK (ZKP)
- การพิสูจน์บล็อค Ethereum ใช้เวลาหลายชั่วโมงในการสร้าง
วิธีแก้ไขปัญหา:
- เครื่องพิสูจน์การขนานขนาดใหญ่
- ZK-SNARK ASIC.
ประเภทที่ 2: เทียบเท่ากับ EVM อย่างสมบูรณ์
สถาปัตยกรรม:
- โครงสร้างข้อมูล (โครงสร้างบล็อกและแผนผังสถานะ) แตกต่างจาก Ethereum อย่างมาก
- เข้ากันได้อย่างสมบูรณ์กับแอปพลิเคชันที่มีอยู่
- การปรับเปลี่ยนเล็กน้อยสำหรับ Ethereum เพื่อการพัฒนาที่ง่ายขึ้นและการสร้างหลักฐานที่เร็วขึ้น
ข้อได้เปรียบ
- ใช้เวลาในการพิสูจน์เร็วกว่าแบบที่ 1;
- EVM ไม่สามารถเข้าถึงโครงสร้างข้อมูลได้โดยตรง
- แอปพลิเคชันที่ทำงานบน Ethereum: มีแนวโน้มที่จะทำงานบน Type 2;
- รองรับเครื่องมือดีบัก EVM ที่มีอยู่และโครงสร้างพื้นฐานการพัฒนาอื่นๆ
ข้อบกพร่อง
ก่อนจะเข้าใจข้อเสีย ต้องเข้าใจก่อนว่า “Keccak” คืออะไร:
- อัลกอริทึมแฮชของ Ethereum blockchain;
- ใช้เพื่อป้องกันข้อมูลบน Ethereum;
- ตรวจสอบให้แน่ใจว่าข้อความถูกแปลงเป็นแฮช
ประเภทที่ 2 เข้ากันไม่ได้กับแอปพลิเคชันที่ตรวจสอบหลักฐาน Merkle ของการบล็อกทางประวัติศาสตร์เพื่อตรวจสอบข้อมูลเกี่ยวกับธุรกรรมในอดีต ใบเสร็จรับเงิน/สถานะ เนื่องจากหากอัลกอริธึมการแฮชเปลี่ยนไป (ไม่ใช่ Keccak อีกต่อไป) การพิสูจน์จะไม่ถูกต้อง
เราอาจคิดว่า Keccak เป็นภาษาที่ใช้การพิสูจน์ Merkle (ตัวอักษร) หาก ZK-EVM แทนที่ Keccak ด้วยอัลกอริธึมการแฮชอื่น (เช่น Poseidon) การพิสูจน์ Merkle จะไม่คุ้นเคยและแอปพลิเคชันจะไม่สามารถอ่านและตรวจสอบการอ้างสิทธิ์ได้
วิธีแก้ปัญหาที่เป็นไปได้สำหรับข้อบกพร่อง: Ethereum สามารถเพิ่มการรวบรวมล่วงหน้าการเข้าถึงประวัติที่ปรับขนาดได้ในอนาคต
โครงการ
- เลื่อน;
- รูปหลายเหลี่ยม Hermez
อย่างไรก็ตาม โครงการเหล่านี้ยังไม่ได้ดำเนินการคอมไพล์ล่วงหน้าที่ซับซ้อนกว่านี้ ดังนั้นจึงอาจถือว่าโครงการเหล่านี้ไม่สมบูรณ์ประเภทที่ 2
ประเภท 2.5: เทียบเท่าบางส่วนกับ EVM
สถาปัตยกรรม:
เพิ่มต้นทุนก๊าซของการดำเนินงาน EVM เฉพาะที่ยากต่อการพิสูจน์ ZK
- คอมไพล์ล่วงหน้า;
- Keccak opcode;
- โหมดการเรียกสัญญา;
- เข้าถึงหน่วยความจำ;
- พื้นที่จัดเก็บ.
ข้อได้เปรียบ
- ปรับปรุงเวลาในการพิสูจน์กรณีเลวร้ายที่สุดอย่างมีนัยสำคัญ
- ปลอดภัยกว่าการเปลี่ยนแปลงที่ลึกลงไปกับ EVM stack
ข้อบกพร่อง
- ความเข้ากันได้ของเครื่องมือการพัฒนาจะลดลง
- แอพบางตัวจะไม่ทำงาน
ประเภทที่ 3: เกือบเทียบเท่ากับ EVM
สถาปัตยกรรม:
- ในการใช้งาน ZK-EVM ฟังก์ชันบางอย่างที่ใช้งานยากมากจะถูกลบออก ซึ่งโดยปกติแล้วจะคอมไพล์ไว้ล่วงหน้า
- ZK-EVM มีความแตกต่างเล็กน้อยในการจัดการรหัสสัญญา หน่วยความจำ หรือสแต็ก
ข้อได้เปรียบ
- ลดระยะเวลาการตรวจสอบ;
- ทำให้การพัฒนา EVM ง่ายขึ้น
- เป้าหมายคือต้องการให้มีการเขียนซ้ำน้อยที่สุดสำหรับแอปพลิเคชันที่เข้ากันได้น้อย
ข้อบกพร่อง
- ความไม่ลงรอยกันมากขึ้น;
- แอปพลิเคชันที่ใช้การคอมไพล์ล่วงหน้าซึ่งถูกลบออกไปใน Type 3 จะต้องเขียนใหม่
โครงการ
ปัจจุบัน Scroll และ Polygon ถือเป็น Type 3 อย่างไรก็ตาม ทีมงาน ZK-EVM ไม่ควรพึงพอใจกับการเป็น Type 3 Type 3 เป็นขั้นเปลี่ยนผ่านที่ ZK-EVM เพิ่มการคอมไพล์ล่วงหน้าเพื่อปรับปรุงความเข้ากันได้และย้ายไปยัง Type 2.5
แบบที่ 4 เทียบเท่าภาษาระดับสูง
สถาปัตยกรรม:
- ยอมรับรหัสสัญญาอัจฉริยะที่เขียนด้วยภาษาระดับสูง (เช่น Solidity, Vyper);
- รวบรวมเป็นภาษาที่ออกแบบมาให้เป็นมิตรกับ ZK-SNARK
ข้อได้เปรียบ
- เวลาพิสูจน์เร็วมาก;
- ลดค่าใช้จ่าย (ต้นทุน เวลา และความพยายามในการคำนวณ);
- ลดอุปสรรคในการเป็นผู้พิสูจน์: เพิ่มระดับของการกระจายอำนาจ
ข้อบกพร่อง
- ในระบบประเภท 4 ที่อยู่ของสัญญาอาจแตกต่างจากที่อยู่ใน EVM เนื่องจากที่อยู่ขึ้นอยู่กับรหัสไบต์ที่แน่นอน
- ซึ่งหมายความว่าหาก ZK-EVM ประเภท 4 ไม่มีรหัสไบต์ จะไม่สามารถสร้างที่อยู่ได้
- ประเภทที่ 4 จะใช้ไม่ได้กับแอปพลิเคชันที่อาศัยสัญญาปลอมในกรณีข้างต้น;
- โครงสร้างพื้นฐานการดีบักจำนวนมากไม่สามารถพกพาได้เนื่องจากทำงานบน EVM bytecode
โครงการ
สุดท้ายนี้ เราสามารถเปรียบเทียบประเภทต่างๆ ข้างต้นเข้าด้วยกันเพื่อช่วยให้ทุกคนเข้าใจ zkEVM ต่างๆ ได้อย่างรวดเร็ว
