บั๊ก Solana v1 อาจทำให้ตัวอ่านค้างและปิดใช้ขีดจำกัดค่าธรรมเนียม

รูปแบบธุรกรรม v1 ของ Solana เพิ่มขนาดเพย์โหลดสูงสุดจาก 1,232 ไบต์เป็น 4,096 ไบต์ หรือประมาณ 3.3 เท่า ธุรกรรมแบบ legacy และ v0 ยังคงมีขีดจำกัดและพฤติกรรมเดิม ผู้ใช้และแอปพลิเคชันที่ยังใช้รูปแบบเหล่านั้นไม่จำเป็นต้องย้าย ระบบอัปเกรดแบบสดของ Solana ระบุว่า v1 ไม่ได้เปิดใช้งานบนเมนเน็ต ณ วันที่ 4 กันยายน เทสต์เน็ตเปิดใช้งานแล้ว ส่วนดีฟเน็ตทำงานอยู่ใน epoch 1140 บันทึกการเปลี่ยนแปลงของ Solana ที่เผยแพร่เมื่อวันที่ 28 สิงหาคมระบุว่าธุรกรรม v1 กำลังจะมา ผู้ใช้ RPC ต้องรองรับรูปแบบนี้ก่อนอ่านข้อมูล v1 การเลือกใช้เพียงแจ้งบริการ RPC ถึงรูปแบบสูงสุดที่ไคลเอนต์ถอดรหัสได้ ไม่ได้เป็นการขอข้อมูล v1 หรือเปลี่ยนวิธีส่งคืนธุรกรรม legacy และ v0 v1 ย้ายขีดจำกัด compute unit ขีดจำกัดข้อมูลบัญชีที่โหลด และค่าธรรมเนียมลำดับความสำคัญไปไว้ในอ็อบเจ็กต์แทนที่จะอยู่ในคำสั่ง อินเด็กเซอร์ที่ยังสแกนคำสั่งอาจรายงานงบประมาณการคำนวณเป็นศูนย์สำหรับธุรกรรม v1 ทุกธุรกรรมโดยไม่แจ้งข้อผิดพลาด แฟล็ก protobuf เป็น true ทั้งสำหรับ v0 และ v1 ดังนั้นผู้ใช้ Geyser หรือ gRPC ที่ใช้ข้อมูลเก่าอาจระบุ v1 เป็น v0 และคงงบประมาณว่างไว้ ผู้ใช้ต้องสร้าง protobuf stubs ใหม่และตรวจสอบฟิลด์ 7 ก่อนอ่านแฟล็ก รีเลเยอร์ เพย์มาสเตอร์ และผู้ลงนามเซิร์ฟเวอร์อื่น ๆ ต้องอัปเดตการตรวจสอบนโยบาย ผู้สนับสนุนที่สแกนคำสั่งเพื่อหาขีดจำกัดค่าธรรมเนียมอาจไม่สามารถบังคับใช้ขีดจำกัดที่มีผลผูกพันได้อีกต่อไป เพราะคำสั่งเหล่านั้นอาจปรากฏใน v1 แต่ทำงานแบบ no-op เซิร์ฟเวอร์ต้องระบุคำนำหน้า v1 และบังคับใช้ขีดจำกัดค่าธรรมเนียมและทรัพยากรในการกำหนดค่าธุรกรรม บทความจัดประเด็นนี้ว่าเป็นความล้มเหลวในการควบคุมระดับแอปพลิเคชัน ไม่ใช่ข้อบกพร่องของฉันทามติ และระบุว่าปัญหานี้ไม่ใช่หลักฐานว่าเงินทุนมีความเสี่ยงโดยอัตโนมัติ Solana ระบุว่า sysvar หรือ syscall ปัจจุบันไม่มีตัวใดเปิดเผยการกำหนดค่าข้อความ v1 โปรแกรมที่กำหนดพฤติกรรมจากคำสั่งที่ตรวจสอบภายในต้องหยุดพึ่งพาการตรวจสอบดังกล่าวเมื่อ v1 เปิดใช้งาน รุ่นขั้นต่ำที่ระบุว่าสามารถอ่านได้คือ 8.0.0, 3.0.0-rc.3, Rust 4.2.x, Python 0.29.0 และ 1.23.0 สาย web3.js 1.x สามารถอ่าน v1 ได้ตั้งแต่ 1.99.0-beta.0 แต่ไม่สามารถสร้าง ลงนาม หรือส่งธุรกรรมดังกล่าวได้ ผู้ใช้ Yellowstone ต้องมีอย่างน้อย 12.6.0, ปลั๊กอิน geyser 15.1.1, ไคลเอนต์ gRPC 12.0.0 หรือ 6.0.0 ขึ้นอยู่กับสแต็กของตน การสร้างธุรกรรม v1 เป็นทางเลือก ทีมที่สร้างธุรกรรมดังกล่าวต้องกำหนดขีดจำกัด compute unit และข้อมูลบัญชีที่โหลดอย่างชัดเจน เพราะทั้งสองค่าจะเริ่มต้นที่ศูนย์ ต้องลบคำสั่ง no-op ต้องหยุดใช้ตารางค้นหาที่อยู่ และต้องใช้ base64 สำหรับเพย์โหลดที่มีขนาดใหญ่กว่า 1,232 ไบต์ กำหนดเวลาเร่งด่วนคือการทดสอบความเข้ากันได้สำหรับบริการที่อาจอ่าน อินเด็กซ์ หรือสนับสนุนธุรกรรม v1 ของผู้ใช้อื่น