หนึ่งในปัญหาของ อีเธอเรียมหรือบล็อคเชนใดๆ ก็คือมันมีขนาดเพิ่มขึ้นเมื่อเวลาผ่านไป ซึ่งหมายความว่าความซับซ้อนของโค้ดและข้อกำหนดในการจัดเก็บข้อมูลจะเพิ่มขึ้น
บล็อกเชนจะต้องเก็บข้อมูลทั้งหมดไว้ตลอดประวัติซึ่งลูกค้าทั้งหมดจะต้องจัดเก็บและดาวน์โหลดโดยลูกค้าใหม่ ส่งผลให้เวลาในการโหลดและการซิงค์ไคลเอ็นต์เพิ่มขึ้นอย่างต่อเนื่อง
นอกจากนี้ ความซับซ้อนของโค้ดจะเพิ่มขึ้นเมื่อเวลาผ่านไป เนื่องจาก “การเพิ่มคุณลักษณะใหม่ได้ง่ายกว่าการลบคุณลักษณะเก่าออก” วิทาลิก บูเตริน เขียนถึงเขา บล็อก–
ดังนั้น Buterin เชื่อว่านักพัฒนาจะต้องทำงานอย่างแข็งขันเพื่อหยุดยั้งแนวโน้มการเติบโตเหล่านี้ ขณะเดียวกันก็รักษาความถาวรของ Ethereum Buterin จึงได้นำเสนอ The Purge ซึ่งเป็นแผนที่ประกอบด้วยสามส่วนที่มีเป้าหมายเพื่อลดความซับซ้อนของบล็อกเชนและลดภาระข้อมูล
ส่วนที่ 1: ประวัติศาสตร์หมดอายุ
ขณะนี้โหนด Ethereum ที่ซิงค์โดยสมบูรณ์ต้องการพื้นที่จัดเก็บข้อมูลประมาณ 1.1 TB สำหรับไคลเอ็นต์การดำเนินการ ต้องใช้พื้นที่เพิ่มอีกสองสามร้อยกิกะไบต์สำหรับไคลเอนต์ที่เป็นเอกฉันท์ จากข้อมูลของ Buterin ข้อมูลส่วนใหญ่เป็นประวัติ เช่น ข้อมูลเกี่ยวกับบล็อกในอดีต ธุรกรรม และใบเสร็จรับเงิน ซึ่งส่วนใหญ่มีอายุหลายปี เพื่อจัดเก็บประวัติทั้งหมดนี้ พื้นที่ดิสก์ที่ต้องการจะเพิ่มขึ้นหลายร้อยกิกะไบต์ทุกปี
บูเทรินเชื่อว่าปัญหาสามารถแก้ไขได้ด้วยสิ่งที่เรียกว่าการหมดอายุของประวัติ
แต่ละบล็อกในบล็อกเชนจะชี้ไปยังบล็อกก่อนหน้าผ่านลิงก์แฮช ซึ่งหมายความว่าฉันทามติในบล็อกปัจจุบันบ่งบอกถึงฉันทามติเกี่ยวกับประวัติศาสตร์
จากข้อมูลของ Buterin ตราบใดที่เครือข่ายมีฉันทามติเกี่ยวกับบล็อกปัจจุบัน ผู้แสดงเพียงคนเดียวสามารถให้ข้อมูลประวัติที่เกี่ยวข้องใดๆ ผ่านการพิสูจน์ Merkle ซึ่งช่วยให้ใครก็ตามสามารถตรวจสอบความสมบูรณ์ของมันได้ ซึ่งหมายความว่าแทนที่จะให้ทุกโหนดจัดเก็บข้อมูลทั้งหมด แต่ละโหนดสามารถจัดเก็บข้อมูลได้เพียงเล็กน้อย ส่งผลให้ความต้องการในการจัดเก็บข้อมูลลดลง
โดยพื้นฐานแล้ว Buterin แนะนำให้ใช้รูปแบบการทำงานของเครือข่ายทอร์เรนต์ โดยที่ผู้เข้าร่วมแต่ละคนจะจัดเก็บและแจกจ่ายข้อมูลเพียงส่วนเล็กๆ ที่จัดเก็บและแจกจ่ายโดยเครือข่ายเท่านั้น
Ethereum ได้ดำเนินการเพื่อลดข้อกำหนดในการจัดเก็บข้อมูลแล้ว ข้อมูลบางอย่างมีวันหมดอายุ ตัวอย่างเช่น บล็อกฉันทามติจะถูกเก็บไว้เป็นเวลาหกเดือน และ Blob จะถูกเก็บไว้เป็นเวลา 18 วัน
EIP-4444 ถือเป็นอีกก้าวหนึ่งในทิศทางนั้น โดยมีเป้าหมายเพื่อจำกัดระยะเวลาการจัดเก็บสำหรับบล็อกและใบเสร็จรับเงินในอดีตที่หนึ่งปี อย่างไรก็ตาม เป้าหมายระยะยาวคือการมีระยะเวลาคงที่หนึ่งช่วง เช่น 18 วัน ซึ่งในระหว่างนั้นทุกโหนดจะต้องจัดเก็บทุกอย่าง จากนั้นข้อมูลเก่าจะถูกจัดเก็บในลักษณะกระจายบนเครือข่ายเพียร์ทูเพียร์
ส่วนที่ 2: การหมดอายุของรัฐ
จากข้อมูลของ Buterin การขจัดความจำเป็นในการให้ลูกค้าจัดเก็บประวัติทั้งหมดไม่ได้ช่วยแก้ปัญหาข้อกำหนดในการจัดเก็บข้อมูลที่บวมได้อย่างสมบูรณ์ เนื่องจากลูกค้าต้องเพิ่มความจุในการจัดเก็บข้อมูลประมาณ 50GB ทุกปี เนื่องจาก “การเติบโตอย่างต่อเนื่องของรัฐ: ยอดคงเหลือในบัญชีและ nonces รหัสสัญญา และการจัดเก็บสัญญา”
สามารถสร้างออบเจ็กต์สถานะใหม่ได้สามวิธี — โดยการสร้างบัญชีใหม่ โดยการส่ง ETH ไปยังบัญชีใหม่ และโดยการตั้งค่าช่องเก็บข้อมูลที่ไม่มีการเคลื่อนไหวก่อนหน้านี้ เมื่อวัตถุสถานะถูกสร้างขึ้น มันก็จะอยู่ในสถานะตลอดไป
Buterin เชื่อว่าโซลูชันในการหมดอายุออบเจ็กต์สถานะโดยอัตโนมัติเมื่อเวลาผ่านไป จะต้องมีประสิทธิภาพ ใช้งานง่าย และเป็นมิตรกับนักพัฒนา ซึ่งหมายความว่าโซลูชันไม่ควรต้องใช้การคำนวณจำนวนมาก ผู้ใช้ไม่ควรสูญเสียการเข้าถึงโทเค็นของตนหากปล่อยทิ้งไว้โดยไม่มีใครแตะต้องเป็นเวลาหลายปี และนักพัฒนาก็ไม่รู้สึกลำบากใจอย่างมากในกระบวนการนี้
Buterin แนะนำ “วิธีแก้ปัญหาที่ทราบดีว่าแย่น้อยที่สุด” สองประเภท:
- โซลูชันการหมดอายุของรัฐบางส่วน
- ข้อเสนอการหมดอายุของรัฐตามระยะเวลาที่อยู่
การหมดอายุของรัฐบางส่วน
ข้อเสนอการหมดอายุของรัฐบางส่วนทำงานตามหลักการแบ่งรัฐออกเป็น “ส่วน” สิ่งนี้ต้องการให้ทุกคนเก็บ “แผนที่ระดับบนสุด” ซึ่งส่วนต่างๆ ว่างเปล่าหรือไม่ว่างเปล่าตลอดไป ข้อมูลภายในกลุ่มจะถูกจัดเก็บเฉพาะเมื่อมีการเข้าถึงล่าสุดเท่านั้น กลไก “การฟื้นคืนชีพ” ช่วยให้ใครก็ตามสามารถนำข้อมูลกลับมาเป็นก้อนได้ หากไม่ได้จัดเก็บโดยแสดงหลักฐานว่าข้อมูลนั้นคืออะไร
การหมดอายุของสถานะตามระยะเวลาที่อยู่
การหมดอายุของสถานะตามช่วงเวลาที่อยู่เสนอให้มีรายการแผนผังสถานะที่เพิ่มขึ้น แทนที่จะจัดเก็บเพียงรายการเดียวที่จัดเก็บทั้งรัฐ สถานะใดๆ ที่ถูกอ่านหรือเขียนจะถูกอัพเดตเป็นแผนผังสถานะล่าสุด แผนผังสถานะว่างใหม่จะถูกเพิ่มหนึ่งครั้งต่องวด ซึ่งอาจนานถึงหนึ่งปี
ในสถานการณ์สมมตินี้ แผนผังสถานะที่เก่ากว่าจะถูกแช่แข็ง และโหนดแบบเต็มจำเป็นต้องจัดเก็บเฉพาะแผนผังสองรายการล่าสุดเท่านั้น หาก state object กลายเป็นส่วนหนึ่งของ tree ที่หมดอายุ ก็สามารถอ่านหรือเขียนได้ แต่ธุรกรรมจะต้องมีการพิสูจน์จาก Merkle หลังจากการทำธุรกรรม มันจะถูกเพิ่มกลับไปยังแผนผังล่าสุด
การล้างข้อมูลคุณลักษณะ
เมื่อเวลาผ่านไป โปรโตคอลทั้งหมดจะซับซ้อน ไม่ว่าจะเริ่มต้นง่ายแค่ไหนก็ตาม
บูเทริน เขียนว่า:
“ถ้าเราไม่ต้องการให้ Ethereum เข้าสู่หลุมดำที่มีความซับซ้อนเพิ่มมากขึ้น เราจำเป็นต้องทำหนึ่งในสองสิ่ง: (i) หยุดทำการเปลี่ยนแปลง และ ทำให้โปรโตคอลแข็งตัว(ii) สามารถทำได้จริง ลบ คุณสมบัติและ ลด ความซับซ้อน–
ตามที่ Buterin กล่าวไว้ การล้างความซับซ้อนของ Ethereum นั้นจำเป็นต้องมีการแก้ไขเล็กๆ น้อยๆ หลายประการ เช่น การลบ opcode ของ SELFDESTRUCT ออก การลบประเภทธุรกรรมเก่าและคณะกรรมการ beacon chain การปฏิรูป LOG และอื่นๆ Buterin ยังแนะนำให้ลดความซับซ้อนของกลศาสตร์ของแก๊ส ขจัดความสามารถในการสังเกตแก๊ส และปรับปรุงการวิเคราะห์แบบคงที่
