อ่านบทความก่อนหน้า: "Vitalik เกี่ยวกับอนาคตที่เป็นไปได้ของ ETH ฟอร์ค (1): The Merge", "Vitalik เกี่ยวกับอนาคตที่เป็นไปได้ของ ETH ฟอร์ค (2): The Surge", "Vitalik เกี่ยวกับอนาคตที่เป็นไปได้ของ ETH ฟอร์ค (3): The Scourge"

ขอขอบคุณ Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams และ Uma Roy สําหรับความคิดเห็นและบทวิจารณ์ของพวกเขา

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

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

แผนงาน > The Verge 2023

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

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

The Verge: วัตถุประสงค์สำคัญ

· โหนดไคลเอนต์ไร้สถานะ: พื้นที่จัดเก็บที่จำเป็นสำหรับการตรวจสอบโหนดไคลเอนต์และติดตั้งโหนดไม่ควรเกินไม่กี่ GB

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

ในบทนี้

· ไคลเอ็นต์ไร้สถานะ: Verkle หรือ STARKs

· การพิสูจน์ความถูกต้องที่ดำเนินการโดย EVM

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

การตรวจสอบไร้สถานะ: Verkle หรือ STARKs

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

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

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

มันทำงานอย่างไร?

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

ในความเป็นจริงการใช้การตรวจสอบแบบไร้สัญชาติจําเป็นต้องมีการเปลี่ยนแปลงโครงสร้างต้นไม้ของรัฐของ Ethereum นี่เป็นเพราะต้นไม้ Merkle Patricia ในปัจจุบันไม่เป็นมิตรอย่างยิ่งต่อการดําเนินการตามรูปแบบการพิสูจน์การเข้ารหัสใด ๆ โดยเฉพาะอย่างยิ่งในสถานการณ์ที่เลวร้ายที่สุด นี่เป็นเรื่องจริงทั้งสําหรับการแตกแขนง Merblk "ดั้งเดิม" และความเป็นไปได้ในการ "ห่อ" ลงใน STARKs ปัญหาหลักเกิดจากจุดอ่อนบางประการของ MPT:

1. นี่คือต้นไม้ที่มีหกโหนด (หรือก็คือแต่ละโหนดมี 16 โหนดลูก) ซึ่งหมายความว่าในต้นไม้ขนาด N การพิสูจน์หนึ่งอันจะต้องใช้ความจำเฉลี่ยอยู่ที่ 32*(16-1)log16(N) = 120 log2(N) ไบต์ หรือในต้นไม้ที่มี 2^32 รายการจะใช้ประมาณ 3840 ไบต์ สำหรับต้นไม้ทวิภาค จะใช้เพียง 32*(2-1)log2(N) = 32 log2(N) ไบต์ หรือประมาณ 1024 ไบต์

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

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

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

ค่าใช้จ่ายสาขาเล็กน้อย (ใช้ 5*480 แทน 8*480) โดยเนื่องจากช่วงส่วนปลายของสาขาจะปรากฏอย่างซ้ำซ้อนเมื่อมีสาขามากขึ้น แต่แม้ว่าเช่นนั้นก็ยังไม่เป็นไปได้ที่จะดาวน์โหลดข้อมูลในช่วงเวลาหนึ่งโดยสมบูรณ์ หากเราพยายามห่อหุ้มด้วย STARK จะเผชิญกับปัญหาสองประการ: (i) KECCAK ทำให้ STARK ไม่เป็นมิตรอย่างมาก; (ii) ข้อมูลขนาด 330MB หมายความว่าเราต้องพิสูจน์การเรียกใช้ฟังก์ชันรอบของ KECCAK 500 ล้านครั้ง ซึ่งอาจจะพิสูจน์ไม่ได้สำหรับฮาร์ดแวร์ทุกชนิดที่ไม่ใช่ฮาร์ดแวร์ระดับการบริโภคที่เป็นที่ทราบ แม้ว่าเราจะทำให้ 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-1og256(N) = 4 * log2(N) ไบต์ ดังนั้น ขนาดการพิสูจน์สูงสุดที่เป็นไปได้ตามทฤษฎีคือประมาณ 130000 ไบต์ (เนื่องจากการกระจายของบล็อกสถานะไม่สม่ำเสมอ ผลการคำนวณจริงจะแตกต่างออกไปนิดหน่อย แต่ถือว่าเป็นค่าโดยประมาณในระดับแรก)

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

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

ต้นไม้แฮชบิต STARKed

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

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

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

1. วิเคราะห์ความปลอดภัยของ Poseidon อย่างรวดเร็วและมากมาย และทำความเข้าใจมันอย่างเพียงพอเพื่อการใช้งานใน L1

2. ใช้ฟังก์ชันแฮช "รักษา " เช่น SHA256 หรือ BLAKE

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

การใช้งานพยาธิการเห็นพิสูจน์นอกเหนือจากบล็อก

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

· พูลหน่วยความจำ: เมื่อธุรกรรมถูกประกาศต่อสู้กับเครือข่าย P2P โหนดจำเป็นต้องตรวจสอบว่าธุรกรรมเป็นสมบูรณ์ก่อนที่จะประกาศต่ออีกครั้ง การตรวจสอบนี้ปัจจุบันรวมถึงการตรวจสอบลายเซ็นต์และการตรวจสอบว่าจำนวนเงินเพียงพอและคำนำหน้าถูกต้อง ในอนาคต (เช่น การใช้แนวคิดบัญชีเดิมเช่น EIP-7701) อาจเกี่ยวข้องการทำงานบางส่วนของรหัส EVM ซึ่งจะดำเนินการเข้าถึงสถานะบางส่วน หากโหนดเป็นไร้สถานะ ธุรกรรมจะต้องแนบพิสูจน์การทำงานของวัตถุสถานะ

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

· light client: หากเราต้องการให้ผู้ใช้เข้าถึงเครือข่ายผ่านกระเป๋าเงิน (เช่น Metamask, Rainbow, Rabby เป็นต้น) ในการทำเช่นนั้น พวกเขาจำเป็นต้องเรียกใช้ไคลเอ็นต์ที่เบา (เช่น Helios) โมดูลหลักของ Helios จะให้ผู้ใช้รากสถานะที่ผ่านการตรวจสอบ และในการที่จะได้รับประสบการณ์ที่ไม่มีความเชื่อถือสมบูรณ์ผู้ใช้จำเป็นต้องให้พิสูจน์สำหรับการเรียกใช้ RPC แต่ละคำขอ (เช่น ผู้ใช้จำเป็นต้องให้พิสูจน์สถานะที่เข้าถึงทั้งหมดที่มีการเรียกของเครือข่าย ETH)

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

กับการวิจัยที่มีอยู่มีความเชื่อมโยงในทางใดบ้าง:

· ต้นไม้ Verkle

· John Kuszmaul เกี่ยวกับบทความต้นฉบับของ Verkle tree

· สตาร์คแวร์

· กระดาษ Poseidon2

· Ajtai (ฟังก์ชันแฮชทดแทนที่ใช้เทคนิคความแข็งและตารางเพื่อความเร็ว)

· Verkle.info

ยังสามารถทำอะไรได้อีกบ้าง?

งานสำคัญที่เหลือคือ

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

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

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

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

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

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

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

· การอัปเดตรากภายใต้ค่าแฮชจะเร็วกว่าการใช้ต้นไม้เวอร์เคิล ซึ่งหมายความว่าวิธีการที่ใช้ค่าแฮชสามารถปล่อยเวลาระบบสะท้อนกลับของโหนดเต็ม

· ต้นไม้ Verkle มีคุณสมบัติการอัปเดตที่น่าสนใจ - พยายามของต้นไม้ Verkle สามารถอัปเดตได้ คุณสมบัตินี้มีประโยชน์ต่อ mempool รายการที่มีและการใช้งานอื่น ๆ และอาจช่วยเพิ่มประสิทธิภาพในการปฏิบัติ: หากมีการอัปเดตวัตถุสถานะ จะสามารถอัปเดตพยายามชั้นสุดท้ายโดยไม่ต้องอ่านเนื้อหาชั้นสุดท้าย

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

หากเราต้องการที่จะได้รับความสามารถในการอัปเดตหลักฐาน Verkle อย่างปลอดภัยที่มีประสิทธิภาพและเหมาะสมด้วยความมั่นคงทางควอนตัม วิธีที่เป็นไปได้คือการใช้ Lattice-based Merkle tree

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

Multi-dimensional แก๊ส อนุญาตการจำกัดทรัพยากรของบล็อกให้เข้าใกล้กับการจำกัดทรัพยากรของฮาร์ดแวร์ระดับต่ำกว่า

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

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

01928374656574839201

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

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

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

การพิสูจน์ความถูกต้องของ EVM

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

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

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

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

อย่างเป็นทางการในข้อกําหนด ETH EVM ถูกกําหนดให้เป็นฟังก์ชันการเปลี่ยนสถานะ: คุณมี S ก่อนสถานะบล็อก B และคุณกําลังคํานวณ S' = STF (S, B) หลังสถานะ หากผู้ใช้ใช้ไคลเอนต์แบบเบาพวกเขาไม่มี S และ S หรือแม้แต่ อย่างครบถ้วน แต่พวกเขามีรากก่อนรัฐ 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 ของ ETH ได้แบบเต็มรูปแบบ ซึ่งทำให้ทรัพยากรของไคลเอ็นต์น้อยมาก ในการเป็นไคลเอ็นต์ที่ยืนยันการดำเนินการของ ETH ได้แบบเต็มรูปแบบจริง ๆ ยังต้องทำงานในด้านฉันทามติเช่นกัน

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

มีความเกี่ยวข้องกับการวิจัยที่มีอยู่ในปัจจุบันอย่างไร

· EFPSE ZK-EVM (ถูกยกเลิกเนื่องจากมีตัวเลือกที่ดีกว่า)

· Zeth คือการทำงานโดยการคอมไพล์ EVM เข้ากับ RISC-0 ZK-VM

· ZK-EVM การตรวจสอบอย่างเป็นทางการ项目

ยังสามารถทำอะไรได้อีกบ้าง?

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

การ proof ที่ถูกต้องต้องรักษาให้แน่ใจว่า SNARK ตรวจสอบการคำนวณของ EVM จริง ๆ และไม่มีช่องโหว่ การเพิ่มความปลอดภัยด้วยเทคโนโลยีหลัก ๆ ที่สองคือ multi-validator และ formal verification multi-validator หมายถึงมีหลาย validity proof implementations ที่เขียนอิสระกันบอกได้เหมือนมีหลาย client ถ้าบล็อกถูกพิสูจน์โดย subset ขนาดใหญ่เพียงพอของ implementations เหล่านี้ client ก็จะยอมรับบล็อกนั้น formal verification เกี่ยวข้องกับการใช้เครื่องมือที่ใช้ธรรมชาติในการพิสูจน์ทฤษฎีคณิต เช่น Lean4 เพื่อพิสูจน์ว่า validity proof ยอมรับเฉพาะการดำเนินการที่ถูกต้องตามข้อกำหนดของ EVM ที่ต่ำกว่า (เช่น EVM K ซีเมนติกหรือ ETH ซีเมนติกของชั้นการดำเนินการของ ETH ที่เขียนด้วย python (EELS))

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

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

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

· ระบบการพิสูจน์เอกลักษณ์ที่ปรับปรุง - ระบบการพิสูจน์เอกลักษณ์ใหม่เช่น Orion, Binius, GRK และข้อมูลอื่น ๆ อาจทำให้เวลาการตรวจสอบการคำนวณทั่วไปลดลงอีกครั้ง

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

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

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

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

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

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

· การพิสูจน์แบบพร็อกทอลที่จำเป็นต้องพิสูจน์ว่าส่วนต่าง ๆ ของระบบสามารถ "แชร์หน่วยความจำ" (เช่นตารางค้นหา) โดยเรารู้ว่าเทคโนโลยีเช่นนี้มีอยู่แต่ต้องการที่จะนำมาใช้งาน

· เราต้องทำการวิเคราะห์เพิ่มเติมเพื่อหาชุดการเปลี่ยนแปลงต้นทุนแก๊สที่เหมาะสมเพื่อลดเวลาการตรวจสอบในสถานการณ์ที่แย่ที่สุดอย่างมาก

เราต้องทำงานเพิ่มเติมในระบบการพิสูจน์

ความเป็นไปได้ของค่าใช้จ่ายคือ:

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

· การกระจายอำนาจ vs การรับรองเวลาของอุปกรณ์: ชุมชนต้องตกลงกันเกี่ยวกับ 'ข้อมูลกำหนด' สำหรับอุปกรณ์การรับรองที่เป็นเป้าหมาย การต้องการให้ผู้รับรองเป็นองค์กรขนาดใหญ่ได้หรือไม่? เราหวังว่าโน้ตบุ๊กสเปคสูงสามารถรับรองบล็อกเชน ETH ของเนื้อหาใน 4 วินาทีได้หรือไม่? หรืออยู่ระหว่างทั้งสอง?

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

01928374656574839201

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

· การพิสูจน์ความถูกต้องของ L2 (หรือ "ZK rollup")

· วิธีการพิสูจน์แฮชทวีตสตาร์คไบนารีที่ไม่มีสถานะ

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

นอกจากนี้ EVM validity proof ของ L1 สามารถเพิ่มค่าของการจำกัดแก๊สของ L1 อย่างมาก

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

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

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

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

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

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

· ECADD（ใช้สำหรับการตรวจสอบลายเซ็น BLS）

· การจับคู่ (สําหรับการตรวจสอบลายเซ็น BLS)

· ค่าแฮช SHA256 (สำหรับอ่านและอัปเดตสถานะ)

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

วิธีการทํางานของการรวม BLS: การตรวจสอบลายเซ็นทั้งหมดต้องใช้ ECADD เพียงหนึ่งรายการต่อผู้เข้าร่วมหนึ่งคน ไม่ใช่ ECMUL หนึ่งคน แต่ 30,000 ECADDs ยังคงเป็นหลักฐานจํานวนมาก

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

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

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

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

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

· การเปลี่ยนแปลงของฟังก์ชันแฮช: ตอนนี้เราใช้ฟังก์ชันแฮช SHA256 "เต็ม" ดังนั้นเนื่องจากเหตุผลในการเติมข้อมูล การเรียกใช้ทุกครั้งจะต้องสอดคล้องกับการเรียกใช้ฟังก์ชันบีบอัดในระดับล่างสองครั้ง หากเราเปลี่ยนเป็นใช้ฟังก์ชันบีบอัด SHA256 เราอาจจะได้รับผลตอบแทน 2 เท่า หากเราเปลี่ยนเป็นใช้ Poseidon เราอาจจะได้รับผลตอบแทนถึง 100 เท่า ซึ่งจะแก้ไขปัญหาทั้งหมดของเรา (อย่างน้อยในเชิงแฮช): แต่ละวินาที 170 ล้านแฮช (54MB) แม้กระทั่งหนึ่งล้านบันทึกการตรวจสอบ ก็สามารถ "อ่าน" ได้ในไม่กี่วินาที

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

· การรวมลายเซ็น: Any high-performance signature aggregation scheme will involve some kind of recursive proof, with different โหนนด in the network performing intermediate attestation of a subset of signatures. This naturally offloads the work of proof among multiple โหนนด in the network, thus greatly reducing the workload of the "ultimate prover".

· โครงการลายเซ็นอื่น ๆ: สำหรับลายเซ็น Lamport+ Merkle เราต้องการ 256 + 32 ค่าแฮชเพื่อยืนยันลายเซ็น; คูณด้วย 32768 ผู้ลงนาม จะได้ 9437184 ค่าแฮช หลังจากปรับปรุงโครงการลายเซ็น สามารถปรับปรุงผลลัพธ์นี้ได้อย่างมีประสิทธิภาพโดยต่อเนื่อง หากเราใช้ Poseidon สิ่งนี้สามารถพิสูจน์ได้ในช่องเสียบเดียว แต่ในความเป็นจริง การใช้โครงการรวมแบบตามลำดับจะเร็วกว่า

มีความเกี่ยวข้องกับการวิจัยที่มีอยู่ในปัจจุบันอย่างไร

· Ethereum ฉันทามติพิสูจน์ที่เรียบง่าย (สำหรับคณะกรรมการซิงโครไนซ์เท่านั้น)

· Helios ใน SP1 ที่เรียบง่าย

· สรุป BLS12-381 ที่เตรียมการ

· การตรวจสอบลายเซ็นชุด BLS ที่พึงพอใจจาก Halo2

01928374656574839201

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

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

มันมีการปฏิสัมพันธ์กับส่วนอื่น ๆ ของแผนที่เส้นทางอย่างไร?

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

01928374656574839201