เนื่องจากแนวคิดของโปรเซสเซอร์ร่วมได้รับความนิยมในช่วงหลายเดือนที่ผ่านมา กรณีการใช้งาน ZK ใหม่นี้จึงเริ่มได้รับความสนใจมากขึ้นเรื่อยๆ

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

1. Co-Processor คืออะไร และอะไรไม่ใช่?

หากคุณถูกขอให้อธิบายตัวประมวลผลร่วมให้กับผู้ที่ไม่ใช่ด้านเทคนิคหรือนักพัฒนาด้วยประโยคเดียว คุณจะอธิบายได้อย่างไร?

ฉันคิดว่าสิ่งที่ดร. Dong Mo พูดอาจใกล้เคียงกับคำตอบมาตรฐานมาก พูดตรงๆ ก็คือตัวประมวลผลร่วม "ทำให้สัญญาอัจฉริยะสามารถดำเนินการ Dune Analytics ได้"

จะแยกประโยคนี้อย่างไร?

ลองนึกภาพสถานการณ์ที่เราใช้ Dune - คุณต้องการทำ LP ใน Uniswap V3 เพื่อรับค่าธรรมเนียมการจัดการ ดังนั้นคุณจึงเปิด Dune และค้นหาปริมาณการซื้อขายล่าสุดของคู่การซื้อขายต่างๆ บน Uniswap ซึ่งเป็น APR ของค่าธรรมเนียมการจัดการใน 7 วันที่ผ่านมา และคู่การซื้อขายหลัก ช่วงความผันผวนบนและล่าง ฯลฯ...

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

แน่นอนว่าคุณอาจไม่เพียงแค่จ้องมองข้อมูลเหล่านี้เท่านั้น แต่ทีมพัฒนาของ Uniswap และ StepN ก็ให้ความสนใจกับข้อมูลเหล่านี้เช่นกัน

ข้อมูลเหล่านี้มีความหมายมาก ไม่เพียงแต่สามารถช่วยตัดสินการเปลี่ยนแปลงของแนวโน้มเท่านั้น แต่ยังใช้เพื่อสร้างเคล็ดลับเพิ่มเติม เช่นเดียวกับแนวทาง "ข้อมูลขนาดใหญ่" ที่บริษัทอินเทอร์เน็ตรายใหญ่ใช้กันทั่วไป

เช่น ตามสไตล์และราคาของรองเท้าที่ผู้ใช้มักซื้อและขาย เราจึงแนะนำรองเท้าที่คล้ายกัน

ตัวอย่างเช่น "โปรแกรมรางวัลความภักดีของผู้ใช้" จะเปิดตัวตามระยะเวลาที่ผู้ใช้ถือ Creation Shoes เพื่อให้ผู้ใช้ที่ภักดีได้รับ airdrops หรือสิทธิประโยชน์มากขึ้น

ตัวอย่างเช่น แผน VIP ที่คล้ายกับ Cex สามารถเปิดตัวได้โดยอิงตาม TVL หรือปริมาณการซื้อขายที่ LP ให้ไว้บน Uniswap หรือ Trader ทำให้ค่าธรรมเนียมการทำธุรกรรมของ Trader ลดลงหรือส่วนแบ่งค่าธรรมเนียมของ LP จะได้รับสิทธิประโยชน์เพิ่มขึ้น...

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

แต่ที่ Web3 ความโปร่งใสและความไม่ไว้วางใจเป็นความถูกต้องทางการเมืองตามธรรมชาติของเรา และเราปฏิเสธกล่องดำ!

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

แบบแรกจะนำคุณไปสู่ปัญหาความไว้วางใจที่ "ไม่ถูกต้องทางการเมือง"

ค่าธรรมเนียมน้ำมันที่เกิดจากส่วนหลังบนห่วงโซ่จะเป็นตัวเลขทางดาราศาสตร์ และกระเป๋าเงิน (ฝั่งโครงการ) ของคุณไม่สามารถจ่ายได้

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

เหตุใดจึงเรียกว่า "โปรเซสเซอร์ร่วม"? อันที่จริงสิ่งนี้มาจาก “GPU” ในประวัติการพัฒนาของ Web2.0 เหตุผลที่ GPU ได้รับการแนะนำเป็นฮาร์ดแวร์การประมวลผลแยกต่างหากและมีอยู่อย่างเป็นอิสระจาก CPU ในขณะนั้น เนื่องจากสถาปัตยกรรมการออกแบบของ GPU สามารถจัดการกับการคำนวณบางอย่างที่โดยพื้นฐานแล้วยากสำหรับ CPU ในการจัดการ เช่น การคำนวณซ้ำขนานขนาดใหญ่ กราฟิก การคำนวณ ฯลฯ เป็นเพราะสถาปัตยกรรม "โปรเซสเซอร์ร่วม" ที่ทำให้เรามีภาพยนตร์ CG เกม โมเดล AI ฯลฯ ที่ยอดเยี่ยมในปัจจุบัน ดังนั้น สถาปัตยกรรมโปรเซสเซอร์ร่วมนี้จึงเป็นก้าวกระโดดในสถาปัตยกรรมการประมวลผลอย่างแท้จริง ขณะนี้ทีมงานประมวลผลร่วมหลายทีมยังหวังที่จะแนะนำสถาปัตยกรรมนี้ใน Web3.0 บล็อกเชนที่นี่คล้ายกับ CPU ของ Web3.0 ไม่ว่าจะเป็น L1 หรือ L2 โดยธรรมชาติแล้วมันไม่เหมาะสมสำหรับงาน "ข้อมูลหนัก" และ "ตรรกะการคำนวณที่ซับซ้อน" ดังนั้นจึงมีการใช้ตัวประมวลผลร่วมบล็อคเชนเพื่อช่วยจัดการกับการคำนวณดังกล่าว ซึ่งจะเป็นการขยายความเป็นไปได้อย่างมากของแอปพลิเคชันบล็อกเชน

ดังนั้นสิ่งที่ตัวประมวลผลร่วมทำสามารถสรุปได้เป็นสองสิ่ง:

1. รับข้อมูลจากบล็อกเชนและใช้ ZK เพื่อพิสูจน์ว่าข้อมูลที่ฉันได้รับนั้นเป็นความจริงและไม่ปลอมปน
2. ทำการคำนวณที่เกี่ยวข้องตามข้อมูลที่ฉันได้รับ และใช้ ZK อีกครั้งเพื่อพิสูจน์ว่าผลลัพธ์ที่ฉันคำนวณนั้นเป็นจริงและไม่มีการปลอมปน ผลการคำนวณสามารถเรียกได้โดยสัญญาอัจฉริยะ “ค่าธรรมเนียมต่ำ + ไร้ความน่าเชื่อถือ”

เมื่อไม่นานมานี้ Starkware มีแนวคิดยอดนิยมที่เรียกว่า Storage Proof หรือที่เรียกว่า State Proof โดยพื้นฐานแล้วจะทำตามขั้นตอนที่ 1 ซึ่งแสดงโดย Herodotus, Langrage ฯลฯ จุดเน้นทางเทคนิคของสะพานข้ามโซ่จำนวนมากที่ใช้เทคโนโลยี ZK ก็อยู่ในขั้นตอนที่ 1 เช่นกัน

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

ดังนั้นเพื่อใช้คำศัพท์ทางเทคนิคในการอธิบายอย่างถูกต้อง ตัวประมวลผลร่วมควรเป็นชุดที่เหนือกว่าของ Storage Proof/State Proof และชุดย่อยของ Verfiable Computation

สิ่งหนึ่งที่ควรทราบก็คือตัวประมวลผลร่วมไม่ใช่ Rollup

ในทางเทคนิคแล้ว การพิสูจน์ ZK ของ Rollup นั้นคล้ายคลึงกับขั้นตอนที่ 2 ข้างต้น และกระบวนการของขั้นตอนที่ 1 “การรับข้อมูล” จะถูกนำไปใช้โดยตรงผ่าน Sequencer แม้แต่ Sequencer แบบกระจายอำนาจก็ใช้เพียงการแข่งขันหรือกลไกฉันทามติบางประเภทเท่านั้นเพื่อให้บรรลุเป้าหมายนี้ ใช้ ZK รูปแบบนี้แทน Storage Proof สิ่งที่สำคัญกว่านั้นคือนอกเหนือจากเลเยอร์การคำนวณแล้ว ZK Rollup ยังต้องใช้เลเยอร์การจัดเก็บข้อมูลที่คล้ายกับ L1 blockchain พื้นที่จัดเก็บข้อมูลนี้เป็นแบบถาวร ในขณะที่ตัวประมวลผลร่วม ZK เป็นแบบ “ไร้สถานะ” หลังจากการคำนวณเสร็จสิ้น สถานะทั้งหมดจะไม่คงอยู่

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

2. เพราะเหตุใดฉันจึงต้องใช้ ZK? ใช้ OP ได้ไหม?

หลังจากอ่านข้อความข้างต้นแล้ว คุณอาจมีข้อสงสัยว่า ต้องใช้ ZK เป็นตัวประมวลผลร่วมหรือไม่ ฟังดูคล้ายกับ “กราฟที่มี ZK เพิ่ม” มากและดูเหมือนเราจะไม่ “มีข้อสงสัยใดๆ มากมาย” เกี่ยวกับผลลัพธ์ของกราฟ

นั่นเป็นเพราะว่าเมื่อคุณใช้ Graph โดยพื้นฐานแล้วเงินจริงจะไม่เกี่ยวข้อง ดัชนีเหล่านี้ให้บริการนอกเครือข่าย สิ่งที่คุณเห็นบนอินเทอร์เฟซผู้ใช้ส่วนหน้าคือปริมาณธุรกรรม ประวัติการทำธุรกรรม ฯลฯ ข้อมูลสามารถจัดหาได้ผ่านผู้ให้บริการดัชนีข้อมูลหลายราย เช่น Graph, Alchemy, Zettablock ฯลฯ แต่ข้อมูลเหล่านี้ไม่สามารถยัดกลับเข้าไปในสัญญาอัจฉริยะได้ เพราะเมื่อคุณยัดกลับเข้าไปแล้ว คุณจะเพิ่มความไว้วางใจเพิ่มเติมในบริการดัชนี เมื่อข้อมูลเชื่อมโยงกับเงินจริง โดยเฉพาะ TVL ในปริมาณมาก ความไว้วางใจเพิ่มเติมนี้จึงมีความสำคัญ ลองนึกภาพว่าครั้งต่อไปที่เพื่อนขอให้คุณยืม 100 หยวน คุณก็อาจจะให้ยืมได้โดยไม่ต้องกระพริบตา ใช่ แล้วเมื่อฉันขอให้คุณยืม 10,000 หยวนหรือแม้แต่ 1 ล้านหยวนล่ะ?

แต่ขอย้ำอีกครั้งว่าเราต้องใช้ ZK เพื่อร่วมประมวลผลสถานการณ์ข้างต้นทั้งหมดหรือไม่ ท้ายที่สุดแล้ว เรามีเส้นทางทางเทคนิคสองเส้นทาง OP และ ZK ใน Rollup ZKML ที่ได้รับความนิยมเมื่อเร็วๆ นี้ยังมีแนวคิด OPML ของเส้นทางสาขาที่สอดคล้องกัน ถามว่าตัวประมวลผลร่วมมีสาขาของ OP เช่น OP-Coprocessor หรือไม่

ในความเป็นจริง มีจริงๆ แต่เรากำลังเก็บรายละเอียดเฉพาะไว้เป็นความลับในตอนนี้ และเราจะเปิดเผยข้อมูลรายละเอียดเพิ่มเติมเร็วๆ นี้

3. ตัวประมวลผลร่วมตัวใดดีที่สุด - การเปรียบเทียบโซลูชันทางเทคนิคของตัวประมวลผลร่วมทั่วไปหลายตัวในตลาด

เบรวิส

สถาปัตยกรรมของ Brevis ประกอบด้วยสามองค์ประกอบ: zkFabric, zkQueryNet และ zkAggregatorRollup

ต่อไปนี้เป็นแผนภาพสถาปัตยกรรม Brevis:

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

zkQueryNet: ตลาดเครื่องมือสืบค้น ZK แบบเปิดที่ยอมรับการสืบค้นข้อมูลจาก dApps และประมวลผลข้อมูลเหล่านั้น การสืบค้นข้อมูลจะประมวลผลการสืบค้นเหล่านี้โดยใช้ส่วนหัวของบล็อกที่ได้รับการตรวจสอบแล้วจาก zkFabric และสร้างการพิสูจน์การสืบค้น ZK เอ็นจิ้นเหล่านี้มีทั้งฟังก์ชันเฉพาะทางสูงและภาษาคิวรีทั่วไปเพื่อตอบสนองความต้องการของแอปพลิเคชันที่แตกต่างกัน

zkAggregatorRollup: ZK Convolutional Blockchain ที่ทำหน้าที่เป็นเลเยอร์การรวมตัวและการจัดเก็บข้อมูลสำหรับ zkFabric และ zkQueryNet โดยจะตรวจสอบการพิสูจน์จากทั้งสององค์ประกอบ จัดเก็บข้อมูลที่ตรวจสอบแล้ว และส่งมอบสถานะรูทที่ผ่านการตรวจสอบด้วย zk ไปยังบล็อกเชนที่เชื่อมต่อทั้งหมด

ZK Fabric เป็นส่วนสำคัญในการสร้างการพิสูจน์สำหรับส่วนหัวของบล็อก มันสำคัญมากที่จะต้องมั่นใจในความปลอดภัยของส่วนนี้ ต่อไปนี้เป็นไดอะแกรมสถาปัตยกรรมของ zkFabric:

ไคลเอ็นต์แสงแบบ Zero-Knowledge Proof (ZKP) ของ zkFabric ทำให้ไม่น่าเชื่อถือโดยสิ้นเชิง โดยไม่ต้องพึ่งพาหน่วยงานตรวจสอบภายนอกใดๆ ไม่จำเป็นต้องพึ่งพาหน่วยงานตรวจสอบภายนอกใด ๆ เนื่องจากการรักษาความปลอดภัยมาจากบล็อกเชนพื้นฐานและการพิสูจน์ที่เชื่อถือได้ทางคณิตศาสตร์

เครือข่าย zkFabric Prover ใช้วงจรสำหรับโปรโตคอล lightclient ของแต่ละบล็อกเชน และเครือข่ายสร้างการพิสูจน์ความถูกต้องสำหรับส่วนหัวของบล็อก ผู้พิสูจน์สามารถใช้ประโยชน์จากตัวเร่งความเร็ว เช่น GPU, FPGA และ ASIC เพื่อลดเวลาและต้นทุนในการพิสูจน์ให้เหลือน้อยที่สุด

zkFabric อาศัยสมมติฐานด้านความปลอดภัยของบล็อกเชนและโปรโตคอลการเข้ารหัสลับพื้นฐาน และสมมติฐานด้านความปลอดภัยของโปรโตคอลการเข้ารหัสลับพื้นฐาน อย่างไรก็ตาม เพื่อให้มั่นใจในประสิทธิภาพของ zkFabric จำเป็นต้องมีรีเลย์ที่ซื่อสัตย์อย่างน้อยหนึ่งตัวเพื่อซิงโครไนซ์ทางแยกที่ถูกต้อง ดังนั้น zkFabric จึงใช้เครือข่ายรีเลย์แบบกระจายอำนาจแทนการใช้รีเลย์ตัวเดียวเพื่อเพิ่มประสิทธิภาพประสิทธิภาพของ zkFabric เครือข่ายรีเลย์นี้สามารถใช้ประโยชน์จากโครงสร้างที่มีอยู่ได้ เช่น เครือข่าย State Guard ในเครือข่าย Celer

การจัดสรรผู้พิสูจน์อักษร: เครือข่ายผู้พิสูจน์อักษรเป็นเครือข่ายผู้พิสูจน์อักษร ZKP แบบกระจายอำนาจ ซึ่งจะเลือกผู้พิสูจน์อักษรสำหรับงานสร้างหลักฐานแต่ละงาน และชำระค่าธรรมเนียมให้กับผู้พิสูจน์เหล่านี้

การใช้งานปัจจุบัน:

ปัจจุบันโปรโตคอลไคลเอนต์แบบ Light ถูกนำไปใช้กับบล็อกเชนต่างๆ รวมถึง Ethereum PoS, Cosmos Tendermint และ BNB Chain เป็นตัวอย่างและการพิสูจน์แนวคิด

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

ด้วยความช่วยเหลือของ Brevis ฮุคสามารถแก้ไขความท้าทายได้ ตอนนี้ Hooks สามารถอ่านจากข้อมูลห่วงโซ่ประวัติทั้งหมดของผู้ใช้หรือ LP และดำเนินการคำนวณที่ปรับแต่งได้ในลักษณะที่ไม่น่าเชื่อถือโดยสิ้นเชิง

เฮโรโดทัส

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

1. สถานะ L1 จาก L2
2. สถานะ L2 จากทั้ง L1 และ L2 อื่นๆ
3. L3/App-Chain ระบุถึง L2 และ L1

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

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

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

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

หลักฐานการจัดเก็บตามที่กำหนดโดย Herodotus คือการหลอมรวมของ:

1. หลักฐานการกักกัน: หลักฐานเหล่านี้ยืนยันการมีอยู่ของข้อมูลเฉพาะในโครงสร้างข้อมูลที่เข้ารหัส (เช่น Merkle tree หรือ Merkle Patricia tree) เพื่อให้มั่นใจว่าข้อมูลที่เป็นปัญหานั้นมีอยู่ในชุดข้อมูลจริงๆ
2. หลักฐานทางการคำนวณ: ตรวจสอบการดำเนินการของเวิร์กโฟลว์แบบหลายขั้นตอน พิสูจน์ความถูกต้องขององค์ประกอบตั้งแต่หนึ่งรายการขึ้นไปในชุดข้อมูลที่กว้าง เช่น บล็อกเชน Ethereum ทั้งหมดหรือผลรวม นอกเหนือจากการระบุถึงการมีอยู่ของข้อมูลแล้ว พวกเขายังตรวจสอบการเปลี่ยนแปลงหรือการดำเนินการที่ใช้กับข้อมูลนั้นด้วย
3. การพิสูจน์ความรู้แบบไม่มีศูนย์: ลดความซับซ้อนของปริมาณข้อมูลที่สัญญาอัจฉริยะจำเป็นต้องโต้ตอบด้วย การพิสูจน์ความรู้แบบ Zero-Knowledge ช่วยให้สัญญาอัจฉริยะสามารถยืนยันความถูกต้องของการเรียกร้องได้โดยไม่ต้องประมวลผลข้อมูลพื้นฐานทั้งหมด

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

1.รับบล็อกแฮช

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

2.รับส่วนหัวของบล็อก

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

มีสองวิธีในการรับแฮช:

1. ใช้ opcode ของ BLOCKHASH เพื่อดึงข้อมูล
2. ค้นหาแฮชของบล็อกที่ได้รับการตรวจสอบในประวัติศาสตร์จาก Block Hash Accumulator

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

3.กำหนดรากที่ต้องการ (ไม่จำเป็น)

ด้วยส่วนหัวของบล็อก เราสามารถเจาะลึกเนื้อหาได้ โดยเฉพาะ:

stateRoot: ข้อมูลสรุปเกี่ยวกับการเข้ารหัสของสถานะบล็อกเชนทั้งหมด ณ เวลาที่บล็อกเชนเกิดขึ้น

ใบเสร็จรับเงิน: สรุปผลการทำธุรกรรมทั้งหมด (ใบเสร็จรับเงิน) ที่เข้ารหัสในบล็อก

TransactionsRoot: สรุปการเข้ารหัสของธุรกรรมทั้งหมดที่เกิดขึ้นในบล็อก

สามารถถอดรหัสได้ ช่วยให้สามารถตรวจสอบได้ว่ามีบัญชี ใบเสร็จ หรือธุรกรรมเฉพาะรวมอยู่ในบล็อกหรือไม่

4. ตรวจสอบข้อมูลกับรูทที่เลือก (ไม่บังคับ)

ด้วยรากที่เราเลือก และเมื่อพิจารณาว่า Ethereum ใช้โครงสร้าง Merkle-Patricia Trie เราสามารถใช้หลักฐานการรวม Merkle เพื่อตรวจสอบว่าข้อมูลมีอยู่ในแผนภูมิหรือไม่ ขั้นตอนการตรวจสอบจะแตกต่างกันไปขึ้นอยู่กับข้อมูลและความลึกของข้อมูลภายในบล็อก

เครือข่ายที่รองรับในปัจจุบัน:

1. จากอีเธอเรียมถึงสตาร์คเน็ต
2. จาก Ethereum Goerli ถึง Starknet Goerli
3. จาก Ethereum Goerli สู่ zkSync Era Goerli

สัจพจน์

Axiom มอบวิธีสำหรับนักพัฒนาในการสืบค้นส่วนหัวของบล็อก บัญชี หรือค่าที่เก็บข้อมูลจากประวัติทั้งหมดของ Ethereum AXIOM ขอแนะนำวิธีใหม่ในการเชื่อมโยงโดยใช้การเข้ารหัส ผลลัพธ์ทั้งหมดที่ส่งคืนโดย Axiom ได้รับการตรวจสอบแบบออนไลน์ผ่านการพิสูจน์ความรู้แบบศูนย์ ซึ่งหมายความว่าสัญญาอัจฉริยะสามารถใช้งานได้โดยไม่ต้องมีสมมติฐานที่เชื่อถือได้เพิ่มเติม

Axiom เพิ่งเปิดตัว Halo2-repl ซึ่งเป็น halo2 REPL บนเบราว์เซอร์ที่เขียนด้วย Javascript ช่วยให้นักพัฒนาสามารถเขียนวงจร ZK โดยใช้ Javascript มาตรฐาน โดยไม่ต้องเรียนรู้ภาษาใหม่ เช่น Rust ติดตั้ง Proof Libraries หรือจัดการกับการขึ้นต่อกัน

Axiom ประกอบด้วยองค์ประกอบทางเทคโนโลยีหลักสองส่วน:

1. AxiomV1 — แคช Ethereum blockchain เริ่มต้นด้วย Genesis
2. AxiomV1Query — สัญญาอัจฉริยะที่ดำเนินการสืบค้นกับ AxiomV1

แฮชบล็อกแคชใน AxiomV1:

AxiomV1 สัญญาอัจฉริยะแคช Ethereum บล็อกแฮชตั้งแต่บล็อกกำเนิดในสองรูปแบบ:

ขั้นแรก รูท Keccak Merkle ของแฮชบล็อกที่ต่อเนื่องกัน 1,024 รายการจะถูกแคชไว้ รากของ Merkle เหล่านี้ได้รับการอัปเดตผ่านการพิสูจน์ ZK โดยตรวจสอบว่าแฮชของส่วนหัวของบล็อกสร้างห่วงโซ่ความมุ่งมั่นที่ลงท้ายด้วยหนึ่งใน 256 บล็อกล่าสุดที่เข้าถึงได้โดยตรงโดย EVM หรือแฮชของบล็อกที่มีอยู่แล้วในแคช AxiomV1

ประการที่สอง Axiom เก็บเทือกเขา Merkle ของราก Merkle เหล่านี้โดยเริ่มจากช่วงกำเนิด เทือกเขา Merkle สร้างขึ้นบนเครือข่ายโดยการอัปเดตส่วนแรกของแคช ซึ่งก็คือราก Keccak Merkle

ดำเนินการค้นหาใน AxiomV1Query:

สัญญาอัจฉริยะ AxiomV1Query ใช้สำหรับการสืบค้นแบบแบตช์เพื่อให้สามารถเข้าถึงส่วนหัวของบล็อก Ethereum ในอดีต บัญชี และข้อมูลที่กำหนดเองที่จัดเก็บไว้ในบัญชีได้อย่างไม่น่าเชื่อถือ การสืบค้นสามารถทำได้แบบออนไลน์และดำเนินการแบบออนไลน์ผ่านการพิสูจน์ ZK เทียบกับแฮชบล็อกแคชของ AxiomV1

การพิสูจน์ ZK เหล่านี้จะตรวจสอบว่าข้อมูล on-chain ที่เกี่ยวข้องนั้นอยู่ในส่วนหัวของบล็อกโดยตรง หรือในบัญชีของบล็อกหรือการทดลองจัดเก็บ โดยการตรวจสอบหลักฐานการรวม (หรือการไม่รวม) ของการทดลอง Merkle-Patricia

เน็กซัส

Nexus พยายามใช้การพิสูจน์ความรู้ที่ไม่มีศูนย์เพื่อสร้างแพลตฟอร์มสากลสำหรับการประมวลผลบนคลาวด์ที่ตรวจสอบได้ ปัจจุบันเป็นเทคโนโลยีที่ไม่เชื่อเรื่องพระเจ้าและสนับสนุน risc 5/ WebAssembly/ EVM เน็กซัสใช้ระบบพิสูจน์ของซูเปอร์โนวา ทีมงานทดสอบว่าหน่วยความจำที่จำเป็นในการสร้างหลักฐานคือ 6GB ในอนาคต จะมีการปรับให้เหมาะสมบนพื้นฐานนี้เพื่อให้คอมพิวเตอร์อุปกรณ์ไคลเอนต์ทั่วไปสามารถสร้างการพิสูจน์ได้

ถ้าให้พูดให้ชัดเจน สถาปัตยกรรมจะแบ่งออกเป็นสองส่วน:

1. Nexus ศูนย์: เครือข่ายการประมวลผลบนคลาวด์แบบกระจายอำนาจที่ตรวจสอบได้ซึ่งขับเคลื่อนโดย Zero-Knowledge Proofs และ zkVM สากล
2. Nexus: เครือข่ายการประมวลผลบนคลาวด์ที่ตรวจสอบได้แบบกระจายอำนาจ ซึ่งขับเคลื่อนโดยการประมวลผลแบบหลายฝ่าย การจำลองเครื่องสถานะ และเครื่องเสมือน WASM สากล

แอปพลิเคชัน Nexus และ Nexus Zero สามารถเขียนด้วยภาษาการเขียนโปรแกรมแบบดั้งเดิม ซึ่งปัจจุบันรองรับ Rust และจะมีภาษาอื่นๆ ตามมาอีกมากมายในอนาคต

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

แอปพลิเคชัน Nexus Zero สืบทอดการรักษาความปลอดภัยของ Ethereum เนื่องจากเป็นโปรแกรมสากลที่มีการพิสูจน์ความรู้เป็นศูนย์ ซึ่งสามารถตรวจสอบได้ทางออนไลน์บนเส้นโค้งวงรี BN-254

เนื่องจาก Nexus สามารถเรียกใช้ไบนารี WASM ที่กำหนดไว้ได้ในสภาพแวดล้อมที่ถูกจำลองแบบ จึงคาดว่าจะใช้เป็นแหล่งพิสูจน์ความถูกต้อง/การกระจายตัว/ความทนทานต่อข้อผิดพลาดสำหรับแอปพลิเคชันที่สร้างขึ้น รวมถึงซีเควนเซอร์ zk-rollup, ซีเควนเซอร์โรลอัพในแง่ดี และเซิร์ฟเวอร์พิสูจน์อักษรอื่นๆ เช่น zkVM ของ Nexus Zero เอง

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [pannewslab] ลิขสิทธิ์ทั้งหมดเป็นของผู้แต่งต้นฉบับ [ABCDE] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว