ชื่อเรื่องต้นฉบับ: การทำให้ L1 ง่ายขึ้น
เขียนโดย : วิทาลิก
Ethereum มีเป้าหมายที่จะเป็นสมุดบัญชีของโลก: แพลตฟอร์มสำหรับจัดเก็บทรัพย์สินและบันทึกของอารยธรรม และเป็นชั้นพื้นฐานสำหรับการเงิน การกำกับดูแล การตรวจสอบข้อมูลที่มีค่าสูง และอื่นๆ อีกมากมาย สิ่งนี้ต้องมีเงื่อนไขสองประการ: ความสามารถในการปรับขนาดและความยืดหยุ่น ฮาร์ดฟอร์ก Fusaka มีเป้าหมายที่จะเพิ่มพื้นที่ที่มีให้สำหรับข้อมูลเลเยอร์ 2 (L2) มากขึ้น 10 เท่า และแผนงานปัจจุบันที่เสนอในปี 2026 ยังเสนอการขยายที่สำคัญที่คล้ายคลึงกันสำหรับเลเยอร์ 1 (L1) อีกด้วย ในเวลาเดียวกัน Ethereum ได้ทำการควบรวมกิจการและอัพเกรดเป็นกลไก Proof of Stake ความหลากหลายของไคลเอนต์เพิ่มขึ้นอย่างรวดเร็ว และการทำงานเกี่ยวกับการตรวจสอบการพิสูจน์ความรู้เป็นศูนย์ (ZK Verifiability) และการต้านทานการประมวลผลแบบควอนตัมก็มีความก้าวหน้าเช่นกัน และแอปพลิเคชันต่างๆ ก็มีความแข็งแกร่งมากขึ้น
บทความนี้มุ่งเน้นที่ด้านของความยืดหยุ่นซึ่งมีความสำคัญเท่าเทียมกันแต่บ่อยครั้งมักถูกประเมินต่ำไป (ซึ่งส่งผลต่อการปรับขนาดในท้ายที่สุด): ความเรียบง่ายของโปรโตคอล
สิ่งที่ดีอย่างหนึ่งเกี่ยวกับ Bitcoin ก็คือโปรโตคอลของมันนั้นเรียบง่ายและสวยงามมาก
บล็อคเชนประกอบด้วยบล็อกหลายบล็อก โดยแต่ละบล็อกเชื่อมต่อกับบล็อกก่อนหน้าผ่านค่าแฮช ความถูกต้องของบล็อกจะได้รับการตรวจสอบผ่านกลไกการพิสูจน์การทำงาน ซึ่งจะตรวจยืนยันว่าหลักไม่กี่หลักแรกของค่าแฮชเป็นศูนย์หรือไม่ แต่ละบล็อกประกอบด้วยธุรกรรมหลายรายการ ซึ่งใช้เหรียญที่สร้างจากการขุดหรือจากผลลัพธ์ของธุรกรรมก่อนหน้า นี่คือกลไกหลักของโปรโตคอล Bitcoin แม้แต่นักเรียนมัธยมต้นที่ฉลาดก็สามารถเข้าใจโปรโตคอลได้โดยสมบูรณ์ และโปรแกรมเมอร์ก็สามารถเขียนไคลเอนต์สำหรับโปรเจ็กต์เสริมได้อีกด้วย
การรักษาโปรโตคอลให้เรียบง่ายมีข้อได้เปรียบสำคัญสำหรับ Bitcoin หรือ Ethereum ที่จะกลายเป็นเลเยอร์ฐานกลางที่ได้รับการยอมรับทั่วโลก:
- โปรโตคอลที่เรียบง่ายนั้นวิเคราะห์ได้ง่ายกว่า ซึ่งสามารถดึงดูดผู้เข้าร่วมให้เข้าร่วมในการวิจัย พัฒนา และกำกับดูแลโปรโตคอลได้มากขึ้น ในขณะเดียวกันก็ลดความเสี่ยงจากการผูกขาดทางเทคโนโลยี
- การลดความซับซ้อนของโครงสร้างโปรโตคอลช่วยลดความพยายามในการพัฒนาที่จำเป็นในการเชื่อมต่อกับโครงสร้างพื้นฐานใหม่ เช่น ไคลเอนต์ ผู้พิสูจน์ เครื่องมือบันทึก และเครื่องมือพัฒนาอื่นๆ ลงได้อย่างมาก
- การออกแบบโปรโตคอลที่เรียบง่ายช่วยลดต้นทุนการบำรุงรักษาในระยะยาวได้อย่างมีประสิทธิภาพ
- ความเสี่ยงของการเกิดช่องโหว่ร้ายแรงในข้อกำหนดโปรโตคอลและการใช้งานลดลงอย่างมาก และสามารถตรวจสอบความปลอดภัยของระบบได้ง่ายยิ่งขึ้น
- พื้นผิวการโจมตีทางสังคมที่ลดลง: การปรับปรุงส่วนประกอบทำให้ระบบป้องกันการแทรกซึมของกลุ่มผลประโยชน์พิเศษได้ง่ายขึ้น และปรับปรุงความปลอดภัยโดยรวม
ในอดีต Ethereum มักล้มเหลวในการนำหลักการความเรียบง่ายมาใช้ในการออกแบบโปรโตคอล (ส่วนหนึ่งเป็นเพราะการตัดสินใจของตัวเอง) ซึ่งส่งผลโดยตรงต่อต้นทุนการวิจัยและพัฒนาที่สูง ความเสี่ยงด้านความปลอดภัยที่เกิดขึ้นบ่อยครั้ง และวัฒนธรรมการวิจัยและพัฒนาแบบปิด รากเหง้าของปัญหาเหล่านี้มักจะเกิดจากการแสวงหาผลกำไรในระยะสั้นซึ่งได้รับการพิสูจน์แล้วในทางปฏิบัติว่าไม่ได้ผล บทความนี้จะอธิบายว่า Ethereum สามารถบรรลุความเรียบง่ายของโปรโตคอลให้ใกล้เคียงกับ Bitcoin ได้อย่างไรในอีกห้าปีข้างหน้า
การลดความซับซ้อนของชั้นฉันทามติ
การจำลองความสิ้นสุดสามช่องใน 3sf-mini (ชื่อรหัสสำหรับเครือข่ายทดสอบ Ethereum)
โซลูชั่นเลเยอร์ฉันทามติใหม่ (เดิมชื่อ "Beam Chain") มีเป้าหมายเพื่อบูรณาการผลการวิจัยในทศวรรษที่ผ่านมาในสาขาต่างๆ เช่น ทฤษฎีฉันทามติ การพิสูจน์ความรู้เป็นศูนย์ (ZK-SNARK) เศรษฐศาสตร์สเตกกิ้ง ฯลฯ เพื่อสร้างกลไกฉันทามติที่เหมาะสมที่สุดสำหรับการพัฒนา Ethereum ในระยะยาว เมื่อเปรียบเทียบกับบีคอนเชนที่มีอยู่แล้ว โซลูชันนี้มีฟีเจอร์ที่เรียบง่ายกว่าอย่างมาก ซึ่งสะท้อนให้เห็นในด้านต่างๆ ต่อไปนี้:
- นวัตกรรมสถาปัตยกรรมความสมบูรณ์แบบแบบ 3 ช่อง: กำจัดการแบ่งแนวคิดของช่องและยุคอิสระ ยกเลิกส่วนประกอบที่ซับซ้อน เช่น กลไกการหมุนเวียนคณะกรรมการและคณะกรรมการการซิงโครไนซ์ และลดความซับซ้อนของข้อกำหนดโปรโตคอลอย่างมาก การใช้งานหลักๆ ต้องใช้โค้ดเพียงประมาณ 200 บรรทัด ซึ่งให้ระดับความปลอดภัยที่เกือบเหมาะสมที่สุดเมื่อเทียบกับโปรโตคอล Gasper
- การจัดการโหนดการตรวจสอบที่ได้รับการปรับให้เหมาะสม: โดยการจำกัดจำนวนโหนดการตรวจสอบที่ใช้งานอยู่ กฎการเลือกจุดแยกสามารถนำไปใช้ได้ในวิธีที่ง่ายกว่าพร้อมทั้งยังมั่นใจในความปลอดภัยของระบบอีกด้วย
- การอัปเกรดโปรโตคอลการรวม: กลไกการรวมที่ใช้ STARK ช่วยให้โหนดใดๆ ก็ตามสามารถมีบทบาทในการรวมได้ โดยหลีกเลี่ยงการพึ่งพาความน่าเชื่อถือในตัวรวบรวมและการสิ้นเปลืองทรัพยากรที่เกิดจากบิตฟิลด์ที่เกิดซ้ำ แม้ว่าการเข้ารหัสแบบรวมจะมีความซับซ้อนค่อนข้างมาก แต่ลักษณะที่มีการหุ้มไว้อย่างเข้มงวดจะช่วยลดความเสี่ยงในระบบได้อย่างมาก
- การปรับปรุงสถาปัตยกรรมเครือข่าย P2P: การเพิ่มประสิทธิภาพสองประการข้างต้นทำให้สามารถสร้างสถาปัตยกรรมเครือข่ายเพียร์ทูเพียร์ที่เรียบง่ายและมีประสิทธิภาพมากยิ่งขึ้น
- การสร้างกระบวนการตรวจสอบใหม่: ออกแบบกลไกการรับ ออก การถอน การโยกย้ายคีย์ และการลงโทษความขี้เกียจของโหนดการตรวจสอบใหม่ ในขณะที่ลดจำนวนโค้ด ชี้แจงกลไกการป้องกันของพารามิเตอร์หลัก (เช่น ช่วงเวลาเชิงอัตนัยที่อ่อนแอ)
- ข้อได้เปรียบทางเทคนิค: ลักษณะการแยกสัมพันธ์ของเลเยอร์ฉันทามติและเลเยอร์การดำเนินการ EVM ให้พื้นที่ทางเทคนิคที่มากขึ้นสำหรับการเพิ่มประสิทธิภาพอย่างต่อเนื่อง เมื่อเปรียบเทียบแล้ว การปรับปรุงที่คล้ายคลึงกันในระดับการดำเนินการจะเผชิญกับความท้าทายที่ยิ่งใหญ่กว่า
ลดความซับซ้อนของชั้นการดำเนินการ
Ethereum Virtual Machine (EVM) ยังคงเติบโตในด้านความซับซ้อน โดยมีความซับซ้อนหลายประการที่พิสูจน์แล้วว่าไม่จำเป็น (และในหลายๆ กรณีเป็นความผิดของฉันเอง): VM 256 บิตที่ได้รับการปรับแต่งให้เหมาะสมเกินไปสำหรับอัลกอริทึมการเข้ารหัสเฉพาะซึ่งปัจจุบันไม่เกี่ยวข้องกันมากขึ้นเรื่อยๆ และสัญญาที่คอมไพล์ไว้ล่วงหน้าซึ่งออกแบบมามากเกินไปสำหรับกรณีการใช้งานเดียวที่มีการใช้งานจริงน้อยมาก
การพยายามแก้ไขปัญหาที่มีอยู่ด้วยการแก้ไขแบบทีละส่วนไม่สามารถทำได้อีกต่อไป การลบโอปโค้ด SELFDESTRUCT ถือเป็นความพยายามที่ยิ่งใหญ่ซึ่งให้ประโยชน์ได้จำกัด และการอภิปรายล่าสุดเกี่ยวกับ EOF ได้เน้นย้ำถึงความยากลำบากในการทำการเปลี่ยนแปลงเพิ่มเติมใน VM
อีกทางเลือกหนึ่ง ฉันได้เสนอแนวทางการเปลี่ยนแปลงที่รุนแรงยิ่งขึ้นเมื่อไม่นานนี้: แทนที่จะปรับเปลี่ยน EVM ในระดับปานกลาง (แต่ยังคงก่อกวน) เพื่อแลกกับการปรับปรุงประสิทธิภาพ 1.5 เท่า จะดีกว่าถ้าเปลี่ยนโดยตรงไปที่สถาปัตยกรรมเครื่องเสมือนใหม่ที่ดีกว่าอย่างมากเพื่อให้ประสิทธิภาพเพิ่มขึ้น 100 เท่า เช่นเดียวกับ The Merge เราลดจำนวนการเปลี่ยนแปลงที่สำคัญลง แต่เพิ่มมูลค่าเชิงกลยุทธ์ของการเปลี่ยนแปลงแต่ละครั้ง โดยเฉพาะอย่างยิ่งขอแนะนำให้แทนที่ EVM ที่มีอยู่ด้วยสถาปัตยกรรม RISC-V หรือเครื่องเสมือนที่ใช้โดยโปรแกรมพิสูจน์ Ethereum ZK การเปลี่ยนแปลงนี้จะส่งผลให้เกิด:
- การปรับปรุงประสิทธิภาพอย่างปฏิวัติวงการ: ในสภาพแวดล้อมการพิสูจน์ ZK สัญญาอัจฉริยะสามารถทำงานบนสถาปัตยกรรมเป้าหมายได้โดยตรงโดยไม่จำเป็นต้องใช้โปรแกรมแปลความสามารถ ข้อมูลที่กระชับแสดงให้เห็นว่าประสิทธิภาพสามารถปรับปรุงได้มากกว่า 100 เท่าในสถานการณ์ส่วนใหญ่
- สถาปัตยกรรมที่เรียบง่ายอย่างยิ่ง: ข้อกำหนด RISC-V ได้รับการปรับปรุงอย่างมากเมื่อเทียบกับ EVM และโซลูชันตัวเลือกอื่นๆ (เช่น Cairo) ยังมีคุณลักษณะที่เรียบง่ายอีกด้วย
- สืบทอดข้อได้เปรียบหลักของ EOF: รวมถึงการจัดการการแบ่งส่วนโค้ด การรองรับการวิเคราะห์แบบคงที่ที่เป็นมิตรมากขึ้น และขีดจำกัดความจุโค้ดที่มากขึ้น
- การขยายเครื่องมือของนักพัฒนา: Solidity และ Vyper สามารถรองรับสถาปัตยกรรมใหม่ๆ ได้โดยการเพิ่มการคอมไพล์แบ็คเอนด์ใหม่ หากเลือก RISC-V นักพัฒนาภาษาหลักสามารถพอร์ตโค้ดที่มีอยู่ได้โดยตรง
- การเพิ่มประสิทธิภาพสัญญาที่คอมไพล์ไว้ล่วงหน้า: ฟังก์ชันที่คอมไพล์ไว้ล่วงหน้าส่วนใหญ่จะไม่จำเป็นอีกต่อไป โดยคงไว้เพียงการดำเนินการเส้นโค้งวงรีที่ได้รับการเพิ่มประสิทธิภาพสูงเท่านั้น (ซึ่งอาจถูกกำจัดได้ด้วยการพัฒนาการประมวลผลแบบควอนตัม)
ความท้าทายหลักก็คือว่า เมื่อเทียบกับโซลูชัน EOF ซึ่งสามารถนำไปใช้งานได้ทันที จะต้องใช้เวลานานกว่าที่เครื่องเสมือนใหม่จะเกิดประโยชน์ต่อนักพัฒนา โซลูชันการเปลี่ยนผ่านระยะสั้นสามารถทำได้โดยดำเนินการปรับปรุง EVM ที่มีค่าสูงบางอย่างพร้อมกัน (เช่น การเพิ่มขีดจำกัดขนาดโค้ดสัญญาและเพิ่มประสิทธิภาพชุดคำสั่ง DUP/SWAP)
การเปลี่ยนแปลงนี้จะทำให้สถาปัตยกรรมเครื่องเสมือนเรียบง่ายขึ้นอย่างมาก คำถามหลักคือ: จะจัดการกับระบบนิเวศ EVM ที่มีอยู่อย่างเหมาะสมได้อย่างไร
กลยุทธ์ความเข้ากันได้แบบย้อนกลับสำหรับการโยกย้ายเครื่องเสมือน
ความท้าทายที่ใหญ่ที่สุดในการลดความซับซ้อน (หรือเพิ่มประสิทธิภาพโดยไม่เพิ่มความซับซ้อน) ในส่วนใดๆ ของ EVM คือการรักษาสมดุลระหว่างการบรรลุเป้าหมายที่ต้องการกับการรักษาความเข้ากันได้แบบย้อนหลังสำหรับแอปพลิเคชันที่มีอยู่
ก่อนอื่น สิ่งสำคัญคือต้องชัดเจนว่าไม่มีมาตรฐานเดียวในการกำหนดว่า "ฐานโค้ด Ethereum" คืออะไร แม้แต่สำหรับไคลเอนต์เพียงรายเดียวก็ตาม
เป้าหมายคือลดพื้นที่สีเขียวให้เหลือน้อยที่สุด: ตรรกะที่โหนดจำเป็นต้องทำงานเพื่อเข้าร่วมในการบรรลุฉันทามติของ Ethereum รวมถึงการคำนวณสถานะปัจจุบัน การสร้างและการตรวจสอบหลักฐาน FOCIL (หมายเหตุ: ต้องยืนยันว่าเป็นคำย่อทางวิชาชีพหรือไม่) และกระบวนการสร้างบล็อก "พื้นฐาน"
พื้นที่สีส้มไม่สามารถลดขนาดได้: หากฟังก์ชันการทำงานของเลเยอร์การดำเนินการ (ไม่ว่าจะเป็นเครื่องเสมือน สัญญาที่คอมไพล์ล่วงหน้า หรือกลไกอื่น) ถูกนำออกจากข้อกำหนดโปรโตคอลหรือฟังก์ชันการทำงานมีการเปลี่ยนแปลง ไคลเอนต์ที่จำเป็นต้องประมวลผลบล็อกประวัติจะต้องรักษาฟังก์ชันการทำงานนั้นไว้ แต่ไคลเอนต์ใหม่ (รวมทั้ง ZK-EVM หรือเครื่องมือตรวจสอบอย่างเป็นทางการ) สามารถละเลยส่วนนี้ได้เลย
พื้นที่สีเหลืองใหม่: อ้างอิงถึงโค้ดที่มีคุณค่าอย่างยิ่งสำหรับการวิเคราะห์ข้อมูลบนเชนปัจจุบันหรือการสร้างบล็อกที่เหมาะสมที่สุด แต่ไม่ใช่ส่วนหนึ่งของกลไกฉันทามติ ตัวอย่างทั่วไปคือ Etherscan และการสนับสนุนของผู้สร้างบล็อกบางส่วนสำหรับการดำเนินการของผู้ใช้ ERC-4337 หากฟังก์ชันหลักของ Ethereum (เช่น บัญชีภายนอก EOA และประเภทธุรกรรมเก่าต่างๆ ที่รองรับ) ถูกแทนที่ด้วยการใช้งาน RISC-V แบบบนเชน โค้ดฉันทามติจะถูกทำให้เรียบง่ายลงอย่างมาก แต่โหนดเฉพาะอาจยังคงต้องใช้โค้ดต้นฉบับสำหรับการแยกวิเคราะห์และประมวลผล
ความซับซ้อนในพื้นที่สีส้มและสีเหลืองถือเป็นความซับซ้อนอย่างแท้จริง และใครก็ตามที่ต้องการทำความเข้าใจโปรโตคอลสามารถข้ามไปได้เลย ส่วนการนำ Ethereum ไปใช้งานจริงนั้นสามารถละเว้นได้ นอกจากนี้ข้อบกพร่องของโค้ดในพื้นที่เหล่านี้ไม่ได้ก่อให้เกิดความเสี่ยงตามความเห็นพ้องต้องกัน ซึ่งหมายความว่าเมื่อเทียบกับความซับซ้อนของโค้ดในพื้นที่สีเขียวแล้ว ความซับซ้อนในพื้นที่สีส้มและสีเหลืองจะส่งผลกระทบเชิงลบต่อระบบโดยรวมต่ำกว่าอย่างมีนัยสำคัญ
แนวคิดการย้ายโค้ดจากพื้นที่สีเขียวไปยังพื้นที่สีเหลืองนั้นคล้ายกับโซลูชันทางเทคนิคของ Apple สำหรับการบรรลุความเข้ากันได้ย้อนหลังในระยะยาวผ่านเลเยอร์การแปล Rosetta
จำเป็นที่สัญญาที่คอมไพล์ไว้ล่วงหน้าที่พัฒนาขึ้นใหม่ทั้งหมดจะต้องมีการใช้งาน RISC-V แบบออนเชนมาตรฐาน ขั้นตอนนี้มีวัตถุประสงค์เพื่อส่งเสริมระบบนิเวศให้ค่อยๆ ปรับตัวเข้ากับสภาพแวดล้อมเครื่องเสมือน RISC-V (โดยใช้การโยกย้าย EVM ไปยัง RISC-V เป็นตัวอย่าง ซึ่งโซลูชันนี้ยังสามารถนำไปใช้กับการโยกย้าย EVM ไปยังไคโรหรือเครื่องเสมือนอื่นๆ ที่ดีกว่าได้อีกด้วย):
- รองรับการทำงานแบบคู่ขนานสำหรับเครื่องเสมือนคู่: รองรับเครื่องเสมือน RISC-V และ EVM ในระดับโปรโตคอลโดยตรง นักพัฒนาสามารถเลือกภาษาในการพัฒนาได้อย่างอิสระ และสัญญาที่เขียนในเครื่องเสมือนที่แตกต่างกันสามารถโต้ตอบกันได้อย่างราบรื่น
- สัญญาที่คอมไพล์ล่วงหน้าจะถูกแทนที่เป็นระยะ ๆ: ยกเว้นสำหรับการดำเนินการเส้นโค้งวงรีและอัลกอริทึมแฮช KECCAK (เนื่องมาจากข้อกำหนดการเพิ่มประสิทธิภาพที่เข้มงวดยิ่ง) สัญญาที่คอมไพล์ล่วงหน้าทั้งหมดจะถูกแทนที่ด้วยการใช้งาน RISC-V ผ่านทางฮาร์ดฟอร์ก
- การดำเนินการที่เฉพาะเจาะจงคือ: ในขณะลบสัญญาที่คอมไพล์ไว้ล่วงหน้าเดิม ให้แก้ไขโค้ดของที่อยู่ (โดยใช้โหมด DAO fork) จากสถานะว่างเปล่าไปเป็นการใช้งาน RISC-V ที่สอดคล้องกัน เนื่องจากสถาปัตยกรรม RISC-V นั้นมีความเรียบง่ายมาก แม้ว่าจะเสร็จสิ้นเพียงขั้นตอนนี้เท่านั้น ความซับซ้อนโดยรวมของระบบก็จะยังลดลง
- การปรับใช้ตัวแปล EVM แบบออนเชน: นำตัวแปล EVM มาใช้งานโดยอิงตาม RISC-V (เครื่องมือพิสูจน์ ZK ได้สนับสนุนการพัฒนาดังกล่าว) และปรับใช้แบบออนเชนเป็นสัญญาอัจฉริยะ หลายปีหลังจากการเปิดตัวครั้งแรก สัญญา EVM ที่มีอยู่จะถูกดำเนินการผ่านทางล่ามนี้ ช่วยให้สามารถเปลี่ยนผ่านไปยังเครื่องเสมือนใหม่ได้อย่างราบรื่น
การลดความซับซ้อนผ่านส่วนประกอบโปรโตคอลที่ใช้ร่วมกัน
การลดความซับซ้อนผ่านส่วนประกอบโปรโตคอลที่ใช้ร่วมกัน
หลังจากขั้นตอนที่ 4 เสร็จสมบูรณ์แล้ว "โซลูชันการนำ EVM ไปใช้งาน" จำนวนมากจะยังคงถูกเก็บรักษาไว้และนำไปใช้เพื่อเพิ่มประสิทธิภาพสถานการณ์ต่างๆ เช่น การสร้างบล็อก เครื่องมือสำหรับนักพัฒนา และการวิเคราะห์ข้อมูลบนเชน แต่การนำการใช้งานเหล่านี้จะไม่เป็นส่วนหนึ่งของข้อมูลจำเพาะฉันทามติหลักอีกต่อไป ในเวลานั้น กลไกการบรรลุฉันทามติของ Ethereum จะรองรับเฉพาะสถาปัตยกรรม RISC-V "โดยพื้นฐาน" เท่านั้น
ความเรียบง่ายผ่านส่วนประกอบโปรโตคอลที่ใช้ร่วมกัน
วิธีที่สามในการลดความซับซ้อนโดยรวมของโปรโตคอล (และเป็นวิธีที่ถูกประเมินต่ำที่สุด) คือการแบ่งปันมาตรฐานแบบรวมระหว่างเลเยอร์ต่าง ๆ ของสแต็กโปรโตคอลให้ได้มากที่สุด โดยทั่วไปแล้ว การใช้โปรโตคอลที่แตกต่างกันในโมดูลที่แตกต่างกันเพื่อให้ได้ฟังก์ชันเดียวกันนั้นไม่จำเป็นและไม่เกิดประโยชน์ใดๆ แต่รูปแบบการออกแบบนี้ยังคงแพร่หลายอยู่ สาเหตุหลักคือการขาดการประสานงานที่มีประสิทธิภาพระหว่างส่วนต่างๆ ของแผนงานโปรโตคอล ต่อไปนี้เป็นตัวอย่างของสถานการณ์เฉพาะที่ Ethereum สามารถลดความซับซ้อนได้โดยการเสริมความแข็งแกร่งให้กับการนำส่วนประกอบกลับมาใช้ซ้ำในทุกเลเยอร์
โซลูชันการเข้ารหัสการลบข้อมูลร่วมกันแบบรวมศูนย์
สามสถานการณ์การใช้งานของรหัสลบ:
- การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล: เมื่อไคลเอนต์ตรวจสอบว่าบล็อกได้รับการเผยแพร่หรือไม่ ไคลเอนต์จำเป็นต้องใช้การเข้ารหัสการลบเพื่อให้แน่ใจว่าข้อมูลมีความสมบูรณ์
- การออกอากาศ P2P ที่มีประสิทธิภาพ: โหนดสามารถยืนยันบล็อกได้เมื่อได้รับชาร์ด n/2 จาก n ชิ้น ทำให้บรรลุสมดุลที่เหมาะสมที่สุดระหว่างการลดเวลาแฝงและความซ้ำซ้อน
- การจัดเก็บประวัติแบบกระจาย: ข้อมูลประวัติของ Ethereum จะถูกแบ่งออกเป็นบล็อกข้อมูลหลายบล็อกเพื่อตอบสนองความต้องการต่อไปนี้:
- แต่ละบล็อกข้อมูลสามารถตรวจสอบได้อย่างอิสระ
- บล็อกข้อมูล n/2 ในกลุ่มใดๆ ก็สามารถกู้คืนบล็อกข้อมูล n/2 ที่เหลือได้
การออกแบบนี้ช่วยลดความเสี่ยงของการสูญเสียข้อมูลจุดเดียวได้อย่างมาก
หากใช้รหัสลบแบบเดียวกัน (เช่น รหัส Reed-Solomon รหัสเชิงเส้นแบบสุ่ม ฯลฯ) ในสามสถานการณ์ต่อไปนี้ จะนำมาซึ่งข้อดีที่สำคัญ:
- โค้ดกระชับ;
- ประสิทธิภาพที่เพิ่มขึ้น: เมื่อโหนดจำเป็นต้องดาวน์โหลดข้อมูลชาร์ด (แทนที่จะเป็นบล็อกที่สมบูรณ์) สำหรับสถานการณ์บางอย่าง ข้อมูลนั้นสามารถนำไปใช้โดยตรงในสถานการณ์อื่นๆ เพื่อหลีกเลี่ยงการส่งซ้ำ
- บล็อกข้อมูลในทุกสถานการณ์สามารถตรวจสอบได้อย่างสม่ำเสมอผ่านแฮชรูท
หากใช้รหัสการลบที่แตกต่างกัน จะต้องเป็นไปตามข้อกำหนดด้านความเข้ากันได้ ตัวอย่างเช่น สามารถใช้รหัส Reed-Solomon ในแนวนอนและรหัสสุ่มเชิงเส้นแนวตั้งพร้อมกันได้ในชาร์ดการสุ่มความพร้อมใช้งานของข้อมูล (DAS) แต่ทั้งสองรหัสจะต้องใช้งานบนฟิลด์จำกัดเดียวกัน
รูปแบบการซีเรียลไลเซชั่นแบบรวม
รูปแบบการซีเรียลไลเซชั่นปัจจุบันของ Ethereum ยังคงอยู่ในสถานะกึ่งปกติ — ข้อมูลสามารถซีเรียลไลเซชั่นใหม่เป็นรูปแบบใดก็ได้และเผยแพร่ โดยมีข้อยกเว้นเพียงอย่างเดียวคือแฮชลายเซ็นธุรกรรม ซึ่งต้องใช้รูปแบบปกติเพื่อให้แน่ใจว่ามีความสอดคล้องกันของแฮช อย่างไรก็ตามในอนาคตมาตรฐานรูปแบบการซีเรียลไลเซชันจะแข็งแกร่งยิ่งขึ้น โดยหลักๆ แล้วเป็นเพราะเหตุผลดังต่อไปนี้:
- การแยกบัญชี (EIP-7701): เนื้อหาธุรกรรมทั้งหมดจะมองเห็นได้อย่างสมบูรณ์บนเครื่องเสมือน (VM)
- สถานการณ์ขีดจำกัดก๊าซสูง: เมื่อขีดจำกัดก๊าซของบล็อกเพิ่มขึ้น ข้อมูลชั้นการดำเนินการจะต้องถูกเก็บไว้ในโครงสร้างแบบบล็อบ
- การแยกบัญชี (EIP-7701): เนื้อหาธุรกรรมทั้งหมดจะมองเห็นได้อย่างสมบูรณ์บนเครื่องเสมือน (VM)
- สถานการณ์ขีดจำกัดก๊าซสูง: เมื่อขีดจำกัดก๊าซของบล็อกเพิ่มขึ้น ข้อมูลชั้นการดำเนินการจะต้องถูกเก็บไว้ในโครงสร้างแบบบล็อบ
ขณะที่การเปลี่ยนแปลงนี้เกิดขึ้น เราจะมีโอกาสที่จะรวมมาตรฐานการเขียนแบบอนุกรมสำหรับสามเลเยอร์หลักของ Ethereum: (i) เลเยอร์การดำเนินการ (ii) เลเยอร์ฉันทามติ และ (iii) การเรียกใช้สัญญาอัจฉริยะ ABI
ขอแนะนำให้ใช้รูปแบบการเขียนซีเรียลไลเซชั่น SSZ ซึ่งมีข้อดีดังต่อไปนี้:
- การถอดรหัสที่มีประสิทธิภาพ รวมถึงสัญญาอัจฉริยะ สามารถถอดรหัสได้อย่างรวดเร็ว เนื่องมาจากการออกแบบ 4 ไบต์และการประมวลผลเงื่อนไขขอบเขตที่น้อยลง
- ชั้นฉันทามติมีการใช้กันอย่างแพร่หลายและถูกผนวกรวมเข้ากับชั้นฉันทามติอย่างลึกซึ้ง
- คล้ายคลึงกับ ABI ที่มีอยู่มาก ปรับและอัปเกรดเครื่องมือได้ง่าย
ปัจจุบันทีมงานเทคนิคที่เกี่ยวข้องกำลังส่งเสริมการโยกย้าย SSZ อย่างครอบคลุม ขอแนะนำให้ดำเนินการตามเส้นทางทางเทคนิคนี้ต่อไปในแผนการอัพเกรดครั้งต่อไปและขยายผลความสำเร็จที่มีอยู่
โครงสร้างต้นไม้ที่ใช้ร่วมกันแบบรวม
เมื่อทำการโยกย้ายจาก EVM ไปยัง RISC-V (หรือสถาปัตยกรรมเครื่องเสมือนที่มีประสิทธิภาพอื่น ๆ) ต้นไม้ Merkle Patricia ที่มี 6 สาขาจะกลายเป็นคอขวดด้านประสิทธิภาพที่ใหญ่ที่สุดสำหรับการพิสูจน์การดำเนินการแบบบล็อก (แม้ในสถานการณ์ปกติ) การเปลี่ยนไปใช้โครงสร้างแบบไบนารีทรีที่ใช้ฟังก์ชันแฮชที่ดีขึ้นจะช่วยปรับปรุงประสิทธิภาพการพิสูจน์และลดต้นทุนการจัดเก็บข้อมูลสำหรับโหนดน้ำหนักเบาและสถานการณ์การใช้งานอื่น ๆ ได้อย่างมาก
เมื่อดำเนินการโยกย้ายนี้ ควรใช้โครงสร้างแบบต้นไม้เดียวกันพร้อมกันเพื่อรวมเลเยอร์ฉันทามติและเลเยอร์การดำเนินการ วิธีนี้จะช่วยให้แน่ใจว่าสแต็ก Ethereum ทั้งหมด (รวมถึงเลเยอร์ฉันทามติและเลเยอร์การดำเนินการ) จะใช้ชุดตรรกะของโค้ดเดียวกันในการเข้าถึงและการแยกวิเคราะห์ข้อมูล
เส้นทางวิวัฒนาการจากสถานการณ์ปัจจุบันสู่เป้าหมาย
ความเรียบง่ายมีความคล้ายคลึงกับการกระจายอำนาจในหลายๆ ด้าน และทั้งสองอย่างนี้เป็นข้อกำหนดเบื้องต้นสำหรับการบรรลุถึงความยืดหยุ่นของระบบ การทำให้ความเรียบง่ายกลายเป็นคุณค่าหลักอย่างชัดเจนนั้นต้องอาศัยการเปลี่ยนแปลงทางวัฒนธรรม ประโยชน์ที่ได้รับมักจะไม่ปรากฏชัดเจนทันที ในขณะที่ประโยชน์ในระยะสั้นของการแสวงหาคุณสมบัติที่ซับซ้อนนั้นชัดเจน อย่างไรก็ตาม เมื่อเวลาผ่านไป ข้อดีของความเรียบง่ายจะชัดเจนมากขึ้นเรื่อยๆ ประวัติการพัฒนาของ Bitcoin เป็นเครื่องพิสูจน์ประเด็นนี้อย่างชัดเจน
ฉันเสนอให้การออกแบบโปรโตคอล Ethereum อ้างอิงจากประสบการณ์จริงของโครงการ TinyGrad กำหนดขีดจำกัดบนที่ชัดเจนสำหรับจำนวนบรรทัดของโค้ดสำหรับข้อกำหนด Ethereum ในระยะยาว และมุ่งมั่นทำให้ความเรียบง่ายของโค้ดฉันทามติ Ethereum ที่สำคัญใกล้เคียงกับระดับของ Bitcoin โดยเฉพาะอย่างยิ่งรหัสที่เกี่ยวข้องในการประมวลผลกฎทางประวัติศาสตร์ของ Ethereum ยังคงสามารถเก็บรักษาไว้ได้ แต่จะต้องแยกออกจากเส้นทางวิกฤตตามฉันทามติอย่างเคร่งครัดเพื่อให้แน่ใจว่าจะไม่ส่งผลกระทบต่อตรรกะตามฉันทามติหลัก ในเวลาเดียวกันแนวคิดการออกแบบของ "การให้ความสำคัญกับโซลูชันที่ง่ายกว่า" ควรนำไปใช้ในการเลือกโซลูชันทางเทคนิค โดยให้ความสำคัญกับการสรุปความซับซ้อนแทนที่จะแพร่กระจายความซับซ้อนของระบบ และต้องให้แน่ใจว่าการตัดสินใจออกแบบทั้งหมดสามารถให้คุณสมบัติและการรับประกันที่ชัดเจนและตรวจสอบได้ จึงก่อให้เกิดวัฒนธรรมทางเทคนิคที่มุ่งเน้นไปที่ความเรียบง่ายโดยรวม
ความคิดเห็นทั้งหมด