461 GiB: กรณีโหนดอีเธอเรียมซิงก์เร็วสุดครึ่งวัน

มีการเปิดเผยกรณีที่ไดเรกทอรีข้อมูลของโหนดอีเธอเรียม(BTC) ลดลงเหลือ 461 GiB ภายใต้การตั้งค่าบางรูปแบบ และใช้เวลาซิงก์เร็วสุดราวครึ่งวัน อย่างไรก็ตาม ตัวเลขดังกล่าวเป็นกรณีของการตั้งค่า Geth เฉพาะรูปแบบ ไม่ได้หมายความว่าพื้นที่จัดเก็บที่จำเป็นสำหรับการรันโหนดทั่วไปจะลดลงทั้งหมด

วีตาลิก บูเทอริน(Vitalik Buterin) ผู้ร่วมก่อตั้งอีเธอเรียม กล่าวว่าใน X เมื่อวันที่ 26 ว่า “ในกรณีที่เร็วที่สุด การซิงก์โหนดอีเธอเรียมหนึ่งโหนดในปัจจุบันใช้เวลาเพียงครึ่งวันก็เพียงพอ” พร้อมอธิบายว่าการใช้การตั้งค่าเชิงรุกสามารถลดการใช้ดิสก์ให้ต่ำกว่า 0.5TB ได้

EtherWorld รายงานซ้ำคำกล่าวของบูเทอริน โดยระบุว่าไดเรกทอรีข้อมูลของโหนด Geth ที่เขายกตัวอย่างมีขนาด 461 GiB ตัวเลขนี้อาจแตกต่างกันตามประเภทของโหนด การตั้งค่าไคลเอนต์ และวิธีการซิงก์

เอกสารทางการของอีเธอเรียมระบุว่า snap sync ของ Geth อาจต้องใช้พื้นที่มากกว่า 500GB ขณะที่พื้นที่จัดเก็บขั้นต่ำสำหรับฟูลโหนดทั่วไปอยู่ที่ NVMe SSD ขนาด 2TB และสเปกที่แนะนำคือ NVMe SSD ขนาด 4TB

โหนดคือคอมพิวเตอร์ที่ดาวน์โหลดและตรวจสอบข้อมูลบล็อกเชน โหนดอีเธอเรียมต้องใช้งานทั้งไคลเอนต์ประมวลผลและไคลเอนต์ฉันทามติ โดยภาระการใช้งานจริงขึ้นอยู่มากกับพื้นที่จัดเก็บ การรับส่งข้อมูลบนดิสก์ และสภาพแวดล้อมเครือข่าย

snap sync เป็นวิธีลดเวลาซิงก์ด้วยการดึงข้อมูลสถานะจากช่วงเวลาหนึ่ง แทนการคำนวณข้อมูลในอดีตทั้งหมดของบล็อกเชนใหม่ตั้งแต่ต้น ระยะเวลาซิงก์และพื้นที่จัดเก็บจริงอาจแตกต่างกันตามไคลเอนต์ ฮาร์ดแวร์ ความเร็วเครือข่าย และการตั้งค่า

EIP-4444 เป็นข้อเสนอที่มุ่งลดภาระการเก็บข้อมูลในอดีตของไคลเอนต์ประมวลผล ทั้งนี้ ยังไม่พบการยืนยันความสัมพันธ์โดยตรงระหว่าง EIP-4444 กับกรณี 461 GiB

โหนดทั่วไปที่ตรวจสอบสถานะล่าสุดสามารถลบข้อมูลเก่าได้บางส่วน ขณะที่อาร์ไคฟ์โหนดต้องเก็บข้อมูลในอดีตทั้งหมด ส่งผลให้ความต้องการพื้นที่จัดเก็บของอาร์ไคฟ์โหนดสูงกว่าโหนดทั่วไปอย่างมาก

หากภาระการเก็บข้อมูลในอดีตลดลง การรันโหนดด้วยฮาร์ดแวร์ภายในบ้านอาจทำได้ง่ายขึ้น โหนดแบบดูแลเองถูกเสนอให้เป็นช่องทางลดการพึ่งพาผู้ให้บริการ RPC รายอื่น รวมถึงเพิ่มความเป็นส่วนตัวและความต้านทานต่อการเซ็นเซอร์ อย่างไรก็ตาม ผู้ดูแลยังต้องจัดหาอุปกรณ์จัดเก็บ จัดการเครือข่าย และบำรุงรักษาไคลเอนต์ด้วยตนเอง

ในทางกลับกัน แอปพลิเคชันที่ต้องใช้ข้อมูลเก่าอาจต้องพึ่งพาผู้ให้บริการข้อมูลหรือเครือข่ายจัดเก็บข้อมูลเฉพาะมากขึ้น เอกสาร EIP-4444 อธิบายด้วยว่า การเข้าถึงข้อมูลที่ลดลงอาจทำให้การพึ่งพาบริการข้อมูลแบบรวมศูนย์เพิ่มขึ้น

ความเชื่อมโยงระหว่างการแพร่หลายของคอมพิวเตอร์ประสิทธิภาพสูงสำหรับ AI กับการรันโหนดอีเธอเรียมเป็นการตีความความเป็นไปได้ทางเทคนิค U.Today วิเคราะห์ว่า หากมีผู้ใช้งานที่มี SSD และหน่วยความจำขนาดใหญ่เพื่อรันโมเดล AI ภายในเครื่องมากขึ้น ภาระส่วนเพิ่มของการรันโหนดบนอุปกรณ์เดียวกันอาจลดลง

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

การอัปเกรดครั้งถัดไป Glamsterdam มุ่งพัฒนาการซิงก์โหนดและการประมวลผลบล็อกแบบขนาน โรดแมปทางการของอีเธอเรียมระบุว่า Glamsterdam อยู่ระหว่างการทดสอบบนเครือข่ายสำหรับนักพัฒนา และวางกำหนดการใช้งานบนเมนเน็ตไว้ในไตรมาส 4 ปี 2026 แต่ยังไม่มีการยืนยันวันที่ที่แน่นอน

Block-Level Access Lists(BAL) ซึ่งมีแผนรวมอยู่ใน Glamsterdam เป็นฟังก์ชันที่จัดระเบียบข้อมูลที่บล็อกจะเข้าถึงและสถานะสุดท้ายไว้ล่วงหน้า BAL ออกแบบมาให้โหนดอัปเดตสถานะโดยใช้ผลลัพธ์สุดท้าย แทนการประมวลผลธุรกรรมทั้งหมดตามลำดับอีกครั้ง และมีเป้าหมายสนับสนุนการประมวลผลแบบขนานกับการอ่านข้อมูลจากดิสก์แบบขนาน

ตัวเลข 461 GiB เป็นกรณีของการตั้งค่า Geth เฉพาะรูปแบบที่เชื่อมโยงกับคำกล่าวของบูเทอริน และไม่สามารถใช้แทนสเปกที่แนะนำสำหรับโหนดทั่วไปได้

กรณีดังกล่าวแสดงให้เห็นว่าภาระการรันโหนดอีเธอเรียมอาจลดลงได้ในสภาพแวดล้อมบางรูปแบบ ขณะที่การใช้งาน Glamsterdam บนเมนเน็ตจะขึ้นอยู่กับการทดสอบบนเครือข่ายสำหรับนักพัฒนาและเทสต์เน็ตต่อไป