Buterin: ข้อมูลเชิงลึกเกี่ยวกับการอ่านข้าม L2 สำหรับกระเป๋าเงินและกรณีการใช้งานอื่นๆ

ผู้เขียน: Vitalik Buterin เรียบเรียง: Vernacular Blockchain

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

โพสต์นี้จะมุ่งเน้นโดยตรงไปที่ด้านเทคนิคของปัญหาย่อยเฉพาะ เช่น: วิธีอ่าน L1 จาก L2 ได้ง่ายขึ้น L2 จาก L1 หรือ L2 จาก L2 อื่น การแก้ไขปัญหานี้มีความสำคัญต่อการเปิดใช้งานสถาปัตยกรรมการแยกสินทรัพย์/ที่เก็บคีย์ แต่ยังมีกรณีการใช้งานที่มีคุณค่าในพื้นที่อื่นๆ โดยเฉพาะอย่างยิ่งการเพิ่มประสิทธิภาพการเรียกสายข้าม L2 ที่เชื่อถือได้ รวมถึงกรณีการใช้งาน เช่น การย้ายสินทรัพย์ระหว่าง L1 และ L2 แคตตาล็อกบทความนี้ เป้าหมายคืออะไร? การพิสูจน์ข้ามสายโซ่มีลักษณะอย่างไร? เราสามารถใช้แผนการพิสูจน์แบบใดได้บ้าง? หลักฐาน Merkle ZK SNARK ใบรับรอง KZG เฉพาะ หลักฐานต้นไม้ Verkle พอลิเมอไรเซชัน อ่านสถานะโดยตรง L2 เรียนรู้รากสถานะ Ethereum ล่าสุดได้อย่างไร กระเป๋าเงินบนโซ่ที่ไม่ใช่ L2s การป้องกันความเป็นส่วนตัว สรุป

1. เป้าหมายคืออะไร?

เมื่อ L2 กลายเป็นกระแสหลัก ผู้ใช้จะเป็นเจ้าของเนื้อหาใน L2 หลายรายการ และอาจรวมถึง L1 ด้วย เมื่อกระเป๋าเงินสัญญาอัจฉริยะ (หลายซิก การกู้คืนโซเชียล หรืออื่นๆ) กลายเป็นกระแสหลัก คีย์ที่จำเป็นในการเข้าถึงบางบัญชีจะเปลี่ยนไปเมื่อเวลาผ่านไป และคีย์เก่าจะไม่จำเป็นอีกต่อไป เมื่อทั้งสองสิ่งนี้เกิดขึ้น ผู้ใช้จะต้องมีวิธีการเปลี่ยนคีย์ที่สามารถเข้าถึงบัญชีจำนวนมากที่อยู่ในที่ต่างๆ โดยไม่ต้องทำธุรกรรมจำนวนมาก โดยเฉพาะอย่างยิ่ง เราต้องการวิธีจัดการกับที่อยู่ปลอม: ที่อยู่ที่ไม่ได้รับการ "ลงทะเบียน" บนเครือข่าย แต่อย่างใด แต่ก็ยังจำเป็นต้องรับและถือเงินอย่างปลอดภัย เราทุกคนพึ่งพาที่อยู่ปลอม: เมื่อคุณใช้ Ethereum เป็นครั้งแรก คุณสามารถสร้างที่อยู่ ETH ที่ใครบางคนสามารถใช้เพื่อชำระเงินให้คุณโดยไม่ต้อง "ลงทะเบียน" ที่อยู่ออนไลน์ (ซึ่งต้องชำระ txfee ดังนั้นจึงมี ETH บางส่วนอยู่แล้ว) สำหรับ EOA ที่อยู่ทั้งหมดจะเริ่มต้นด้วยที่อยู่ปลอม ด้วยกระเป๋าเงินสัญญาอัจฉริยะ ที่อยู่ปลอมแปลงยังคงเป็นไปได้ด้วยส่วนใหญ่ CREATE2 ซึ่งช่วยให้คุณมีที่อยู่ ETH ที่สามารถกรอกโดยสัญญาอัจฉริยะด้วยรหัสที่ตรงกับแฮชเฉพาะ

EIP-1014 (CREATE2) อัลกอริทึมการคำนวณที่อยู่

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

มีสองวิธีในการบรรลุเป้าหมายนี้:

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

• ข้อเสีย: ในการเปลี่ยนคีย์การยืนยัน คุณต้องทำการเปลี่ยนคีย์แบบ on-chain ในที่เก็บคีย์และในกระเป๋าเงินเริ่มต้นทุกใบ (แต่ไม่ใช่กระเป๋าเงินปลอม) นี้สามารถใช้ก๊าซมาก เวอร์ชันหนา (ตรวจสอบทุก tx): ทุกธุรกรรมจำเป็นต้องมีการพิสูจน์ข้ามสายโซ่ซึ่งแสดงรหัสปัจจุบันในที่เก็บคีย์
• ข้อดี: ความซับซ้อนของระบบน้อยลง การอัปเดตที่เก็บคีย์ราคาถูก
• ข้อเสีย: Single tx มีราคาแพง จึงจำเป็นต้องมีวิศวกรรมมากขึ้นเพื่อให้การพิสูจน์แบบข้ามโซ่มีราคาถูกลงมาก ยังไม่เข้ากันได้กับ ERC-4337 ซึ่งปัจจุบันไม่รองรับการอ่านวัตถุที่ไม่แน่นอนระหว่างสัญญาระหว่างการตรวจสอบ

2. การพิสูจน์ข้ามสายโซ่มีลักษณะอย่างไร?

เพื่อแสดงความซับซ้อนทั้งหมด เราจะสำรวจกรณีที่ยากที่สุด: ที่เก็บคีย์ใน L2 หนึ่ง กระเป๋าเงินใน L2 อื่น ต้องการเพียงครึ่งหนึ่งของการออกแบบนี้หากที่เก็บคีย์บนกระเป๋าเงินอยู่บน L1

สมมติว่าที่เก็บคีย์อยู่บน Linea และกระเป๋าเงินอยู่บน Kakarot หลักฐานที่สมบูรณ์ของรหัสกระเป๋าเงินประกอบด้วย:

• พิสูจน์สถานะรูทของ Linea ปัจจุบัน โดยพิจารณาจากรูทสถานะ Ethereum ปัจจุบันที่ Kakarot รู้จัก
• พิสูจน์คีย์ปัจจุบันในที่เก็บคีย์ โดยกำหนดสถานะของ Linea ปัจจุบัน มีปัญหาการใช้งานที่ยุ่งยากสองประการที่นี่:
• เราใช้หลักฐานแบบไหน? (มันเป็นข้อพิสูจน์ของ Merkel อย่างอื่นอีกไหม?
• L2 จะเรียนรู้รูทสถานะ L1 (Ethereum) ที่ใกล้ที่สุดได้อย่างไร (หรืออย่างที่เราจะเห็นว่าอาจเป็นสถานะ L1 แบบเต็ม) หรือ L1 เรียนรู้รากสถานะ L2 อย่างไร ในทั้งสองกรณี ความล่าช้าระหว่างสิ่งที่เกิดขึ้นในด้านหนึ่งกับสิ่งที่สามารถพิสูจน์ได้ในอีกด้านหนึ่งนั้นนานแค่ไหน?

3. เราสามารถใช้แผนการพิสูจน์ประเภทใดได้บ้าง?

มีห้าตัวเลือกหลัก:

• หลักฐาน Merkle -ZK-SNARK ทั่วไป
• หลักฐานเฉพาะ (เช่น การใช้ KZG) -Verkle แสดงให้เห็นว่าอยู่ระหว่าง KZG และ ZK-SNARK ในแง่ของภาระงานโครงสร้างพื้นฐานและต้นทุน
• ไม่ต้องพิสูจน์อาศัยการอ่านสถานะโดยตรง ในแง่ของงานโครงสร้างพื้นฐานที่จำเป็นและค่าใช้จ่ายของผู้ใช้ ฉันจะจัดอันดับคร่าวๆ ดังนี้:

"การรวม" หมายถึงการรวมการพิสูจน์ทั้งหมดที่ได้รับจากผู้ใช้ภายในแต่ละบล็อกเป็น meta-proof ขนาดใหญ่ที่รวมการพิสูจน์ทั้งหมด สิ่งนี้เป็นไปได้กับ SNARK และ KZG แต่ไม่ใช่กับ Merkle forks (คุณสามารถรวม Merkle forks ได้เล็กน้อย แต่จะบันทึกเฉพาะ log(txs ต่อบล็อก)/log(จำนวนที่เก็บคีย์ทั้งหมด) ในทางปฏิบัติ น่าจะเป็น 15-30% กลางๆเลยน่าจะไม่คุ้มราคา) การรวมจะคุ้มค่าก็ต่อเมื่อสถานการณ์มีผู้ใช้จำนวนมาก ดังนั้นในทางปฏิบัติ การใช้งานเวอร์ชัน 1 อาจละเว้นการรวมและนำไปใช้ในเวอร์ชัน 2

4. Merkle Proofs ทำงานอย่างไร?

อันนี้ง่าย: เพียงทำตามแผนภาพในส่วนก่อนหน้า ให้แม่นยำยิ่งขึ้น "การพิสูจน์" แต่ละรายการ (สมมติว่ากรณีการพิสูจน์ความยากสูงสุดของ L2 หนึ่งไปยังอีก L2) จะประกอบด้วย: สาขาของ Merkle ยืนยันสถานะรูทของ L2 ที่เก็บคีย์สโตร์ โดยพิจารณาจากรูทสถานะล่าสุดของ Ethereum ที่ L2 รู้จัก ที่เก็บคีย์เก็บสถานะรูทของ L2 ที่จัดเก็บไว้ในสล็อตหน่วยเก็บข้อมูลที่รู้จักในแอดเดรสที่รู้จัก (สัญญาใน L1 แทน L2) ดังนั้นพาธผ่านทรีจึงสามารถฮาร์ดโค้ดได้ สาขาของ Merkle ยืนยันคีย์การยืนยันปัจจุบัน โดยกำหนดสถานะรูทของ L2 ที่เก็บคีย์สโตร์ อีกครั้ง คีย์การตรวจสอบความถูกต้องจะถูกจัดเก็บไว้ในสล็อตที่เก็บข้อมูลที่รู้จักในที่อยู่ที่รู้จัก ดังนั้นจึงสามารถฮาร์ดโค้ดพาธได้ น่าเสียดายที่ Ethereum Proofs of State มีความซับซ้อน แต่มีไลบรารี่สำหรับตรวจสอบความถูกต้อง และหากคุณใช้ไลบรารีเหล่านั้น กลไกนี้ก็ไม่ซับซ้อนเกินไปที่จะนำไปใช้ **ปัญหาใหญ่คือค่าใช้จ่าย **การพิสูจน์ของ Merkle นั้นยาวมาก น่าเสียดายที่ Patricia tree นั้นยาวเกินความจำเป็น ~3.9 เท่า (พูดตามตรง: การพิสูจน์ของ Merkle ในอุดมคติสำหรับต้นไม้ที่ถือครองวัตถุ N ชิ้นนั้นมีความยาว 32 * log2(N) ไบต์ และเนื่องจากต้นไม้ Patricia ของ Ethereum มี 16 ใบไม้ต่อหนึ่งลูก และหลักฐานของต้นไม้เหล่านี้คือ 32 * 15 * log16(N) ~= 125 * log2(N) ไบต์ยาว) ในสถานะที่มีบัญชีประมาณ 250 ล้านบัญชี (~2²⁸) ค่านี้ทำให้การพิสูจน์แต่ละรายการมีค่า 125 * 28 = 3500 ไบต์ หรือประมาณ 56,000 ไบต์ บวกกับค่าใช้จ่ายเพิ่มเติมในการถอดรหัสและตรวจสอบแฮช เมื่อรวมกัน การพิสูจน์ทั้งสองจะมีราคาประมาณ 100,000 ถึง 150,000 ก๊าซ (หากใช้ต่อการทำธุรกรรม ไม่รวมการตรวจสอบลายเซ็น) ซึ่งสูงกว่าราคาฐานปัจจุบันที่ 21,000 ก๊าซต่อการทำธุรกรรม อย่างไรก็ตาม หากพิสูจน์ยืนยันใน L2 ความคลาดเคลื่อนจะยิ่งแย่ลงไปอีก การคำนวณภายใน L2 นั้นมีราคาถูก เนื่องจากการคำนวณนั้นทำนอกเครือข่ายและในระบบนิเวศที่มีโหนดน้อยกว่า L1 มาก ในทางกลับกัน ข้อมูลจะต้องเผยแพร่ไปยัง L1 ดังนั้นการเปรียบเทียบจึงไม่ใช่ก๊าซ 21k เทียบกับก๊าซ 15k แต่เป็นก๊าซ 21k L2 เทียบกับก๊าซ 100k L1 เราสามารถคำนวณความหมายได้โดยดูที่การเปรียบเทียบระหว่างต้นทุนก๊าซ L1 และต้นทุนก๊าซ L2:

ปัจจุบัน L1 มีราคาแพงกว่า L2 15-25 เท่าสำหรับการส่งอย่างง่าย และมีราคาแพงกว่า 20-50 เท่าสำหรับการสลับโทเค็น การส่งอย่างง่ายนั้นมีปริมาณข้อมูลค่อนข้างมาก แต่ปริมาณการแลกเปลี่ยนที่คำนวณนั้นใหญ่กว่ามาก ดังนั้นการแลกเปลี่ยนจึงเป็นเกณฑ์มาตรฐานที่ดีกว่าสำหรับค่าใช้จ่ายโดยประมาณของการคำนวณ L1 เทียบกับการคำนวณ L2 เมื่อคำนึงถึงสิ่งเหล่านี้ทั้งหมด หากเราถือว่าอัตราส่วนต้นทุน 30x ระหว่างต้นทุนการคำนวณ L1 และต้นทุนการคำนวณ L2 ดูเหมือนว่าจะบ่งบอกเป็นนัยว่าค่าใช้จ่ายในการวางหลักฐาน Merkle บน L2 อาจเทียบเท่ากับการทำธุรกรรมปกติ 50 รายการ แน่นอน การใช้ Merkle tree แบบไบนารีช่วยลดต้นทุนได้ประมาณ 4 เท่า แต่ถึงอย่างนั้น ในกรณีส่วนใหญ่ ค่าใช้จ่ายก็สูงเกินไป - หากเราเต็มใจที่จะเสียสละที่ไม่เข้ากันกับแผนผังสถานะหกเหลี่ยมในปัจจุบันของ Ethereum เราจะมองหา ตัวเลือกที่ดีกว่า

5. การพิสูจน์ ZK-SNARK จะทำงานอย่างไร?

การใช้ ZK-SNARK นั้นมีแนวคิดที่เข้าใจง่ายเช่นกัน คุณเพียงแค่แทนที่ข้อพิสูจน์ของ Merkle ในแผนภาพด้านบนด้วย ZK-SNARK เพื่อพิสูจน์การมีอยู่ของข้อพิสูจน์ของ Merkle เหล่านั้น ZK-SNARK ต้องการ ~400,000 GAS สำหรับการคำนวณ ซึ่งใช้เวลาประมาณ 400 ไบต์ (เทียบกับ: ธุรกรรมพื้นฐานต้องใช้ 21,000 แก๊สและ 100 ไบต์ ซึ่งสามารถลดลงเหลือ ~25 คำหลังจากการบีบอัดในเทศกาลในอนาคต) ดังนั้นจากมุมมองของการคำนวณ ต้นทุนของ ZK-SNARK คือ 19 เท่าของต้นทุนของธุรกรรมพื้นฐานในปัจจุบัน และจากมุมมองของข้อมูล ต้นทุนของ ZK-SNARK คือ 4 เท่าของธุรกรรมพื้นฐานในปัจจุบันและ 16 เท่า ต้นทุนของเวลาธุรกรรมพื้นฐานในอนาคต ตัวเลขเหล่านี้เป็นการปรับปรุงครั้งใหญ่เหนือข้อพิสูจน์ของ Merkel แต่ก็ยังค่อนข้างแพง มีสองวิธีในการปรับปรุงสิ่งนี้: (i) การพิสูจน์ KZG เพื่อวัตถุประสงค์พิเศษ หรือ (ii) การรวม ซึ่งคล้ายกับการรวม ERC-4337 แต่ใช้การคำนวณทางคณิตศาสตร์ของนักเล่น เราสามารถเรียนทั้งสองอย่างพร้อมกันได้

6. การปรู๊ฟ KZG เพื่อจุดประสงค์พิเศษจะทำงานอย่างไร?

คำเตือน ส่วนนี้เป็นคณิตศาสตร์มากกว่าส่วนอื่นๆ เนื่องจากเรากำลังก้าวไปไกลกว่าเครื่องมืออเนกประสงค์ และสร้างเครื่องมือวัตถุประสงค์พิเศษที่มีราคาถูกลง ดังนั้นเราจึงต้องดำเนินการ "อย่างมีชั้นเชิง" ให้มากขึ้น หากคุณไม่ชอบคณิตศาสตร์เชิงลึก ให้ข้ามไปยังส่วนถัดไปได้เลย ขั้นแรก สรุปว่าพันธสัญญาของ KZG ทำงานอย่างไร: เราสามารถแสดงชุดข้อมูล [D_1...D_n] โดยใช้การพิสูจน์ KZG ของพหุนามที่ได้จากข้อมูล: โดยเฉพาะ พหุนาม P โดยที่ P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n. w นี่คือ "ยูนิฟอร์มรูท" ค่าของ wN = 1 สำหรับขนาดโดเมนการประเมินบางขนาด N (ทั้งหมดนี้ทำในฟิลด์จำกัด) ในการ "ผูกมัด" กับ P เราสร้างจุดโค้งวงรี com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk ที่นี่: -G คือจุดกำเนิดของเส้นโค้ง -Pi คือค่าสัมประสิทธิ์ ith ของพหุนาม P -Si เป็นจุด ith ในการตั้งค่าที่เชื่อถือได้ เพื่อพิสูจน์ว่า P(z) = a เราสร้างผลหารพหุนาม Q = (P - a) / (X - z) และสร้างความมุ่งมั่น com(Q) จะสร้างพหุนามดังกล่าวได้ก็ต่อเมื่อ P(z) เท่ากับ a เท่านั้น ในการตรวจสอบการพิสูจน์ เราตรวจสอบสมการ Q * (X - z) = P - a โดยดำเนินการตรวจสอบเส้นโค้งวงรีในการพิสูจน์ com(Q) และพันธะพหุนาม com(P): เราตรวจสอบ e(com(Q) ), คอม( X - z)) ? = จ(คอม(P) - คอม(ก), คอม(1)) คุณสมบัติหลักที่ควรทราบ ได้แก่ :

• การพิสูจน์เป็นเพียงค่า com(Q) ซึ่งเป็น 48 ไบต์ -com（P₁） + com（P₂） = com（P₁ + P₂） นอกจากนี้ยังหมายความว่าคุณสามารถ "แก้ไข" มูลค่าในสัญญาที่มีอยู่ได้ สมมติว่าเรารู้ว่าปัจจุบัน D_i เป็น a เราต้องการตั้งค่าเป็น b และข้อผูกมัดที่มีอยู่กับ D คือ com(P) สัญญาว่า "P แต่ P(wⁱ) = b และไม่มีการเปลี่ยนแปลงการประเมินอื่นๆ" จากนั้นเราตั้งค่า com(new_P) = com(P) + (ba)*com(Li) โดยที่ Li คือ "lag Langerian พหุนาม" เท่ากับ 1 ที่ wⁱ และ 0 ที่จุด wj อื่นๆ ในการดำเนินการอัปเดตเหล่านี้อย่างมีประสิทธิภาพ ไคลเอนต์แต่ละรายสามารถคำนวณล่วงหน้าและจัดเก็บการผูกมัด N ทั้งหมดกับพหุนาม Lagrange (com(Li)) ในสัญญาออนไลน์ อาจมากเกินไปที่จะเก็บข้อผูกมัด N ทั้งหมด ดังนั้นคุณจึงสามารถผูกมัด KZG กับชุดของค่า com(L_i) (หรือ hash(com(L_i)) ดังนั้นเมื่อใดก็ตามที่ บางคนต้องการ เมื่ออัปเดตทรีออนเชน พวกเขาสามารถแสดงหลักฐานความถูกต้องไปยัง com(L_i) ที่เหมาะสมได้ ดังนั้นเราจึงมีโครงสร้างที่เราสามารถเพิ่มมูลค่าต่อท้ายรายการที่เพิ่มขึ้นได้ แม้ว่าจะมีขนาดจำกัดก็ตาม (อันที่จริง อาจทำได้หลายร้อยล้านรายการ) จากนั้นเราจะใช้สิ่งนี้เป็นโครงสร้างข้อมูลของเราในการจัดการ (i) ข้อผูกมัดกับรายการคีย์บน L2 แต่ละอัน ซึ่งจัดเก็บไว้ใน L2 นั้นและมิเรอร์ไปยัง L1 และ (ii) ข้อผูกมัดกับรายการข้อผูกมัดของคีย์ L2 ที่จัดเก็บไว้ใน Ethereum L1 และ มิเรอร์ทุก L2 การอัปเดตข้อผูกพันสามารถเป็นส่วนหนึ่งของตรรกะหลัก L2 หรือดำเนินการผ่านสะพานฝากและถอนโดยไม่ต้องเปลี่ยนโปรโตคอลหลัก L2

ดังนั้น หลักฐานฉบับเต็มจึงต้องการ:

• ที่เก็บคีย์เก็บ com ล่าสุด (รายการคีย์) บน L2 (48 ไบต์) -KZG พิสูจน์ว่า com (รายการคีย์) คือ com (ค่าใน mirror_list) ความมุ่งมั่นต่อรายการส่งรายการคีย์ทั้งหมด (48 ไบต์) -KZG พิสูจน์ว่าคีย์ของคุณอยู่ใน com (รายการคีย์) (48 ไบต์ บวก 4 ไบต์สำหรับดัชนี) เป็นไปได้จริงที่จะรวมการพิสูจน์ KZG สองตัวเป็นหนึ่งเดียว เราจึงได้ขนาดรวมเพียง 100 ไบต์ หมายเหตุรายละเอียด: เนื่องจากรายการคีย์เป็นรายการ ไม่ใช่การแมปคีย์/ค่าเหมือนที่รัฐเป็น รายการคีย์ต้องได้รับการกำหนดตำแหน่งตามลำดับ สัญญาสัญญาคีย์จะมีรีจีสทรีภายในของตัวเอง การแม็พที่เก็บคีย์แต่ละรายการกับ ID และสำหรับแต่ละคีย์ จะเก็บแฮช (ที่อยู่ของที่เก็บคีย์) แทนที่จะเก็บเพียงคีย์ เพื่อที่จะสื่อสารกับ L2 อื่น ๆ อย่างชัดเจนว่าที่เก็บคีย์ใด รายการใดรายการหนึ่งกำลังพูดถึง ข้อดีของเทคนิคนี้คือทำงานได้ดีมากใน L2 ข้อมูลมีขนาด 100 ไบต์ ซึ่งสั้นกว่า ZK-SNARK ประมาณ 4 เท่า และสั้นกว่าการพิสูจน์ของ Merkle ค่าคำนวนหลักๆคือ เช็คคู่ 1 ครั้ง หรือประมาณ 119,000 แก๊ส ใน L1 ข้อมูลมีความสำคัญน้อยกว่าการคำนวณ ดังนั้น KZG จึงมีราคาแพงกว่าการพิสูจน์ของ Merkle เล็กน้อย

7. ต้นไม้ Verkle จะทำงานอย่างไร?

โดยพื้นฐานแล้ว Verkle tree เกี่ยวข้องกับการรวมข้อผูกพันของ KZG เข้าด้วยกัน (หรือข้อผูกพัน IPA ซึ่งอาจมีประสิทธิภาพมากกว่าและใช้การเข้ารหัสที่ง่ายกว่า): ในการจัดเก็บค่า 2⁴⁸ คุณต้องทำสัญญากับ KZG กับรายการของค่า 2²⁴ ซึ่งแต่ละค่าเป็นข้อผูกพันของ KZG 2²⁴ ค่า ต้นไม้ Verkle ได้รับการพิจารณาอย่างมากสำหรับต้นไม้สถานะ Ethereum เนื่องจากต้นไม้ Verkle สามารถใช้เพื่อเก็บการแมปคีย์-ค่า ไม่ใช่แค่รายการ (โดยทั่วไป คุณสามารถสร้างต้นไม้ขนาด 2²⁵⁶ แต่เริ่มว่างได้ เฉพาะในกรณีที่คุณเติมเฉพาะส่วนเฉพาะของ ต้นไม้เมื่อคุณต้องการเติมจริง ๆ )

ต้นไม้ Vicker มีลักษณะอย่างไร อันที่จริง คุณสามารถให้แต่ละโหนดมีความกว้าง 256 == 2⁸ สำหรับต้นไม้ที่ใช้ IPA และ 2²⁴ สำหรับต้นไม้ที่ใช้ KZG การพิสูจน์ในทรี Verkle นั้นค่อนข้างยาวกว่าใน KZG พวกมันสามารถยาวได้หลายร้อยไบต์ นอกจากนี้ยังยากแก่การตรวจสอบ โดยเฉพาะอย่างยิ่งหากคุณพยายามรวมหลักฐานหลายอย่างเข้าด้วยกัน อันที่จริง ต้นไม้ Verkle ควรได้รับการพิจารณาเหมือนกับต้นไม้ Merkle แต่เป็นไปได้มากกว่าหากไม่มี SNARKing (เนื่องจากต้นทุนข้อมูลที่ต่ำกว่า) และ SNARKing นั้นถูกกว่า (เนื่องจากต้นทุนการพิสูจน์ที่ต่ำกว่า) ข้อได้เปรียบที่ใหญ่ที่สุดของ Verkle tree คือสามารถประสานโครงสร้างข้อมูลได้: การพิสูจน์ Verkle สามารถใช้โดยตรงกับสถานะ L1 หรือ L2 ไม่มีโครงสร้างซ้อน และใช้กลไกเดียวกันทุกประการสำหรับ L1 และ L2 เมื่อควอนตัมคอมพิวเตอร์กลายเป็นปัญหา หรือเมื่อการแตกสาขาของ Merkle พิสูจน์แล้วว่ามีประสิทธิภาพเพียงพอ ต้นไม้ Verkle จะถูกแทนที่ด้วยต้นไม้แฮชแบบไบนารีด้วยฟังก์ชันแฮชที่เหมาะกับ SNARK ที่เหมาะสม

8. การรวม

หากผู้ใช้ N รายทำธุรกรรม N รายการ (หรือตามความเป็นจริง N ERC-4337 UserOperations) จำเป็นต้องพิสูจน์การอ้างสิทธิ์ข้ามเครือข่าย N ครั้ง เราสามารถประหยัดเงินได้มากโดยการรวมหลักฐานเหล่านี้เข้าด้วยกัน: การรวมธุรกรรมเหล่านี้เป็นบล็อกหรือตัวสร้างบันเดิล ที่เข้าไปในบล็อกสามารถสร้างหลักฐานที่พิสูจน์การอ้างสิทธิ์ทั้งหมดนี้ได้ในเวลาเดียวกัน นี่อาจหมายถึง:

• หลักฐาน ZK-SNARK สำหรับสาขา N Merkle
• KZG หลายหลักฐาน
• Verkle หลายหลักฐาน (หรือ ZK-SNARK หลายหลักฐาน) ในทั้งสามกรณี การพิสูจน์แต่ละครั้งต้องใช้น้ำมันเพียงไม่กี่แสน ผู้สร้างจำเป็นต้องสร้างสิ่งเหล่านี้ในแต่ละ L2 สำหรับผู้ใช้ใน L2 นั้น ดังนั้น เพื่อความสะดวกในการสร้าง โครงร่างทั้งหมดจำเป็นต้องใช้อย่างเพียงพอที่โดยปกติจะมีธุรกรรมอย่างน้อยสองสามรายการในบล็อกเดียวกันในการแลกเปลี่ยน L2 ที่สำคัญหลายรายการ . หากใช้ ZK-SNARK ต้นทุนส่วนเพิ่มหลักจะเป็นเพียง "ตรรกะทางธุรกิจ" ในการส่งผ่านหมายเลขระหว่างสัญญา ดังนั้นผู้ใช้แต่ละคนอาจต้องใช้ก๊าซ L2 หลายพันถัง หากใช้ KZG multi-proof ผู้พิสูจน์จำเป็นต้องเพิ่ม 48 gas สำหรับแต่ละที่เก็บคีย์ที่มี L2 ที่ใช้ภายในบล็อก ดังนั้นต้นทุนส่วนเพิ่มของโครงร่างต่อผู้ใช้จะเป็นต่อ L2 (ไม่ใช่ต่อผู้ใช้) แล้วจึงเพิ่ม ~800 L1 gas . แต่ค่าใช้จ่ายเหล่านี้จะต่ำกว่ามากเมื่อไม่มีการรวม ซึ่งเกี่ยวข้องกับก๊าซ L1 มากกว่า 10,000 และก๊าซ L2 หลายแสนต่อผู้ใช้อย่างหลีกเลี่ยงไม่ได้ สำหรับ Verkle tree คุณสามารถใช้ Verkle multi-proofs ได้โดยตรง โดยเพิ่มประมาณ 100-200 ไบต์ต่อผู้ใช้หนึ่งราย หรือคุณสามารถสร้าง ZK-SNARK ของ Verkle multi-proofs ซึ่งมีราคาใกล้เคียงกับ ZK-SNARK ที่ Merkle-forked แต่ค่าใช้จ่ายในการพิสูจน์ ต่ำกว่ามาก จากมุมมองของการนำไปใช้งาน จะเป็นการดีกว่าสำหรับผู้รวมกลุ่มเพื่อรวบรวมการพิสูจน์ข้ามสายโซ่ผ่านมาตรฐานการแยกบัญชี ERC-4337 ERC-4337 มีกลไกสำหรับผู้สร้างในการรวมส่วนต่าง ๆ ของการกระทำของผู้ใช้ด้วยวิธีที่กำหนดเอง มีแม้แต่การใช้งานสำหรับการรวมลายเซ็น BLS ซึ่งสามารถลดต้นทุนก๊าซใน L2 ได้ 1.5 ถึง 3 เท่า ขึ้นอยู่กับรูปแบบการบีบอัดอื่น ๆ ที่รวมอยู่ด้วย

ไดอะแกรมจากโพสต์การใช้งานกระเป๋าเงิน BLS ที่แสดงเวิร์กโฟลว์สำหรับลายเซ็นรวม BLS ใน ERC-4337 เวอร์ชันก่อนหน้า เวิร์กโฟลว์สำหรับการรวมการพิสูจน์ข้ามสายโซ่อาจดูคล้ายกันมาก

9. การอ่านสถานะโดยตรง

ความเป็นไปได้ขั้นสุดท้ายที่มีให้สำหรับ L2 ที่อ่าน L1 เท่านั้น (และไม่ใช่ L1 ที่อ่าน L2) คือการแก้ไข L2 เพื่อให้พวกเขาทำการเรียกคงที่โดยตรงไปยังสัญญาบน L1 สิ่งนี้สามารถทำได้ด้วย opcodes หรือการคอมไพล์ล่วงหน้า ซึ่งอนุญาตให้เรียกไปยัง L1 โดยที่คุณระบุที่อยู่เป้าหมาย ข้อมูลก๊าซ และข้อมูลการโทร และส่งคืนเอาต์พุต แต่เนื่องจากการเรียกเหล่านี้เป็นแบบคงที่ จึงไม่สามารถเปลี่ยนสถานะ L1 ใดๆ ได้ L2 ต้องรู้ว่า L1 ได้ดำเนินการกับเงินฝากแล้ว ดังนั้นจึงไม่มีอะไรขัดขวางการดำเนินการดังกล่าวได้ นี่เป็นความท้าทายในการดำเนินการด้านเทคนิคเป็นส่วนใหญ่ (ดู: สิ่งนี้มาจาก RFP ในแง่ดีเพื่อสนับสนุนการเรียกแบบคงที่ไปยัง L1) โปรดทราบว่าหากที่เก็บคีย์อยู่บน L1 และ L2 รวมการเรียกแบบสแตติก L1 ไม่จำเป็นต้องมีการยืนยันเลย! อย่างไรก็ตาม หาก L2 ไม่รวมการเรียกแบบสแตติก L1 หรือถ้าที่เก็บคีย์อยู่บน L2 (ซึ่งอาจต้องทำในที่สุดเมื่อ L1 แพงเกินไปสำหรับผู้ใช้ที่จะใช้แม้แต่นิดเดียว) ก็จำเป็นต้องมีการพิสูจน์

10. L2 เรียนรู้รากสถานะ Ethereum ล่าสุดได้อย่างไร

รูปแบบข้างต้นทั้งหมดต้องการ L2 เพื่อเข้าถึงรูทสถานะ L1 ที่ใกล้ที่สุดหรือสถานะ L1 ที่ใกล้ที่สุดทั้งหมด โชคดีที่ L2 ทั้งหมดมีฟังก์ชันบางอย่างในการเข้าถึงสถานะ L1 ล่าสุดอยู่แล้ว นี่เป็นเพราะพวกเขาต้องการฟังก์ชันดังกล่าวเพื่อจัดการข้อความจาก L1 ถึง L2 โดยเฉพาะการฝาก ในความเป็นจริง หาก L2 มีฟังก์ชันฝาก คุณสามารถใช้ L2 นั้นเพื่อย้ายรูทสถานะ L1 ไปยังสัญญาบน L2: เพียงแค่มีสัญญาบน L1 เรียก BLOCKHASH opcode และส่งต่อไปยัง L2 เป็นข้อความฝาก . สามารถรับส่วนหัวของบล็อกแบบเต็มได้ที่ด้าน L2 และแยกสถานะของรูทออก อย่างไรก็ตาม แต่ละ L2 มีวิธีที่ชัดเจนในการเข้าถึงสถานะ L1 ล่าสุดแบบเต็มหรือรากสถานะ L1 ที่ใกล้ที่สุดโดยตรง ความท้าทายหลักในการเพิ่มประสิทธิภาพวิธีที่ L2 รับรูทสถานะ L1 ล่าสุดคือการได้รับความปลอดภัยและความหน่วงต่ำในเวลาเดียวกัน:

• หาก L2 ใช้ฟังก์ชัน "อ่าน L1 โดยตรง" แบบสันหลังยาว อ่านเฉพาะรากสถานะ L1 สุดท้าย โดยทั่วไปแล้วการหน่วงเวลาจะอยู่ที่ 15 นาที แต่ในกรณีที่ไม่มีการใช้งานรั่วไหล (ซึ่งคุณต้องทนรับ) การหน่วงเวลาอาจเป็นได้ สัปดาห์.
• L2 สามารถออกแบบมาให้อ่านรูทของสถานะ L1 ที่อัปเดตได้อย่างแน่นอน แต่เนื่องจาก L1 สามารถกู้คืนได้ (ซึ่งเกิดขึ้นระหว่างการรั่วไหลที่ไม่ได้ใช้งานแม้ว่าจะมีการสิ้นสุดของซ็อกเก็ตเดียว) L2 จึงจำเป็นต้องสามารถกู้คืนได้เช่นกัน จากมุมมองของวิศวกรรมซอฟต์แวร์ สิ่งนี้มีความท้าทายทางเทคนิค แต่อย่างน้อย Optimistic ก็มีความสามารถ
• หากคุณใช้สะพานเงินฝากเพื่อนำรากสถานะ L1 มาสู่ L2 เศรษฐศาสตร์อย่างง่ายอาจต้องใช้เวลาระหว่างการอัปเดตเงินฝากนาน: หากต้นทุนเต็มของเงินฝากคือ 100,000 ก๊าซ สมมติว่า $1800 เป็น ETH และค่าธรรมเนียม 200 gwei และราก L1 เข้าสู่ L2 วันละครั้ง ซึ่งจะมีค่าใช้จ่าย $236 ต่อ L ต่อวัน หรือ $13,148 ต่อ L2 ต่อปีในการบำรุงรักษาระบบ การล่าช้าหนึ่งชั่วโมงมีค่าใช้จ่ายสูงถึง $315,569 ต่อ L2 ต่อปี ที่ดีที่สุดคือมีผู้ใช้ที่ร่ำรวยที่ใจร้อนจำนวนมากจ่ายเงินเพื่ออัปเดตและทำให้ระบบทันสมัยอยู่เสมอสำหรับทุกคน ที่เลวร้ายที่สุด ผู้กระทำการที่เห็นแก่ผู้อื่นบางคนจะต้องจ่ายเอง
• "Oracles" (อย่างน้อยก็เป็นเทคโนโลยีที่ DeFi บางคนเรียกว่า "oracles") ไม่ใช่วิธีแก้ปัญหาที่ยอมรับได้ที่นี่: การจัดการคีย์กระเป๋าเงินเป็นฟังก์ชันระดับต่ำที่มีความสำคัญอย่างยิ่งต่อความปลอดภัย ดังนั้นจึงควรขึ้นอยู่กับ A ที่ง่ายมาก โครงสร้างพื้นฐานระดับต่ำที่ไม่ต้องการความน่าเชื่อถือในการเข้ารหัส นอกจากนี้ ในทิศทางตรงกันข้าม (L1s อ่านว่า L2):
• ในการรวมในแง่ดี การรูทสถานะจะใช้เวลาหนึ่งสัปดาห์ในการเข้าถึง L1 เนื่องจากความล่าช้าในการพิสูจน์การฉ้อโกง ในการยกเลิก ZK ตอนนี้ต้องใช้เวลาหลายชั่วโมงเนื่องจากเวลาที่ใช้ในการตรวจสอบและข้อจำกัดทางเศรษฐกิจร่วมกัน แม้ว่าเทคโนโลยีในอนาคตจะลดขั้นตอนนี้ลงก็ตาม
• การยืนยันล่วงหน้า (จากซีเควนเซอร์ ผู้รับรอง ฯลฯ) ไม่ใช่วิธีแก้ปัญหาที่ยอมรับได้สำหรับ L1 ที่อ่าน L2 การจัดการกระเป๋าเงินเป็นฟังก์ชันระดับต่ำที่มีความสำคัญอย่างยิ่งต่อความปลอดภัย ดังนั้นระดับความปลอดภัยของการสื่อสาร L2 - L1 จะต้องเป็นแบบสัมบูรณ์: เป็นไปไม่ได้เลยที่จะพุชสถานะ L1 ที่ไม่ถูกต้องด้วยการเข้าใช้ชุดเครื่องมือตรวจสอบความถูกต้องของ L2 รูทสถานะเดียวที่ L1 ควรเชื่อถือคือรูทสถานะสุดท้ายที่ได้รับการยอมรับว่าเป็นรูทสถานะสุดท้ายโดยสัญญาการถือครองรูทสถานะของ L2 บน L1 สำหรับกรณีการใช้งาน DeFi หลายๆ กรณี บางกรณีนั้นช้าจนไม่สามารถยอมรับได้สำหรับการดำเนินการข้ามสายโซ่ที่ไม่ไว้วางใจ ในกรณีเหล่านี้ คุณต้องการบริดจ์ที่เร็วกว่าด้วยโมเดลการรักษาความปลอดภัยที่ไม่สมบูรณ์แบบมากกว่านี้ อย่างไรก็ตาม สำหรับกรณีการใช้งานของการอัปเดตรหัสกระเป๋าเงิน ความล่าช้าที่นานขึ้นจะเป็นที่ยอมรับมากกว่า: แทนที่จะทำธุรกรรมล่าช้าเป็นเวลาหลายชั่วโมง คุณจะชะลอการเปลี่ยนแปลงคีย์ คุณเพียงแค่ต้องเก็บกุญแจเก่าไว้นานขึ้น หากคุณเปลี่ยนกุญแจเพราะถูกขโมย คุณมีช่องโหว่มานานแล้ว แต่สามารถบรรเทาได้ เช่น ผ่านกระเป๋าเงินที่มีฟังก์ชั่นการแช่แข็ง ท้ายที่สุด วิธีแก้ปัญหาการลดเวลาแฝงที่ดีที่สุดคือการให้ L2 ใช้การอ่านโดยตรงของสถานะรูท L1 อย่างเหมาะสม โดยที่แต่ละบล็อก L2 (หรือบันทึกการคำนวณรูทสถานะ) มีตัวชี้ไปยังบล็อก L1 ล่าสุด ดังนั้นหาก L1 กู้คืนและ L2 ก็สามารถฟื้นตัวได้เช่นกัน ควรวางสัญญา Keystore บน mainnet หรือบน L2 ของ ZK Rollup เพื่อให้สามารถผูกมัดกับ L1 ได้อย่างรวดเร็ว

บล็อกของห่วงโซ่ L2 ไม่เพียงขึ้นอยู่กับบล็อก L2 ก่อนหน้า แต่ยังรวมถึงบล็อก L1 ด้วย หาก L1 กู้คืนจากลิงก์ดังกล่าว L2 ก็จะกู้คืนเช่นกัน เป็นที่น่าสังเกตว่านี่เป็นวิธีการที่ Sharding เวอร์ชันก่อนหน้า (ก่อน Dank) ถูกจินตนาการให้ทำงาน ดูโค้ดที่นี่

11. เชนอื่นจำเป็นต้องเชื่อมต่อกับ Ethereum มากน้อยเพียงใดในการเก็บคีย์สโตร์ที่รูทใน Ethereum หรือกระเป๋าเงิน L2

น่าแปลกใจที่ไม่มาก จริงๆ แล้วไม่จำเป็นต้องเป็นการยกเลิกด้วยซ้ำ: หากเป็น L3 หรือการตรวจสอบความถูกต้อง คุณสามารถเก็บกระเป๋าเงินไว้ที่นั่นได้ ตราบใดที่คุณเก็บคีย์สโตร์ไว้ในการยกเลิก L1 หรือ ZK สิ่งที่คุณต้องการจริงๆ คือห่วงโซ่ที่สามารถเข้าถึงรูทสถานะ Ethereum ได้โดยตรง และความมุ่งมั่นด้านเทคนิคและสังคมที่จะเต็มใจจัดระเบียบใหม่หาก Ethereum จัดโครงสร้างใหม่ และฮาร์ดฟอร์กหาก Ethereum ฮาร์ดฟอร์ก คำถามการวิจัยที่น่าสนใจคือการกำหนดขอบเขตที่ chain สามารถมีรูปแบบการเชื่อมต่อนี้กับ chain อื่นๆ (เช่น Ethereum และ Zcash) การทำเช่นนี้แบบไร้เดียงสาเป็นไปได้: หาก Ethereum หรือ Zcash จัดระเบียบใหม่ ห่วงโซ่ของคุณสามารถตกลงที่จะจัดระเบียบใหม่ (และฮาร์ดฟอร์กหาก Ethereum หรือ Zcash ทำการฮาร์ดฟอร์ก) แต่ผู้ให้บริการโหนดและชุมชนของคุณมักจะมีการพึ่งพาทางเทคโนโลยีและการเมืองสองเท่า ดังนั้นเทคนิคนี้สามารถใช้เชื่อมต่อกับเครือข่ายอื่น ๆ ได้ แต่มีค่าใช้จ่ายเพิ่มขึ้น โครงร่างที่ใช้สะพาน ZK มีคุณสมบัติทางเทคนิคที่น่าสนใจ แต่จุดอ่อนที่สำคัญคือไม่ทนทานต่อการโจมตี 51% หรือการฮาร์ดฟอร์ก อาจมีวิธีแก้ปัญหาที่ชาญฉลาดกว่าเช่นกัน

12. การคุ้มครองความเป็นส่วนตัว

เป็นการดีที่เราต้องการรักษาความเป็นส่วนตัวด้วย หากคุณมีกระเป๋าเงินจำนวนมากที่จัดการโดยที่เก็บคีย์เดียวกัน เราต้องการให้แน่ใจว่า:

• ไม่ชัดเจนว่ากระเป๋าเงินเหล่านี้เชื่อมต่อกันทั้งหมด
• ผู้ดูแลการฟื้นฟูสมรรถภาพทางสังคมไม่รู้ว่าพวกเขากำลังปกป้องที่อยู่ใด สิ่งนี้สร้างปัญหาบางอย่าง:
• เราไม่สามารถใช้การพิสูจน์ของ Merkle ได้โดยตรง เนื่องจากไม่ได้ปกป้องความเป็นส่วนตัว
• หากเราใช้ KZG หรือ SNARK การพิสูจน์จะต้องระบุรหัสยืนยันแบบปกปิดโดยไม่เปิดเผยตำแหน่งของรหัสยืนยัน
• ถ้าเราใช้การรวมรวม ผู้รวบรวมไม่ควรเรียนรู้ตำแหน่งในข้อความธรรมดา แต่ผู้รวบรวมควรได้รับการพิสูจน์ที่มองไม่เห็นและมีวิธีในการรวมการพิสูจน์เหล่านี้
• เราไม่สามารถใช้ "รุ่นไลท์" (การต่ออายุคีย์โดยใช้การพิสูจน์ข้ามสายโซ่เท่านั้น) เพราะมันทำให้เกิดการรั่วไหลของความเป็นส่วนตัว: หากมีการอัปเดตกระเป๋าเงินหลายใบพร้อมกันเนื่องจากกระบวนการอัปเดต ข้อมูลการรั่วไหลของเวลาที่อาจเกี่ยวข้องกับ กระเป๋าเงินเหล่านี้ ดังนั้นเราจึงต้องใช้ "เวอร์ชันหนัก" (การพิสูจน์ข้ามเชนของแต่ละธุรกรรม) เมื่อใช้ SNARK โซลูชันจะเรียบง่ายตามแนวคิด โดยค่าเริ่มต้น การพิสูจน์จะถูกปกปิดข้อมูล และผู้รวบรวมข้อมูลจำเป็นต้องสร้าง SNARK แบบเรียกซ้ำเพื่อพิสูจน์ SNARK

ความท้าทายหลักของแนวทางนี้ในปัจจุบันคือการรวมต้องการให้ตัวรวบรวมสร้าง SNARK แบบเรียกซ้ำ ซึ่งขณะนี้ช้ามาก ด้วย KZG เราสามารถใช้งานนี้ (ดูเพิ่มเติม: เวอร์ชันที่เป็นทางการมากขึ้นของงานนี้ในเอกสาร Caulk) ในการพิสูจน์ KZG ที่ไม่เปิดเผยดัชนีเป็นจุดเริ่มต้น อย่างไรก็ตาม การรวมการพิสูจน์คนตาบอดเป็นปัญหาเปิดที่ต้องให้ความสนใจมากขึ้น น่าเสียดายที่การอ่าน L1 โดยตรงจากภายใน L2 ไม่ได้รักษาความเป็นส่วนตัว แม้ว่าการใช้ฟังก์ชันการอ่านโดยตรงจะยังมีประโยชน์อยู่มาก ทั้งเพื่อลดเวลาแฝงและเนื่องจากยูทิลิตี้สำหรับแอปพลิเคชันอื่นๆ

13. สรุป

หากต้องการมีกระเป๋าเงินสำหรับการกู้คืนทางสังคมแบบข้ามสายโซ่ เวิร์กโฟลว์ที่สมจริงที่สุดคือกระเป๋าเงินที่รักษาที่เก็บคีย์ไว้ในที่เดียว และกระเป๋าเงินที่ดูแลกระเป๋าเงินในหลาย ๆ ที่ ซึ่งกระเป๋าเงินจะอ่านที่เก็บคีย์เพื่อ (i) อัปเดตคีย์การตรวจสอบสิทธิ์ในเครื่อง ดู หรือ (ii) ในกระบวนการตรวจสอบธุรกรรมแต่ละรายการ องค์ประกอบสำคัญที่ทำให้สิ่งนี้เป็นไปได้คือการพิสูจน์ข้ามสายโซ่ เราจำเป็นต้องทำงานเพื่อเพิ่มประสิทธิภาพการพิสูจน์เหล่านี้ ZK-SNARK หรือโซลูชัน KZG แบบกำหนดเองที่รอการพิสูจน์จาก Verkle ดูเหมือนจะเป็นตัวเลือกที่ดีที่สุด ในระยะยาว โปรโตคอลการรวม (โดยที่บันเดิลสร้างการพิสูจน์รวมซึ่งเป็นส่วนหนึ่งของการสร้างบันเดิลของการดำเนินการของผู้ใช้ทั้งหมดที่ส่งโดยผู้ใช้) เป็นสิ่งจำเป็นเพื่อลดค่าใช้จ่าย สิ่งนี้น่าจะรวมอยู่ในระบบนิเวศ ERC-4337 แม้ว่าอาจต้องมีการเปลี่ยนแปลง ERC-4337 ควรปรับ L2 ให้เหมาะสมเพื่อลดเวลาแฝงของการอ่านสถานะ L1 (หรืออย่างน้อยสถานะรูท) จากภายใน L2 เหมาะอย่างยิ่งสำหรับ L2s ในการอ่านสถานะ L1 โดยตรง ช่วยประหยัดพื้นที่ในการพิสูจน์ กระเป๋าเงินไม่สามารถอยู่บน L2 เท่านั้น คุณยังสามารถใส่กระเป๋าเงินในระบบที่มีระดับการเชื่อมต่อกับ Ethereum ต่ำกว่า (L3 หรือแม้กระทั่งตกลงที่จะรวมรากสถานะ Ethereum และ chain of fork ที่เป็นอิสระ) อย่างไรก็ตาม ที่เก็บคีย์ควรอยู่บน L1 หรือ ZK rollup ความปลอดภัยสูง L2 การใช้ L1 ช่วยประหยัดความซับซ้อนได้มาก แต่ถึงแม้จะมีราคาแพงเกินไปในระยะยาว ดังนั้นจึงจำเป็นต้องใช้ที่เก็บคีย์บน L2 การรักษาความเป็นส่วนตัวจะต้องทำงานพิเศษและทำให้การเลือกบางอย่างยากขึ้น อย่างไรก็ตาม เราน่าจะหันมาใช้วิธีการรักษาความเป็นส่วนตัวอยู่ดี อย่างน้อยก็ต้องแน่ใจว่าสิ่งที่เราคิดขึ้นมานั้นสอดคล้องกับการรักษาความเป็นส่วนตัว