TL;DR

ชื่อระดับแรก

1. เรากำลังทำงานอย่างหนักเพื่อสร้าง ZKVM ตัวแรกที่ใช้ PE-VM ด้วยการออกแบบที่เป็นมิตรกับ ZK และการปรับปรุงอัลกอริทึม ZK ทำให้มีอัตราปริมาณงานที่สูงขึ้น ลักษณะทางเทคนิคมีดังนี้:

ก. พิสูจน์อย่างรวดเร็ว:

i. เป็นมิตรกับ ZK: รับขนาดวงจรที่เล็กลงและหน่วยข้อจำกัดพื้นฐานที่ง่ายขึ้น

ii. การใช้งาน ZK ที่เร็วขึ้น: การปรับปรุงที่เหมาะสมเพิ่มเติมสำหรับ plonky 2;

ข ดำเนินการอย่างรวดเร็ว:

ใช้ VM การดำเนินการแบบขนาน (ในบริบทของเทคโนโลยีการพิสูจน์แบบขนาน ยิ่งเวลาสร้างการพิสูจน์สั้นลง ผลกระทบที่ชัดเจนยิ่งขึ้น)

2. สิ่งที่เราได้ทำ:

ก. ในเดือนกรกฎาคม 2022 สมุดปกขาวของ OlaVM ได้รับการเผยแพร่

c. สำหรับอัลกอริทึม ZK ที่มีประสิทธิภาพการดำเนินการเร็วที่สุด ณ ปัจจุบัน เราได้เสร็จสิ้นการออกแบบวงจรและการวิจัยอัลกอริทึมของ plonky 2 แล้ว คุณสามารถเปิดลิงก์: https://github.com/Sin 7 Y/plonky 2/tree/ main/plonky 2/ การออกแบบเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการออกแบบของ plonky 2 เราจะปรับให้เหมาะสมและปรับปรุงในขั้นตอนต่อไป โปรดให้ความสนใจต่อไป . .

ชื่อระดับแรก

เรากำลังทำอะไรอยู่

OlaVM เป็น ZKVM เลเยอร์ 2 แรกที่แนะนำ VM การดำเนินการแบบขนาน โดยผสานรวมจุดทางเทคนิคของสองโครงร่างเพื่อให้ได้ความเร็วในการดำเนินการที่เร็วขึ้นและความเร็วในการพิสูจน์ที่เร็วขึ้น เพื่อให้ได้ปริมาณงานของระบบที่สูงขึ้นในอนาคต

ในระบบ Ethereum ปัจจุบัน มีเหตุผลหลักสองประการที่ทำให้ทรูพุตช้า:

1. กระบวนการฉันทามติ: แต่ละโหนดดำเนินการธุรกรรมซ้ำ ๆ เพื่อตรวจสอบความถูกต้องของธุรกรรม

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

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

ทำอย่างไรให้ได้ปริมาณงานสูง?

ชื่อเรื่องรอง

การสร้างหลักฐานให้เร็วที่สุด (ปัจจุบันมีความสำคัญสูงสุด)

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

1. จำกัดขนาดให้เล็กที่สุด

a. Prophet

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

b. Zk-friendly

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

เมื่อการคำนวณมีความซับซ้อน Prophet สามารถช่วยลดขนาดของวิถีที่ดำเนินการโดย VM แต่ก่อนหน้านั้น เราต้องการให้การคำนวณนั้นเป็นมิตรกับ Zk ดังนั้น ในการออกแบบ เราจะใช้การดำเนินการบางอย่างที่เป็นมิตรกับ Zk เช่น อัลกอริธึมแฮชทั่วไป อัลกอริทึมการตรวจสอบลายเซ็น ฯลฯ การเพิ่มประสิทธิภาพเหล่านี้มักมีอยู่ในโซลูชัน ZK(E)VM อื่นๆ แต่กุญแจสำคัญสุดท้ายคือ เมื่อคุณ เลือกการคำนวณเชิงซ้อนที่เป็นมิตรกับ Zk จะจำกัดการคำนวณที่ซับซ้อนนี้ด้วยข้อจำกัดที่เล็กลงได้อย่างไร

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

เนื่องจากประสิทธิภาพที่น่าทึ่งของ Plonky 2 เราจึงใช้ Plonky 2 เป็นแบ็กเอนด์ ZK ของ OlaVM เป็นการชั่วคราว เราได้วิเคราะห์อย่างลึกซึ้งเกี่ยวกับการออกแบบ Gate การออกแบบ Gadget และหลักการโปรโตคอลของ Plonky 2 และพบแนวทางการเพิ่มประสิทธิภาพ คุณสามารถติดตาม Github Repo: Plonky 2 ของเราเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับเรื่องนี้

ชื่อเรื่องรอง

การดำเนินการธุรกรรมเร็วขึ้น (ไม่ใช่คอขวดในขั้นตอนนี้)

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

ชื่อระดับแรก

ความเข้ากันได้?

แน่นอน เป้าหมายหลักของ OlaVM ยังคงเป็นการสร้าง ZKVM ที่มีทรูพุตสูง เมื่อขั้นตอนแรกของเราดำเนินไปด้วยดี เราจะพิจารณาบรรลุความเข้ากันได้

All Together

เมื่อรวมโมดูลทั้งหมดข้างต้นเข้าด้วยกันแล้ว แผนภูมิการไหลของข้อมูลของทั้งระบบจะแสดงอย่างคร่าว ๆ ในรูปด้านล่าง:

Coming Soon

ชื่อระดับแรก

1. ต้นเดือนธันวาคม 2565:

ก. ดำเนินการออกแบบ OlaVM DSL ให้เสร็จสมบูรณ์

b. ดำเนินการออกแบบและพัฒนาสัญญาที่คอมไพล์ล่วงหน้าของ OlaVM ให้เสร็จสมบูรณ์

อ้างถึง

อ้างถึง

1.OlaVM:https://olavm.org/whitepaper/OlaVM-07-25.pdf

2.Plonkish:https://zcash.github.io/halo 2/concepts/arithmetization.html

3.Cairo VM:https://starknet.io/docs/how_cairo_works/cairo_intro.html#field-elements

4.Plonky 2:https://github.com/Sin 7 Y/plonky 2/blob/main/field/src/goldilocks_field.rs

5.Ingonyama:https://github.com/ingonyama-zk/cloud-ZK

6.Semisand:https://semisand.com/

7.Plonky 2 designs:https://github.com/Sin 7 Y/plonky 2/tree/main/plonky 2/designs

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

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

Sin7y ก่อตั้งขึ้นในปี 2564 และประกอบด้วยนักพัฒนาบล็อกเชนชั้นนำ เราเป็นทั้งผู้บ่มเพาะโครงการและทีมวิจัยเทคโนโลยีบล็อกเชน สำรวจเทคโนโลยีที่สำคัญและล้ำสมัยที่สุด เช่น EVM, Layer 2, cross-chain, การประมวลผลเพื่อความเป็นส่วนตัว และโซลูชันการชำระเงินอัตโนมัติ

GitHub | Twitter | Telegram | Medium| Mirror | HackMD | HackerNoon