วิตาลิก บูเทริน เรียกร้องให้มีการพัฒนาโปรโตคอลอีเธอเรียมให้เรียบง่ายขึ้นและมีการ "จัดการขยะ"

PANews 18 มกราคม รายงานข่าวว่า Vitalik Buterin ได้โพสต์ข้อความบนแพลตฟอร์ม X ระบุว่า ด้านหนึ่งที่สำคัญและถูกประเมินต่ำมานานเกี่ยวกับ "ความไม่ไว้วางใจ" (trustlessness) "การออกจากทดสอบ" (exit test) และ "สิทธิ์ในการเป็นเจ้าของตนเอง" (self-sovereignty) คือความเรียบง่ายของโปรโตคอล (protocol simplicity) แม้ว่าโปรโตคอลจะมีโหนดหลายแสนโหนด สามารถทนต่อการโจมตีแบบ Byzantine ได้ถึง 49% และโหนดสามารถตรวจสอบทุกสิ่งได้อย่างสมบูรณ์ผ่าน peerDAS และ STARKs ที่ปลอดภัยต่อควอนตัม แต่หากโปรโตคอลนั้นประกอบด้วยโค้ดหลายแสนบรรทัดและใช้ระบบเข้ารหัสที่ซับซ้อนระดับปริญญาเอกหลายประเภท โปรโตคอลนี้จะล้มเหลวในทุกเกณฑ์ทั้งสามอย่างในที่สุด: 1. ไม่มีความไม่ไว้วางใจ เพราะผู้ใช้ต้องเชื่อถือกลุ่มเล็กๆ ของผู้เชี่ยวชาญระดับสูงเพื่อให้ข้อมูลเกี่ยวกับคุณสมบัติของโปรโตคอล 2. ไม่สามารถผ่าน "การทดสอบการออกจากระบบ" (exit test) เพราะหากทีมผู้พัฒนาไคลเอนต์ปัจจุบันออกจากโครงการ ทีมใหม่จะมีความยากมากในการพัฒนาคุณภาพเทียบเท่า 3. ไม่มีสิทธิ์ในการเป็นเจ้าของตนเอง เพราะแม้แต่ผู้ใช้ที่มีทักษะทางเทคนิคสูงสุดก็ไม่สามารถตรวจสอบและเข้าใจโปรโตคอลได้ ดังนั้นโปรโตคอลจึงไม่เป็นของผู้ใช้อย่างแท้จริง นอกจากนี้ ความปลอดภัยก็ต่ำลงด้วย เพราะทุกส่วนของโปรโตคอล โดยเฉพาะเมื่อส่วนต่างๆ สามารถโต้ตอบกันได้ในรูปแบบที่ซับซ้อน ย่อมมีความเสี่ยงสูงที่โปรโตคอลจะล้มเหลว ความกังวลหนึ่งของฉันเกี่ยวกับการพัฒนาโปรโตคอลของ Ethereum คือเราอาจเพิ่มฟีเจอร์ใหม่ๆ อย่างเร่งรีบเพื่อตอบสนองความต้องการเฉพาะทาง แม้ว่าฟีเจอร์เหล่านี้จะทำให้โปรโตคอลซับซ้อนขึ้น หรือเพิ่มส่วนประกอบการโต้ตอบใหม่ๆ หรือองค์ประกอบเข้ารหัสที่ซับซ้อนเป็นส่วนสำคัญ ซึ่งในระยะสั้นอาจเพิ่มฟังก์ชันได้ แต่ในระยะยาวจะทำลายความสามารถในการเป็นเจ้าของตนเองอย่างยั่งยืน และการสร้างโครงสร้างกระจายศูนย์ที่สามารถอยู่รอดได้แม้จะมีการเปลี่ยนแปลงของจักรวรรดิหรืออุดมการณ์ ปัญหาหลักคือ หากใช้เกณฑ์วัดการเปลี่ยนแปลงโปรโตคอลจาก "การเปลี่ยนแปลงที่มีต่อโปรโตคอลที่มีอยู่" ความปรารถนาในการรักษาความเข้ากันได้ย้อนกลับ (backward compatibility) หมายความว่าการเพิ่มสิ่งใหม่จะเกิดขึ้นบ่อยกว่าการลดทอน ซึ่งทำให้โปรโตคอลแน่นอนว่าจะซับซ้อนขึ้นเรื่อยๆ ดังนั้นกระบวนการพัฒนา Ethereum จึงจำเป็นต้องมีฟังก์ชัน "การลดทอน" (simplification) หรือ "การกำจัดขยะ" (garbage collection) อย่างชัดเจน โดยการลดทอนมีเกณฑ์วัด 3 อย่าง: 1. ลดจำนวนบรรทัดของโค้ดทั้งหมดในโปรโตคอลให้น้อยที่สุด 2. หลีกเลี่ยงการพึ่งพาองค์ประกอบทางเทคนิคที่ซับซ้อนโดยไม่จำเป็น 3. เพิ่มคุณสมบัติที่ไม่เปลี่ยนแปลง (invariant) ซึ่งเป็นคุณสมบัติหลักที่โปรโตคอลสามารถพึ่งพาได้ เช่น EIP-6780 (การลบ selfdestruct) ที่เพิ่มคุณสมบัติว่าแต่ละบล็อกสามารถเปลี่ยนแปลงได้ไม่เกิน N ช่องเก็บข้อมูล (storage slot) ซึ่งช่วยลดความซับซ้อนในการพัฒนาไคลเอนต์อย่างมาก การกำจัดขยะสามารถทำได้ทั้งแบบเล็กๆ น้อยๆ หรือแบบใหญ่ๆ วิธีการแบบเล็กๆ น้อยๆ คือการปรับปรุงฟีเจอร์ที่มีอยู่ให้เรียบง่ายและสมเหตุสมผลขึ้น ในขณะที่การกำจัดขยะแบบใหญ่ๆ อาจเป็นการเปลี่ยนจาก PoW เป็น PoS อีกวิธีหนึ่งคือ "การเข้ากันได้ย้อนกลับแบบ Rosetta" ซึ่งฟีเจอร์ที่ซับซ้อนแต่ใช้ไม่บ่อยยังคงใช้งานได้อยู่ แต่ถูก "ลดระดับ" ให้เป็นส่วนหนึ่งของโค้ดสัญญาอัจฉริยะ (smart contract code) แทนที่จะเป็นส่วนที่จำเป็นของโปรโตคอล ดังนั้นนักพัฒนาไคลเอนต์รุ่นใหม่จึงไม่จำเป็นต้องจัดการกับส่วนนั้น ตัวอย่างเช่น หลังจากอัปเกรดไปยังการเป็นเจ้าของบัญชีแบบสมบูรณ์ (full native account abstraction) ประเภทของการทำธุรกรรมเก่าทั้งหมดสามารถถูกยกเลิกได้; แทนที่การใช้ precompiled ด้วยโค้ด EVM หรือ RISC-V; และในที่สุดเปลี่ยนเครื่องเสมือน (virtual machine) จาก EVM ไปเป็น RISC-V สุดท้าย หวังว่านักพัฒนาไคลเอนต์จะไม่จำเป็นต้องจัดการกับทุกเวอร์ชันเก่าของโปรโตคอล Ethereum อย่างต่อเนื่อง ระยะยาว ความเร็วในการเปลี่ยนแปลงของ Ethereum ควรจะลดลง และเราควรพยายามหลีกเลี่ยงไม่ให้ส่วนที่ไม่จำเป็นกลายเป็นภาระถาวรของโปรโตคอล Ethereum