ชื่อต้นฉบับ: อนาคตที่เป็นไปได้ของโปรโตคอล Ethereum ตอนที่ 4: The Verge
ผู้เขียนต้นฉบับ: Vitalik Buterin
การรวบรวมต้นฉบับ: Mensh, ChainCatcher
ขอขอบคุณเป็นพิเศษสำหรับ Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams และ Uma Roy สำหรับคำติชมและบทวิจารณ์
หนึ่งในคุณสมบัติที่ทรงพลังที่สุดของบล็อคเชนคือใครๆ ก็สามารถรันโหนดบนคอมพิวเตอร์ของตนเองและตรวจสอบความถูกต้องของบล็อคเชนได้ แม้ว่าโหนด 9596 ที่ทำงานเป็นเอกฉันท์ของห่วงโซ่ (PoW, PoS) ทั้งหมดเห็นด้วยกับการเปลี่ยนแปลงกฎทันที และเริ่มสร้างบล็อกตามกฎใหม่ ทุกคนที่เรียกใช้โหนดที่ได้รับการตรวจสอบความถูกต้องโดยสมบูรณ์จะปฏิเสธที่จะยอมรับห่วงโซ่ คนงานเหมืองที่ไม่ได้เป็นส่วนหนึ่งของกลุ่มพันธมิตรดังกล่าวจะมารวมตัวกันในเครือข่ายที่ยังคงปฏิบัติตามกฎเก่าโดยอัตโนมัติ และสร้างเครือข่ายนี้ต่อไป ในขณะที่ผู้ใช้ที่ได้รับการตรวจสอบอย่างสมบูรณ์จะติดตามเครือข่ายนี้
นี่คือข้อแตกต่างที่สำคัญระหว่างบล็อคเชนและระบบรวมศูนย์ อย่างไรก็ตาม เพื่อให้คุณลักษณะนี้เป็นจริง การเรียกใช้โหนดที่ได้รับการตรวจสอบโดยสมบูรณ์จะต้องเป็นไปได้จริงสำหรับคนจำนวนมากพอ สิ่งนี้ใช้ได้กับทั้งผู้รณรงค์ (เพราะหากผู้รณรงค์ไม่ตรวจสอบความถูกต้องของห่วงโซ่ พวกเขาจะไม่มีส่วนร่วมในการบังคับใช้กฎของโปรโตคอล) และกับผู้ใช้ทั่วไป ปัจจุบัน มีความเป็นไปได้ที่จะรันโหนดบนแล็ปท็อปสำหรับผู้บริโภค (รวมถึงเครื่องที่ฉันเขียนบทความนี้ด้วย) แต่การทำเช่นนี้เป็นเรื่องยาก The Verge มีเป้าหมายที่จะเปลี่ยนแปลงสถานการณ์นี้ ทำให้ค่าใช้จ่ายในการคำนวณในการตรวจสอบห่วงโซ่อย่างสมบูรณ์ต่ำมากจนกระเป๋าเงินมือถือ กระเป๋าเงินของเบราว์เซอร์ และแม้แต่นาฬิกาอัจฉริยะทุกเครื่องจะตรวจสอบตามค่าเริ่มต้น
โรดแมป The Verge 2023
เดิมที Verge หมายถึงการย้ายที่เก็บข้อมูลสถานะ Ethereum ไปยังแผนผัง Verkle ซึ่งเป็นโครงสร้างแบบต้นไม้ที่ช่วยให้มีการพิสูจน์ที่มีขนาดกะทัดรัดมากขึ้น ช่วยให้สามารถตรวจสอบบล็อก Ethereum แบบไร้สถานะได้ โหนดสามารถตรวจสอบบล็อก Ethereum ได้โดยไม่ต้องจัดเก็บสถานะ Ethereum ใด ๆ (ยอดคงเหลือในบัญชี รหัสสัญญา พื้นที่เก็บข้อมูล...) ไว้ในฮาร์ดไดรฟ์ โดยเสียข้อมูลพิสูจน์หลายร้อย KB และใช้เวลาเพิ่มเติมหลายร้อยมิลลิวินาทีในการตรวจสอบพิสูจน์ . ในปัจจุบัน Verge แสดงถึงวิสัยทัศน์ที่ใหญ่ขึ้นซึ่งมุ่งเน้นไปที่การเปิดใช้งานการตรวจสอบความถูกต้องของทรัพยากรสูงสุดของห่วงโซ่ Ethereum ซึ่งรวมถึงไม่เพียงแต่เทคโนโลยีการตรวจสอบแบบไร้สถานะเท่านั้น แต่ยังรวมไปถึงการใช้ SNARK เพื่อตรวจสอบการดำเนินการ Ethereum ทั้งหมด
นอกเหนือจากการมุ่งเน้นไปที่การตรวจสอบ SNARK ของห่วงโซ่ทั้งหมดในระยะยาวแล้ว คำถามที่เกิดขึ้นอีกประการหนึ่งก็คือ Verkle tree เป็นเทคโนโลยีที่ดีที่สุดหรือไม่ ต้นไม้ Verkle เสี่ยงต่อการถูกโจมตีโดยคอมพิวเตอร์ควอนตัม ดังนั้นหากเราแทนที่ต้นไม้ KECCAK Merkle Patricia ในปัจจุบันด้วยต้นไม้ Verkle เราจะต้องเปลี่ยนต้นไม้อีกครั้งในภายหลัง ทางเลือกอื่นที่มีในตัวเองสำหรับต้นไม้ Merkle คือการข้าม STARK โดยใช้สาขา Merkle และใส่ไว้ในต้นไม้ไบนารี ในอดีต วิธีการนี้ถือว่าไม่สามารถทำได้เนื่องจากค่าใช้จ่ายและความซับซ้อนทางเทคนิค อย่างไรก็ตาม เมื่อเร็วๆ นี้ เราเห็นว่า Starkware พิสูจน์แฮชของโพไซดอนได้ 1.7 ล้านแฮชต่อวินาทีโดยใช้ ckcle STARK บนแล็ปท็อป และด้วยเทคโนโลยีอย่าง GKB เวลาในการพิสูจน์สำหรับแฮช แบบดั้งเดิม ที่มากขึ้นก็ลดลงอย่างรวดเร็วเช่นกัน ดังนั้นในปีที่ผ่านมา Verge จึงมีความเปิดกว้างมากขึ้น แต่ก็มีความเป็นไปได้หลายประการ
The Verge: วัตถุประสงค์หลัก
ไคลเอ็นต์ไร้สถานะ: พื้นที่เก็บข้อมูลที่จำเป็นในการตรวจสอบสิทธิ์ไคลเอ็นต์โดยสมบูรณ์และทำเครื่องหมายโหนดไม่ควรเกินสองสาม GB
(ระยะยาว) ห่วงโซ่ที่ได้รับการตรวจสอบอย่างสมบูรณ์ (ฉันทามติและการดำเนินการ) บนสมาร์ทวอทช์ ดาวน์โหลดข้อมูลบางส่วน ตรวจสอบ SNARK และเสร็จสิ้น
ในบทนี้
ลูกค้าไร้สัญชาติ: Verkle หรือ STARKs
หลักฐานยืนยันประสิทธิผลของการดำเนินการ EVM
หลักฐานความถูกต้องของความเห็นพ้องต้องกัน
การยืนยันแบบไร้สัญชาติ: Verkle หรือ STARKs
เรากำลังพยายามแก้ไขปัญหาอะไร
ในปัจจุบัน ลูกค้า Ethereum จำเป็นต้องจัดเก็บข้อมูลสถานะหลายร้อยกิกะไบต์เพื่อตรวจสอบความถูกต้องของบล็อก และจำนวนนี้จะเพิ่มขึ้นทุกปี ข้อมูลสถานะดิบจะเพิ่มขึ้นประมาณ 30 GB ต่อปี และไคลเอนต์รายเดียวจะต้องจัดเก็บข้อมูลเพิ่มเติมบางส่วนไว้เพื่ออัปเดตสามรายการได้อย่างมีประสิทธิภาพ
สิ่งนี้จะช่วยลดจำนวนผู้ใช้สามารถเรียกใช้โหนด Ethereum ที่ตรวจสอบความถูกต้องได้อย่างสมบูรณ์: แม้ว่าฮาร์ดไดรฟ์จะมีขนาดใหญ่พอที่จะจัดเก็บสถานะ Ethereum ทั้งหมดและแม้กระทั่งประวัติความเป็นมาหลายปีก็ตาม ผู้คนมักจะซื้อคอมพิวเตอร์โดยค่าเริ่มต้นโดยมีพื้นที่จัดเก็บเพียงไม่กี่ร้อยกิกะไบต์ ขนาดของรัฐยังทำให้เกิดความขัดแย้งที่สำคัญในกระบวนการตั้งค่าโหนดเป็นครั้งแรก โดยโหนดจำเป็นต้องดาวน์โหลดสถานะทั้งหมด ซึ่งอาจใช้เวลาหลายชั่วโมงหรือหลายวัน สิ่งนี้มีเอฟเฟกต์การกระแทกทุกประเภท ตัวอย่างเช่น ผู้สร้างโหนดจะอัพเกรดการตั้งค่าโหนดได้ยากขึ้นอย่างมาก ในทางเทคนิค คุณสามารถทำการอัปเกรดให้เสร็จสิ้นโดยไม่ต้องหยุดทำงาน - เริ่มไคลเอนต์ใหม่ รอให้ซิงค์ จากนั้นปิดไคลเอนต์เก่าและถ่ายโอนคีย์ - แต่ในทางปฏิบัติ สิ่งนี้มีความซับซ้อนมากในทางเทคนิค
มันทำงานอย่างไร?
การตรวจสอบแบบไร้สถานะเป็นเทคโนโลยีที่ช่วยให้โหนดสามารถตรวจสอบการบล็อกโดยไม่ต้องควบคุมสถานะทั้งหมด แต่ละบล็อกจะมาพร้อมกับพยานซึ่งรวมถึง: (i) ค่า รหัส ยอดคงเหลือ ที่เก็บข้อมูลในตำแหน่งเฉพาะในสถานะที่บล็อกจะเข้าถึง (ii) การพิสูจน์การเข้ารหัสว่าค่าเหล่านี้ถูกต้อง
ในความเป็นจริง การใช้การยืนยันแบบไร้สถานะจำเป็นต้องเปลี่ยนโครงสร้างแผนผังสถานะของ Ethereum เนื่องจากต้น Merkle Patricia ในปัจจุบันไม่เป็นมิตรอย่างยิ่งต่อการดำเนินการตามโครงการพิสูจน์การเข้ารหัสใดๆ โดยเฉพาะอย่างยิ่งในสถานการณ์กรณีที่เลวร้ายที่สุด สิ่งนี้เป็นจริงไม่ว่าจะเป็นส้อม Merblk ดั้งเดิม หรือความเป็นไปได้ที่จะถูก ห่อ ไว้ใน STARK ปัญหาหลักเกิดจากจุดอ่อนของ MPT:
1. นี่คือเฮกซะทรี (กล่าวคือ แต่ละโหนดมีโหนดลูก 16 โหนด) ซึ่งหมายความว่าในแผนผังขนาด N การพิสูจน์ต้องมีค่าเฉลี่ย 32*(16-1)*log 16(N) = 120* log 2(N) ไบต์ หรือประมาณ 3840 ไบต์ สำหรับต้นไม้ไบนารี ต้องใช้ไบต์ 32*(2-1)*log 2(N) = 32* log 2(N) เท่านั้น หรือประมาณ 1,024 ไบต์
2. รหัสไม่ Merkleized ซึ่งหมายความว่าการพิสูจน์การเข้าถึงรหัสบัญชีจำเป็นต้องระบุรหัสทั้งหมด ซึ่งสามารถมีขนาดได้ถึง 24,000 ไบต์
เราสามารถคำนวณสถานการณ์กรณีที่เลวร้ายที่สุดได้ดังนี้:
30000000 gas / 2400 (ค่าใช้จ่ายในการอ่านบัญชีเย็น) * (5 * 488 + 24000) = 330000000 ไบต์
ต้นทุนสาขาลดลงเล็กน้อย (5* 480 แทนที่จะเป็น 8* 480) เพราะเมื่อมีสาขามากขึ้น ส่วนบนของสาขาจะซ้ำกัน แต่ถึงกระนั้น ปริมาณข้อมูลที่จะดาวน์โหลดในช่วงเวลาหนึ่งก็ไม่สมจริงเลย หากเราพยายามรวมมันด้วย STARK เราจะพบปัญหาสองประการ: (i) KECCAK ค่อนข้างไม่เป็นมิตร (ii) ข้อมูล 330 MB หมายความว่าเราต้องปรับการเรียก 5 ล้านครั้งไปยังฟังก์ชันปัดเศษของ KECCAK ซึ่งนี่อาจไม่ ได้รับการพิสูจน์แล้วสำหรับทุกคน ยกเว้นฮาร์ดแวร์สำหรับผู้บริโภคที่ทรงพลังที่สุด แม้ว่าเราจะให้ STARK พิสูจน์ได้ว่า KECCAK นั้นมีประสิทธิภาพมากกว่าก็ตาม
หากเราแทนที่ต้นไม้เลขฐานสิบหกโดยตรงด้วยต้นไม้ไบนารีและทำการ Merkleization ของโค้ดเพิ่มเติม สถานการณ์กรณีที่เลวร้ายที่สุดจะกลายเป็นประมาณ 30000000/2400* 32*(32-14+ 8) = 10400000 ไบต์ (14 คือการลบบิตที่ซ้ำซ้อน สำหรับ 2^14 สาขา และ 8 คือความยาวของการพิสูจน์ที่เข้าไปในลีฟในบล็อคโค้ด) โปรดทราบว่าจำเป็นต้องเปลี่ยนค่าน้ำมันเพื่อเรียกเก็บเงินสำหรับการเข้าถึงแต่ละบล็อกของรหัส EIP-4762 ทำเช่นนี้ ความจุ 10.4 MB นั้นดีกว่ามาก แต่ก็ยังมีข้อมูลมากเกินไปสำหรับการดาวน์โหลดในช่วงเวลาเดียวสำหรับหลายโหนด ดังนั้นเราจึงจำเป็นต้องแนะนำเทคโนโลยีที่ทรงพลังกว่านี้ มีสองโซลูชั่นชั้นนำในเรื่องนี้: Verkle tree และ STARKed binary hash tree
ต้นไม้เวอร์เคิล
ต้นไม้ Verkle ใช้พันธะเวกเตอร์ที่ใช้เส้นโค้งรูปไข่เพื่อการพิสูจน์ที่สั้นกว่า กุญแจสำคัญในการปลดล็อคสิ่งนี้ก็คือ ส่วนการพิสูจน์สำหรับความสัมพันธ์ระหว่างแม่และลูกแต่ละรายการมีขนาดเพียง 32 ไบต์ โดยไม่คำนึงถึงความกว้างของแผนผัง ข้อจำกัดเพียงอย่างเดียวเกี่ยวกับความกว้างของแผนผังการพิสูจน์ก็คือ หากแผนผังการพิสูจน์กว้างเกินไป การพิสูจน์จะมีประสิทธิภาพในการคำนวณน้อยลง การใช้งานที่เสนอสำหรับ Ethereum มีความกว้าง 256
ดังนั้น ขนาดของสาขาเดียวในการพิสูจน์จะเป็น 32 - 1 og 256(N) = 4* log 2(N) ไบต์ ดังนั้นขนาดการพิสูจน์สูงสุดตามทฤษฎีคือประมาณ 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 ไบต์ (ผลการคำนวณจริงจะแตกต่างกันเล็กน้อยเนื่องจากการกระจายบล็อกสถานะที่ไม่สม่ำเสมอ แต่เป็นการประมาณครั้งแรกคือ ตกลง).
สิ่งที่ควรทราบอีกประการหนึ่งคือในตัวอย่างข้างต้นทั้งหมด กรณีที่เลวร้ายที่สุด นี้ไม่ใช่สถานการณ์กรณีที่เลวร้ายที่สุด: กรณีที่แย่กว่านั้นคือผู้โจมตีจงใจ ขุด ที่อยู่สองแห่งเพื่อให้มีตำแหน่งร่วมกันที่ยาวขึ้นในคำนำหน้าแผนผังและ อ่านข้อมูลจากที่อยู่ใดที่อยู่หนึ่ง ซึ่งอาจขยายความยาวสาขาที่เลวร้ายที่สุดได้อีก 2 เท่า แม้ว่าจะเป็นกรณีนี้ก็ตาม ความยาวในการพิสูจน์กรณีที่แย่ที่สุดของแผนผัง Verkle คือ 2.6 MB ซึ่งโดยพื้นฐานแล้วจะสอดคล้องกับข้อมูลการตรวจสอบกรณีที่แย่ที่สุดในปัจจุบัน
นอกจากนี้เรายังทำอย่างอื่นด้วยข้อแม้นี้: เราทำให้การเข้าถึงพื้นที่เก็บข้อมูล ที่อยู่ติดกัน ถูกมาก: ไม่ว่าจะเป็นบล็อกโค้ดจำนวนมากในสัญญาเดียวกัน หรือช่องจัดเก็บข้อมูลที่อยู่ติดกัน EIP-4762 ให้คำจำกัดความของ adjacency และเรียกเก็บเงินเพียง 200 แก๊สสำหรับการเข้าถึง adjacency ในกรณีของการเข้าถึงที่อยู่ติดกัน ขนาดการพิสูจน์กรณีที่แย่ที่สุดจะกลายเป็น 30000000 / 200* 32 - 4800800 ไบต์ ซึ่งยังคงอยู่ภายในเกณฑ์ความคลาดเคลื่อนโดยประมาณ หากเราต้องการลดค่านี้ด้วยเหตุผลด้านความปลอดภัย เราสามารถเพิ่มต้นทุนการเข้าถึงที่อยู่ติดกันเล็กน้อยได้
ต้นไม้แฮชไบนารี STARKed
หลักการของเทคนิคนี้อธิบายได้ในตัว: คุณเพียงแค่สร้างไบนารีทรี รับการพิสูจน์ที่มีขนาดสูงสุด 10.4 MB พิสูจน์ค่าในบล็อก จากนั้นแทนที่การพิสูจน์ด้วย STARK ของการพิสูจน์ ด้วยวิธีนี้ การพิสูจน์จะประกอบด้วยเฉพาะข้อมูลที่ได้รับการพิสูจน์ บวกกับค่าใช้จ่ายคงที่ 100-300 kB จาก STARK จริง
ความท้าทายหลักที่นี่คือเวลาในการตรวจสอบ โดยพื้นฐานแล้วเราสามารถคำนวณแบบเดียวกับข้างต้นได้ ยกเว้นแต่แทนที่จะนับไบต์ เราจะนับแฮชแทน บล็อก 10.4 MB หมายถึง 330,000 แฮช หากคุณเพิ่มความเป็นไปได้ที่ผู้โจมตีจะ ขุด โครงสร้างที่อยู่ด้วยคำนำหน้าสาธารณะที่ยาวขึ้น ค่าแฮชที่แย่ที่สุดจะอยู่ที่ประมาณ 660,000 แฮช ดังนั้นหากเราสามารถพิสูจน์ได้ 200,000 แฮชต่อวินาทีก็ไม่เป็นไร
ตัวเลขเหล่านี้ทำได้บนแล็ปท็อปสำหรับผู้บริโภคโดยใช้ ฟังก์ชันแฮชของโพไซดอน ซึ่งได้รับการออกแบบมาโดยเฉพาะเพื่อความเป็นมิตรต่อ STARK อย่างไรก็ตาม ระบบโพไซดอนยังค่อนข้างไม่สมบูรณ์ ผู้คนจำนวนมากจึงยังไม่ไว้วางใจความปลอดภัยของระบบ จึงมีหนทางที่เป็นจริงอยู่สองทางข้างหน้า:
ทำการวิเคราะห์ความปลอดภัยที่ครอบคลุมบน Poseidon อย่างรวดเร็ว และทำความคุ้นเคยเพียงพอที่จะปรับใช้ที่ L1
ใช้ฟังก์ชันแฮชที่ อนุรักษ์นิยม มากกว่า เช่น SHA 256 หรือ BLAKE
หากคุณต้องการพิสูจน์ฟังก์ชันแฮชแบบอนุรักษ์นิยม วงกลม STARK ของ Starkware สามารถพิสูจน์แฮชได้เพียง 10-30,000 ต่อวินาทีบนแล็ปท็อปสำหรับผู้บริโภคในขณะที่เขียน อย่างไรก็ตาม เทคโนโลยี STARK กำลังพัฒนาอย่างรวดเร็ว แม้กระทั่งทุกวันนี้ เทคโนโลยีที่ใช้ GKR ก็แสดงให้เห็นว่าเพิ่มความเร็วนี้ให้อยู่ในช่วง 100-2 O 0 k
กรณีการใช้งานพยานนอกเหนือจากการตรวจสอบบล็อก
นอกเหนือจากการตรวจสอบบล็อกแล้ว ยังมีกรณีการใช้งานหลักอีกสามกรณีที่ต้องการการตรวจสอบความถูกต้องไร้สถานะที่มีประสิทธิภาพมากขึ้น:
Mempool: เมื่อมีการออกอากาศธุรกรรม โหนดในเครือข่าย P2P จำเป็นต้องตรวจสอบว่าธุรกรรมนั้นถูกต้องก่อนที่จะออกอากาศซ้ำ การยืนยันในวันนี้รวมถึงการตรวจสอบลายเซ็นแต่ยังตรวจสอบว่ายอดคงเหลือเพียงพอและคำนำหน้าถูกต้อง ในอนาคต (เช่น การใช้นามธรรมบัญชีดั้งเดิม เช่น EIP-7701) สิ่งนี้อาจเกี่ยวข้องกับการเรียกใช้โค้ด EVM บางตัวที่เข้าถึงสถานะบางอย่าง หากโหนดไม่มีสถานะ ธุรกรรมจะต้องมีการพิสูจน์ออบเจ็กต์สถานะด้วย
รายการรวม: นี่คือคุณลักษณะที่นำเสนอที่ช่วยให้ผู้ตรวจสอบความถูกต้องของหลักฐานการเดิมพัน (อาจเล็กกว่าและซับซ้อนน้อยกว่า) บังคับให้บล็อกถัดไปรวมธุรกรรม โดยไม่คำนึงถึงความปรารถนาของผู้สร้างบล็อก (อาจใหญ่กว่าและซับซ้อนกว่า) สิ่งนี้จะทำให้ความสามารถของผู้มีอำนาจในการจัดการบล็อคเชนลดลงโดยการชะลอการทำธุรกรรม อย่างไรก็ตาม สิ่งนี้กำหนดให้ผู้ตรวจสอบต้องมีวิธีการตรวจสอบความถูกต้องของธุรกรรมที่รวมอยู่ในรายการ
ไคลเอนต์แบบ Light: หากเราต้องการให้ผู้ใช้เข้าถึงเชน (เช่น Metamask, Rainbow, Rabby ฯลฯ) ผ่านกระเป๋าเงิน ในการดำเนินการนี้ พวกเขาจำเป็นต้องเรียกใช้ไคลเอนต์แบบเบา (เช่น Helios) โมดูลหลักของ Helios จะมอบการตรวจสอบให้ผู้ใช้ รากของรัฐ หากต้องการได้รับประสบการณ์ที่ไร้ความน่าเชื่อถือโดยสิ้นเชิง ผู้ใช้จะต้องแสดงหลักฐานสำหรับการเรียก RPC ทุกครั้งที่ทำ (เช่น สำหรับคำขอการโทรผ่านอีเทอร์เน็ต (ผู้ใช้ต้องพิสูจน์สถานะทั้งหมดที่เข้าถึงได้ในระหว่างการโทร)
กรณีการใช้งานเหล่านี้มีเหมือนกันคือต้องมีการพิสูจน์ค่อนข้างน้อย แต่แต่ละหลักฐานมีขนาดเล็ก ดังนั้น การพิสูจน์ STARK จึงไม่มีความสำคัญในทางปฏิบัติสำหรับพวกเขา แนวทางที่สมจริงที่สุดคือการใช้สาขา Merkle โดยตรง ข้อดีอีกประการหนึ่งของสาขา Merkle คือสามารถอัปเดตได้: เมื่อพิจารณาถึงการพิสูจน์สถานะออบเจ็กต์ 2 คือรูท การพิสูจน์ Verkle สามารถอัปเดตได้แบบเนทีฟเช่นกัน
ความเชื่อมโยงกับการวิจัยที่มีอยู่คืออะไร:
มีอะไรอีกที่สามารถทำได้?
งานหลักที่เหลืออยู่คือ
1. การวิเคราะห์เพิ่มเติมเกี่ยวกับผลที่ตามมาของ EIP-4762 (การเปลี่ยนแปลงต้นทุนก๊าซไร้สัญชาติ)
2. งานเพิ่มเติมในการทำให้เสร็จสิ้นและทดสอบขั้นตอนการเปลี่ยนผ่าน ซึ่งเป็นส่วนสำคัญของความซับซ้อนของแผนปฏิบัติการสำหรับสภาพแวดล้อมไร้สัญชาติ
3. การวิเคราะห์ความปลอดภัยเพิ่มเติมของ Poseidon, Ajtai และฟังก์ชันแฮชที่ เป็นมิตรกับ STARK อื่นๆ
4. การพัฒนาเพิ่มเติมของคุณสมบัติโปรโตคอล STARK ที่มีประสิทธิภาพสูงสำหรับการแฮชแบบ อนุรักษ์นิยม (หรือ ดั้งเดิม) เช่น ตามมุมมองของ Binius หรือ GKR
นอกจากนี้ เร็วๆ นี้เราจะตัดสินใจเลือกหนึ่งในสามตัวเลือกต่อไปนี้: (i) Verkle tree, (ii) ฟังก์ชันแฮชที่เป็นมิตรของ STARK และ (iii) ฟังก์ชันแฮชแบบอนุรักษ์นิยม ลักษณะสามารถสรุปได้คร่าว ๆ ในตารางต่อไปนี้:
นอกจาก หมายเลขพาดหัว เหล่านี้แล้ว ยังมีข้อควรพิจารณาที่สำคัญอื่นๆ อีกด้วย:
ปัจจุบันโค้ดต้นไม้ Verkle ค่อนข้างสมบูรณ์ การใช้โค้ดอื่นนอกเหนือจาก Verkle จะทำให้การปรับใช้ล่าช้าและน่าจะเป็นฮาร์ดฟอร์ค ก็ไม่เป็นไรเช่นกัน โดยเฉพาะอย่างยิ่งหากเราต้องการเวลาเพิ่มเติมสำหรับการวิเคราะห์ฟังก์ชันแฮชหรือการใช้งานเครื่องมือตรวจสอบความถูกต้อง หรือหากเรามีคุณสมบัติที่สำคัญอื่นๆ ที่เราต้องการรวมเข้ากับ Ethereum ก่อนหน้านี้
การใช้แฮชเพื่ออัปเดตรูทสถานะนั้นเร็วกว่าการใช้ต้นไม้ Verkle ซึ่งหมายความว่าวิธีการแบบแฮชสามารถลดเวลาการซิงโครไนซ์ของโหนดเต็มได้
ต้นไม้ Verkle มีคุณสมบัติการอัปเดตพยานที่น่าสนใจ - พยานต้นไม้ Verkle สามารถอัปเดตได้ คุณสมบัตินี้มีประโยชน์สำหรับ mempools รวมรายการ และกรณีการใช้งานอื่น ๆ และอาจช่วยทำให้การใช้งานมีประสิทธิภาพมากขึ้น: หากออบเจ็กต์สถานะได้รับการอัปเดต พยานของเลเยอร์สุดท้ายสามารถอัปเดตได้โดยไม่ต้องอ่านเนื้อหาของเลเยอร์สุดท้าย
ต้นไม้ Verkle นั้นยากกว่าในการพิสูจน์ SNARK การพิสูจน์ Verkle ก่อให้เกิดปัญหาบางอย่างหากเราต้องการลดขนาดการพิสูจน์ให้เหลือสองสามกิโลไบต์ เนื่องจากการตรวจสอบการพิสูจน์ Verkle ต้องใช้การดำเนินการ 256 บิตจำนวนมาก ซึ่งกำหนดให้ระบบการพิสูจน์มีค่าใช้จ่ายสูงหรือตัวมันเองต้องมีโครงสร้างภายในแบบกำหนดเองที่มีส่วนการพิสูจน์ Verkle 256 บิต นี่ไม่ใช่ปัญหาของการไร้สัญชาติแต่จะสร้างความยากลำบากมากขึ้น
หากเราต้องการได้รับความสามารถในการอัปเดตพยานของ Verkle ในลักษณะที่ปลอดภัยด้วยควอนตัมและมีประสิทธิภาพพอสมควร อีกแนวทางหนึ่งที่เป็นไปได้คือต้นไม้ Merkle ที่ใช้โครงขัดแตะ
หากในกรณีที่เลวร้ายที่สุด ปรากฎว่าระบบไม่มีประสิทธิภาพเพียงพอ เราก็สามารถใช้เครื่องมือที่ไม่คาดคิดของก๊าซหลายมิติเพื่อชดเชยข้อบกพร่องนี้: สำหรับ (i) calldata; (ii) การคำนวณ; ) การเข้าถึงของรัฐและทรัพยากรอื่นๆ ที่เป็นไปได้อาจกำหนดขีดจำกัดก๊าซแยกกัน ก๊าซหลายมิติเพิ่มความซับซ้อน แต่ในทางกลับกัน ก๊าซจะจำกัดอัตราส่วนระหว่างกรณีเฉลี่ยและกรณีที่เลวร้ายที่สุดให้เข้มงวดยิ่งขึ้น ด้วยก๊าซหลายมิติ จำนวนสาขาสูงสุดที่ต้องพิสูจน์สามารถลดลงตามทฤษฎีจาก 12,500 เหลือ เช่น 3,000 สิ่งนี้จะทำให้ BLAKE 3 (แทบจะไม่) เพียงพอแม้กระทั่งทุกวันนี้
ก๊าซหลายมิติช่วยให้ขีดจำกัดทรัพยากรของบล็อกใกล้เคียงกับฮาร์ดแวร์พื้นฐานมากขึ้น
เครื่องมือที่ไม่คาดคิดอีกอย่างหนึ่งคือการชะลอการคำนวณรูทสถานะไปจนถึงช่วงเวลาหลังบล็อก นี่ทำให้เรามีเวลา 12 วินาทีเต็มในการคำนวณรากของสถานะ ซึ่งหมายความว่าแม้ในกรณีที่รุนแรงที่สุด เพียง 60,000 แฮชต่อวินาทีก็เพียงพอแล้วในการพิสูจน์ ซึ่งทำให้เราคิดอีกครั้งว่า BLAKE 3 สามารถตอบสนองความต้องการได้เพียงเล็กน้อยเท่านั้น
ข้อเสียของแนวทางนี้คือจะเพิ่มเวลาแฝงไคลเอ็นต์แบบเบาหนึ่งช่อง แต่มีเทคนิคที่ชาญฉลาดกว่าซึ่งสามารถลดเวลาแฝงนี้เพื่อพิสูจน์เวลาแฝงในการสร้างได้ ตัวอย่างเช่น การพิสูจน์สามารถออกอากาศบนเครือข่ายได้ทันทีที่โหนดใดๆ สร้างขึ้น แทนที่จะรอบล็อกถัดไป
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
การแก้ปัญหาคนไร้รัฐไร้สัญชาติจะเพิ่มความยากในการกำหนดจุดตายตัวแบบคนเดียวอย่างมาก สิ่งนี้จะเป็นไปได้มากขึ้นหากมีเทคโนโลยีที่ลดความสมดุลขั้นต่ำสำหรับการกำหนดเป้าหมายผู้เล่นเดี่ยว เช่น Orbit SSF หรือกลยุทธ์เลเยอร์แอปพลิเคชัน เช่น การกำหนดเป้าหมายแบบทีม
การวิเคราะห์ก๊าซหลายมิติจะง่ายขึ้นหากใช้ EOF ด้วย เนื่องจากความซับซ้อนในการดำเนินการหลักของแก๊สหลายมิติมาจากการจัดการกับการโทรย่อยที่ไม่ผ่านแก๊สทั้งหมดของการเรียกหลัก และ EOF สามารถทำให้ปัญหานี้เป็นเรื่องเล็กน้อย (และเกิดขึ้นเอง) โดยเพียงแค่ทำให้การโทรย่อยดังกล่าวผิดกฎหมาย ทางเลือกในโปรโตคอลสำหรับบางกรณีการใช้งานหลักในปัจจุบันของก๊าซ
นอกจากนี้ยังมีการทำงานร่วมกันที่สำคัญระหว่างการตรวจสอบความถูกต้องไร้สัญชาติและการหมดอายุของประวัติ ปัจจุบัน ลูกค้าต้องจัดเก็บข้อมูลประวัติเกือบหนึ่งเทราไบต์ ข้อมูลนี้มากกว่าข้อมูลสถานะหลายเท่า แม้ว่าไคลเอนต์จะไม่มีสถานะไร้สัญชาติ ความฝันของลูกค้าที่เกือบจะไร้พื้นที่จัดเก็บข้อมูลก็จะไม่เป็นจริง เว้นแต่เราจะสามารถแบ่งเบาความรับผิดชอบของลูกค้าในการจัดเก็บข้อมูลประวัติได้ ขั้นตอนแรกในเรื่องนี้คือ EIP-4444 ซึ่งหมายถึงการจัดเก็บข้อมูลประวัติในทอร์เรนต์หรือพอร์ทัลในเครือข่ายพอร์ทัลด้วย
หลักฐานยืนยันประสิทธิผลของการดำเนินการ EVM
เรากำลังพยายามแก้ไขปัญหาอะไร
เป้าหมายระยะยาวของการตรวจสอบบล็อก Ethereum นั้นชัดเจน - ควรตรวจสอบบล็อก Ethereum ได้โดย: (i) ดาวน์โหลดบล็อก หรือแม้แต่ดาวน์โหลดเพียงตัวอย่างเล็กๆ น้อยๆ ของข้อมูลที่มีอยู่ในบล็อก (ii) ตรวจสอบพื้นที่ หลักฐานเล็กๆ น้อยๆ ที่ขัดขวางการทำงาน นี่จะเป็นการดำเนินการที่ใช้ทรัพยากรต่ำมากและสามารถทำได้ในไคลเอนต์มือถือ กระเป๋าสตางค์ของเบราว์เซอร์ หรือแม้แต่ในเครือข่ายอื่น (โดยไม่มีส่วนที่พร้อมใช้งานของข้อมูล)
เพื่อให้บรรลุเป้าหมายนี้ จำเป็นต้องมีการพิสูจน์ SNARK หรือ STARK สำหรับ (i) ชั้นฉันทามติ (เช่น Proof of Stake) และ (ii) ชั้นการดำเนินการ (เช่น EVM) แบบแรกถือเป็นความท้าทายในตัวเอง และควรได้รับการแก้ไขในการปรับปรุงชั้นฉันทามติอย่างต่อเนื่อง (เช่น สำหรับจุดสิ้นสุดของช่องเดียว) อย่างหลังต้องมีหลักฐานการดำเนินการ EVM
มันคืออะไรและมันทำงานอย่างไร?
อย่างเป็นทางการในข้อกำหนด Ethereum นั้น EVM ถูกกำหนดให้เป็นฟังก์ชันการเปลี่ยนสถานะ: คุณมี pre-state S, บล็อก B และคุณกำลังคำนวณ post-state S = STF(S, B) หากผู้ใช้ใช้ไคลเอ็นต์แบบเบา ผู้ใช้จะไม่ได้เป็นเจ้าของ S และ S อย่างสมบูรณ์ หรือแม้แต่ E แทน ผู้ใช้จะมีรูท R ก่อนสถานะ R หลังสถานะ และแฮชบล็อก H
อินพุตสาธารณะ: รูทก่อนสถานะ R, รูทหลังสถานะ R, บล็อกแฮช H
อินพุตส่วนตัว: เนื้อหาบล็อก B, วัตถุในสถานะที่เข้าถึงได้โดยบล็อก Q, วัตถุเดียวกันหลังจากดำเนินการบล็อก Q, การพิสูจน์สถานะ (เช่น สาขา Merkle) P
ข้อเรียกร้องที่ 1: P เป็นข้อพิสูจน์ที่ถูกต้องว่า Q มีสถานะบางส่วนที่แสดงโดย R
ข้อเรียกร้องที่ 2: หากคุณเรียกใช้ STF บน Q (i) การดำเนินการเข้าถึงเฉพาะอ็อบเจ็กต์ภายใน Q (ii) บล็อกข้อมูลนั้นถูกต้อง (iii) ผลลัพธ์คือ Q
ข้อเรียกร้องที่ 3: หากคุณใช้ข้อมูลของ Q และ P เพื่อคำนวณรูทสถานะใหม่ คุณจะได้ R
หากเป็นกรณีนี้ ก็เป็นไปได้ที่จะมีไคลเอ็นต์แบบ light ที่รับรองความถูกต้องของการดำเนินการ Ethereum EVM โดยสมบูรณ์ ส่งผลให้ทรัพยากรของลูกค้าเหลือน้อยอยู่แล้ว เพื่อให้บรรลุถึงไคลเอนต์ Ethereum ที่ได้รับการตรวจสอบอย่างครบถ้วนอย่างแท้จริง งานเดียวกันนี้จำเป็นต้องทำโดยได้รับความเห็นพ้องต้องกัน
การใช้งานการพิสูจน์ความถูกต้องสำหรับการคำนวณ EVM มีอยู่แล้วและ L2 ใช้งานอย่างหนัก ยังมีงานอีกมากที่ต้องทำเพื่อให้การพิสูจน์ความถูกต้องของ EVM เป็นไปได้ใน L1
อะไรคือความเชื่อมโยงกับการวิจัยที่มีอยู่?
มีอะไรอีกที่สามารถทำได้?
ทุกวันนี้ ความมีประสิทธิผลของระบบบัญชีอิเล็กทรอนิกส์ได้รับการพิสูจน์แล้วว่าบกพร่องในสองด้าน: ความปลอดภัยและเวลาในการตรวจสอบ
การพิสูจน์ความถูกต้องที่ปลอดภัยจำเป็นต้องตรวจสอบให้แน่ใจว่า SNARK ตรวจสอบการคำนวณของ EVM จริง ๆ และไม่มีช่องโหว่ เทคนิคหลักสองประการในการปรับปรุงความปลอดภัยคือเครื่องมือตรวจสอบหลายรายการและการตรวจสอบอย่างเป็นทางการ เครื่องมือตรวจสอบความถูกต้องหลายรายการหมายถึงการมีการใช้งานพิสูจน์ความถูกต้องที่เป็นลายลักษณ์อักษรอย่างอิสระหลายรายการ เช่นเดียวกับที่มีไคลเอนต์หลายตัว และหากบล็อกได้รับการรับรองโดยชุดย่อยของการใช้งานเหล่านี้ที่มีขนาดใหญ่เพียงพอ ไคลเอนต์จะยอมรับชิ้นส่วนของบล็อก การตรวจสอบอย่างเป็นทางการเกี่ยวข้องกับการใช้เครื่องมือที่โดยทั่วไปใช้เพื่อพิสูจน์ทฤษฎีบททางคณิตศาสตร์ เช่น Lean 4 เพื่อพิสูจน์ว่าการพิสูจน์ความถูกต้องยอมรับเฉพาะการดำเนินการที่ถูกต้องของข้อกำหนด EVM พื้นฐานเท่านั้น (เช่น EVM K semantics หรือ Ethereum Execution Layer Specification (EELS) ที่เขียนด้วย Python) .
เวลาในการตรวจสอบที่รวดเร็วเพียงพอหมายความว่าสามารถตรวจสอบบล็อก Ethereum ใด ๆ ได้ภายในเวลาไม่ถึง 4 วินาที ปัจจุบันเรายังห่างไกลจากเป้าหมายนั้น แม้ว่าเราจะอยู่ใกล้มากกว่าที่เราคิดไว้เมื่อสองปีที่แล้วก็ตาม เพื่อให้บรรลุเป้าหมายนี้ เราจำเป็นต้องก้าวหน้าในสามทิศทาง:
การทำงานแบบขนาน – เครื่องมือตรวจสอบ EVM ที่เร็วที่สุดในปัจจุบันสามารถพิสูจน์บล็อก Ethereum ได้โดยเฉลี่ย 15 วินาที ทำได้โดยการวาง GPU หลายร้อยตัวแบบขนานและรวบรวมงานเข้าด้วยกันในตอนท้าย ตามทฤษฎีแล้ว เรารู้วิธีสร้างเครื่องตรวจสอบ EVM ที่สามารถพิสูจน์การคำนวณในเวลา O(log(N)) ได้ โดยปล่อยให้ GPU ทำแต่ละขั้นตอนให้เสร็จสิ้น และสุดท้ายก็สร้าง แผนผังการรวมกลุ่ม:
มีความท้าทายในการบรรลุเป้าหมายนี้ แม้ในสถานการณ์กรณีที่เลวร้ายที่สุด ซึ่งธุรกรรมขนาดใหญ่มากครอบครองทั้งบล็อก การแบ่งพาร์ติชันการคำนวณไม่สามารถทำได้ในแต่ละรอบ แต่จะต้องเป็นไปตาม opcode (opcode ของเครื่องเสมือนพื้นฐาน เช่น EVM หรือ RISC-V) การตรวจสอบให้แน่ใจว่า หน่วยความจำ ของเครื่องเสมือนยังคงสอดคล้องกันระหว่างส่วนต่างๆ ของการรับรองถือเป็นความท้าทายที่สำคัญระหว่างการใช้งาน อย่างไรก็ตาม หากเราสามารถใช้การพิสูจน์แบบเรียกซ้ำประเภทนี้ได้ เราก็จะรู้ว่าอย่างน้อยปัญหาความหน่วงของตัวพิสูจน์ก็ได้รับการแก้ไขแล้ว แม้ว่าจะไม่มีการปรับปรุงในด้านอื่น ๆ ก็ตาม
การปรับปรุงระบบพิสูจน์ให้เหมาะสม - ระบบพิสูจน์ใหม่ เช่น Orion, Binius, GRK และอื่นๆ อีกมากมายมีแนวโน้มที่จะช่วยลดเวลาในการตรวจสอบยืนยันสำหรับการคำนวณวัตถุประสงค์ทั่วไปลงอย่างมาก
การเปลี่ยนแปลงอื่นๆ ในต้นทุนก๊าซ EVM - หลายๆ สิ่งใน EVM สามารถเพิ่มประสิทธิภาพได้เพื่อให้เป็นประโยชน์ต่อผู้พิสูจน์มากขึ้น โดยเฉพาะอย่างยิ่งในสถานการณ์กรณีที่เลวร้ายที่สุด การพิสูจน์บล็อก Ethereum ปกติใน 4 วินาทีนั้นไม่เพียงพอหากผู้โจมตีสามารถสร้างบล็อกที่บล็อกผู้พิสูจน์เป็นเวลาสิบนาที การเปลี่ยนแปลง EVM ที่จำเป็นสามารถแบ่งออกกว้าง ๆ เป็นประเภทต่อไปนี้:
- การเปลี่ยนแปลงของต้นทุนก๊าซ - หากการดำเนินการใช้เวลานานในการพิสูจน์ ก็ควรมีต้นทุนก๊าซสูง แม้ว่าการคำนวณจะค่อนข้างเร็วก็ตาม EIP-7667 เป็น EIP ที่เสนอเพื่อจัดการกับปัญหาที่ร้ายแรงที่สุดในเรื่องนี้: มันเพิ่มต้นทุนการใช้ฟังก์ชันแฮช (แบบดั้งเดิม) อย่างมีนัยสำคัญ เนื่องจาก opcodes และการคอมไพล์ล่วงหน้าของฟังก์ชันเหล่านี้มีราคาค่อนข้างถูก เพื่อชดเชยต้นทุนก๊าซที่เพิ่มขึ้น เราสามารถลดต้นทุนก๊าซของ opcode EVM ที่ค่อนข้างพิสูจน์ได้ต่ำได้ ดังนั้นจึงรักษาปริมาณงานเฉลี่ยให้คงที่
- การเปลี่ยนโครงสร้างข้อมูล - นอกเหนือจากการแทนที่แผนผังสถานะด้วยวิธีที่เป็นมิตรต่อ STARK มากขึ้นแล้ว เรายังจำเป็นต้องแทนที่รายการธุรกรรม แผนผังการรับ และโครงสร้างอื่นๆ ที่พิสูจน์แล้วว่ามีราคาแพง การย้ายโครงสร้างธุรกรรมและการรับ EIP ของ Etan Kissling ไปยัง SSZ ถือเป็นก้าวหนึ่งในทิศทางนี้
นอกจากนี้ เครื่องมือทั้งสองที่กล่าวถึงในส่วนที่แล้ว (ก๊าซหลายมิติและรากสถานะล่าช้า) ก็สามารถช่วยในเรื่องนี้ได้เช่นกัน อย่างไรก็ตาม เป็นที่น่าสังเกตว่าการใช้เครื่องมือทั้งสองนี้ต่างจากการตรวจสอบแบบไร้สถานะตรงที่หมายความว่าเรามีเทคโนโลยีเพียงพอที่จะทำสิ่งที่เราต้องการในปัจจุบัน และแม้จะมีเทคโนโลยีเหล่านี้ การตรวจสอบ ZK-EVM เต็มรูปแบบยังต้องการการทำงานมากขึ้นเช่นกัน เพียงแต่ใช้น้อยลงเท่านั้น งาน.
สิ่งหนึ่งที่ไม่ได้กล่าวถึงข้างต้นคือฮาร์ดแวร์ของตัวพิสูจน์: การใช้ GPU, FPGA และ ASIC เพื่อสร้างการพิสูจน์ได้เร็วขึ้น Fabric Cryptography, Cysic และ Accseal คือบริษัทสามแห่งที่มีความก้าวหน้าในด้านนี้ สิ่งนี้มีค่ามากสำหรับ L2 แต่ไม่น่าจะถือเป็นการพิจารณาที่เด็ดขาดสำหรับ L1 เนื่องจากมีความปรารถนาอย่างแรงกล้าสำหรับ L1 ที่จะยังคงมีการกระจายอำนาจในระดับสูง ซึ่งหมายความว่าการสร้างหลักฐานจะต้องอยู่ในขอบเขตที่เหมาะสมของผู้ใช้ Ethereum และไม่ควรอยู่ภายใต้ ข้อจำกัดคอขวดของฮาร์ดแวร์ของบริษัทเดียว L2 สามารถสร้างการแลกเปลี่ยนเชิงบวกได้มากขึ้น
ในด้านเหล่านี้ยังมีงานที่ต้องทำเพิ่มเติม:
การพิสูจน์ความขนานต้องพิสูจน์ว่าส่วนต่างๆ ของระบบสามารถ แบ่งปันหน่วยความจำ ได้ (เช่น ตารางการค้นหา) เรารู้ว่าเทคโนโลยีจะทำสิ่งนี้ได้ แต่จำเป็นต้องนำไปใช้
เราต้องทำการวิเคราะห์เพิ่มเติมเพื่อค้นหาชุดของความแปรผันของต้นทุนก๊าซที่เหมาะสมที่สุด ซึ่งช่วยลดเวลาการตรวจสอบในกรณีที่เลวร้ายที่สุด
เราจำเป็นต้องทำงานเพิ่มเติมเกี่ยวกับระบบการพิสูจน์
ค่าใช้จ่ายที่เป็นไปได้คือ:
การรักษาความปลอดภัยเทียบกับเวลาตรวจสอบ: คุณสามารถลดเวลาตรวจสอบได้หากคุณเลือกฟังก์ชันแฮชเชิงรุกมากขึ้น ระบบพิสูจน์ที่ซับซ้อนมากขึ้น หรือสมมติฐานด้านความปลอดภัยเชิงรุกมากขึ้นหรือโซลูชันการออกแบบอื่น ๆ
การกระจายอำนาจและระยะเวลาในการพิสูจน์: ชุมชนจำเป็นต้องตกลงเกี่ยวกับ ข้อกำหนด ของฮาร์ดแวร์ผู้รับรองที่เป็นเป้าหมาย เป็นไปได้ไหมที่จะกำหนดให้ผู้รับรองเป็นนิติบุคคลขนาดใหญ่ เราคาดหวังให้แล็ปท็อปผู้บริโภคระดับไฮเอนด์พิสูจน์บล็อก Ethereum ภายใน 4 วินาทีหรือไม่? ที่ไหนสักแห่งในระหว่าง?
ขอบเขตที่ความเข้ากันได้แบบย้อนหลังถูกทำลาย: ข้อบกพร่องอื่นๆ สามารถชดเชยได้ด้วยการเปลี่ยนแปลงต้นทุนก๊าซที่รุนแรงมากขึ้น แต่มีแนวโน้มที่จะเพิ่มต้นทุนอย่างไม่สมส่วนสำหรับแอปพลิเคชันบางตัว บังคับให้นักพัฒนาต้องเขียนใหม่และปรับใช้โค้ดใหม่เพื่อให้ยังคงใช้งานได้ในเชิงเศรษฐกิจ ในทำนองเดียวกัน เครื่องมือทั้งสองก็มีความซับซ้อนและข้อเสียของตัวเอง
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
เทคโนโลยีหลักที่จำเป็นในการใช้การพิสูจน์ความถูกต้องของ L1 EVM นั้นมีการแบ่งปันส่วนใหญ่กับอีกสองด้าน:
หลักฐานความถูกต้องของ L2 (เช่น การยกเลิก ZK)
วิธีการ STARK Binary Hash Proof แบบไม่ระบุสถานะ
การใช้การพิสูจน์ความถูกต้องที่ประสบความสำเร็จใน L1 จะช่วยให้การเดิมพันแบบคนเดียวเป็นเรื่องง่ายในที่สุด แม้แต่คอมพิวเตอร์ที่อ่อนแอที่สุด (รวมถึงโทรศัพท์มือถือหรือนาฬิกาอัจฉริยะ) ก็สามารถเดิมพันได้ สิ่งนี้จะเพิ่มคุณค่าของการจัดการกับข้อจำกัดอื่นๆ ของการเดิมพันเดี่ยว เช่น ขั้นต่ำ 32 ETH
นอกจากนี้ ความถูกต้องของ EVM ของ L1 พิสูจน์ให้เห็นว่าขีดจำกัดก๊าซของ L1 สามารถปรับปรุงได้อย่างมาก
หลักฐานความถูกต้องของความเห็นพ้องต้องกัน
เรากำลังพยายามแก้ไขปัญหาอะไร
หากเราต้องการตรวจสอบบล็อก Ethereum อย่างสมบูรณ์ด้วย SNARK การดำเนินการ EVM ไม่ใช่เพียงส่วนเดียวที่เราต้องพิสูจน์ นอกจากนี้เรายังต้องการหลักฐานฉันทามติ ซึ่งเป็นส่วนหนึ่งของระบบที่จัดการการฝาก การถอน ลายเซ็น การอัปเดตยอดคงเหลือของเครื่องมือตรวจสอบความถูกต้อง และองค์ประกอบอื่น ๆ ของส่วนพิสูจน์การเดิมพันของ Ethereum
ฉันทามตินั้นง่ายกว่า EVM มาก แต่ความท้าทายก็คือเราไม่มี L2 EVM Convolution ดังนั้นงานส่วนใหญ่ก็ยังต้องทำต่อไป ดังนั้น การดำเนินการตามฉันทามติพิสูจน์ Ethereum ใดๆ จะต้อง เริ่มต้นจากศูนย์ แม้ว่าระบบพิสูจน์เองจะเป็นความพยายามร่วมกันที่สามารถสร้างขึ้นได้
มันคืออะไรและมันทำงานอย่างไร?
สายสัญญาณบีคอนถูกกำหนดให้เป็นฟังก์ชันการเปลี่ยนสถานะ เช่นเดียวกับ EVM ฟังก์ชันการเปลี่ยนสถานะส่วนใหญ่ประกอบด้วยสามส่วน:
ECADD (สำหรับการตรวจสอบลายเซ็น BLS)
การจับคู่ (สำหรับการตรวจสอบลายเซ็น BLS)
แฮช SHA 256 (ใช้สำหรับอ่านและอัปเดตสถานะ)
ในแต่ละบล็อก เราจำเป็นต้องพิสูจน์ 1-16 BLS 12-381 ECADD สำหรับเครื่องมือตรวจสอบความถูกต้องแต่ละตัว (อาจมีมากกว่าหนึ่ง เนื่องจากลายเซ็นอาจรวมอยู่ในหลายชุด) ซึ่งสามารถชดเชยได้ด้วยเทคนิคการคำนวณล่วงหน้าเซตย่อย ดังนั้นเราจึงสามารถพูดได้ว่าผู้ตรวจสอบแต่ละรายจำเป็นต้องพิสูจน์ BLS 12-381 ECADD เพียงอันเดียวเท่านั้น ปัจจุบันมีลายเซ็นของผู้ตรวจสอบความถูกต้อง 30,000 รายต่อช่อง ในอนาคต เมื่อบรรลุจุดสิ้นสุดของสล็อตเดี่ยว สถานการณ์นี้อาจเปลี่ยนแปลงในสองทิศทาง: หากเราใช้เส้นทาง กำลังดุร้าย จำนวนผู้ตรวจสอบต่อสล็อตอาจเพิ่มขึ้นเป็น 1 ล้าน ในเวลาเดียวกัน หากใช้ Orbit SSF จำนวนผู้ตรวจสอบจะยังคงอยู่ที่ 32,768 หรือลดลงเหลือ 8,192 คน
วิธีการทำงานของการรวม BLS: การตรวจสอบลายเซ็นทั้งหมดต้องใช้ ECADD หนึ่งรายการต่อผู้เข้าร่วมเท่านั้น ไม่ใช่ ECMUL แต่ ECADD จำนวน 30,000 รายการยังคงเป็นข้อพิสูจน์อีกมาก
ในแง่ของการจับคู่ ขณะนี้มีการพิสูจน์ได้สูงสุด 128 รายการต่อช่อง ซึ่งหมายความว่าต้องมีการตรวจสอบการจับคู่ 128 รายการ ด้วย ElP-7549 และการปรับเปลี่ยนเพิ่มเติม สามารถลดลงเหลือ 16 รายการต่อช่อง จำนวนคู่มีน้อย แต่ค่าใช้จ่ายสูงมาก: การจับคู่แต่ละครั้งใช้เวลารัน (หรือพิสูจน์) นานกว่า ECADD หลายพันเท่า
ความท้าทายที่สำคัญในการพิสูจน์การทำงานของ BLS 12-381 คือไม่มีเส้นโค้งที่สะดวกและมีลำดับเส้นโค้งเท่ากับขนาดสนาม BLS 12-381 ซึ่งจะเพิ่มค่าใช้จ่ายจำนวนมากให้กับระบบพิสูจน์ใดๆ ในทางกลับกัน แผนผัง Verkle ที่เสนอสำหรับ Ethereum นั้นถูกสร้างขึ้นด้วยเส้นโค้ง Bandersnatch ซึ่งทำให้ BLS 12-381 นั้นเป็นเส้นโค้งในตัวเองที่ใช้ในการพิสูจน์กิ่งก้านของ Verkle ในระบบ SNARK การใช้งานที่ค่อนข้างง่ายสามารถพิสูจน์การเพิ่ม 100 G 1 ต่อวินาที การพิสูจน์ได้เร็วเพียงพอแทบจะต้องใช้เทคนิคที่ชาญฉลาดเช่น GKR
สถานการณ์กรณีที่เลวร้ายที่สุดในขณะนี้สำหรับแฮช SHA 256 คือบล็อกการเปลี่ยนแปลงยุคซึ่งมีการอัปเดตแผนผังยอดคงเหลือแบบสั้นของตัวตรวจสอบทั้งหมดและยอดคงเหลือของตัวตรวจสอบความถูกต้องจำนวนมาก แผนผังสมดุลแบบสั้นสำหรับเครื่องมือตรวจสอบความถูกต้องแต่ละตัวมีเพียง 1 ไบต์เท่านั้น ดังนั้นข้อมูล 1 MB จึงถูกแฮชใหม่ ซึ่งเทียบเท่ากับการโทร 32768 SHA 256 หากยอดคงเหลือของผู้ตรวจสอบความถูกต้องหนึ่งพันรายอยู่เหนือหรือต่ำกว่าเกณฑ์ ยอดคงเหลือที่ถูกต้องในบันทึกผู้ตรวจสอบความถูกต้องจำเป็นต้องได้รับการอัปเดต ซึ่งเทียบเท่ากับสาขา Merkle นับพันสาขา ดังนั้นจึงอาจต้องใช้แฮชหนึ่งหมื่น กลไกการสับเปลี่ยนต้องใช้ 90 บิตต่อเครื่องมือตรวจสอบความถูกต้อง (และดังนั้นจึงมีข้อมูล 11 MB) แต่สามารถคำนวณได้ตลอดเวลาระหว่างยุคหนึ่ง ในกรณีของการสิ้นสุดสล็อตเดี่ยว จำนวนเหล่านี้อาจเพิ่มขึ้นหรือลดลงเป็นกรณีไป การสับเปลี่ยนไม่จำเป็น แม้ว่า Orbit จะสามารถฟื้นฟูความต้องการนั้นได้ในระดับหนึ่งก็ตาม
ความท้าทายอีกประการหนึ่งคือความจำเป็นในการรับสถานะผู้ตรวจสอบความถูกต้องทั้งหมดอีกครั้ง รวมถึงกุญแจสาธารณะ เพื่อตรวจสอบความถูกต้องของบล็อก สำหรับผู้ตรวจสอบความถูกต้อง 1 ล้านคน การอ่านรหัสสาธารณะเพียงอย่างเดียวจะต้องใช้พื้นที่ 48 ล้านไบต์ บวกกับสาขา Merkle ด้วย สิ่งนี้ต้องใช้แฮชหลายล้านครั้งต่อยุค หากเราต้องพิสูจน์ความถูกต้องของ PoS แนวทางที่สมจริงจะเป็นรูปแบบของการคำนวณที่ตรวจสอบได้เพิ่มขึ้น: จัดเก็บโครงสร้างข้อมูลเดียวภายในระบบพิสูจน์ที่ได้รับการปรับให้เหมาะสมเพื่อค้นหาอย่างมีประสิทธิภาพและพิสูจน์ว่าการอัปเดตโครงสร้าง
โดยรวมแล้วมีความท้าทายมากมาย การจัดการกับความท้าทายเหล่านี้อย่างมีประสิทธิผลสูงสุดน่าจะต้องมีการออกแบบห่วงโซ่บีคอนใหม่อย่างลึกซึ้ง ซึ่งอาจเกิดขึ้นพร้อมกับการเปลี่ยนไปสู่การยกเลิกช่องเดียว คุณสมบัติของการออกแบบใหม่นี้อาจรวมถึง:
การเปลี่ยนแปลงฟังก์ชันแฮช: ตอนนี้ใช้ฟังก์ชันแฮช เต็ม SHA 256 แล้ว ดังนั้นจึงมีการเรียกฟังก์ชันการบีบอัดพื้นฐานสองครั้งสำหรับการเรียกแต่ละครั้งเนื่องจากการแพดดิ้ง หากเราใช้ฟังก์ชันการบีบอัด SHA 256 แทน เราจะได้กำไรเพิ่มขึ้นอย่างน้อย 2 เท่า หากเราใช้โพไซดอนแทน เราอาจได้รับกำไรเพิ่มขึ้น 100 เท่า แก้ปัญหาทั้งหมดของเราได้อย่างสมบูรณ์ (อย่างน้อยก็ในแง่ของแฮช): ที่ 1.7 ล้านแฮชต่อวินาที (54 MB) แม้ว่าจะมีการตรวจสอบนับล้านก็ตาม บันทึกก็สามารถ อ่าน ได้ เป็นการพิสูจน์ภายในไม่กี่วินาที
ในกรณีของ Orbit ให้จัดเก็บบันทึกเครื่องมือตรวจสอบความถูกต้องแบบสับโดยตรง: หากผู้ตรวจสอบความถูกต้องจำนวนหนึ่ง (เช่น 8192 หรือ 32768) ได้รับเลือกให้เป็นคณะกรรมการสำหรับช่องที่กำหนด ให้วางโดยตรงในสถานะที่อยู่ติดกัน เช่นนี้เท่านั้น จำเป็นต้องมีการแฮชน้อยที่สุดเพื่ออ่านคีย์สาธารณะของผู้ตรวจสอบความถูกต้องทั้งหมดในการพิสูจน์ นอกจากนี้ยังช่วยให้การอัปเดตสมดุลทั้งหมดเสร็จสิ้นได้อย่างมีประสิทธิภาพ
การรวมลายเซ็น: รูปแบบการรวมลายเซ็นที่มีประสิทธิภาพสูงจะเกี่ยวข้องกับการพิสูจน์แบบเรียกซ้ำบางประเภท โดยที่โหนดต่างๆ ในเครือข่ายทำการพิสูจน์ระดับกลางในชุดย่อยของลายเซ็น วิธีนี้จะกระจายงานพิสูจน์อักษรไปยังหลายโหนดในเครือข่ายตามธรรมชาติ ซึ่งช่วยลดภาระงานของ ผู้พิสูจน์ขั้นสุดท้าย ได้อย่างมาก
รูปแบบลายเซ็นอื่นๆ: สำหรับลายเซ็น Lamport+Merkle เราต้องมีแฮช 256 + 32 เพื่อยืนยันลายเซ็น คูณผู้ลงนาม 32,768 คน เราจะได้แฮช 9437184 หลังจากปรับรูปแบบลายเซ็นให้เหมาะสมแล้ว ผลลัพธ์นี้สามารถปรับปรุงเพิ่มเติมได้อีกโดยใช้ปัจจัยคงที่เล็กน้อย สิ่งนี้แสดงให้เห็นภายในช่องเดียวหากเราใช้โพไซดอน แต่ในทางปฏิบัติ การใช้รูปแบบการรวมแบบเรียกซ้ำจะเร็วกว่า
อะไรคือความเชื่อมโยงกับการวิจัยที่มีอยู่?
งานอะไรที่ต้องทำให้เสร็จและจะเลือกอย่างไร:
ในความเป็นจริง จะต้องใช้เวลาหลายปีก่อนที่เราจะพิสูจน์ความถูกต้องของความเห็นพ้องต้องกันของ Ethereum นี่เป็นระยะเวลาเท่ากันโดยประมาณที่เราใช้ในการดำเนินการขั้นสุดท้ายของสล็อตเดียว, Orbit, ปรับเปลี่ยนอัลกอริธึมลายเซ็น และการวิเคราะห์ความปลอดภัยที่ต้องใช้ความมั่นใจเพียงพอในการใช้ฟังก์ชันแฮช เชิงรุก เช่น โพไซดอน ดังนั้น สิ่งที่ฉลาดที่สุดที่ต้องทำคือแก้ไขปัญหาอื่นๆ เหล่านี้ และดำเนินการดังกล่าวโดยคำนึงถึงความเป็นมิตรกับ STARK เป็นหลัก
การแลกเปลี่ยนหลักมีแนวโน้มที่จะอยู่ในลำดับการดำเนินงาน ระหว่างแนวทางที่เพิ่มขึ้นมากขึ้นในการปฏิรูปชั้นฉันทามติของ Ethereum และแนวทาง เปลี่ยนแปลงหลาย ๆ อย่างในคราวเดียว ที่ต่างไปจากเดิมอย่างสิ้นเชิง สำหรับ EVM วิธีการแบบเพิ่มหน่วยนั้นสมเหตุสมผล เนื่องจากจะลดการหยุดชะงักของความเข้ากันได้แบบย้อนหลังให้เหลือน้อยที่สุด จะมีผลกระทบต่อความเข้ากันได้แบบย้อนหลังน้อยลงในเลเยอร์ฉันทามติ และยังจะได้รับประโยชน์จากการคิดใหม่ ที่ครอบคลุม มากขึ้นเกี่ยวกับรายละเอียดต่างๆ เกี่ยวกับวิธีการสร้างสายสัญญาณบีคอนเพื่อเพิ่มประสิทธิภาพความเป็นมิตรต่อ SNARK ให้ดีที่สุด
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
ในการออกแบบ Ethereum PoS ใหม่ในระยะยาว ความเป็นมิตรของ STARK จะต้องได้รับการพิจารณาเบื้องต้น โดยเฉพาะอย่างยิ่ง single-slot Finality, Orbit, การเปลี่ยนแปลง Signature Scheme และ Signature Aggregation
