Fusaka คืออะไร ทำไมอัปเกรดนี้ถึงสำคัญกับ Ethereum

วันที่ 3 ธันวาคม 2025 เครือข่าย Ethereum จะเปิดใช้งานอัปเกรด Fusaka บนเมนเน็ต ซึ่งนับเป็น ฮาร์ดฟอร์กใหญ่ครั้งที่สองของปี ต่อจาก Pectra ในเดือนพฤษภาคม

จุดสำคัญคือ วันนี้ Rollup กลายเป็นตัวแบกธุรกรรมและรายได้ค่าธรรมเนียมส่วนใหญ่ของ Ethereum แล้ว แต่ก็ยังติดข้อจำกัดเรื่อง

• ปริมาณ “ดาต้า” ที่สามารถโพสต์กลับมาบนเลเยอร์ 1

• ค่าใช้จ่ายในการโพสต์ข้อมูลเหล่านั้น

Fusaka จึงถูกออกแบบมาเพื่อ “คลายคอขวดด้าน Data” ผ่านฟีเจอร์หลักอย่าง PeerDAS (peer data availability sampling) ที่ให้วาลิเดเตอร์ตรวจสอบข้อมูล blob ของ Rollup ได้ โดยไม่ต้องดาวน์โหลดทั้งก้อน ลดภาระทั้งแบนด์วิธและสตอเรจ พร้อมเปิดทางให้เพิ่มความจุดาต้าได้อีกมากในอนาคต

ควบคู่กันนั้นยังมี

• Blob Parameter Only (BPO) forks

• การปรับ gas / block size

• และการจัดการ history expiry

ทั้งหมดนี้ทำให้ Ethereum สามารถขยายขีดความสามารถแบบ “เพิ่มครั้งละน้อยแต่เพิ่มบ่อย” แทนการรออัปเกรดใหญ่ทีเดียวเป็นปี ๆ

Fusaka บนโรดแมป Merge–Surge–Verge–Purge

ถ้าย้อนดูโรดแมประยะยาวของ Ethereum จะเห็นลำดับอัปเกรดสำคัญ ๆ ดังนี้

• The Merge (2022): เปลี่ยนจาก Proof-of-Work เป็น Proof-of-Stake ลดการใช้พลังงาน ~99.9%

• Shapella (2023): เปิดถอน ETH ที่ stake ไว้ ทำให้ระบบ staking มีสภาพคล่องมากขึ้น

• Dencun (มี.ค. 2024): เพิ่ม EIP-4844 “blobs” หรือช่องทางเก็บดาต้าราคาถูกสำหรับ Rollup (protodanksharding)

• Pectra (พ.ค. 2025): เพิ่มฟีเจอร์ account abstraction (EIP-7702) และปรับโครงสร้างการ stake เช่น เปลี่ยนเพดาน validator 2,048 ETH

ทั้งหมดนี้สอดคล้องกับโรดแมปย่อของ Vitalik: Merge, Surge, Verge, Purge, Splurge

• Surge = เน้นสเกลผ่าน Rollup และ data availability

• Verge / Purge = ทำให้โหนดเบาลง ซิงก์เร็วขึ้น ตัดประวัติที่ไม่จำเป็น

Fusaka ถือเป็นอัปเกรดแรกที่ “ดึงทุกคันโยกพร้อมกัน”

• ช่วยสเกลดาต้าสำหรับ Rollup (Surge)

• เดินหน้าตัด History และเบาโหนด (Verge / Purge)

• พร้อมตั้งเป้าชัดเจนว่าจะผลัก Ethereum ไปสู่บทบาท L1 สำหรับ Settlement และ Data Engine ที่สามารถรองรับสแตกโมดูลาร์เกิน 100,000 TPS เมื่อรวม L2 ทั้งหมด

PeerDAS, Blobs และ Block ที่ใหญ่ขึ้น (แต่ยังปลอดภัย)

หัวใจของ Fusaka คือ EIP-7594: PeerDAS โดยก่อนหน้านี้ full node ต้องดาวน์โหลด blob ดาต้าทั้งก้อน จาก Rollup เพื่อยืนยันความถูกต้อง ทำให้การเพิ่มขนาด blob มีข้อจำกัด เพราะจะทำให้

• โหนดต้องใช้เน็ตและสตอเรจเยอะ

• Home staker เสี่ยงต้องอัปเกรดเป็นระดับดาต้าเซ็นเตอร์

PeerDAS แก้ปัญหานี้ด้วยการ

• แบ่ง blob ออกเป็น “cell” เล็ก ๆ

• ใช้เทคนิค sampling + erasure coding ให้วาลิเดเตอร์ดึงข้อมูลแค่บางส่วนแบบสุ่ม

• ถ้าข้อมูลตัวอย่างเพียงพอ ระบบก็มั่นใจได้ว่าดาต้าทั้งก้อน “มีอยู่จริงในเครือข่าย”

ผลลัพธ์คือ

• ลดแบนด์วิธและสตอเรจต่อโหนด

• ปูพื้นให้เพิ่มความจุ blob ได้หลายเท่าในอนาคต โดยไม่บีบ home staker

เพื่อทำให้การเพิ่มความจุนี้ “ยืดหยุ่น” ขึ้น Fusaka ยังเพิ่ม

• EIP-7892: Blob Parameter Only (BPO) forks

  • เป็นฮาร์ดฟอร์กไซซ์จิ๋วที่เปลี่ยนแค่ 3 ค่าพารามิเตอร์ของ blob: target, max, base fee factor

  • ทำให้ Ethereum สามารถ “ขยับความจุ blob ทีละสเต็ป” ตามดีมานด์ L2 ไม่ต้องรออัปเกรดใหญ่

ด้าน execution layer ก็มีการปรับ gas / block size ให้รองรับทรานแซกชันซับซ้อนมากขึ้น เช่น

• ตั้ง เพดาน gas ต่อหนึ่งทรานแซกชัน (EIP-7825)

• จำกัดขนาดบล็อกสูงสุดที่ 10MB ผ่าน RLP limit (EIP-7934) เพื่อปิดช่องโจมตีแบบ DoS

• ปรับราคาและจำกัดการเรียก MODEXP precompile (EIP-7823 / 7883) เพื่อไม่ให้การคำนวณหนัก ๆ หนึ่งครั้งลากทั้งบล็อกให้ช้า

แปลเป็นภาษาคน: Fusaka ให้อิสระในการเพิ่มความจุและความซับซ้อนของบล็อกมากขึ้น แต่ใส่ “รั้วกันตกเหว” เพื่อไม่ให้โหนดธรรมดาตามไม่ทัน

อัปเกรดด้าน UX, Security และ Developer Experience

Fusaka ไม่ได้มีแต่เรื่อง “สเกลดาต้า” เท่านั้น ยังมี EIP ที่แตะประสบการณ์ใช้งานและเครื่องมือของนักพัฒนาโดยตรง เช่น

• EIP-7917 – deterministic proposer lookahead

  • ทำให้รู้ล่วงหน้าบนเชนว่า “ใครจะเป็นคน propose บล็อกใน epoch ถัดไป”

  • สำคัญต่อ based rollup, pre-confirmation และ fast finality ที่อยากให้ผู้ใช้ได้คำยืนยันเร็ว ๆ แบบเชื่อถือได้

• EIP-7951 – secp256r1 precompile (P-256)

  • เพิ่มการรองรับลายเซ็น P-256 ใน EVM

  • คือ curve เดียวกับที่ใช้ใน Apple Secure Enclave, Android Keystore, FIDO2, WebAuthn

  • เปิดทางให้ กระเป๋าเงินเชื่อมกับ biometric / passkey ของเครื่องโดยตรง ลดการพึ่ง seed phrase ทำให้ UX ใกล้เคียงฟินเทคกระแสหลัก

• EIP-7939 – count leading zeros opcode

  • คำสั่งนับจำนวนเลข 0 ด้านหน้าของเลข 256 บิต

  • ทำให้การคำนวณระดับบิต, big integer, และ circuit ของ zk-proof บางแบบถูกและง่ายขึ้น

• EIP-7642 – ขยายงานด้าน history expiry

  • อนุญาตให้ client ทิ้งข้อมูลเก่าบางช่วง (โดยเฉพาะ pre-Merge) ได้มากขึ้น

  • โหนดสามารถประกาศช่วงข้อมูลที่ตัวเองมีให้เครือข่ายรู้

  • ประหยัดสตอเรจได้ระดับ หลายร้อย GB ต่อโหนด และช่วยให้โหนดใหม่ซิงก์เร็วขึ้นอย่างมีนัยสำคัญ

ใครได้อะไรจาก Fusaka: L2, Validator และผู้ถือ ETH

1. Rollup และระบบนิเวศ L2
 

คือผู้ได้ประโยชน์ตรงที่สุด

• PeerDAS + BPO ทำให้ “ช่องทางดาต้า” สำหรับ L2 ใหญ่ขึ้นและยืดหยุ่นกว่าเดิม

• ค่าธรรมเนียม blob มีโอกาสถูกลงอย่างมีนัยสำคัญ โดยเฉพาะสำหรับเคสที่ยิงดาต้าเยอะ เช่น

  • DeFi ปริมาณเทรดสูง

  • เกม Web3

  • Social / messaging บน L2

ผลคือ L2 มีพื้นที่ทดลองโมเดลธุรกิจใหม่ ๆ มากขึ้น และการแข่งขันกันเรื่อง ค่าธรรมเนียม + UX น่าจะเดือดกว่าเดิม

2. โหนดและวาลิเดเตอร์

• ด้านดี: sampling + history expiry ช่วยลดดาต้าที่ต้องเก็บและต้องโหลด ทำให้การเปิดโหนดใหม่/ซิงก์ใหม่ง่ายขึ้น

• ด้านท้าทาย: เมื่อ BPO เพิ่มจำนวน blob ขึ้นเรื่อย ๆ โหนดที่มีทรัพยากรมากจะต้อง “แบกเน็ตอัปโหลด” หนักขึ้น ถ้าออกแบบไม่ดีอาจเอียงไปทางโอเปอเรเตอร์รายใหญ่ได้

ฝั่งสถาบันและผู้ให้บริการ staking มอง Fusaka เป็น “ตัวเปิดทาง” ให้การวางแผนโครงสร้างพื้นฐานระยะยาวง่ายขึ้น ทั้งด้าน throughput, ค่า gas และการจัดการประวัติข้อมูล

3. ผู้ถือ ETH

ในมุมผู้ถือเหรียญ Fusaka คือการจูน Ethereum ให้กลายเป็น

• Settlement layer + Data engine สำหรับ L2

• เพิ่มโอกาสให้มี activity มากขึ้นกลับมาลงที่ L1 ในรูปค่าธรรมเนียมและ blob fee

ซึ่งมีผลต่อ

• รายได้ของวาลิเดเตอร์

• โครงสร้างแรงจูงใจของผู้ stake ETH

แต่ก็แลกมากับความซับซ้อนของโปรโตคอลที่เพิ่มขึ้น ถ้าผู้ใช้ปลายทางไม่รู้สึกว่าค่าธรรมเนียมถูกลงหรือ UX ดีขึ้นจริง อาจโดนตั้งคำถามเรื่อง “สเกลเพื่อใคร” ได้เหมือนกัน

หลัง Fusaka: Glamsterdam และเส้นทางสู่ 100,000 TPS

อัปเกรดถัดไปในโรดแมปมีชื่อว่า Glamsterdam คาดว่าจะตามมาในปี 2026 โดยมีสองฟีเจอร์หลักที่ถูกพูดถึงแล้วคือ

• ePBS (enshrined proposer-builder separation)

  • แยกบทบาทผู้สร้างบล็อก (builder) กับผู้เสนอร่างบล็อก (proposer) ในระดับโปรโตคอล

  • เป้าคือทำให้ห่วงโซ่ MEV โปร่งใสและปลอดภัยขึ้น ไม่ต้องพึ่งรีเลย์ภายนอกอย่างเดียว

• Block-level Access Lists (BALs)

  • ทำให้การเข้าถึง state ภายในบล็อกมีประสิทธิภาพขึ้น

  • ช่วยรองรับการเพิ่ม blob capacity ในอนาคต

ถ้า Ethereum เดินตามโรดแมปนี้ได้ต่อเนื่อง การมอง Fusaka แค่เป็น “อีกหนึ่งฮาร์ดฟอร์ก” อาจจะน้อยไป เพราะมันคือจุดที่โรดแมปเริ่มกลายเป็น “โปรแกรมสเกลแบบมีทิศทาง”

เป้าหมายสุดท้ายคือ สแตกโมดูลาร์ที่วิ่งได้เกิน 100,000 TPS โดยไม่ทิ้งหลักการกระจายศูนย์ (decentralization) ที่ทำให้ Ethereum มีคุณค่าตั้งแต่แรกเริ่ม

อ้างอิง : cointelegraph.com