บทความใหม่ของ Vitaliks: อนาคตที่เป็นไปได้ของ Ethereum, The Verge

ชื่อเรื่องเดิม: อนาคตที่เป็นไปได้ของโปรโตคอล 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 สำหรับคำติชมและคำวิจารณ์ของพวกเขา

หนึ่งในคุณสมบัติที่ทรงพลังที่สุดของบล็อคเชนก็คือใครๆ ก็สามารถรันโหนดบนคอมพิวเตอร์ของตนและตรวจสอบความถูกต้องของบล็อคเชนได้ แม้ว่าโหนดทั้งหมด 9,596 โหนดที่รันเชนคอนเซนซัส (PoW, PoS) จะตกลงทันทีที่จะเปลี่ยนกฎและเริ่มผลิตบล็อคตามกฎใหม่ แต่ทุกคนที่ใช้โหนดที่ตรวจสอบได้อย่างสมบูรณ์จะปฏิเสธที่จะยอมรับเชน นักขุดเหรียญที่ไม่ได้เป็นส่วนหนึ่งของกลุ่มสมคบคิดนี้จะบรรจบกันบนเชนที่ยังคงปฏิบัติตามกฎเดิมและสร้างบนเชนนี้ต่อไปโดยอัตโนมัติ และผู้ใช้ที่ผ่านการตรวจสอบอย่างสมบูรณ์จะปฏิบัติตามเชนนี้

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

แผนงานของ The Verge ในปี 2023

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

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

The Verge: เป้าหมายหลัก

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

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

ในบทนี้

• ลูกค้าไร้รัฐ: Verkle หรือ STARKs?

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

• หลักฐานการพิสูจน์ความถูกต้องตามฉันทามติ

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

เรากำลังพยายามแก้ไขปัญหาอะไร?

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

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

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

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

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

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

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

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

30000000 แก๊ส / 2400 (ค่าอ่านบัญชีเย็น) * (5 * 488 + 24000) = 330000000 ไบต์

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

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

ต้นเวอร์เคิล

ต้นไม้ 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 ซึ่งสอดคล้องกับข้อมูลยืนยันในกรณีที่เลวร้ายที่สุดในปัจจุบัน

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

STARKed ไบนารีแฮชทรี

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

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

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

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

2. ใช้ฟังก์ชันแฮชที่อนุรักษ์นิยมมากขึ้น เช่น SHA 256 หรือ BLAKE

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

พยานกรณีการใช้งานนอกเหนือจากการตรวจสอบบล็อก

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

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

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

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

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

มีความเชื่อมโยงกับงานวิจัยที่มีอยู่อย่างไร?

• ต้นเวอร์เคิล

• กระดาษต้นฉบับของ John Kuszmaul บนต้น Verkle

• สตาร์คแวร์

• กระดาษโพไซดอน 2

• Ajtai (ฟังก์ชันแฮชด่วนทางเลือกที่ใช้พื้นฐานจากความแข็งของโครงตาข่าย)

• เวร์เคิล.อินโฟ

สามารถทำอะไรได้อีก?

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

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

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

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

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

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

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

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

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

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

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

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

หากระบบพิสูจน์ไม่มีประสิทธิภาพเพียงพอในกรณีที่เลวร้ายที่สุด เราก็สามารถทดแทนข้อบกพร่องนี้ด้วยเครื่องมือที่ไม่คาดคิดอย่างก๊าซหลายมิติได้ เช่น ขีดจำกัดก๊าซแยกต่างหากสำหรับ (i) ข้อมูลการโทร (ii) การคำนวณ (iii) การเข้าถึงสถานะ และทรัพยากรอื่นๆ ที่แตกต่างกัน ก๊าซหลายมิติเพิ่มความซับซ้อน แต่ในทางกลับกัน จะจำกัดอัตราส่วนระหว่างกรณีเฉลี่ยและกรณีที่เลวร้ายที่สุดอย่างเข้มงวดยิ่งขึ้น ด้วยก๊าซหลายมิติ จำนวนสูงสุดของสาขาที่จำเป็นต้องพิสูจน์ในทางทฤษฎีอาจลดลงจาก 12,500 เป็น 3,000 ตัวอย่างเช่น ซึ่งจะทำให้ BLAKE 3 เพียงพอ (อย่างแทบ) แม้กระทั่งในปัจจุบัน

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

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

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

มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?

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

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

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

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

เรากำลังพยายามแก้ไขปัญหาอะไร?

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

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

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

ตามทางการ ในข้อกำหนดของ Ethereum 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

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

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

มีความเชื่อมโยงกับงานวิจัยที่มีอยู่อย่างไร?

• EFPSE ZK-EVM (ปัจจุบันหยุดจำหน่ายแล้วเนื่องจากมีตัวเลือกที่ดีกว่า)

• Zeth ซึ่งทำงานโดยการคอมไพล์ EVM ลงใน RISC-0 ZK-VM

• โครงการตรวจสอบอย่างเป็นทางการของ ZK-EVM

สามารถทำอะไรได้อีก?

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

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

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

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

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

• การเพิ่มประสิทธิภาพระบบพิสูจน์ – ระบบพิสูจน์ใหม่ๆ เช่น Orion, Binius, GRK และอื่นๆ อีกมากมาย น่าจะส่งผลให้เวลาในการตรวจสอบสำหรับการคำนวณวัตถุประสงค์ทั่วไปลดลงอย่างมีนัยสำคัญอีกครั้ง

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

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

– การแทนที่โครงสร้างข้อมูล – นอกจากการแทนที่สถานะ trie ด้วยสิ่งที่เป็นมิตรกับ 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 Rollup)

• วิธีการพิสูจน์แฮชไบนารี STARK แบบไร้สถานะ

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

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

หลักฐานการพิสูจน์ความถูกต้องตามฉันทามติ

เรากำลังพยายามแก้ไขปัญหาอะไร?

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

การสร้างฉันทามติจะง่ายกว่า EVM มาก แต่ความท้าทายคือเราไม่มีคอนโวลูชั่น L2 EVM ดังนั้นงานส่วนใหญ่จึงต้องทำอยู่แล้ว ดังนั้นการนำฉันทามติ Ethereum แบบ Proof-of-Scratch ไปใช้ต้องเริ่มต้นใหม่ตั้งแต่ต้น แม้ว่าระบบ Proof-of-Scratch เองจะเป็นความพยายามร่วมกันที่สามารถสร้างบนระบบนี้ได้ก็ตาม

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

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

• ECADD (สำหรับตรวจสอบลายเซ็น BLS)

• การจับคู่ (เพื่อยืนยันลายเซ็น BLS)

• ค่าแฮช SHA 256 (ใช้ในการอ่านและอัปเดตสถานะ)

ในแต่ละบล็อก เราจำเป็นต้องพิสูจน์ BLS 12-381 ECADD จำนวน 1-16 รายการต่อผู้ตรวจสอบ (อาจมากกว่าหนึ่งรายการ เนื่องจากลายเซ็นอาจรวมอยู่ในชุดหลายชุด) ซึ่งสามารถชดเชยได้ด้วยเทคนิคการคำนวณล่วงหน้าแบบย่อย ดังนั้นเราจึงกล่าวได้ว่าผู้ตรวจสอบแต่ละรายจำเป็นต้องพิสูจน์ BLS 12-381 ECADD เพียงรายการเดียวเท่านั้น ปัจจุบันมีลายเซ็นผู้ตรวจสอบ 30,000 รายการต่อสล็อต ในอนาคต เมื่อบรรลุจุดสิ้นสุดของสล็อตเดียวแล้ว อาจมีการเปลี่ยนแปลงในสองทิศทาง: หากเราใช้วิธีการบรูทฟอร์ซ จำนวนผู้ตรวจสอบต่อสล็อตอาจเพิ่มขึ้นเป็น 1 ล้านรายการ ในขณะเดียวกัน หากใช้ Orbit SSF จำนวนผู้ตรวจสอบจะยังคงอยู่ 32,768 รายการ หรืออาจลดลงเหลือ 8,192 รายการก็ได้

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

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

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

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

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

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

• การเปลี่ยนแปลงในฟังก์ชันแฮช: ตอนนี้เรากำลังใช้ฟังก์ชันแฮช SHA 256 เต็มรูปแบบ ดังนั้นการเรียกแต่ละครั้งจะจับคู่กับการเรียกสองครั้งไปยังฟังก์ชันการบีบอัดพื้นฐานเนื่องจากการแพดดิ้ง เราอาจได้รับกำไรอย่างน้อย 2 เท่าโดยใช้การบีบอัด SHA 256 แทน เราอาจได้รับกำไร 100 เท่าโดยใช้ Poseidon แทน ดังนั้นจึงแก้ปัญหาทั้งหมดของเราได้อย่างหมดจด (อย่างน้อยก็ในแง่ของอัตราแฮช): ที่อัตราแฮช 1.7 ล้านต่อวินาที (54 MB) แม้แต่บันทึกการตรวจสอบหนึ่งล้านรายการก็สามารถอ่านลงในหลักฐานได้ภายในไม่กี่วินาที

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

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

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

มีความเชื่อมโยงกับงานวิจัยที่มีอยู่อย่างไร?

• หลักฐานยืนยันฉันทามติของ Ethereum อย่างกระชับ (เฉพาะคณะกรรมการที่ซิงโครไนซ์เท่านั้น)

• Helios ใน SP 1 ขนาดกะทัดรัด

• การคอมไพล์เบื้องต้น BLS 12-381 แบบย่อ

• การตรวจสอบลายเซ็นรวมของ BLS บนพื้นฐานของ Halo 2

งานที่ยังต้องทำมีอะไรบ้างและจะเลือกอย่างไร:

ในความเป็นจริงแล้ว เราต้องใช้เวลาหลายปีกว่าจะได้หลักฐานยืนยันความถูกต้องของ Ethereum consensus ซึ่งก็เท่ากับเวลาที่เราใช้ในการบรรลุ single-slot finality, Orbit, แก้ไขอัลกอริทึมลายเซ็น และวิเคราะห์ความปลอดภัยที่จำเป็นเพื่อให้มีความมั่นใจเพียงพอที่จะใช้ฟังก์ชันแฮชที่รุนแรงเช่น Poseidon ดังนั้น แนวทางที่สมเหตุสมผลที่สุดคือการแก้ปัญหาอื่นๆ เหล่านี้และพิจารณาความเป็นมิตรของ STARK ขณะแก้ไขปัญหาเหล่านี้

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

มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?

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

บทความนี้มีที่มาจากอินเทอร์เน็ต: บทความใหม่ของ Vitaliks: อนาคตที่เป็นไปได้ของ Ethereum, The Verge

ที่เกี่ยวข้อง: ซูเปอร์สตาร์ที่ตกอับ: ย้อนดูการจับกุมบุคคลสำคัญในวงการสกุลเงินดิจิทัล

บทนำ: การจับกุม Pavel Durov ในเดือนสิงหาคม 2024 Pavel Durov ผู้ก่อตั้ง Telegram ถูกจับกุมในปารีส ซึ่งเป็นเหตุการณ์ที่ดึงดูดความสนใจและการอภิปรายอย่างกว้างขวางในชุมชนสกุลเงินดิจิทัล การจับกุม Durov ไม่เพียงแต่ส่งผลกระทบเชิงลบโดยตรงต่อโครงการ Toncoin เท่านั้น แต่ยังทำให้ประสิทธิภาพการตลาดลดลงอย่างรวดเร็ว ทั้งราคาและปริมาณการซื้อขายลดลงอย่างรวดเร็ว แต่ยังเน้นย้ำถึงความเสี่ยงทางกฎหมายและข้อบังคับในด้านสกุลเงินดิจิทัลอีกด้วย Toncoin เป็นโครงการสกุลเงินดิจิทัลที่พัฒนาบนพื้นฐานของ Telegram Open Network (TON) ซึ่งมีเป้าหมายเพื่อมอบเครือข่ายบล็อคเชนความเร็วสูง ปลอดภัย และปรับขนาดได้ อย่างไรก็ตาม การจับกุม Durov ในข้อสงสัยว่ามีส่วนเกี่ยวข้องในธุรกรรมที่ผิดกฎหมาย รวมถึงการครอบครองและเผยแพร่สื่อลามกเด็ก ทำให้อนาคตของโครงการนี้มืดมน หลังจากข่าวการจับกุม Durov เครมลินก็ประกาศอย่างรวดเร็วว่า...