Vitalik เผยแพร่คำแนะนำเกี่ยวกับขั้นตอนต่อไปสำหรับการลดความซับซ้อนของโปรโตคอล Ethereum และการลดภาระทรัพยากรโหนด (Purge)

Vitalik Buterin ผู้ร่วมก่อตั้ง Ethereum ของ Odaily News เผยแพร่คำแนะนำ Purge ในขั้นตอนต่อไปเพื่อลดความซับซ้อนของโปรโตคอล Ethereum และลดภาระทรัพยากรของโหนด Vitalik กล่าวว่า EIP-6780 ในฮาร์ดฟอร์ก Dencun จะลบฟังก์ชันการทำงานส่วนใหญ่ของ opcode SELFDESTRUCT ออก ทำให้โปรโตคอลง่ายขึ้นโดยขจัดความซับซ้อนและเพิ่มการรับประกันความปลอดภัยใหม่ ดังนั้น Vitalik จึงทำเครื่องหมายว่าเป็นส่วนสำคัญของ การล้างข้อมูล เกี่ยวกับ การล้างข้อมูล อื่นๆ ที่กำลังเกิดขึ้น Vitalik ให้ตัวอย่างสามตัวอย่าง: 1. เมื่อเร็วๆ นี้ Geth ได้ยกเลิกการรองรับเครือข่ายก่อนการควบรวมกิจการ (PoW) มีโค้ดหลายพันบรรทัดที่ถูก ลบออก. ;2.EIP-161 ทำให้ความจริงที่ว่าเราไม่จำเป็นต้องมีโค้ดอีกต่อไปเพื่อกังวลเกี่ยวกับ บัญชีว่างเปล่า ข้อเสนอนี้ได้นำเสนอแนวคิดนี้โดยเป็นส่วนหนึ่งของการแก้ไขสำหรับการโจมตี Shanghai DoS;3.Blobs ใน Dencun 18 วัน หน้าต่างการจัดเก็บข้อมูลหมายความว่าโหนด Ethereum ต้องการพื้นที่เพียงประมาณ 500GB เพื่อจัดเก็บข้อมูล Blob และจำนวนนี้จะไม่เพิ่มขึ้นเมื่อเวลาผ่านไป สองประเด็นแรกปรับปรุงประสบการณ์การทำงานสำหรับนักพัฒนาไคลเอนต์อย่างมีนัยสำคัญ ในขณะที่จุดสุดท้ายปรับปรุงประสบการณ์การทำงานสำหรับผู้ปฏิบัติงานโหนดอย่างมีนัยสำคัญ นอกจากนี้ ในส่วนอื่นๆ ที่อาจจำเป็นต้อง กำจัด นั้น Vitalik ได้ระบุการรวบรวมล่วงหน้า การบันทึกประวัติ (EIP-4444) การปฏิรูป LOG และการย้ายไปยัง SSZ เกี่ยวกับการคอมไพล์ล่วงหน้า Vitalik ชี้ให้เห็นว่า: ความต้องการสำหรับการคอมไพล์ล่วงหน้าบางส่วนนั้นต่ำกว่าที่คาดไว้มากและฟังก์ชันที่คอมไพล์แล้วเหล่านี้เป็นสาเหตุใหญ่ของข้อผิดพลาดที่เป็นเอกฉันท์และเป็นอุปสรรคอย่างมากสำหรับการใช้งาน EVM ใหม่ มีสองวิธีในการลบการคอมไพล์ล่วงหน้าเหล่านี้: 1 จำเป็นต้องลบการคอมไพล์ล่วงหน้าเท่านั้น เช่น EIP-7266 จะลบ BLAKE2 2. แทนที่การคอมไพล์ล่วงหน้าด้วยโค้ด EVM ชิ้นหนึ่งที่ทำงานแบบเดียวกัน ความต้องการอย่างหนึ่ง คำถามสำคัญที่ต้องแก้ไขคือ: หากทุก ๆ โหนดไม่ได้เก็บประวัติเก่าไว้ แล้วใครจะเป็นคนจัดเก็บมัน ที่จริงแล้ว หน่วยงานขนาดใหญ่ เช่น Block Explorer จะจัดเก็บ อย่างไรก็ตาม มันก็เป็นไปได้และไม่ยากที่จะสร้างเพียร์- โปรโตคอลเครือข่าย to-peer เพื่อจัดเก็บและส่งข้อมูลนี้เหมาะสมกว่าสำหรับงานนี้ บล็อกเชน Ethereum เป็นแบบถาวร แต่การกำหนดให้แต่ละโหนดจัดเก็บข้อมูลทั้งหมดอย่างถาวรเป็นวิธีที่ เกินกำลัง มากในการปรับใช้ความคงทน วิธีเพียร์ทู- ง่ายๆ เครือข่าย torrent ประวัติศาสตร์เก่าแบบ peer ก็เป็นอีกทางหนึ่ง โปรโตคอลที่ได้รับการปรับปรุงให้เหมาะสมที่สุดสำหรับการใช้งานโดย Ethereum นั้นเป็นอีกทางหนึ่ง EIP-4444 สามารถปรับปรุงการกระจายอำนาจของโหนด Ethereum ได้อย่างมาก หากทุกโหนดเริ่มต้นโดยการจัดเก็บเพียงส่วนเล็ก ๆ ของประวัติ จำนวนที่เก็บไว้ สำเนาของประวัติศาสตร์แต่ละชิ้นบนเครือข่ายในทางทฤษฎีอาจจะเหมือนกับในปัจจุบันโดยประมาณ เกี่ยวกับการปฏิรูป LOG นั้น Vitalik ตั้งข้อสังเกตว่า: เราสามารถลบ Bloom และทำให้ opcode ของ LOG ง่ายขึ้นเพียงสร้างค่าและแฮชมันเข้าไปในสถานะ จากนั้นเราสามารถสร้างโปรโตคอลแยกต่างหากโดยใช้ ZK-SNARK และการคำนวณที่ตรวจสอบได้ส่วนเพิ่ม (IVC) เพื่อสร้าง ต้นไม้บันทึก ที่ถูกต้องอย่างพิสูจน์ได้ ต้นไม้เหล่านี้แสดงตารางบันทึกที่ค้นหาได้ง่ายสำหรับหัวข้อที่กำหนด และแอปพลิเคชันที่ต้องใช้บันทึกและต้องการการกระจายอำนาจก็สามารถใช้ได้ โปรโตคอลที่แยกจากกันเหล่านี้ เกี่ยวกับการย้ายไปยัง SSZ นั้น Vitalik กล่าวว่า: เลเยอร์ฉันทามติของ Ethereum ได้ย้าย SimpleSerialize (SSZ) ที่สะอาดกว่าและมีประสิทธิภาพมากขึ้น อย่างไรก็ตาม การเปลี่ยนแปลงยังคงต้องทำให้เสร็จสิ้นและเลเยอร์การดำเนินการถูกย้ายไปยังโครงสร้างเดียวกัน ในวันนี้ มีโครงสร้างข้อมูลการเข้ารหัสสามแบบใน Ethereum: SHA256 binary tree, SHA3 RLP hash list และ hexadecimal Patricia tree เมื่อเราเปลี่ยนมาใช้ SSZ เสร็จแล้ว จะเหลือเพียงสองรายการเท่านั้น: SHA256 binary tree และ Verkle tree ในอนาคตอันยาวนาน เมื่อเราดีพอที่จะใช้ SNARK สำหรับการแฮชแล้ว ก็อาจเป็นไปได้ที่จะใช้ไบนารี Merkle tree แทนที่ SHA256 binary tree และ Verkle tree ด้วยอัลกอริธึมแฮชที่เหมาะสมสำหรับ SNARK