ชื่อเดิม: อนาคตที่เป็นไปได้ของโปรโตคอล 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) จะตกลงตั้งแต่ต้นทุนกติกาและเริ่มผลิตบล็อกตามกฎระเบียบใหม่ ผู้ใช้ที่ทำการยืนยันโหนดทั้งหมดจะปฏิเสธการยอมรับโหนดที่ไม่เป็นส่วนหนึ่งของกลุ่มข้อกล่าวหานี้และจะรวมตัวกันในเส้นทางที่ยังคงปฏิบัติตามกฎระเบียบเก่า on-chain และดำเนินการสร้างเส้นทางนี้ต่อไป ผู้ใช้ที่ผ่านการตรวจสอบทั้งหมดจะปฏิบัติตามเส้นทางนี้

นี่คือความแตกต่างระหว่างบล็อกเชนและระบบที่เซ็นทรัลได้รับการยอมรับว่าเป็นความแตกต่างสำคัญ อย่างไรก็ตาม เพื่อให้คุณสมบัตินี้เป็นไปได้ จำเป็นต้องมีโหนดที่ถูกต้องพอมาก ทั้งนี้เหมาะสำหรับนักสร้างชื่อ (เนื่องจากหากนักสร้างชื่อไม่ยืนยันโซ่เชื่อมต่อ จะไม่มีการร่วมสนับสนุนกฎโปรโตคอล) และผู้ใช้ทั่วไป ในปัจจุบัน การเปิดใช้งานโหนดบนเครื่องคอมพิวเตอร์โน้ตบุ๊ค (รวมถึงโน้ตบุ๊คที่ใช้เขียนบทความนี้) เป็นเรื่องที่เป็นไปได้ แต่ยากที่จะทำ到ขั้นนั้น The Verge กำลังพยายามเปลี่ยนสถานการณ์ให้โหนดที่ยืนยันทั้งหมดมีต้นทุนการคำนวณที่ต่ำ ให้โทรศัพท์มือถือกระเป๋า บราวเซอร์กระเป๋า หรือแม้กระทั่งนาฬิกาอัจฉริยะก็จะมีการยืนยันโดยค่าเริ่มต้น

แผนทางของ The Verge 2023

เริ่มต้น "Verge" เป็นการโอนสถานะของ ETH จากการเก็บรักษาไปยังต้นไม้ Verkle - โครงสร้างต้นไม้ที่อนุญาตให้พิสูจน์ที่แนบแน่นขึ้น สามารถทำให้โหนดยืนยันบล็อก ETH โดยไม่จำเป็นต้องเก็บสถานะของ ETH บนฮาร์ดไดรฟ์ของตน (ยอดเงินในบัญชี โค้ดสัญญา พื้นที่จัดเก็บ ......) โดยต้องใช้ข้อมูลพิสูจน์ระหว่างกว่าหลายร้อย KB และเวลาพิเศษต่อหลายร้อยมิลลิวินาทีเพื่อยืนยันการพิสูจน์ ในปัจจุบัน Verge แทนความฝันที่ใหญ่ขึ้น โดยมุ่งเน้นการยืนยันการใช้ทรัพยากรของ ETH โซลูชันที่ใช้เทคโนโลยีการพิสูจน์ที่แนบแน่นทั้งหมดของ ETH ไม่ว่าจะเป็นการยืนยันที่ไม่มีสถานะหรือการใช้ SNARK ในการยืนยันการดำเนินการใน ETH

นอกจากการติดตามระยะยาวของ SNARK ทั้งลำดับโซ่แล้ว ปัญหาใหม่อีกปัญหาหนึ่งเกี่ยวข้องกับว่า Verkle ต้นไม้เป็นเทคโนโลยีที่ดีที่สุดหรือไม่ ต้นไม้เวอร์เคิลมีความเปรอะเปื้อนต่อการโจมตีจากคอมพิวเตอร์ควอนตัม ดังนั้นหากเรานำต้นไม้เวอร์เคิลออกจากต้นไม้ Merkle Patricia ของ KECCAK ปัจจุบัน เราต้องแทนที่ต้นไม้ใหม่อีกครั้งในอนาคต วิธีการทดแทนต้นไม้ Merkle ด้วยตนเองคือการข้าม STARK ที่ใช้สาขา Merkle และใส่ลงในต้นไม้ทวิภาค จากประวัติศาสตร์มาดู วิธีการนี้ถูกพิจารณาว่าใช้ไม่ได้เนื่องจากความต้องการและความซับซ้อนของเทคโนโลยี อย่างไรก็ตามเมื่อเร็วๆ นี้เราเห็นว่า Starkware ใช้ STARKs ของ ckcle ในโน้ตบุ๊คเพื่อพิสูจน์พลังงาน Poseidon แฮช 1.7 ล้านข้อมูลต่อวินาที และด้วยความเจริญเติบโตของเทคโนโลยีอื่น ๆ เช่น GKB การพิสูจน์เวลาของ "แฮช" แบบดั้งเดิมก็ย่อมเร็วขึ้นอย่างรวดเร็ว ดังนั้นในปีที่ผ่านมา "Verge" กลายมาเป็นเรื่องง่ายขึ้นมีโอกาสมากขึ้นหลายอย่าง

The Verge: ประเด็นสำคัญ

• ลูกค้าที่ไม่มีสถานะ: พื้นที่จัดเก็บที่ต้องใช้สำหรับการตรวจสอบลูกค้าและโหนดที่ทำเครื่องหมายไม่ควรเกินกว่าหลาย GB
• (ระยะยาว) ทำการยืนยัน blockchain (ฉันทามติและการดำเนินการ) บนนาฬิกาอัจฉริยะอย่างสมบูรณ์ ดาวน์โหลดข้อมูลบางส่วน ยืนยัน SNARK และเสร็จสิ้น

ในบทนี้

• ไคลเอนต์ไร้สถานะ: Verkle หรือ STARKs
• การพิสูจน์ความถูกต้องของ EVM
• ฉันทามติของvalidity proof

การยืนยันไร้สถานะ: Verkle หรือ STARKs

เราต้องการแก้ปัญหาอะไร？

ในปัจจุบัน ETH คลายเครื่องลูกค้าต้องเก็บรักษาข้อมูลสถานะมากกว่าหนึ่งพันกิโลไบต์เพื่อยืนยันบล็อก และปริมาณนี้เพิ่มขึ้นทุกปี ข้อมูลสถานะเดิมเพิ่มขึ้นประมาณ 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) ไบต์ หรือในต้นไม้ที่มี 2 ^ 32 รายการจะใช้ประมาณ 3840 ไบต์ สำหรับต้นไม้ทรงสองเหลี่ยมเพียงแค่ต้องการ 32 * (2-1) * log 2(N) = 32 * log 2(N) ไบต์ หรือประมาณ 1024 ไบต์

2. โค้ดไม่ได้รับการ Merkle หมายความว่าต้องพิสูจน์สิทธิ์การเข้าถึงบัญชีโค้ดโดยการให้โค้ดทั้งหมด สูงสุด 24000 ไบต์

เราสามารถคำนวณสถานการณ์ที่เลวร้ายที่สุดได้ดังนี้：

30000000 แก๊ส / 2400 (冷บัญชี阅读成本) * （5 * 488 + 24000) = 330000000 字节

ต้นทุนของสาขาเล็กน้อย (ใช้ 5 * 480 แทน 8 * 480) เพราะเมื่อมีสาขามากขึ้นแล้ว ส่วนบนจะซ้ำกัน แต่ถึงอย่างไรก็ตาม ปริมาณข้อมูลที่ต้องดาวน์โหลดในช่วงเวลาหนึ่งๆ ก็ยังไม่เป็นไปได้ทั้งสิ้น หากเราพยายามใช้ STARK เพื่อห่อหุ้มมัน เราจะพบกับปัญหาสองประการ: (i) KECCAK ไม่ใช่เพื่อนตัวแทนสำหรับ STARK; (ii) ปริมาณข้อมูล 330 MB หมายความว่าเราต้องพิสูจน์ว่าเรียกใช้รอบฟังก์ชัน KECCAK ได้ 5 ล้านครั้ง ซึ่งอาจทำให้พิสูจน์ไม่ได้สำหรับฮาร์ดแวร์ทุกชนิดนอกจากฮาร์ดแวร์ระดับผู้บริโภคที่ทรงพลังแม้กระทั่งเราสามารถทำให้ STARK พิสูจน์ KECCAK ได้อย่างมีประสิทธิภาพกว่าเดิม

หากเราใช้ต้นไม้ทวิภาคแทนต้นไม้สิบหกเหลี่ยมโดยตรงและทำการ Merkle รหัสเพิ่มเติมให้กับรหัส สิ่งที่เลวร้ายที่สุดคือประมาณ 30000000/2400 * 32 * (32-14 + 8) = 10400000 ไบต์ (14 หมายถึงการลบตัวเลขฐานสองของต้นไม้ขยายออกเพิ่มเติม 2 ^ 14 และ 8 คือความยาวของพิสูจน์ในโครงสร้างข้อมูลในบล็อกโค้ด) ควรทราบว่านี่เป็นต้นทุนแก๊สที่เปลี่ยนแปลงไป ทุกๆ บล็อกของรหัสที่เรียกเก็บค่าเข้าถึงแต่ละบล็อกแต่ละบล็อก ดังนั้น EIP-4762 ทำเช่นนั้น การจัดสรรพื้นที่ 10.4 MB ดีกว่ามาก แต่สำหรับโหนดจำนวนมาก ข้อมูลที่ดาวน์โหลดในแต่ละช่องเวลายังมีมากเกินไป ดังนั้นเราต้องนำเทคโนโลยีที่ทันสมัยกว่าเข้ามา ในทางนี้มีสองวิธีที่นำมาใช้คือต้นไม้ Verkle และต้นไม้แบบ STARKed ในรูปแบบไบนารี

ต้นไม้ Verkle

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

ดังนั้น การพิสูจน์ขนาดของแต่ละสาขาในหลักทศนิยมเป็น 32 - 1 og 256(N) = 4* log 2(N) ไบต์ ดังนั้น ขนาดการพิสูจน์สูงสุดทศนิยมเป็น 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 ไบต์ (เนื่องจากการกระจายของบล็อกสถานะไม่สมดุล ผลลัพธ์จริงจะแตกต่างเล็กน้อย แต่เป็นค่าเฉลี่ยครั้งแรกได้)

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

นอกจากนี้เรายังใช้ประโยชน์จากการพิจารณานี้เพื่อทําสิ่งอื่น: เราได้ทําให้ค่าใช้จ่ายในการเข้าถึงที่เก็บข้อมูล "ติดกัน" ราคาถูกมาก: รหัสหลายบล็อกสําหรับสัญญาเดียวกันหรือช่องเก็บข้อมูลที่อยู่ติดกัน EIP - 4762 ให้คําจํากัดความของ adjacency และมีค่าธรรมเนียมเพียง 200 แก๊สสําหรับการเข้าถึง adjacency ในกรณีของการเข้าถึงที่อยู่ติดกันขนาดหลักฐานกรณีที่เลวร้ายที่สุดจะกลายเป็น 300000000 / 200 * 32 - 4800800 ไบต์ซึ่งยังอยู่ในเกณฑ์ที่ยอมรับได้ หากด้วยเหตุผลด้านความปลอดภัยเราต้องการลดค่านี้เราสามารถเพิ่มค่าใช้จ่ายในการเยี่ยมชมที่อยู่ติดกันได้เล็กน้อย

STARKed ต้นไม้แบบไบนารีแฮช

หลักการของเทคโนโลยีนี้เป็นเรื่องที่เข้าใจได้โดยอัตโนมัติ: คุณเพียงแค่สร้างต้นไม้ทวิภาคธรรมชาติที่มีการพิสูจน์ขนาดสูงสุด 10.4 MB เพื่อพิสูจน์ค่าในบล็อกและใช้ STARK ที่พิสูจน์แทนพิสูจน์ดังกล่าว ดังนั้นพิสูจน์เองก็จะประกอบด้วยเฉพาะข้อมูลที่ได้รับการพิสูจน์แล้วร่วมกับค่าใช้จ่ายคงที่ขนาด 100-300 kB จาก STARK จริงๆ

ความท้าทายหลักที่นี่คือการยืนยันเวลา พวกเราสามารถดำเนินการคำนวณที่คล้ายกับคำนวณพื้นฐานที่กล่าวมาได้ เพียงแต่เราคำนวณไม่ใช่ข้อมูลขนาดไบต์ แต่เป็นค่าแฮช บล็อกขนาด 10.4 MB หมายถึง 330000 ค่าแฮช ถ้าเราเพิ่มการ "ขุด" โดยผู้โจมตีซึ่งอาจมีโอกาสมีค่าแฮชร่วมกันในต้นไม้ที่ยาวมากขึ้น ค่าแฮชที่แย่ที่สุดจะเป็นประมาณ 660000 ค่าแฮช ดังนั้นถ้าเราสามารถพิสูจน์ได้ว่าค่าแฮชต่อวินาทีคือ 200,000 ก็จะไม่มีปัญหา

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

1. ทำการวิเคราะห์ความปลอดภัยของ Poseidon อย่างรวดเร็วและเข้าใจอย่างเพียงพอเพื่อนำไปใช้ใน L1
2. ใช้ฟังก์ชันแฮช "อนุรักษ์" เช่น SHA 256 หรือ BLAKE

หากต้องการพิสูจน์ฟังก์ชันแฮชที่อยู่ในรูปแบบอนุญาตให้สำรวจได้ วง STARK ของ Starkware ในขณะเขียนบทความนี้สามารถพิสูจน์ได้เพียง 10-30 k ค่าแฮชต่อวินาทีเท่านั้นบนเครื่องพีซีแบบโน้ตบุ๊คชนิดผู้ใช้งานทั่วไป อย่างไรก็ตามเทคโนโลยี STARK กำลังพัฒนาอย่างรวดเร็ว แม้ในปัจจุบันเทคโนโลยีที่พิเศษจาก GKR ก็แสดงให้เห็นว่าความเร็วนี้สามารถเพิ่มขึ้นไปได้ในช่วง 100-2 O 0 k

ทั้งหมดยกเว้นกรณีใช้พยานเพื่อยืนยันบล็อก

นอกจากการตรวจสอบบล็อกแล้วยังมีกรณีใช้ที่สำคัญอื่น ๆ 3 ที่ต้องการการตรวจสอบที่ไม่มีสถานะที่มีประสิทธิภาพมากขึ้น

• พูลหน่วยความจำ: เมื่อธุรกรรมถูกเผยแพร่ โหนดในเครือข่าย P2P จำเป็นต้องตรวจสอบว่าธุรกรรมถูกต้องก่อนที่จะเผยแพร่ใหม่ การตรวจสอบปัจจุบันรวมถึงการตรวจสอบลายเซ็น การตรวจสอบว่ายอดเงินเพียงพอ และการตรวจสอบค่าย่อยว่าถูกต้อง ในอนาคต (เช่น การใช้หลักบัญชีแบบธรรมชาติ เช่น EIP-7701 นี้อาจเกี่ยวข้องกับการเรียกใช้รหัส EVM บางส่วนที่จะมีการเข้าถึงสถานะบางอย่าง หากโหนดเป็นไร้สถานะ ธุรกรรมจะต้องแนบหลักฐานการเข้าถึงสถานะของวัตถุสถานะ
• รายการที่รวมอยู่: นี่คือคุณลักษณะที่เสนอให้ (อาจเป็นขนาดเล็กและไม่ซับซ้อน) การรับรองดังกล่าวเป็นการบังคับให้ผู้ตรวจสอบความถูกต้องทำให้บล็อกถัดไปมีการทำธุรกรรม โดยไม่คำนึงถึงความต้องการของผู้สร้างบล็อก (ซึ่งอาจมีขนาดใหญ่และซับซ้อน) นี้จะทำให้เกิดการลดความสามารถของผู้มีอำนาจในการแฝงการทำธุรกรรมผ่านเครือข่ายเวลา อย่างไรก็ตาม ผู้ตรวจสอบความถูกต้องจำเป็นต้องมีวิธีการตรวจสอบความถูกต้องของธุรกรรมที่รวมอยู่ในรายการ
• ลูกค้าเบา: หากเราต้องการให้ผู้ใช้เข้าถึงเครือข่ายผ่านกระเป๋าเงิน (เช่น Metamask, Rainbow, Rabby เป็นต้น) การทำเช่นนั้นจำเป็นต้องรันไคลเอ็นต์เบา (เช่น Helios) โมดูลหลักของ Helios ให้สถานะรากที่ได้รับการตรวจสอบแก่ผู้ใช้ และเพื่อให้ได้ประสบการณ์ที่ไม่มีการเชื่อมั่นอย่างเต็มที่ผู้ใช้จำเป็นต้องให้พิสูจน์สำหรับทุกการเรียกใช้ RPC ที่พวกเขาทำ (เช่น สำหรับการเรียกของเครือข่าย ETH (ผู้ใช้ต้องพิสูจน์ว่าเข้าถึงสถานะทั้งหมดที่เขาเข้าถึงในขั้นตอนการเรียกใช้)

ทุก use case เหล่านี้มีจุดร่วมกันคือพวกเขาต้องการพิสูจน์จำนวนมาก แต่แต่ละพิสูจน์มีขนาดเล็ก ดังนั้นการพิสูจน์ STARK ไม่มีความหมายจริงในกรณีเหล่านี้ ในทางกลับกันวิธีที่เหมาะสมที่สุดคือใช้ Merkle branch โดยตรง Merkle branch ยังมีข้อดีอีกอย่างคือสามารถอัปเดตได้ ให้มีการให้พิสูจน์สถานะใด ๆ X ที่มีบล็อก B เป็นราก ถ้าได้รับบล็อกย่อย B 2 และพิสูจน์ของมัน ก็สามารถอัปเดตพิสูจน์ให้เป็นรากบล็อก B 2 ได้ Verkle proof ก็สามารถอัปเดตได้เช่นกัน

มีความเกี่ยวข้องกับงานวิจัยที่มีอยู่แล้วอย่างไรบ้าง:

• ต้นไม้เวอร์เคิล
• John Kuszmaul เกี่ยวกับ Verkle tree บทความต้นฉบับ
• สตาร์คแวร์
• เอกสาร Poseidon 2
• Ajtai (ฟังก์ชันแฮชทดแทนที่ใช้ความยากลำบากของเครือข่ายเพื่อให้การทำงานเป็นไปอย่างรวดเร็ว)
• Verkle.info

01928374656574839201

งานหลักที่เหลืออยู่คือ

1. การวิเคราะห์เพิ่มเติมเกี่ยวกับผลกระทบของ EIP-4762 (การเปลี่ยนแปลงค่า แก๊ส ไร้สถานะ)

2. ดำเนินการและทดสอบงานเพิ่มเติมของโปรแกรมการเรียกรองที่สำคัญสำหรับความซับซ้อนของการปฏิบัติในสภาพแวดล้อมที่ไม่มีสัญชาติ

3.การวิเคราะห์ความปลอดภัยเพิ่มเติมของฟังก์ชั่นแฮช Poseidon, Ajtai และฟังก์ชั่นอื่น ๆ ที่เหมาะสมกับ "STARK-friendly"

4. เพื่อพัฒนาฟีเจอร์ STARK ที่มีประสิทธิภาพสูงมากขึ้นสำหรับ "การเก็บรักษา" (หรือ "ดั้งเดิม") โดยใช้เทคโนโลยี Binius หรือ GKR เป็นตัวอย่าง

นอกจากนี้เราจะตัดสินใจเลือกหนึ่งในทางเลือกสามต่อไปนี้เร็ว ๆ นี้: (i) ต้นไม้ Verkle, (ii) ฟังก์ชันแฮชที่เป็นมิตรกับ STARK และ (iii) ฟังก์ชันแฮชอนุรักษ์ ลักษณะพิเศษของพวกเขาสามารถสรุปได้ในตารางด้านล่าง:

นอกเหนือจากเลขหัวข้อเหล่านี้ยังมีปัจจัยสำคัญอื่น ๆ ที่ควรพิจารณา:

• ณ ปัจจุบันโค้ด Verkle ได้รับการพัฒนาอย่างมีเสถียรภาพแล้ว นอกจาก Verkle แล้ว การใช้โค้ดอื่นๆ จะทำให้การใช้งานล่าช้า และอาจจะทำให้ Fork แข็งขันล่าช้า ซึ่งไม่เป็นไร โดยเฉพาะอย่างยิ่งหากเราต้องการเวลาเพิ่มเติมสำหรับการวิเคราะห์ฟังก์ชันแฮชหรือการประสานงานของผู้ตรวจสอบ หรือหากเรามีคุณลักษณะที่สำคัญอื่นที่ต้องการนำเข้าไว้ในอีเธอเรียกมาก่อน
• การอัปเดตรากสถานะด้วยค่าแฮชเร็วกว่าการใช้ต้นไม้เวอร์เคิล ซึ่งหมายความว่าวิธีการที่ใช้ค่าแฮชสามารถปล่อยเวลาการซิงโครไนส์ของโหนดเต็ม
• Verkle Tree มีคุณสมบัติการอัปเดตพยายามที่น่าสนใจ - พยายาม Verkle Tree มีคุณสมบัติการอัปเดตแบบอัปเดตได้ คุณสมบัตินี้มีประโยชน์ต่อ mempool รายการที่มีและอื่น ๆ และอาจช่วยเพิ่มประสิทธิภาพการปฏิบัติ : หากมีการอัปเดตวัตถุประสงค์ จะสามารถอัปเดตพยายามของชั้นสองจากท้ายสุดได้โดยไม่ต้องอ่านเนื้อหาชั้นสุดท้าย
• Verkle การพิสูจน์ SNARK ทำได้ยากขึ้น เมื่อเราต้องการลดขนาดของการพิสูจน์ลงไปที่หลายพันไบต์ Verkle การพิสูจน์ก็จะนำมาซักหน่อย นั่นเป็นเพราะการตรวจสอบของ Verkle การพิสูจน์ มีการใช้งาน 256 บิตอย่างมาก ซึ่งจะต้องการระบบการพิสูจน์ที่มีค่าใช้จ่ายมาก หรือโครงสร้างภายในที่กำหนดเองที่มีส่วน Verkle การพิสูจน์ 256 บิต นี้ไม่ได้เป็นปัญหาสำหรับไร้สถานะโดยตนเอง แต่มันจะนำมาซักหน่อย

หากเราต้องการที่จะได้รับความสามารถในการอัปเดตพิสูจน์ Verkle ได้อย่างปลอดภัยด้วยวิธีที่มีประสิทธิภาพและเหมาะสมอย่างหนึ่งนั้นคือการใช้ lattice ที่มีพื้นที่ Merkle ต้นไม้

หากในกรณีที่เลวร้ายที่สุดพบว่าประสิทธิภาพของระบบไม่เพียงพอ เรายังสามารถใช้แก๊สมิติมากกว่า โดยไม่คาดคิด เพื่อเติมเต็มข้อบกพร่องเหล่านี้: สำหรับ (i) calldata; (ii) การคำนวณ; (iii) การเข้าถึงสถานะและข้อจำกัดแก๊สที่แตกต่างออกไปที่เป็นไปได้ แก๊ส อิสระ แก๊สเพิ่มความซับซ้อน แต่เป็นการแลกเปลี่ยน มันจำกัดอย่างเข้มงวดระหว่างสถานการณ์เฉลี่ยและสถานการณ์ที่เลวร้ายมากยิ่งมากจาก 12500 ถึงเช่น 3000 ทศนิยม นี้จะทำให้ BLAKE 3 มีประโยชน์ (อย่างน้อย) ในปัจจุบัน

ก๊าซหลายมิติช่วยให้ขีด จํากัด ทรัพยากรของบล็อกอยู่ใกล้กับขีด จํากัด ทรัพยากรของฮาร์ดแวร์พื้นฐาน

อีกหนึ่งเครื่องมือที่ไม่คาดคิดคือการคำนวณค่าเครือข่ายเวลาแฝงของรากสถานะไปยังช่วงเวลาหลังจากบล็อก ด้วยวิธีนี้เราจะมีเวลาทั้ง 12 วินาทีในการคำนวณรากสถานะ ซึ่งหมายความว่าแม้กระทั่งในสถานการณ์ที่หนักมากที่สุด ก็ยังพอดีกับเวลาพิสูจน์ 60000 แฮชต่อวินาที ซึ่งทำให้เราคิดว่า BLAKE 3 ก็เพียงพอในทางทฤษฎีเท่านั้น

ข้อเสียของวิธีนี้คือ จะเพิ่ม light client ใน time slot แต่ก็มีเทคโนโลยีที่ดีกว่าที่สามารถลดค่าเครือข่ายเวลาแฝงเหล่านี้ลงมาเพียงแค่การสร้างพรโอฟที่เกิดขึ้นในค่าเครือข่ายเวลาแฝง ตัวอย่างเช่น พรโอฟสามารถกระจายในเครือข่ายทันทีหลังจากโหนดใดๆ สร้างขึ้นโดยไม่ต้องรอบล็อกถัดไป

มันจะทำงานร่วมกับส่วนอื่น ๆ ของแผน

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

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

การยืนยันสถานะแบบไม่มีข้อมูลการตรวจสอบและการหมดอายุในอดีตมีความสำคัญอีกอย่างหนึ่ง ในปัจจุบัน ไคลเอ็นต์จำเป็นต้องเก็บข้อมูลประวัติขนาดใกล้ 1 TB ข้อมูลเหล่านี้เป็นข้อมูลสถานะหลายเท่า แม้ว่าไคลเอ็นต์จะไม่มีสถานะ แต่หากเราไม่สามารถปลดปล่อยความรับผิดชอบในการเก็บข้อมูลประวัติของไคลเอ็นต์ จะเกือบจะหายไปเป็นฝันของไคลเอ็นต์ที่ไม่มีการจัดเก็บได้ การเคลื่อนไหวแรกเริ่มของด้านนี้คือ EIP-4444 ซึ่งหมายความว่าจะเก็บข้อมูลประวัติใน torrents หรือ Portal Network

หลักฐานความถูกต้องของการดำเนินการ EVM

เราต้องการแก้ปัญหาอะไร？

ETH บล็อกการยืนยันของเครือข่ายมีเป้าหมายยาวนานที่ชัดเจน - ควรสามารถยืนยันบล็อก ETH ได้โดย (i) ดาวน์โหลดบล็อก หรือแม้แต่ดาวน์โหลดส่วนเล็ก ๆ ของข้อมูลที่ใช้ได้ในบล็อก; (ii) การยืนยันบล็อกที่ถูกต้องด้วยพยานเล็ก ๆ น้อย ๆ นี้จะเป็นการดำเนินการที่ใช้ทรัพยากรอย่างน้อย สามารถทำได้ในโทรศัพท์มือถือ บราวเซอร์ กระเป๋าเงิน และอาจสามารถทำได้ในเครือข่ายอื่น ๆ ด้วย (ไม่มีส่วนของข้อมูลที่ใช้ได้)

เพื่อทำได้นี้จำเป็นต้องมีการพิสูจน์ SNARK หรือ STARK สำหรับเลเยอร์ความเห็นร่วมกัน (เช่น Proof of Stake) และเลเยอร์ดำเนินการ (เช่น EVM) ข้อแรกเป็นความท้าทายเองและควรได้รับการแก้ไขขณะที่ขั้นตอนการปรับปรุงเลเยอร์ความเห็นร่วมกันกำลังดำเนินอยู่ (เช่น ใช้กับ Single Slot Finality) ข้อที่สองต้องการการพิสูจน์การดำเนินการของ EVM

มันคืออะไร และทำงานอย่างไร?

จากเส้นทางที่มองเห็นได้ ในมาตรฐาน ETH ฟอร์ม EVM ถูกกำหนดให้เป็นฟังก์ชันการเปลี่ยนสถานะ: คุณมีสถานะก่อนหน้า S บล็อก B คุณกำลังคำนวณสถานะหลัง 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'

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

การสร้าง validity proof สำหรับการคำนวณใน EVM ถูกสร้างขึ้นแล้ว และถูกใช้โดย L2 อย่างแพร่หลาย แต่การทำให้ EVM validity proof เป็นไปได้ใน L1 ยังมีงานมากที่ต้องทำ

มีความเกี่ยวข้องกับงานวิจัยที่มีอยู่แล้วอย่างไรบ้าง?

• EFPSE ZK-EVM (ไม่ได้ใช้งานแล้วเนื่องจากมีตัวเลือกที่ดีกว่า)
• Zeth ทำงานโดยการคอมไพล์ EVM เข้าสู่ RISC-0 ZK-VM
• โครงการ ZK-EVM การตรวจสอบอย่างเป็นทางการ

01928374656574839201

ในปัจจุบัน ระบบบัญชีอิเล็กทรอนิกส์มีข้อจำกัดในสองด้าน: ความปลอดภัยและเวลาการตรวจสอบของ validity proof

การพิสูจน์ความถูกต้องที่ปลอดภัยต้องรับประกันว่า SNARK ได้ตรวจสอบการคำนวณของ EVM และไม่มีช่องโหว่ วิธีการเพิ่มความปลอดภัยสองอย่างหลักคือการมีการตรวจสอบหลายตัวกันและการตรวจสอบรูปแบบ การตรวจสอบหลายตัวกันหมายถึงมีการดำเนินการการพิสูจน์ความถูกต้องที่เขียนอย่างอิสระหลายรูปแบบ เช่นเดียวกับมีหลายไคลเอนต์ หากบล็อกได้รับการพิสูจน์ความถูกต้องจากซับเซ็ตย่อยใด ๆ ที่มีขนาดเพียงพอ ไคลเอนต์ก็จะยอมรับบล็อกนั้น การตรวจสอบรูปแบบเกี่ยวข้องกับการใช้เครื่องมือที่ใช้ปกป้องทฤษฎีคณิตศาสตร์เช่น Lean 4 เพื่อพิสูจน์ว่าการพิสูจน์ความถูกต้องเฉพาะรับการดำเนินการที่ถูกต้องตามข้อกำหนด EVM ที่เหมาะสม (เช่น EVM K ความหมายหรือกฎระดับการดำเนินงานของ ETH ที่เขียนด้วย python (EELS))

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

• การแบ่งเบาะแส—ตอนนี้ EVM ตัวตรวจสอบที่เร็วที่สุดใช้เวลาเฉลี่ย 15 วินาทีเพื่อพิสูจน์บล็อกของอีเธอเรียม มันทำได้โดยการแบ่งงานของพวกมันระหว่างหลายร้อย GPU แล้วรวมผลงานของพวกมันเข้าด้วยกันท้ายที่สุด จากทฤษฎีแล้ว เราทราบอย่างแน่นอนว่าเราสามารถสร้างตัวตรวจสอบ EVM ที่สามารถพิสูจน์การคำนวณในเวลา O(log(N)) ได้: ให้ GPU ทำแต่ละขั้นตอนแล้วทำ "ต้นไม้รวม"

การทำงานนี้เป็นที่ท้าทาย แม้ว่าในกรณีที่แย่ที่สุด คือ กรณีที่ธุรกรรมขนาดใหญ่มากใช้พื้นที่บล็อกทั้งหมด การแบ่งคำนวณต้องไม่ทำตามลำดับ แต่ต้องทำตามรหัสการดำเนินการ (รหัสการดำเนินการของ EVM หรือ RISC-V เป็นต้น) การรักษา "หน่วยความจำ" ของเครื่องจำลองระหว่างส่วนต่าง ๆ ของการพิสูจน์เป็นอีกรายการที่ท้าทาย อย่างไรก็ตาม ถ้าเราสามารถทำการพิสูจน์เชิง recursive แบบนี้ได้ เราจะรู้ว่า แม้แต่ถ้าไม่มีการปรับปรุงใด ๆ อย่างอื่น ๆ ก็อย่างน้อยก็ได้แก้ไขปัญหาค่าเครือข่ายเวลาแฝงของผู้พิสูจน์แล้ว

• ระบบการพิสูจน์ถูกปรับปรุง - ระบบการพิสูจน์ใหม่ เช่น Orion、Binius、GRK และข้อมูลอื่น ๆ อาจส่งผลให้เวลาการตรวจสอบการคำนวณทั่วไปลดลงอีกครั้ง
• การเปลี่ยนแปลงค่าแก๊ส EVM อื่น ๆ - มีอยู่หลายสิ่งที่สามารถปรับปรุงใน EVM ให้เหมาะสมกับผู้พิสูจน์ได้มากขึ้นโดยเฉพาะอย่างยิ่งในกรณีที่เลวร้ายที่สุด หากผู้โจมตีสามารถสร้างบล็อกที่บล็อกผู้พิสูจน์ในเวลาสิบนาที เพียงแค่ 4 วินาทีก็ไม่เพียงพอที่จะพิสูจน์บล็อก ETH ธรรมดา การเปลี่ยนแปลงที่จำเป็นต้องใช้ EVM สามารถแบ่งออกเป็นหลัก ๆ ดังนี้

• ต้นทุน แก๊ส การเปลี่ยนแปลง - หากการดำเนินการใด ๆ ต้องใช้เวลานานในการพิสูจน์ แม้แต่ความเร็วในการคำนวณจะสูงเท่าไร ก็ตามควรมี แก๊ส ต้นทุนสูงมาก EIP-7667 เป็นหนึ่งใน EIP ที่เสนอขึ้นเพื่อแก้ไขปัญหาที่รุนแรงที่สุดในเรื่องนี้ มันเพิ่ม แก๊ส ต้นทุนของฟังก์ชันการ แฮช (แบบดั้งเดิม) อย่างมากเนื่องจากโค้ดและการเตรียมการก่อนหน้านั้นถูกกำหนดราคาถูก ในการชดเชยค่าใช้จ่ายใน แก๊ส เหล่านี้ที่เพิ่มขึ้น เราสามารถปล่อย รหัสประมวลผล EVM ที่มีค่าใช้ แก๊ส ต่ำมาก ๆ เพื่อรักษาประสิทธิภาพการถ่ายทอดเฉลี่ยให้คงที่

• การแทนที่โครงสร้างข้อมูล - นอกจากการแทนที่ต้นไม้สถานะด้วยวิธีที่เป็นมิตรกับ STARK แล้ว เรายังต้องการแทนที่รายการธุรกรรม ต้นไม้ใบสำคัญ และโครงสร้างที่มีค่าใช้จ่ายสูงอื่น ๆ Etan Kissling คือการย้ายโครงสร้างธุรกรรมและใบสำคัญไปยัง SSZ ใน EIP นี้เป็นขั้นตอนที่สำคัญ

นอกจากนี้ คุณสามารถใช้เครื่องมือสองอย่าง (หัวหลากแก๊สและสถานะรากเวลาแฝง) ที่ถูกกล่าวถึงในส่วนก่อนหน้านี้เพื่อช่วยในด้านนี้ได้อีกด้วย อย่างไรก็ตามควรจะทราบว่า ต่างจากการตรวจสอบแบบไม่มีสถานะ การใช้เครื่องมือสองอย่างนี้หมายความว่าเรามีเทคโนโลยีเพียงพอที่จะทำงานที่เราต้องการในขณะนี้ และแม้ว่าจะใช้เทคโนโลยีเหล่านี้แล้ว การตรวจสอบ ZK-EVM ที่สมบูรณ์จะต้องใช้เวลาและแรงงานมากขึ้น - แต่อย่างไรก็ตามทำงานที่ต้องการน้อยลงเท่านั้น

หนึ่งจุดที่ไม่ได้ถูกกล่าวถึงในบทความข้างต้นคือฮาร์ดแวร์ของเครื่องพิสูจน์: การใช้ GPU、FPGA และ ASIC ในการสร้างพิสูจน์อย่างรวดเร็วกว่า บริษัท Fabric Cryptography、Cysic และ Accseal เป็นบริษัทที่มีความคืบหน้าในด้านนี้ สำหรับ L2 มีความสำคัญมาก แต่น่าจะไม่เป็นปัจจัยสำคัญในการตัดสินใจของ L1 เนื่องจากผู้คนต้องการให้ L1 คงความ การกระจายอำนาจสูงอยู่ ซึ่งหมายความว่าการสร้างพิสูจน์จำเป็นต้องอยู่ในขอบเขตที่เหมาะสมสำหรับผู้ใช้ ETH และไม่ควรได้รับการจำกัดจากข้อจำกัดของฮาร์ดแวร์ของบริษัทเดียว ส่วน L2 สามารถทำการตัดสินใจที่ดีกว่าได้

ในพื้นที่เหล่านี้ยังมีงานอีกมากที่ต้องทำ:

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

ค่าที่เป็นไปได้คือ:

• ความปลอดภัยและเวลาของตัวตรวจสอบ: หากเลือกฟังก์ชันแฮชที่เข้มงวดมากขึ้น, ระบบพิสูจน์ที่ซับซ้อนมากขึ้นหรือสมมติฐานความปลอดภัยที่เข้มข้นขึ้นหรือแผนการออกแบบอื่น ๆ ก็อาจทำให้เวลาตรวจสอบสั้นลงได้
• การกระจายอำนาจ และเวลาของผู้พิสูจน์：ชุมชนต้องตกลงกันเกี่ยวกับ "ข้อกำหนด" ของฮาร์ดแวร์ที่เป็นเป้าหมาย การต้องการให้ผู้พิสูจน์เป็นองค์กรขนาดใหญ่ได้หรือไม่? เราหวังว่าโน้ตบุ๊กแบบพรีเมียมสามารถพิสูจน์บล็อกบนเครือข่าย ETH ใน 4 วินาทีได้หรือไม่? หรือเป็นระหว่างทั้งสอง?
• ระดับของการทำลายความเข้ากันได้ย้อนหลัง: สิ่งที่ขาดทุนในด้านอื่น ๆ อาจจะถูกชดเชยด้วยการเปลี่ยนแปลงต้นทุน แก๊ส ที่เชิงบวกมากขึ้น แต่น่าจะเพิ่มค่าในอัตราส่วนที่ไม่สมเหตุสมผลและทำให้ต้นทุนของแอปพลิเคชันบางอย่างเพิ่มขึ้น ทำให้นักพัฒนาต้องเขียนโค้ดและติดตั้งใหม่เพื่อรักษาความเป็นไปได้ทางเศรษฐกิจ อย่างไรก็ตาม ทั้งสองเครื่องมือนี้ก็มีความซับซ้อนและข้อเสียของตัวเอง

มันแอบแฝงกับส่วนอื่น ๆ ของแผนที่ถนนอย่างไร

เทคโนโลยีหลักที่จำเป็นสำหรับการสร้างหลักฐานการพิสูจน์ความถูกต้องของ L1 EVM เป็นส่วนใหญ่เชื่อมโยงกับสองพื้นที่อื่น ๆ

• การพิสูจน์ความถูกต้องของ L2 (หรือ "ZK rollup")
• วิธี "STARK ไร้สถานะ" ในรูปแบบบินารีแฮช

เมื่อ L1 ทำการ validty proof สำเร็จ จะสามารถ stake โดยง่าย ๆ ได้: แม้กระทั้งคอมพิวเตอร์ที่อ่อนแอที่สุด (รวมถึงโทรศัพท์มือถือหรือนาฬิกาอัจฉริยะ) ก็สามารถ stake ได้ ซึ่งเพิ่มมูลค่าของการแก้ไขข้อจำกัดอื่น ๆ ในการ stake ของบุคคลเดียว (เช่น ขีดจำกัดต่ำสุดที่ 32 ETH) อีกด้วย

นอกจากนี้ การพิสูจน์ความถูกต้องของ EVM ของ L1 สามารถเพิ่มขีดจำกัด แก๊ส ของ L1 ได้อย่างมาก

ฉันทามติของvalidity proof

เราต้องการแก้ปัญหาอะไร？

หากเราต้องการยืนยันบล็อกของ ETH ด้วย SNARK อย่างสมบูรณ์ การดำเนินการของ EVM ไม่ใช่ส่วนที่เราต้องการพิสูจน์เพียงอย่างเดียว นอกจากนี้เรายังต้องการการรับรองฉันทามติ คือ ส่วนของระบบที่จัดการกับการฝากเงิน การถอนเงิน การเซ็นต์ การยืนยันความถือครองของผู้ตรวจสอบและส่วนของบล็อก ETH อื่น ๆ 01928374656574839201

ฉันทามติ比 EVM ง่ายมาก แต่ท้าทายอยู่ที่เราไม่มี L2 EVM สำหรับการคอนเวอร์จัน ดังนั้น งานส่วนใหญ่ต้องทำเสร็จ ดังนั้น การสร้าง ETH ฉันทามติ จำเป็นต้อง "สร้างจากต้น" แม้ว่าระบบพิสูจน์เชิงร่วมกันสามารถสร้างขึ้นบนพื้นฐานของมันได้

มันคืออะไรและทำงานอย่างไร?

Beacon Chain ถูกนิยามให้เป็นฟังก์ชันการเปลี่ยนสถานะเช่นเดียวกับ EVM ฟังก์ชันการเปลี่ยนสถานะประกอบด้วยส่วนสำคัญ 3 ส่วน:

• ECADD (ใช้สำหรับการตรวจสอบลายเซ็น BLS)
• คู่ (ใช้สำหรับการยืนยันลายเซ็น BLS)
• ค่าแฮช SHA 256 (ใช้สำหรับอ่านและอัปเดตสถานะ)

ในแต่ละบล็อกเราจำเป็นต้องพิสูจน์ BLS 12-381 ECADD 1-16 รายการสำหรับผู้ตรวจสอบความถูกต้อง (อาจมีมากกว่าหนึ่งเนื่องจากลายเซ็นอาจรวมอยู่ในเซ็ตหลายๆ ชุด) นี้สามารถระดับหมู่ย่อย ทำให้เราสามารถบอกได้ว่าผู้ตรวจสอบความถูกต้องแต่ละคนจะต้องพิสูจน์ BLS 12-381 ECADD อย่างน้อยหนึ่งรายการ ปัจจุบันแต่ละสล็อตมีลายเซ็นของผู้ตรวจสอบความถูกต้อง 30000 รายการ ในอนาคตเมื่อการแก้ไขเส้นทางยุติธรรมสำหรับแต่ละสล็อต สถานการณ์อาจจะเปลี่ยนไปในทิศทางสองทิศทางแรก หากเราเลือก "แบบบ้านร้าง" จำนวนผู้ตรวจสอบความถูกต้องในแต่ละสล็อตอาจเพิ่มขึ้นไปถึง 1000000 รายการในขณะเดียวกันหากใช้ Orbit SSF จำนวนผู้ตรวจสอบความถูกต้องจะคงที่ที่ 32768 รายการ หรือลดลงไปถึง 8192 รายการ

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

เมื่อพูดถึงการจับคู่ ปัจจุบันมีหลุมหรือช่องใส่ข้อมูลล่าสุดสูงสุด 128 รายการต่อหลุม นั่นหมายความว่าต้องยืนยันการจับคู่ 128 รายการ ด้วย ElP-7549 และการแก้ไขเพิ่มเติมถึงแม้ว่าจำนวนการจับคู่จะน้อยแต่ต้นทุนสูงมาก: เวลารัน (หรือพิสูจน์) ของแต่ละการจับคู่นั้นยาวกว่า ECADD หลายเท่า

การทดสอบ BLS 12-381 พบว่าหนึ่งในความท้าทายหลักคือไม่มีเส้นโค้งที่มีอันดับเท่ากับขนาดของฟิลด์ BLS 12-381 ซึ่งทำให้ระบบการพิสูจน์ใดๆ ก็ต้องมีค่าใช้จ่ายที่สูงมาก ทว่าอีกด้านหนึ่ง ต้น Verkle ที่เสนอสำหรับ Ethereum ถูกสร้างขึ้นด้วยเส้นโค้ง Bandersnatch ซึ่งทำให้ BLS 12-381 เองกลายเป็นเส้นโค้งที่ใช้ใน SNARK ในการพิสูจน์ Verkle branch การปรับปรุงอย่างง่ายสามารถพิสูจน์การบวก G1 100 ล้านต่อวินาที หากต้องการให้ความเร็วในการพิสูจน์เพียงพอแน่นอนจำเป็นต้องใช้เทคโนโลยีที่ชาญฉลาดเช่น GKR

สำหรับค่าแฮช SHA 256 กรณีที่แย่ที่สุดคือบล็อกการแปลงสมัยใหม่ ต้นไม้สมดุลย์ของตัวตรวจสอบทั้งหมดและการสมดุลย์ของตัวตรวจสอบจะถูกอัปเดต เพียงต้นไม้สมดุลย์ของแต่ละตัวตรวจสอบเท่านั้นที่มีขนาดเพียงหนึ่งไบต์ดังนั้นจะมีข้อมูล 1 MB ที่ต้องถูกคำนวณแฮชใหม่ ซึ่งเทียบเท่ากับการเรียกใช้ SHA 256 ครั้ง 32768 หากมีผู้ตรวจสอบที่มียอดคงเหลือที่สูงกว่าหรือต่ำกว่าค่าเกณฑ์หนึ่งพบว่าต้องอัปเดตยอดเงินที่ถือไว้ของผู้ตรวจสอบที่ถูกต้องที่บันทึกไว้ ซึ่งเทียบเท่ากับการสร้าง Merkle branch หนึ่งพันครั้งดังนั้นอาจต้องใช้ค่าแฮชหนึ่งหมื่นครั้ง กลไกการเรียงการ์ดต้องใช้ 90 บิตต่อตัวตรวจสอบ ซึ่งต้องใช้ข้อมูล 11 MB แต่สามารถคำนวณได้ในเวลาใดก็ได้ในรอบหนึ่ง ในกรณีที่สิ้นสุดช่องเดียว ตัวเลขเหล่านี้อาจมีการเปลี่ยนแปลงขึ้นลงได้ตามสถานการณ์ที่เกิดขึ้น การเรียงการ์ดกลายเป็นไม่จำเป็นแม้ว่า Orbit อาจจะช่วยเรื่องนี้ได้บ้าง

อีกที่ท้าทายคือต้องเรียกรับสถานะของ validators ทั้งหมด รวมถึงกุญแจสาธารณะเพื่อทำการตรวจสอบบล็อกหนึ่ง สำหรับ 100 ล้าน validators เพียงการอ่านกุญแจสาธารณะก็ต้องใช้ 4800 ล้านไบต์ รวมถึง Merkle แบรนช์ นี่ต้องการค่าแฮชที่มีล้านๆ ค่าสำหรับแต่ละ epoch หากเราต้องการพิสูจน์ความถูกต้องของ PoS วิธีที่เป็นจริงคือการใช้การคำนวณที่สามารถพิสูจน์ได้เพิ่มขึ้นในรูปแบบหนึ่ง: เก็บโครงสร้างข้อมูลแยกต่างหากภายในระบบพิสูจน์ที่ถูกปรับปรุงโดยเฉพาะ โดยโครงสร้างข้อมูลนี้ถูกปรับปรุงให้สามารถค้นหาได้โดยมีประสิทธิภาพสูง และพิสูจน์ได้ว่ามีการปรับปรุงข้อมูลโครงสร้างดังกล่าว

สรุปว่า มีความท้าทายมากมาย ในการจัดการกับความท้าทายเหล่านี้อย่างมีประสิทธิภาพสูง อาจจำเป็นต้องทำการออกแบบใหม่ของ Beacon Chain อย่างละเอียดอ่อน และอาจมีการสิ้นสุดสลอตเดียวพร้อมกัน ลักษณะการออกแบบใหม่นี้อาจประกอบไปด้วย:

• การเปลี่ยนแปลงฟังก์ชันแฮช: เราใช้ฟังก์ชันแฮช SHA 256 'ครบถ้วน' ในขณะนี้เพื่อเหตุผลในการเติม ดังนั้นการเรียกใช้งานทุกครั้งจะต้องสอดคล้องกับการเรียกใช้งานฟังก์ชันการบีบอัดระดับต่ำอย่างน้อยสองครั้ง หากเราเปลี่ยนเป็นการบีบอัดฟังก์ชัน SHA 256 เราอาจได้รับผลตอบแทนสองเท่า หากเราเปลี่ยนเป็น Poseidon เราอาจได้รับผลตอบแทนเพิ่มขึ้นถึง 100 เท่าซึ่งจะแก้ไขปัญหาทั้งหมดของเรา (อย่างน้อยในเชิงแฮช): เราสามารถ 'อ่าน' บันทึกการยืนยันหนึ่งล้านรายการในไม่กี่วินาที ในแต่ละวินาทีวงจรแฮช 1.7 ล้านรายการ (54 MB)
• หากเป็นระบบ Orbit จะเก็บบันทึกของตัวตรวจสอบหลังจากการสับเปลี่ยนได้โดยตรง: หากเลือกตัวตรวจสอบจำนวนที่กำหนด (เช่น 8192 หรือ 32768 ตัว) เป็นคณะกรรมการสำหรับช่องที่กำหนดให้ จะเก็บไว้ในสถานะข้างกันโดยตรง ซึ่งทำให้เพียงแค่แฮชน้อยที่สุดก็สามารถอ่านกุญแจสาธารณะของตัวตรวจสอบทั้งหมดเข้าสู่หลักฐานได้ นอกจากนี้ยังสามารถทำการอัปเดตสมดุลได้อย่างมีประสิทธิภาพ
• การรวมลายมือ: การรวมลายมือที่มีประสิทธิภาพสูงจะเกี่ยวข้องกับการพิสูจน์แบบเรกูร์ซีฟแบบใดก็ตาม โหนดที่แตกต่างกันในเครือข่ายจะทำการพิสูจน์ระหว่างชุดลายมือ ซึ่งจะลดหน้าที่ของ "ผู้พิสูจน์สุดท้าย" อย่างมีข้อแม้งลงอย่างมาก
• วิธีเซ็นต์อื่น ๆ: สำหรับลามพอร์ท + เซ็นต์เนอร์เคิลเราต้องการ 256 + 32 ค่าแฮชในการตรวจสอบลายเซ็น; โดยมีผู้เซ็นทั้งหมด 32768 คน จะได้รับ 9437184 ค่าแฮช หลังจากการปรับปรุงแล้วเราสามารถดีกว่าอีกขั้นตอนหนึ่งโดยค่าคงที่ขนาดเล็กถ้าเราใช้ Poseidon เราสามารถพิสูจน์ได้ในช่องเดียว แต่ในความเป็นจริงการใช้วิธีการรวมแบบเรียกกลับจะทำให้เร็วขึ้น

มีความเกี่ยวข้องกับงานวิจัยที่มีอยู่แล้วอย่างไรบ้าง?

• หลักธรรมชาติของ Ethereum ที่เป็นรูปแบบ Proof-of-Stake (สำหรับกรรมการที่เชื่อมต่อเพียงอย่างเดียว)
• Helios ที่อยู่ใน SP 1 ของความกระชับ
• สรุป BLS 12-381 ก่อนคอมไพล์
• การตรวจสอบลายเซ็นชุด BLS ที่พิสูจน์ตาม Halo 2

ยังมีงานที่ต้องทำอีกบ้าง การตัดสินใจอย่างไร

ในความเป็นจริงเราจะใช้เวลาหลายปีในการพิสูจน์ความถูกต้องของ ETH Fang ฉันทามติ นี่เป็นเวลาเดียวกับที่เราใช้เวลาในการบรรลุขั้นสุดท้ายของช่องเดียว Orbit ปรับเปลี่ยนอัลกอริธึมลายเซ็นและการวิเคราะห์ความปลอดภัยซึ่งต้องการความมั่นใจเพียงพอที่จะใช้ฟังก์ชันแฮช "ก้าวร้าว" เช่นโพไซดอน ดังนั้นจึงเป็นการดีที่สุดที่จะแก้ไขปัญหาอื่น ๆ เหล่านี้และคํานึงถึงความเป็นมิตรของ STARKs ในขณะที่จัดการกับปัญหาเหล่านี้

ความสมดุลสำคัญอาจจะอยู่ที่ลำดับการดำเนินการ ระหว่างวิธีการที่เป็นขั้นตอนของการปรับปรุง consensus layer ของ Ethereum แบบ progressive และวิธีการที่หลากหลายและก้าวกระโดดขึ้นทีเดียวได้ สำหรับ EVM การใช้วิธีการ progressive เป็นสิ่งที่เหมาะสม เนื่องจากสามารถลดอันตรายที่จะเกิดขึ้นกับความเข้ากันได้ย้อนกลับได้เป็นปริมาณสูงที่สุด สำหรับ consensus layer ผลกระทบต่อความเข้ากันได้ย้อนกลับน้อยกว่า และการสร้าง Beacon Chain อีกครั้งที่ได้รับการปรับปรุงอย่างละเอียดอ่อนจึงจะมีประโยชน์ในการทำให้ SNARK เป็นมิตรในระดับที่ดีที่สุด

มันจะทำงานร่วมกับส่วนอื่น ๆ ของแผน

ในการทำการออกแบบใหม่สำหรับ PoS ของ Ethereum ในระยะยาว ความเป็นมิตรของ STARK จะต้องเป็นปัจจัยหลักที่ต้องพิจารณา โดยเฉพาะอย่างยิ่งการเสร็จสิ้นของสล็อตเดียว โอบิท การเปลี่ยนแปลงแผนลายเซ็น และการรวมลายเซ็น