ขยายขนาดธุรกรรม v1 โซลานา(SOL) เป็น 4,096 ไบต์ จากเดิม 1,232 ไบต์

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

มูลนิธิโซลานา(Solana Foundation) ระบุในเอกสารอัปเดตอย่างเป็นทางการว่าได้จัดหมวดฟีเจอร์ 'Larger Transaction Sizes' ไว้ในสถานะ 'Pending Feature Activation' หรือรอการเปิดใช้งาน การเปลี่ยนแปลงครั้งนี้อ้างอิงจากข้อเสนอ SIMD-0296 และ SIMD-0385 โดยแดชบอร์ดอัปเกรดอย่างเป็นทางการระบุว่าไคลเอนต์ 'อากาเว่(Agave) 4.2' เป็นเวอร์ชันที่เผยแพร่ในเดือนสิงหาคม 2026 แต่ฟีเจอร์ขยายขนาดธุรกรรมยังคงอยู่ในสถานะรอเปิดใช้งาน ยังไม่ถูกเปิดใช้จริง

หัวใจของการอัปเกรดครั้งนี้อยู่ที่ขีดจำกัดขนาดธุรกรรม เดิมโซลานากำหนดเพดานไว้ที่ 1,232 ไบต์ ซึ่งเอกสาร SIMD-0296 อธิบายว่ามีที่มาจากการออกแบบตามค่า IPv6 MTU ที่ 1,280 ไบต์ เมื่อหักส่วนหัวข้อมูล (header) ออกแล้ว เหลือพื้นที่สำหรับข้อมูลธุรกรรมจริงเพียง 1,232 ไบต์เท่านั้น

หลังจากโซลานานำโปรโตคอล QUIC มาใช้ ทีมพัฒนาเห็นว่าเครือข่ายมีความพร้อมมากขึ้นสำหรับการส่งธุรกรรมขนาดใหญ่ขึ้น จึงเสนอขีดจำกัดใหม่ที่ 4,096 ไบต์ ถือเป็นการปรับขีดจำกัดธุรกรรมใหม่ให้สอดคล้องกับโครงสร้างการส่งข้อมูลที่เปลี่ยนไป หลังจากที่ขีดจำกัดเดิมถูกกำหนดตามข้อจำกัดขนาดแพ็กเก็ตในอดีต

รูปแบบ v1 จะไม่มาแทนที่ธุรกรรมรูปแบบ v0 และรูปแบบเดิม (legacy) ที่ใช้งานอยู่ แต่แอปพลิเคชัน กระเป๋าเงินดิจิทัล และระบบดัชนี (indexer) ที่ต้องการใช้ขนาดธุรกรรมที่ใหญ่ขึ้นจะต้องปรับให้รองรับรูปแบบใหม่นี้ เอกสาร RPC ของโซลานาระบุว่าต้องตั้งค่า maxSupportedTransactionVersion เป็น 1 ในคำขอ จึงจะสามารถรับข้อความธุรกรรมแบบ v1 ได้

ตามเอกสาร RPC ธุรกรรมแบบ v1 จะมีอ็อบเจ็กต์ transactionConfig ซึ่งบรรจุค่าขีดจำกัดหน่วยประมวลผล ขีดจำกัดขนาดข้อมูลบัญชีที่โหลด และค่าธรรมเนียมลำดับความสำคัญ โดยอยู่ในพารามิเตอร์ computeUnitLimit, loadedAccountsDataSizeLimit และ priorityFee ซึ่งต่างจากวิธีเดิมที่ต้องใส่คำสั่งแยกต่างหากเพื่อขอทรัพยากร

โครงสร้างเทคนิคที่เปลี่ยนไป

โครงสร้างเทคนิคของธุรกรรมก็เปลี่ยนไปเช่นกัน เอกสาร SIMD-0385 อธิบายว่าธุรกรรมแบบ v1 จะใช้ 'version byte' หมายเลข 129 และแทนที่จะใช้คำสั่ง ComputeBudgetProgram แบบเดิม จะบรรจุคำขอทรัพยากรไว้ในรูปแบบ 'config mask' ภายในส่วนหัวของธุรกรรมโดยตรง ทั้งนี้ v1 ยังไม่รองรับตารางค้นหาที่อยู่ (Address Lookup Table, ALT)

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

การเปลี่ยนแปลงนี้เปิดพื้นที่ให้นักพัฒนาสามารถรวมงานหลายอย่างไว้ใน 'ธุรกรรมอะตอมมิก' (atomic transaction) เดียวได้มากขึ้น มูลนิธิโซลานาอธิบายว่าก่อนหน้านี้การพิสูจน์แบบไม่เปิดเผยข้อมูล (zero-knowledge proof) การทำมัลติซิกขนาดใหญ่ งานแบบชุด (batch) และโครงสร้างลายเซ็นบนเชนบางประเภท ยากที่จะบรรจุไว้ในธุรกรรมเดียวภายใต้ขีดจำกัดเดิมที่ 1,232 ไบต์ ธุรกรรมอะตอมมิกคือโครงสร้างที่งานหลายอย่างต้องสำเร็จหรือล้มเหลวไปพร้อมกันทั้งหมด

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

ถึงอย่างนั้น v1 ก็ไม่ได้แก้ปัญหาคอขวดทั้งหมดของเครือข่าย คำอธิบายอย่างเป็นทางการของโซลานาระบุว่า v1 ช่วยให้ทีมวาลิเดเตอร์ (validator) และทีมไคลเอนต์สามารถอ่านค่าธรรมเนียมและคำขอทรัพยากรได้เร็วขึ้นตั้งแต่ต้น แต่สำหรับนักพัฒนาแอปพลิเคชัน ขีดจำกัดจำนวนบัญชีสูงสุด 64 บัญชีต่อธุรกรรมยังคงเป็นข้อจำกัดที่หลงเหลืออยู่

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

ในสภาพแวดล้อมทดสอบระดับโลคัล การทดลองใช้งานเปิดให้ทำได้ก่อนแล้ว ตัวอย่างจากคลังโค้ดของโซลานาระบุว่า 'feature gate' ชื่อ enable_tx_v1 ถูกเปิดใช้งานไว้แล้วใน solana-test-validator แต่โค้ดระดับรันไทม์กำหนดให้ปฏิเสธธุรกรรมแบบ v1 ด้วยสถานะ UnsupportedVersion หากฟีเจอร์เกตนี้ยังไม่ถูกเปิดในคลัสเตอร์นั้น จึงจำเป็นต้องตรวจสอบสถานะการเปิดใช้งานเป็นรายคลัสเตอร์

คริปโตบรีฟฟิ่ง(Crypto Briefing) รายงานว่าธุรกรรมแบบ v1 อาจเริ่มเข้าสู่เทสต์เน็ต (testnet) ได้ภายในไม่กี่สัปดาห์ข้างหน้า อย่างไรก็ตาม ตามเอกสารทางการของโซลานา สถานะล่าสุดยังคงอยู่ระหว่างรอการเปิดใช้งาน การนำไปใช้จริงบนเมนเน็ต (mainnet) และกำหนดเวลาที่ชัดเจนยังต้องยืนยันผ่านสถานะการเปิดใช้ฟีเจอร์อย่างเป็นทางการอีกครั้ง

การอัปเกรดครั้งนี้เป็นเรื่องของการเปลี่ยนแปลงโครงสร้างพื้นฐานด้านการพัฒนา มากกว่าจะเป็นประเด็นเกี่ยวกับทิศทางราคา กระเป๋าเงินดิจิทัล ระบบ RPC ระบบดัชนี และเครื่องมือพัฒนาต่าง ๆ จำเป็นต้องตรวจสอบว่ารองรับการแปลผลธุรกรรมแบบ v1 และอ็อบเจ็กต์ transactionConfig หรือไม่ ธุรกรรมรูปแบบ v0 และรูปแบบเดิมยังคงใช้งานได้ตามปกติ แต่บริการที่ต้องการใช้ธุรกรรมขนาดสูงสุด 4,096 ไบต์ จำเป็นต้องรองรับรูปแบบใหม่นี้ก่อน