4,096 ไบต์ ขนาดธุรกรรมใหม่ของโซลานา(SOL) เร่งตรวจสอบความเข้ากันได้ก่อนเปิดใช้งาน

โซลานา(SOL) กำลังอยู่ระหว่างการตรวจสอบความเข้ากันได้ของโครงสร้างพื้นฐานครั้งใหญ่ ก่อนที่รูปแบบธุรกรรมใหม่ที่เรียกว่า v1 จะถูกเปิดใช้งานจริงบนเมนเน็ต การเปลี่ยนแปลงหลักคือการขยายขนาดธุรกรรมสูงสุดต่อรายการจาก 1,232 ไบต์ เป็น 4,096 ไบต์ แต่ประเด็นที่ถูกจับตาไม่ใช่ความเสี่ยงที่เครือข่ายจะหยุดทำงาน หากแต่เป็นคำถามว่า RPC, ตัวอินเด็กซ์(indexer), gRPC และผู้ให้บริการอุดหนุนค่าธรรมเนียม(fee sponsor) จะอ่านรูปแบบธุรกรรมใหม่นี้ได้ถูกต้องหรือไม่

มูลนิธิโซลานา(Solana Foundation) ระบุผ่านหน้าอัปเกรดเครือข่ายว่า อากาเว(Agave) เวอร์ชัน 4.2 ได้ถูกติดตั้งบนเมนเน็ตแล้ว แต่ฟีเจอร์ 'Larger Transaction Sizes' ยังอยู่ในสถานะรอเปิดใช้งาน ณ วันที่ 4 กันยายน 2026 โดยฟีเจอร์นี้จะขยายขีดจำกัดขนาดธุรกรรมเดิมผ่านรูปแบบ v1 ให้ใหญ่ขึ้นราว 3.3 เท่า

การเปลี่ยนแปลงครั้งนี้ไม่ใช่แค่การขยายขนาดธุรกรรมเฉยๆ เอกสาร SIMD-0296 และ SIMD-0385 ระบุเหตุผลเบื้องหลังว่าเพื่อรองรับการใช้งานอย่างมัลติซิกขนาดใหญ่ การพิสูจน์แบบไม่เปิดเผยข้อมูล(zero-knowledge proof) และการส่งธุรกรรมแบบเป็นชุด(batch) ในรูปแบบ v1 การพึ่งพา 'address lookup table' ที่ธุรกรรมเดิมเคยใช้จะลดลง ขณะที่ข้อมูลค่าธรรมเนียมและขีดจำกัดทรัพยากรจะถูกย้ายไปอยู่ในค่าคอนฟิกใหม่ที่ชื่อว่า transactionConfig แทน

วิธีอ่านข้อมูลของระบบเดิมอาจกลายเป็นปัญหาตรงจุดนี้ หากตัวอินเด็กซ์หรือผู้ให้บริการอุดหนุนค่าธรรมเนียมยังคงสแกนหาเฉพาะคำสั่ง ComputeBudget เพื่อคำนวณค่าธรรมเนียมสำคัญหรือขีดจำกัดหน่วยประมวลผล(compute unit) ระบบอาจพลาดค่าเพดานค่าธรรมเนียม(fee cap) ของธุรกรรม v1 หรืออ่านค่าดังกล่าวเป็นศูนย์ได้ คลังตัวอย่างโค้ด transaction-v1 ของมูลนิธิโซลานาระบุว่า ข้อความธุรกรรมแบบ v1 จะบรรจุ TransactionConfig แทนที่คำสั่ง ComputeBudget

เอกสาร RPC ของโซลานาแนะนำให้ใส่ค่า maxSupportedTransactionVersion: 1 ในการเรียกใช้ฟังก์ชัน getTransaction, getBlock และ blockSubscribe หากละเว้นค่านี้หรือปล่อยไว้ที่ 0 เมื่อมีธุรกรรม v1 เข้ามา getTransaction อาจแจ้งข้อผิดพลาด ขณะที่ getBlock อาจอ่านข้อมูลทั้งบล็อกไม่สำเร็จ

การสมัครรับข้อมูลผ่านเว็บซ็อกเก็ต(WebSocket) ก็ไม่ใช่ข้อยกเว้น หากตั้งค่าไม่ถูกต้อง blockSubscribe อาจส่งค่า block: null ออกมา ซึ่งเอกสารสำหรับนักพัฒนาของโซลานาระบุว่าต้องตีความกรณีนี้ว่าเป็น 'ความล้มเหลว' ไม่ใช่บล็อกที่ว่างเปล่า ทั้งนี้ธุรกรรม v1 จะถูกระบุตัวตนได้จากไบต์แรกของธุรกรรมที่ถูกซีเรียลไลซ์ ซึ่งมีค่าเท่ากับ 129 หรือ 0x81

ฝั่ง gRPC และ Geyser อาจเกิดความผิดพลาดที่สังเกตเห็นได้ยากกว่า เอกสารสำหรับนักพัฒนาของโซลานาเตือนว่า gRPC ไม่มีค่าออปต์อินอย่าง maxSupportedTransactionVersion ให้ตั้ง และสตับ(stub) ของ protobuf รุ่นเก่าอาจตัดฟิลด์ Message.config ทิ้งไปโดยไม่รู้ตัว กรณีนี้ระบบจะไม่หยุดทำงาน แต่จะมองธุรกรรม v1 เป็นเหมือนธุรกรรม v0 และอาจตกหล่นข้อมูลการตั้งค่าค่าธรรมเนียมไปได้

คลังตัวอย่างโค้ดของมูลนิธิโซลานาแนะนำเวอร์ชันขั้นต่ำของไลบรารีที่เกี่ยวข้อง ได้แก่ @solana/kit เวอร์ชัน 8.0.0, yellowstone-grpc-proto เวอร์ชัน 12.6.0 และ yellowstone-grpc geyser เวอร์ชัน 15.1.1 พร้อมทั้งมีตัวอย่างโค้ดแยกสำหรับการอ่านข้อมูล การส่งธุรกรรม การทำดัชนีบล็อก และการเชื่อมต่อผ่าน gRPC ให้ด้วย

การตรวจสอบในฝั่งเครื่องมือหลัก(core tooling) ก็ยังดำเนินอยู่เช่นกัน อิสชู(issue) หมายเลข #831 บนคลัง solana-sdk ของ anza-xyz ตั้งคำถามว่าขีดจำกัดขนาดสูงสุด 4,096 ไบต์ของ v1 ยังไม่ถูกบังคับใช้อย่างเข้มงวดในขั้นตอนดีซีเรียลไลซ์(deserializer) และตัวตรวจสอบความถูกต้อง(sanitizer) อย่างไรก็ตาม หน้าสถานะของโซลานาแสดงว่า ณ วันที่ 4 กันยายน 2026 โหนด Mainnet Beta RPC ยังทำงานปกติ และไม่มีรายงานเหตุขัดข้องในวันดังกล่าว

โดยสรุปแล้ว เรื่องนี้มีลักษณะเป็นการตรวจสอบความเข้ากันได้ของโครงสร้างพื้นฐานที่เกี่ยวโยงกับการขยายขีดจำกัดธุรกรรม v1 ของโซลานาเป็นหลัก หากประเด็นก่อนหน้านี้คือขนาดขีดจำกัด 4,096 ไบต์และสถานะการเปิดใช้งานฟีเจอร์ในแต่ละคลัสเตอร์ ประเด็นล่าสุดคือระบบแบ็กเอนด์จะอ่านโครงสร้างใหม่ได้หรือไม่ เมื่อธุรกรรม v1 เริ่มเข้ามาจริง

หน้าอัปเกรดของโซลานาระบุว่า ณ วันที่ 4 กันยายน 2026 ฟีเจอร์ 'Larger Transaction Sizes' ยังอยู่ในสถานะรอเปิดใช้งาน ตารางเวลาดังกล่าวจึงมีลักษณะใกล้เคียงกับแผนงานทางเทคนิคที่ต้องให้กระเป๋าเงิน(wallet), RPC, ตัวอินเด็กซ์ และเครื่องมือสำหรับนักพัฒนาต่างทยอยเตรียมความพร้อม มากกว่าจะเป็นเหตุการณ์เดียวที่เปลี่ยนโครงสร้างการประมวลผลของโซลานาในคราวเดียว

ในทางเทคนิค ธุรกรรม v1 ไม่ได้เข้ามาแทนที่ธุรกรรมรูปแบบ v0 และรูปแบบดั้งเดิม(legacy) รูปแบบเดิมยังคงทำงานต่อไปได้ตามปกติ แต่แอปพลิเคชันที่ต้องการใช้ขนาดธุรกรรมที่ใหญ่ขึ้นและใช้ transactionConfig จำเป็นต้องมีการรองรับรูปแบบใหม่นี้ก่อน โดยทั่วไปแล้ว ในการอัปเกรดโครงสร้างพื้นฐานบล็อกเชน ความเสี่ยงด้านปฏิบัติการที่แท้จริงมักไม่ได้ขึ้นอยู่กับกฎฉันทามติ(consensus) เพียงอย่างเดียว แต่ขึ้นอยู่กับความเข้ากันได้ของระบบรอบข้างที่ทำหน้าที่อ่านและจัดเก็บข้อมูลด้วย

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

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

ก่อนที่ธุรกรรม v1 ของโซลานาจะเริ่มเข้ามาจริง รายการที่ต้องตรวจสอบหลักๆ ได้แก่ △การตั้งค่า maxSupportedTransactionVersion: 1 ในออปชันการเรียก RPC △การรองรับเส้นทางจัดเก็บ transactionConfig △การสร้างสตับ protobuf ของ gRPC ใหม่ △การรู้จำพรีฟิกซ์เวอร์ชัน 0x81 ทั้งนี้ ตามหน้าอัปเกรดของโซลานา ฟีเจอร์ 'Larger Transaction Sizes' ยังอยู่ในสถานะรอเปิดใช้งาน ณ วันที่ 4 กันยายน 2026