ชื่อเรื่องเดิม: Simplifying the L1

ผู้เขียนต้นฉบับ: Vitalik Buterin

การแปลต้นฉบับ: GaryMa, Wu Says Blockchain

บทคัดย่อ

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

เป้าหมายของ Ethereum คือการเป็นบัญชีแยกประเภทระดับโลก: แพลตฟอร์มสำหรับจัดเก็บทรัพย์สินและบันทึกของอารยธรรมมนุษย์ ให้บริการด้านการเงิน การกำกับดูแล และการพิสูจน์ตัวตนข้อมูลที่มีมูลค่าสูง สิ่งนี้ต้องการการสนับสนุนในสองด้าน: ความสามารถในการปรับขนาดและความยืดหยุ่น ฮาร์ดฟอร์กของ Fusaka ถูกกำหนดให้เพิ่มพื้นที่ที่มีให้สำหรับข้อมูล L2 เป็น 10 เท่า ในขณะที่แผนงานปี 2026 ที่เสนอในปัจจุบันถูกกำหนดให้เพิ่มพื้นที่ที่มีให้สำหรับเลเยอร์ L1 ในปริมาณที่ใกล้เคียงกัน ในเวลาเดียวกัน Ethereum ได้เสร็จสิ้นการเปลี่ยนผ่านไปสู่ Proof of Stake (PoS) แล้ว ความหลากหลายของไคลเอนต์เพิ่มขึ้นอย่างรวดเร็ว การตรวจสอบความรู้เป็นศูนย์ (ZK) และการวิจัยการต้านทานควอนตัมก็มีความก้าวหน้าอย่างต่อเนื่อง และระบบนิเวศของแอปพลิเคชันก็มีความแข็งแกร่งเพิ่มมากขึ้น

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

สิ่งที่น่าทึ่งที่สุดเกี่ยวกับโปรโตคอล Bitcoin ก็คือความเรียบง่ายที่หรูหรา:

1. มีบล็อกเป็นโซ่ โดยแต่ละบล็อกจะเชื่อมต่อกับบล็อกก่อนหน้าผ่านแฮช

2. ความถูกต้องของบล็อกจะได้รับการตรวจสอบโดย Proof of Work (PoW) ซึ่งก็คือการตรวจสอบว่าหลักแรก ๆ ไม่กี่หลักของค่าแฮชเป็นศูนย์หรือไม่

3. แต่ละบล็อกจะมีธุรกรรม และเหรียญที่ใช้ในธุรกรรมมาจากรางวัลการขุดหรือจากผลลัพธ์ของธุรกรรมก่อนหน้า

แค่นั้นแหละ! แม้กระทั่งนักเรียนมัธยมปลายที่ฉลาดก็สามารถเข้าใจได้อย่างถ่องแท้ว่าโปรโตคอล Bitcoin ทำงานอย่างไร และโปรแกรมเมอร์ก็สามารถเขียนไคลเอนต์เป็นโปรเจ็กต์เสริมได้อีกด้วย ความเรียบง่ายของโปรโตคอลทำให้ Bitcoin (และ Ethereum) มีข้อได้เปรียบสำคัญหลายประการในฐานะเลเยอร์ฐานระดับโลกที่เป็นกลางและเชื่อถือได้:

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

2. ลดต้นทุนการพัฒนา: การทำให้โปรโตคอลเรียบง่ายขึ้นจะช่วยลดต้นทุนในการสร้างโครงสร้างพื้นฐานใหม่ๆ (เช่น ไคลเอนต์ใหม่ ผู้พิสูจน์ เครื่องมือสำหรับนักพัฒนา ฯลฯ) ได้อย่างมาก

3. ลดภาระการบำรุงรักษา: ลดต้นทุนการบำรุงรักษาตามสัญญาระยะยาว

4. ลดความเสี่ยงของข้อผิดพลาด: ลดความเป็นไปได้ของข้อผิดพลาดร้ายแรงในการกำหนดรายละเอียดและการใช้งานโปรโตคอล และอำนวยความสะดวกในการตรวจสอบว่าข้อผิดพลาดดังกล่าวไม่มีอยู่

5. ลดพื้นผิวการโจมตี: ลดส่วนประกอบที่ซับซ้อนของโปรโตคอลและลดความเสี่ยงในการถูกโจมตีโดยกลุ่มผลประโยชน์พิเศษ

ในอดีต Ethereum (และบางครั้งอาจเป็นเพราะการตัดสินใจส่วนตัวของฉัน) มักล้มเหลวในการรักษาสิ่งต่าง ๆ ให้เรียบง่าย ส่งผลให้มีค่าใช้จ่ายในการพัฒนาที่มากเกินไป มีความเสี่ยงด้านความปลอดภัยมากขึ้น และวัฒนธรรมการวิจัยและพัฒนาแบบปิด ซึ่งผลกำไรที่ได้จากการติดตามความซับซ้อนเหล่านี้มักพิสูจน์ให้เห็นว่าเป็นภาพลวงตา บทความนี้จะเจาะลึกว่า Ethereum ในอีก 5 ปีข้างหน้าจะเข้าใกล้ความเรียบง่ายของ Bitcoin อย่างไร

เลเยอร์ฉันทามติแบบง่าย

การออกแบบเลเยอร์ฉันทามติแบบใหม่ (ซึ่งเดิมเรียกว่า "บีคอนเชน") มีเป้าหมายเพื่อใช้ประโยชน์จากประสบการณ์กว่าทศวรรษที่ผ่านมาในด้านทฤษฎีฉันทามติ การพัฒนา ZK-SNARK เศรษฐศาสตร์สเตค และด้านอื่นๆ เพื่อสร้างเลเยอร์ฉันทามติที่เรียบง่ายและเหมาะสมในระยะยาว เมื่อเปรียบเทียบกับบีคอนเชนที่มีอยู่ การออกแบบใหม่จะเรียบง่ายขึ้นอย่างมาก:

1. การออกแบบขั้นสุดท้ายแบบ 3 ช่อง: ลบแนวคิดต่างๆ เช่น ช่อง ยุค การจัดระเบียบคณะกรรมการใหม่ และกลไกการประมวลผลที่มีประสิทธิภาพที่เกี่ยวข้อง (เช่น คณะกรรมการการซิงโครไนซ์) การใช้งานจริงของ 3-slot finality ขั้นพื้นฐานใช้โค้ดเพียงประมาณ 200 บรรทัด และมีความปลอดภัยเกือบเหมาะสมที่สุดเมื่อเทียบกับ Gasper

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

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

4. ลดความซับซ้อนของสถาปัตยกรรม P2P: ปัจจัยดังกล่าวข้างต้นอาจสนับสนุนสถาปัตยกรรมเครือข่ายเพียร์ทูเพียร์ที่เรียบง่ายและแข็งแกร่งยิ่งขึ้น

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

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

การลดความซับซ้อนของเลเยอร์การดำเนินการ

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

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

เมื่อไม่นานมานี้ ฉันได้เสนอวิธีแก้ปัญหาที่รุนแรงยิ่งขึ้น: แทนที่จะทำการเปลี่ยนแปลง EVM ในระดับปานกลาง (แต่ยังคงก่อกวน) เพื่อแลกกับผลประโยชน์ 1.5 เท่า เราสามารถเปลี่ยนไปใช้ VM ที่ดีกว่าและง่ายกว่า และได้รับผลประโยชน์ 100 เท่าได้ คล้ายกับ The Merge เราลดจำนวนการเปลี่ยนแปลงที่สำคัญลง แต่ทำให้การเปลี่ยนแปลงแต่ละครั้งมีความหมายมากขึ้น โดยเฉพาะอย่างยิ่ง ฉันเสนอให้แทนที่ EVM ด้วย RISC-V หรือเครื่องเสมือนอื่นที่ใช้โดยตัวพิสูจน์ Ethereum ZK สิ่งนี้จะนำมาซึ่ง:

1. การปรับปรุงประสิทธิภาพที่สำคัญ: การดำเนินการสัญญาอัจฉริยะ (ในผู้พิสูจน์) ไม่จำเป็นต้องมีโปรแกรมแปลและทำงานโดยตรง ข้อมูลของ Succinct แสดงให้เห็นว่าประสิทธิภาพสามารถปรับปรุงได้มากกว่า 100 เท่าในสถานการณ์ต่างๆ มากมาย

2. ความเรียบง่ายที่ได้รับการปรับปรุงอย่างมีนัยสำคัญ: ข้อกำหนด RISC-V นั้นเรียบง่ายมากเมื่อเทียบกับ EVM และทางเลือกอื่นๆ เช่น Cairo ก็เรียบง่ายพอๆ กัน

3. แรงจูงใจในการสนับสนุน EOF: เช่น การแบ่งพาร์ติชั่นโค้ด การวิเคราะห์แบบคงที่ที่เป็นมิตรมากขึ้น ขีดจำกัดขนาดโค้ดที่ใหญ่กว่า ฯลฯ

4. ตัวเลือกสำหรับนักพัฒนาเพิ่มเติม: Solidity และ Vyper สามารถเพิ่มแบ็กเอนด์เพื่อคอมไพล์เป็นเครื่องเสมือนใหม่ได้ หากคุณเลือก RISC-V นักพัฒนาภาษาหลักก็สามารถพอร์ตโค้ดของตนไปยังเครื่องเสมือนนี้ได้อย่างง่ายดายเช่นกัน

5. ลบการคอมไพล์ล่วงหน้าส่วนใหญ่: อาจจะเหลือเพียงการดำเนินการเส้นโค้งวงรีที่ได้รับการปรับให้เหมาะสมสูงเท่านั้น (แม้ว่าการดำเนินการเหล่านี้จะหายไปหลังจากคอมพิวเตอร์ควอนตัมได้รับความนิยมแล้วก็ตาม)

ข้อเสียเปรียบหลักก็คือ แตกต่างจาก EOF แบบพร้อมใช้งาน ประโยชน์ของ VM ใหม่นั้นต้องใช้เวลานานกว่าที่จะส่งต่อไปยังนักพัฒนา เราบรรเทาปัญหานี้ได้โดยดำเนินการปรับปรุง EVM คุณค่าสูงในระยะสั้น (เช่น การเพิ่มขีดจำกัดขนาดรหัสสัญญาและรองรับ DUP/SWAP17–32)

สิ่งนี้จะส่งผลให้เครื่องเสมือนมีความเรียบง่ายมากขึ้น ความท้าทายหลักคือ: จะจัดการกับ EVM ที่มีอยู่ได้อย่างไร

กลยุทธ์ความเข้ากันได้แบบย้อนหลังสำหรับการเปลี่ยนผ่านเครื่องเสมือน

ความท้าทายที่ยิ่งใหญ่ที่สุดในการลดความซับซ้อน (หรือปรับปรุงโดยไม่เพิ่มความซับซ้อน) EVM คือการสร้างสมดุลระหว่างการใช้งานเป้าหมายกับความเข้ากันได้แบบย้อนหลังของแอปพลิเคชันที่มีอยู่

· ก่อนอื่น เราต้องชี้แจงให้ชัดเจนว่าไม่มีวิธีใดเพียงวิธีเดียวในการกำหนดฐานโค้ด Ethereum (แม้ว่าจะอยู่ในไคลเอนต์เพียงตัวเดียวก็ตาม)

· เป้าหมายคือการลด พื้นที่สีเขียว ให้เหลือน้อยที่สุด: ตรรกะที่จำเป็นสำหรับโหนดที่จะเข้าร่วมในฉันทามติ Ethereum รวมถึงการคำนวณสถานะปัจจุบัน หลักฐาน การตรวจสอบ FOCIL (กฎการเลือกฟอร์ก) และการสร้างบล็อก "ปกติ"

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

· พื้นที่สีเหลืองที่เพิ่มใหม่: มีประโยชน์มากสำหรับการทำความเข้าใจโซ่ปัจจุบันหรือการเพิ่มประสิทธิภาพการสร้างบล็อก แต่ไม่รวมอยู่ในตรรกะฉันทามติ ตัวอย่างเช่น Etherscan และโปรแกรมสร้างบล็อกบางตัวรองรับการดำเนินการผู้ใช้ ERC-4337 หากเราแทนที่ฟังก์ชันการทำงานของ Ethereum บางอย่าง (เช่น EOA และประเภทธุรกรรมเดิมที่รองรับ) ด้วยการใช้งาน RISC-V แบบบนเชน โค้ดฉันทามติจะเรียบง่ายลงอย่างมาก แต่โหนดเฉพาะอาจยังคงใช้โค้ดเดิมสำหรับการแยกวิเคราะห์

· ความซับซ้อนในพื้นที่สีส้มและสีเหลืองคือความซับซ้อนของการห่อหุ้ม ผู้ที่เข้าใจโปรโตคอลสามารถข้ามส่วนเหล่านี้ได้ และการนำ Ethereum ไปใช้ก็สามารถละเลยส่วนเหล่านี้ได้ ข้อผิดพลาดในพื้นที่เหล่านี้จะไม่ทำให้เกิดความเสี่ยงต่อความสอดคล้องกัน ดังนั้นความซับซ้อนของโค้ดในพื้นที่สีส้มและสีเหลืองจึงสร้างความเสียหายน้อยกว่าความซับซ้อนในพื้นที่สีเขียวมาก แนวคิดในการย้ายโค้ดจากพื้นที่สีเขียวไปยังพื้นที่สีเหลืองนั้นคล้ายกับกลยุทธ์ของ Apple ที่ต้องการรับประกันความเข้ากันได้ย้อนหลังในระยะยาวผ่านเลเยอร์การแปล Rosetta ได้รับแรงบันดาลใจจากบทความล่าสุดของทีม Ipsilon ฉันจึงเสนอกระบวนการเปลี่ยนแปลง VM ดังต่อไปนี้ (ใช้ EVM เป็น RISC-V เป็นตัวอย่าง แต่ยังสามารถใช้สำหรับ EVM เป็น Cairo หรือ RISC-V เป็น VM ที่ดีกว่าได้อีกด้วย):

1. ต้องมีการเตรียมการคอมไพล์ล่วงหน้าใหม่เพื่อให้สามารถใช้งาน RISC-V แบบออนเชนได้: อนุญาตให้ระบบนิเวศน์ค่อยๆ ปรับตัวให้เข้ากับเครื่องเสมือน RISC-V

2. แนะนำ RISC-V เป็นตัวเลือกสำหรับนักพัฒนา: โปรโตคอลนี้รองรับทั้ง RISC-V และ EVM และสัญญาของเครื่องเสมือนทั้งสองสามารถโต้ตอบกันได้อย่างอิสระ

3. แทนที่การคอมไพล์ล่วงหน้าส่วนใหญ่: ยกเว้นการดำเนินการเส้นโค้งวงรีและ KECCAK (เนื่องจากความต้องการความเร็วสูง) การคอมไพล์ล่วงหน้าอื่นๆ จะถูกแทนที่ด้วยการใช้งาน RISC-V การพรีคอมไพล์ถูกลบออกผ่านฮาร์ดฟอร์ก และโค้ดที่อยู่นั้น (คล้ายกับ DAO fork) ได้ถูกเปลี่ยนจากไม่มีอะไรเลยไปเป็นการใช้งาน RISC-V เครื่องเสมือน RISC-V นั้นง่ายมากและการหยุดเพียงแค่นี้ก็จะช่วยลดความซับซ้อนของโปรโตคอลเท่านั้น

4. นำ EVM interpreter มาใช้งานใน RISC-V: แบบออนเชนเป็นสัญญาอัจฉริยะ (ดำเนินการแล้วเนื่องจากข้อกำหนดของผู้พิสูจน์ ZK) หลายปีหลังจากการเปิดตัวครั้งแรก สัญญา EVM ที่มีอยู่จะดำเนินการผ่านล่ามนี้

หลังจากเสร็จสิ้นขั้นตอนที่ 4 แล้ว "การนำ EVM ไปใช้งาน" หลายอย่างจะยังคงใช้เพื่อเพิ่มประสิทธิภาพการสร้างบล็อก เครื่องมือสำหรับนักพัฒนา และการวิเคราะห์ห่วงโซ่ แต่จะไม่ถือเป็นส่วนหนึ่งของข้อกำหนดฉันทามติหลักอีกต่อไป Ethereum Consensus จะเข้าใจ RISC-V เท่านั้น "โดยธรรมชาติ"

การลดความซับซ้อนผ่านส่วนประกอบโปรโตคอลที่ใช้ร่วมกัน

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

รหัสลบรวม

เราต้องการรหัสลบในสามสถานการณ์:

1. การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล: ไคลเอนต์ตรวจสอบว่าบล็อกได้รับการเผยแพร่แล้ว

2. การออกอากาศ P2P ที่เร็วขึ้น: โหนดสามารถยอมรับบล็อกหลังจากได้รับชิ้นส่วน n/2 ชิ้น ทำให้เกิดความสมดุลระหว่างความหน่วงและความซ้ำซ้อน

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

หากใช้รหัสลบแบบเดียวกัน (ไม่ว่าจะเป็น Reed-Solomon, รหัสเชิงเส้นแบบสุ่ม ฯลฯ) ในทั้งสามสถานการณ์ จะได้ข้อดีดังต่อไปนี้:

1. ลดจำนวนโค้ดให้เหลือน้อยที่สุด:ลดจำนวนบรรทัดโค้ดทั้งหมด

2. ปรับปรุงประสิทธิภาพ: หากโหนดดาวน์โหลดชิ้นส่วนบางส่วนสำหรับฉาก ข้อมูลเหล่านี้สามารถนำไปใช้ในฉากอื่นๆ ได้

3. ให้แน่ใจถึงความสามารถในการตรวจสอบ: ส่วนของฉากทั้งหมดสามารถตรวจสอบได้เทียบกับราก

หากใช้รหัสการลบที่แตกต่างกัน อย่างน้อยก็ควรแน่ใจว่ามีความเข้ากันได้ เช่น รหัส Reed-Solomon ในแนวนอนสำหรับการสุ่มข้อมูลพร้อมใช้งานและรหัสเชิงเส้นสุ่มแนวตั้งทำงานในโดเมนเดียวกัน

รูปแบบการซีเรียลไลเซชั่นแบบรวม

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

2. ขีดจำกัดแก๊สที่สูงขึ้น: ข้อมูลของเลเยอร์การดำเนินการจำเป็นต้องวางไว้ในบล็อกข้อมูล (บล็อบ)

เมื่อถึงเวลานั้น เราจะมีโอกาสในการรวมรูปแบบการเขียนแบบอนุกรมของสามระดับของ Ethereum ได้: ชั้นการดำเนินการ ชั้นฉันทามติ และ ABI ของการเรียกใช้สัญญาอัจฉริยะ

ฉันเสนอให้ใช้ SSZ เนื่องจาก SSZ:

1. ง่ายต่อการถอดรหัส: รวมอยู่ในสัญญาอัจฉริยะ (เนื่องจากการออกแบบบนพื้นฐาน 4 ไบต์และกรณีขอบน้อยลง)

2. มีการใช้กันอย่างแพร่หลายในเลเยอร์ฉันทามติ

3. คล้ายคลึงกับ ABI ที่มีอยู่มาก: การปรับแต่งเครื่องมือนั้นค่อนข้างง่าย

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

โครงสร้างแบบต้นไม้รวม

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

จากตอนนี้สู่อนาคต

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

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

ลิงก์ต้นฉบับ