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

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

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

Execution Resource and Data Resource Short-term and Long-term Expansion

ไวทาลิคในเริ่มต้นของบทความกล่าวว่า, "เพื่อที่จะขยาย Ethereum ในระยะ 5 ปีถัดไป จำเป็นต้องขยายทรัพยากร 3 ประการ":

- ทรัพยากรด้านการดำเนินการ: การคำนวณของ 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 มิติหลายมิติอาจจะเป็น "เรื่องแรก" ณ ปัจจุบัน ทุกการดำเนินการบนอีเธอเรียมใช้ค่า Gas เดียวกัน แต่ความคิดของวิทัลิคคือ ดำเนินการต่าง ๆ ควรมีราคาต่างกัน

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

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

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

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

การขยายโด่งดั่งนั้นคือการทำให้ฮาร์ดไดรฟ์ของเครือข่ายเติบแข็งขึ้นเขียนใหฝีทักษะที่ซึงเป็นโอกาสน้อยให้แก้ภัยความขึ้นอย่าง Blobs + PeerDAS กับ ZK-EVM ปล่องระลุคราคาขั้นตอนของการใช้งาน

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

การใช้งานของ PeerDAS—ไม่ต้องโหลดข้อมูลทั้งหมด จำเป็นตอบเฉลองข้อมูลบางส่วนเทียบสองยกอยญตรวจเช็คขอมลสมบันเเกี่ยว การระแยะการบริม่าข้อมูลจดูงค่ั ใยอ่างพงัใยเอ้ายยนระบรอ่ยว่าข้อมูลสจูV่าอ่าสร่างุั

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

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

ไม่มี "ยาสิ้นคิด" ในการขยายสถานะ

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

คำตอบของ Vitalik คือ ไม่มีอะไรเลย.

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

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

ปัญหาอยู่ที่ไม่ใช่การติดตั้งฮาร์ดดิสก์ไม่ได้ แต่อยู่ใน:

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

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

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

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

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

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

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

- การจัดเก็บเป็นระยะ: คล้ายกับการจัดเก็บชั่วคราว แต่ระยะเวลายาวกว่า เช่น 1 ปี

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

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

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

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

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia