Vitalik กำหนดทิศทาง Ethereum ในห้าปีถัดไป: เพิ่มประสิทธิภาพการดำเนินการ, การแบ่งข้อมูล, การแบ่งชั้นสถานะ

27 กุมภาพันธ์ 2026, Vitalik Buterin ได้โพสต์บทความยาวใน Ethereum Research ภายใต้หัวข้อ "Hyper-scaling state by creating new forms of state (การขยายขนาดสถานะขั้นสูงสุดโดยการสร้างรูปแบบสถานะใหม่)"

ในบทความนี้ Vitalik Buterin ได้จัดเรียงแนวทางการขยายขนาดของ Ethereum เพิ่มเติม บทความนี้ไม่เพียงแต่พูดถึงการขยายขนาดของ Ethereum จากมุมมองทางเทคนิคเท่านั้น แต่ยังให้แผนการขยายขนาดแบบเป็นขั้นตอนจากมุมมองของสถาปัตยกรรมโดยรวม โดยมีเป้าหมายเพื่อสร้างพื้นฐานสำหรับการเพิ่มความจุเครือข่ายของ Ethereum อย่างต่อเนื่องในอีกหลายปีข้างหน้า

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

การขยายทรัพยากรการดำเนินการและทรัพยากรข้อมูลในระยะสั้นและระยะยาว

Vitalik ระบุในตอนต้นของบทความยาวว่า "เพื่อขยายขนาด Ethereum ในอีกห้าปีข้างหน้า จำเป็นต้องขยายทรัพยากรสามประเภท":

- ทรัพยากรการดำเนินการ: การคำนวณ EVM, การตรวจสอบลายเซ็น ฯลฯ

- ทรัพยากรข้อมูล: ผู้ส่งธุรกรรม, ผู้รับ, ลายเซ็น ฯลฯ

- ทรัพยากรสถานะ: ยอดคงเหลือบัญชี, รหัส, ที่เก็บข้อมูล

สองประเภทแรกมีแผนการขยายในระยะสั้นและระยะยาว

สำหรับทรัพยากรการดำเนินการ ระยะสั้นจะใช้รายการการเข้าถึงบล็อก (BAL), ePBS และการกำหนดราคา Gas ใหม่เพื่อให้ได้การเติบโตประมาณ 10-30 เท่า ระยะยาวจะใช้ ZK-EVM เพื่อให้ได้การเติบโตประมาณ 1000 เท่า และสำหรับการคำนวณบางประเภทเฉพาะ (ลายเซ็น, SNARK/STARK) การรวมกลุ่มนอกเชนสามารถเพิ่มประสิทธิภาพได้ประมาณ 10000 เท่า

สำหรับทรัพยากรข้อมูล ระยะสั้นจะใช้การปรับปรุง p2p และ Gas แบบหลายมิติเพื่อให้ได้การเติบโตประมาณ 10-20 เท่า ระยะยาวจะใช้ Blobs + PeerDAS เพื่อให้ได้การเติบโตประมาณ 500 เท่า

การขยายในระยะสั้นมุ่งเน้นที่จะทำให้ Ethereum ทำงานเร็วขึ้น สาเหตุที่ Ethereum ช้าอยู่ตอนนี้เป็นเพราะวิธีการตรวจสอบในปัจจุบันเป็นแบบอนุกรม - ตรวจสอบธุรกรรมทีละรายการ หากธุรกรรมใดหยุดชะงัก กระบวนการตรวจสอบทั้งหมดก็จะหยุดชะงัก

ดังนั้น การอัปเกรด Glamsterdam ในปีนี้จะเปิดตัวรายการการเข้าถึงบล็อก (BAL) และ ePBS

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

ePBS คือการแยกกระบวนการจัดแพ็กเกจและการตรวจสอบบล็อก - ผู้สร้างบล็อกรับผิดชอบการจัดแพ็กเกจธุรกรรม ผู้เสนอรับผิดชอบการเสนอบล็อก ผู้ตรวจสอบรับผิดชอบการตรวจสอบบล็อก แต่ละบทบาททำหน้าที่ของตัวเอง หากทุกคนทำงานส่วนของตัวเองได้ดี ผู้สร้างบล็อกก็สามารถจัดแพ็กเกจธุรกรรมเพิ่มเติมได้อย่างรุนแรงมากขึ้น เพราะผู้เสนอและผู้ตรวจสอบจะช่วยเขาตรวจสอบ ไม่ต้องกังวลเกี่ยวกับปัญหาด้านความปลอดภัย

การกำหนดราคา Gas ใหม่ + Gas แบบหลายมิติอาจเรียกว่าเป็น "เทคนิคหลัก" ในปัจจุบัน การดำเนินการทั้งหมดบน Ethereum ใช้ Gas ประเภทเดียวกัน แต่แนวคิดของ Vitalik คือ การดำเนินการที่แตกต่างกันควรมีราคาที่แตกต่างกัน

โดยเฉพาะอย่างยิ่ง การสร้างสถานะใหม่ (เช่น การสร้างบัญชีใหม่, การปรับใช้สัญญาใหม่) ควรมี "ค่าธรรมเนียมการสร้างสถานะ" พิเศษ เพราะการสร้างสถานะใหม่เป็นการดำเนินการที่แพงที่สุด มันไม่เพียงแต่ใช้ทรัพยากรการคำนวณ แต่ยังใช้ทรัพยากรการจัดเก็บข้อมูล และต้นทุนนี้เป็นถาวร - เมื่อสร้างแล้ว สถานะนี้จะคงอยู่ตลอดไป

ดังนั้น แนวคิดของ Vitalik คือ: ทำให้การสร้างสถานะใหม่มีราคาแพงขึ้น แต่ทำให้ธุรกรรมทั่วไปถูกกว่า

วิธีการดำเนินการคือ "กลไกอ่างเก็บน้ำ" ลองนึกภาพถังสองใบ ใบหนึ่งเก็บ "ค่าธรรมเนียมการสร้างสถานะ" อีกใบเก็บ "ค่าธรรมเนียม Gas ทั่วไป" เมื่อสัญญาเรียกใช้ซึ่งกันและกัน Gas จะถูกยืมจากทั้งสองถังโดยอัตโนมัติ เพื่อให้แน่ใจว่าจะไม่เกิดความสับสน

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

การขยายในระยะยาวคือการทำให้เมนเน็ตเองแข็งแกร่งและใหญ่ขึ้น ลดการพึ่งพา Layer 2 ซึ่งรวมถึง Blobs + PeerDAS และการเปิดตัวแบบเป็นขั้นตอนของ ZK-EVM

Blobs เป็นที่เก็บไฟล์ขนาดใหญ่ชั่วคราว ปัจจุบันใช้หลักสำหรับ Layer 2 ในอนาคต Ethereum เมนเน็ตเองจะใช้ Blobs เพื่อจัดเก็บข้อมูลด้วย แต่ปัญหาก็ตามมา - หากโหนดทุกโหนดต้องดาวน์โหลด Blobs ทั้งหมด เครือข่ายจะถูกทำให้เต็ม

นี่คือที่มาของ PeerDAS - ไม่จำเป็นต้องดาวน์โหลดข้อมูลทั้งหมด แค่ดาวน์โหลดส่วนเล็ก ๆ ก็พอ คล้ายกับการสำรวจตัวอย่าง ไม่จำเป็นต้องถามทุกคน แค่ถามคนกลุ่มเล็ก ๆ ก็สามารถสรุปสถานการณ์ของทั้งกลุ่มได้ เมื่อรวมกับการพิสูจน์ ZK แม้ว่าคุณจะดาวน์โหลดข้อมูลเพียง 1/16 ของข้อมูลทั้งหมด คุณก็สามารถยืนยันความสมบูรณ์ของข้อมูลได้

จากนั้นคือการเปิดตัวแบบเป็นขั้นตอนของ ZK-EVM ซึ่งทำให้การตรวจสอบบล็อกไม่จำเป็นต้องดำเนินการธุรกรรมทั้งหมดในบล็อกใหม่ โหนดแค่เชื่อการพิสูจน์ ZK เท่านั้น ต้นทุนการตรวจสอบจึงลดลงจาก "การดำเนินการธุรกรรมทั้งหมด" เป็น "การตรวจสอบการพิสูจน์ ZK หนึ่งครั้ง"

แผนของ Vitalik คือ ในปี 2026 ให้โหนดบางส่วนทดลองใช้การตรวจสอบ ZK ภายในปี 2027 ส่งเสริมให้โหนดมากขึ้นใช้ และในที่สุด บล็อกหนึ่งบล็อกจะต้องมี 3 ใน 5 ประเภทการพิสูจน์จากระบบการพิสูจน์ที่แตกต่างกันจึงจะถือว่าถูกต้อง เขาคาดว่าโหนดทั้งหมด (ยกเว้นโหนดดัชนี) ในที่สุดจะพึ่งพาการพิสูจน์ ZK-EVM

การขยายสถานะที่ไม่มี "ยาวิเศษ"

ตอนนี้เรามาดู "ทรัพยากรสถานะ" ที่ยังไม่ได้พูดถึงในการขยายระยะสั้นและระยะยาว แม้ว่าในระยะสั้น ยังสามารถเพิ่มประสิทธิภาพได้ประมาณ 5-30 เท่าผ่านการซิงโครไนซ์กับรายการการเข้าถึงบล็อก การปรับปรุง p2p และการปรับปรุงฐานข้อมูล แต่ในระยะยาวล่ะ?

คำตอบของ Vitalik คือ ไม่มี

ทำไมทรัพยากรสถานะถึงขยายได้ยากขนาดนี้? สถานะของ Ethereum เหมือนกับฐานข้อมูลขนาดยักษ์ ฐานข้อมูลนี้เก็บยอดคงเหลือของบัญชีทั้งหมด รหัสของสัญญาทั้งหมด ข้อมูลของตำแหน่งที่เก็บข้อมูลทั้งหมด

ตอนนี้ฐานข้อมูลนี้ยังไม่ใหญ่ มีขนาดประมาณ 100 GB เท่านั้น แต่หากขยายสถานะ 20 เท่า ก็จะเป็น 2 TB แล้วถ้าเวลาผ่านไปนานกว่านี้ล่ะ? 8 TB?

ปัญหาไม่ได้อยู่ที่ฮาร์ดดิสก์เก็บไม่ไหว แต่คือ:

- ประสิทธิภาพของฐานข้อมูลได้รับผลกระทบ: ฐานข้อมูลสมัยใหม่ใช้โครงสร้างต้นไม้ (เช่น Merkle tree) เพื่อจัดระเบียบข้อมูล เมื่อเขียนข้อมูลใหม่ จำเป็นต้องอัปเดตทั้งต้นไม้ ซึ่งหมายความว่าหากคุณต้องการทำการอัปเดต X ครั้ง ในระดับฐานข้อมูลก็จะเป็นการดำเนินการ X ครั้งอีกครั้ง แทนที่จะอัปเดตครั้งเดียว การดำเนินการฐานข้อมูลก็ทำครั้งเดียวก็พอ ยิ่งอัปเดตมาก การดำเนินการก็ยิ่งมาก การเขียนจะช้าจนระเบิด

- การซิงโครไนซ์ยาก: โหนดใหม่ที่เข้าร่วมเครือข่าย Ethereum จำเป็นต้องดาวน์โหลดสถานะทั้งหมด เพื่อตรวจสอบบล็อกใหม่ หากขนาดข้อมูลถึง 8 TB ความเร็วอินเทอร์เน็ตของคนส่วนใหญ่ในปัจจุบันก็ต้องใช้เวลาดาวน์โหลดนาน

มีวิธีแก้ปัญหา แต่ Vitalik คิดว่าทุกวิธีมีปัญหา:

- "สถานะไร้สถานะแบบเข้มข้น": โหนดไม่จำเป็นต้องเก็บสถานะที่สมบูรณ์ แค่ผู้ใช้ให้การพิสูจน์ Merkle ก็พอ Vitalik คิดว่า แผนนี้มีปัญหาการรวมศูนย์ของการเก็บสถานะ การเข้าถึงที่เก็บข้อมูลแบบไดนามิกทำให้ธุรกรรมล้มเหลว และปัญหาต้นทุนแบนด์วิดท์

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

วิธีสุดท้ายของ Vitalik คือ การรวมสองแผนนี้เข้าด้วยกัน และเสนอรูปแบบสถานะใหม่หลายรูปแบบ นี่เป็นการเปลี่ยนแปลงโครงสร้างทรัพยากรสถานะของ Ethereum โดยรวม:

- ที่เก็บข้อมูลชั่วคราว: ที่เก็บข้อมูลที่หมดอายุโดยอัตโนมัติ ตัวอย่างเช่น สามารถสร้างต้นไม้ใหม่ที่ล้างข้อมูลอัตโนมัติทุกเดือน ที่เก็บข้อมูลนี้สามารถใช้สำหรับข้อมูลชั่วคราว เช่น สมุดคำสั่ง, พูลสภาพคล่อง, เคาน์เตอร์ชั่วคราว ข้อมูลเหล่านี้มักไม่จำเป็นต้องเก็บถาวร หลังจากหนึ่งเดือน คำสั่งเก่าหมดอายุ พูลสภาพคล่องใหม่ก็ถูกสร้างขึ้น

- ที่เก็บข้อมูลเป็นช่วงเวลา: คล้ายกับที่เก็บข้อมูลชั่วคราว แต่มีช่วงเวลานานกว่า เช่น 1 ปี

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

ในเวลาเดียวกัน รักษารูปแบบสถานะที่มีอยู่เดิมไว้ ด้วยวิธีนี้ การดำเนินการอาจถูกกว่า 1000 เท่า (ผ่าน ZK-EVM) แต่การสร้างสถานะใหม่อาจถูกกว่าเพียง 20 เท่า

Vitalik คิดว่า เมื่อมีรูปแบบสถานะใหม่ นักพัฒนาก็มีทางเลือก ใช้รูปแบบสถานะที่มีอยู่เดิมต่อไป แต่จ่ายค่าธรรมเนียมที่สูงกว่า หรือออกแบบแอปพลิเคชันใหม่ ใช้รูปแบบสถานะใหม่ เพื่อได้รับค่าธรรมเนียมที่ต่ำกว่า สำหรับกรณีการใช้งานทั่วไป (เช่น ยอดคงเหลือ ERC20, NFT) จะมีเวิร์กโฟลว์มาตรฐาน และสำหรับกรณีการใช้งานที่ซับซ้อนกว่า (เช่น DeFi) นักพัฒนาจะต้องหาวิธีปรับปรุงประสิทธิภาพด้วยตัวเอง

กลยุทธ์นี้ค่อนข้างน่าสนใจ ค่อนข้างมีลักษณะที่นักพัฒนาต้องใช้สมองเพื่อลดต้นทุน และผู้ใช้ Ethereum ทั่วไปได้รับประโยชน์จากมัน