ข่าวสาร คริปโต ข่าวต่างประเทศ บล็อกเชน (Blockchain)

Solana เปิดใช้ Transaction V1 วันนี้ ขยายขนาดธุรกรรม 3.3 เท่า

9 กันยายน 2026

0

📌 สรุป 3 บรรทัด: Solana มีกำหนดเปิดใช้งาน Transaction V1 บน mainnet วันนี้ (9 ก.ย. 2569) ขยายขนาดธุรกรรมสูงสุดจาก 1,232 เป็น 4,096 ไบต์ (โต 3.3 เท่า) พร้อมตัดระบบ Address Lookup Table (ALT) ออก เปิดทางให้ธุรกรรมซับซ้อนอย่าง ZK proof และ multisig ขนาดใหญ่ทำงานในธุรกรรมเดียวได้ ผู้ถือ SOL ทั่วไปไม่ต้องทำอะไร เพราะรูปแบบเดิมยังใช้งานได้ปกติ

Solana กำลังเดินหน้าอัปเกรดรูปแบบธุรกรรมครั้งใหญ่ที่สุดนับตั้งแต่เปิดตัวระบบ v0 พร้อม Address Lookup Table เมื่อหลายปีก่อน โดย Anza ทีมพัฒนาหลักของเครือข่าย ยืนยันตั้งแต่วันที่ 29 สิงหาคม 2569 ว่าจะเปิดใช้งาน “Transaction V1” บน mainnet ในวันที่ 9 กันยายน 2569 — ขยายขนาดธุรกรรมสูงสุดจาก 1,232 ไบต์ เป็น 4,096 ไบต์ หลังผ่านการทดสอบบน testnet มาตั้งแต่วันที่ 1 กันยายน (epoch 1025) อย่างไรก็ตาม Solana Foundation เองยังระบุในหน้า roadmap ว่าสถานะ mainnet เป็น “pending” และกำหนดการของ Anza เป็นแบบ “tentative” ที่อาจเปลี่ยนแปลงได้

ราคา Solana (SOL) วันนี้ โซลานา

฿3,405.21▲0.36%

ราคา Bitkub ฿3,414.93 (พรีเมียม +0.29%)

สูง/ต่ำ 24 ชม. ฿3,445.64 / ฿3,343.74

ดูกราฟและข้อมูลเต็ม →

ข้อมูลจาก SiamBitcoin Cap · อัปเดต 11:10

Transaction V1 คืออะไร

Transaction V1 ถูกกำหนดโดยเอกสารข้อเสนอปรับปรุง 2 ฉบับที่เขียนโดยวิศวกร Anza คือ Jacob Creech และ Andrew Fitzgerald: SIMD-0296 ที่ขยายเพดานขนาดธุรกรรม และ SIMD-0385 ที่นิยามโครงสร้างข้อความแบบ v1 ทั้งชุด ขีดจำกัดเดิม 1,232 ไบต์ ถูกกำหนดไว้ตั้งแต่ยุคแรกของเครือข่ายตามขนาด MTU ของ IPv6 (1,280 ไบต์) แต่หลังจากเปลี่ยนมาใช้โปรโตคอล QUIC รับส่งธุรกรรมตั้งแต่ปี 2565 ข้อจำกัดนี้ก็ไม่มีเหตุผลทางเทคนิครองรับอีกต่อไป เพราะ QUIC ไม่ได้กำหนดขนาด stream สูงสุดไว้

ตัวเลข 4,096 ไบต์ที่เลือกใช้ไม่ได้สุ่มมา แต่จงใจให้ตรงกับขนาด “memory page” มาตรฐานของฮาร์ดแวร์ validator ที่ 4 KB พอดี เพื่อให้การจัดการหน่วยความจำต่อธุรกรรมยังคงมีต้นทุนต่ำ ไม่ต้องให้ธุรกรรมเดียวกระจายข้ามหลายเพจ

รายการ	รูปแบบเดิม (Legacy / v0)	Transaction V1
ขนาดสูงสุด	1,232 ไบต์	4,096 ไบต์ (×3.3)
Address Lookup Table	ใช้ได้ (บีบอัดที่อยู่ผ่าน index 1 ไบต์)	ตัดออก ใส่ที่อยู่เต็ม 32 ไบต์ตรงๆ
ค่าธรรมเนียม/compute limit	อยู่ใน ComputeBudgetProgram instruction	อยู่ใน TransactionConfigMask ตำแหน่งตายตัว
จำนวนบัญชีต่อธุรกรรม	สูงสุด 64 บัญชี	สูงสุด 64 บัญชี (ไม่เปลี่ยน)
สถานะการใช้งาน	ใช้งานต่อได้ตามปกติ	เลือกใช้ได้ (opt-in) ไม่บังคับ

ทำไมต้องตัด Address Lookup Table ทิ้ง

ระบบ v0 เดิมใช้ Address Lookup Table (ALT) เพื่อ “บีบอัด” ที่อยู่บัญชีให้เหลือ index ตัวเดียวขนาด 1 ไบต์ต่อบัญชี แทนที่จะใส่ที่อยู่เต็ม 32 ไบต์ตรงๆ เหตุผลง่ายๆ คือถ้าธุรกรรมหนึ่งอ้างอิงบัญชีสูงสุด 64 บัญชีโดยไม่บีบอัดเลย จะกินพื้นที่ถึง 2,048 ไบต์ ซึ่งเกินเพดานเดิม 1,232 ไบต์ไปมาก ALT จึงเป็นทางออกที่จำเป็นในตอนนั้น

แต่พอเพดานขยายเป็น 4,096 ไบต์ การใส่ที่อยู่ 64 บัญชีเต็มรูปแบบก็ใช้พื้นที่แค่ 2,048 ไบต์ ยังเหลือพื้นที่อีกครึ่งหนึ่ง ทีม Anza จึงมองว่า ALT กลายเป็นความซับซ้อนที่ไม่คุ้มค่าอีกต่อไป เพราะการอ่านธุรกรรมแบบ v0 ต้องให้ validator โหลดตาราง ALT จากฐานข้อมูลบัญชี ตรวจสอบเจ้าของตาราง ถอดรหัสสถานะ แล้วค่อยแปลง index กลับเป็นที่อยู่จริง ซึ่งเป็นขั้นตอนที่ขึ้นกับสถานะเครือข่าย (state-dependent) และทำให้ประมวลผลช้าลง ข้อมูลจาก Solana Foundation ระบุว่า 90% ของธุรกรรมตัวอย่างที่แปลงจาก v0 เป็น v1 จะเพิ่มขนาดน้อยกว่า 1,400 ไบต์เท่านั้น ส่วนใหญ่จึงยังพอดีกับเพดานใหม่สบายๆ

✅ จุดสำคัญ: ตัวธุรกรรมแบบ v0 และ legacy เดิม ไม่ได้ถูกยกเลิก — ยังใช้งานต่อได้ตามปกติทั้งหมด เพราะ v1 เป็นฟีเจอร์ที่ต้อง “เลือกใช้” (opt-in) จากฝั่งผู้ส่งธุรกรรมหรือ dApp เท่านั้น

ปลดล็อกอะไรได้บ้าง

ข้อจำกัด 1,232 ไบต์ เดิมทำให้งานคริปโตกราฟีบางประเภทใส่ในธุรกรรมเดียวไม่ได้เลย หรือต้องหั่นเป็นหลายธุรกรรมต่อกัน ซึ่งเสี่ยงที่บางขั้นตอนจะสำเร็จแต่บางขั้นตอนล้มเหลว ทำให้ผลลัพธ์ไม่เป็น atomic (ทำครบทุกขั้นตอนพร้อมกันหรือไม่ทำเลย) พื้นที่ที่เพิ่มขึ้นเปิดทางให้:

1

Zero-Knowledge Proofs

ฟีเจอร์อย่าง Confidential Transfers บนมาตรฐาน Token Extensions ที่ต้องใช้ ZK proof ขนาดใหญ่ ก่อนหน้านี้ใส่ในธุรกรรมเดียวไม่ได้เลย

2

BLS Signature Aggregation

รวมลายเซ็นจากหลายฝ่ายให้เหลือ proof เดียวขนาดกะทัดรัด มีประโยชน์กับการยืนยันธุรกรรมข้ามเชน (cross-chain bridge)

3

Multisig ขนาดใหญ่

กระเป๋า multisig สำหรับสถาบันหรือ DAO เช่นที่ใช้ผ่าน Squads รองรับผู้ร่วมเซ็นได้มากขึ้นโดยไม่ล้นเพดานขนาด

4

DeFi Route ซับซ้อนขึ้น

รวมหลายคำสั่งซื้อขาย-สลับเหรียญไว้ในธุรกรรมเดียวแบบ atomic ลดความเสี่ยงที่บางขั้นตอนจะค้างกลางทาง

ใครกระทบบ้าง ต้องทำอะไรไหม

เพราะ Transaction V1 เป็นระบบ opt-in ที่ไม่บังคับ ผลกระทบจึงกระจุกอยู่ที่ฝั่งโครงสร้างพื้นฐาน ไม่ใช่ผู้ใช้ทั่วไป:

👤 ผู้ถือ SOL ทั่วไป

ไม่ต้องทำอะไร ไม่ต้องโยกเหรียญ ไม่ต้อง claim ใดๆ กระเป๋าและธุรกรรมแบบเดิมใช้งานได้ตามปกติ 100%

⚠️ RPC Provider / Indexer / Explorer

ต้องอัปเดตซอฟต์แวร์ให้รองรับ — คำสั่งอย่าง getTransaction หรือ getBlock ต้องระบุ maxSupportedTransactionVersion: 1 ไม่งั้นจะ error ทันทีที่เจอธุรกรรมแบบ v1

⚠️ นักพัฒนา / Wallet SDK

ต้องรองรับการ encode/decode รูปแบบใหม่ และอ่านค่าธรรมเนียม-compute limit จาก TransactionConfigMask แทนการสแกน instruction แบบเดิม

💡 แม้แต่ Solana Foundation เองก็ยังระบุสถานะการเปิดใช้บน mainnet ว่า “pending” (รอดำเนินการ) และเตือนว่ากำหนดการฝั่ง Anza เป็นแบบ “tentative” — แปลว่าวันที่ 9 กันยายนอาจขยับได้หากพบปัญหาก่อนเปิดใช้จริง

มุมมองนักลงทุน-นักพัฒนาไทย

สำหรับคนไทยที่ถือ SOL ผ่านกระดานในประเทศอย่าง Bitkub หรือ Binance TH ข่าวนี้ไม่กระทบการฝาก-ถอนหรือยอดคงเหลือใดๆ เพราะเป็นการอัปเกรดที่ backward-compatible เต็มรูปแบบ ไม่ใช่การ hard fork ที่ต้องหยุดระบบหรือให้ผู้ใช้ทำอะไรเพิ่ม ฝั่งที่ต้องติดตามจริงๆ คือทีมพัฒนา dApp หรือ DeFi ไทยที่ build บน Solana ซึ่งควรเช็กเวอร์ชัน RPC/SDK ที่ใช้อยู่ว่ารองรับ maxSupportedTransactionVersion: 1 แล้วหรือยัง ก่อนที่ผู้ใช้บนแพลตฟอร์มจะเริ่มส่งธุรกรรมแบบ v1 เข้ามาในอนาคต ราคา SOL ล่าสุดขณะเขียนข่าวอยู่ที่ราว 103 ดอลลาร์ ยังไม่มีสัญญาณว่าข่าวอัปเกรดนี้ส่งผลต่อราคาโดยตรง เพราะเป็นการปรับปรุงเชิงเทคนิคที่ตลาดรับรู้ล่วงหน้ามาตั้งแต่ปลายเดือนสิงหาคมแล้ว

คำถามที่พบบ่อย

Q1: Transaction V1 กระทบคนถือ SOL ทั่วไปไหม?
ไม่กระทบ เพราะเป็นระบบ opt-in — ธุรกรรมแบบ legacy และ v0 เดิมยังใช้งานได้ปกติทุกอย่าง ไม่ต้องโยกเหรียญหรืออัปเดตกระเป๋า

Q2: ต้องอัปเดตกระเป๋า (wallet) ไหม?
ผู้ใช้ทั่วไปไม่ต้อง ส่วนนักพัฒนาที่ดูแล RPC/wallet/indexer ต้องอัปเดตให้รองรับรูปแบบ v1 เพื่อไม่ให้เกิด error เวลาอ่านธุรกรรมแบบใหม่

Q3: ทำไมเลือกขยายเป็น 4,096 ไบต์ ไม่ใช่ตัวเลขอื่น?
เพราะตรงกับขนาด memory page มาตรฐาน 4 KB ของฮาร์ดแวร์ validator พอดี ช่วยให้ต้นทุนจัดการหน่วยความจำต่อธุรกรรมยังต่ำ โดยไม่ต้องให้ธุรกรรมเดียวกระจายข้ามหลายเพจหน่วยความจำ

⚠️ คำเตือน: บทความนี้เป็นความรู้เพื่อการศึกษา ไม่ใช่คำแนะนำในการลงทุน (NFA) การลงทุนในคริปโตมีความเสี่ยงสูง ควรศึกษาข้อมูลเพิ่มเติมและลงทุนเฉพาะเงินที่พร้อมจะเสีย

ที่มา: Solana Foundation, crypto.news