Solana(SOL) mở rộng giới hạn giao dịch v1 lên 4.096 byte, chờ kích hoạt chính thức

Solana (SOL) đang chuẩn bị nâng cấp định dạng giao dịch v1, mở rộng kích thước giao dịch tối đa từ 1.232 byte lên 4.096 byte, tức gấp khoảng 3,3 lần so với giới hạn hiện tại.

Theo tài liệu nâng cấp chính thức của Solana Foundation, tính năng “Larger Transaction Sizes” hiện được xếp vào nhóm “Pending Feature Activation” (chờ kích hoạt). Thay đổi này dựa trên hai đề xuất kỹ thuật SIMD-0296 và SIMD-0385. Bảng điều khiển nâng cấp chính thức ghi nhận phiên bản Agave 4.2 dự kiến triển khai vào tháng 8/2026, nhưng tính năng mở rộng kích thước giao dịch vẫn đang ở trạng thái chờ kích hoạt.

Giới hạn 1.232 byte hiện tại, theo tài liệu SIMD-0296, xuất phát từ thiết kế MTU 1.280 byte của IPv6. Sau khi trừ phần header, phần payload thực tế dành cho giao dịch chỉ còn 1.232 byte. Solana cho rằng việc triển khai giao thức QUIC đã tạo điều kiện gửi các giao dịch lớn hơn, nên đề xuất nâng giới hạn mới lên 4.096 byte. Nói cách khác, đây là bước điều chỉnh lại giới hạn giao dịch vốn được thiết lập theo ràng buộc kích thước gói tin cũ, trong bối cảnh cấu trúc truyền tải mạng đã thay đổi.

Định dạng v1 không thay thế định dạng v0 và giao dịch kiểu cũ (legacy) hiện có. Các ứng dụng, ví và công cụ index muốn dùng kích thước giao dịch lớn hơn sẽ phải hỗ trợ định dạng mới. Tài liệu RPC của Solana quy định rằng để nhận thông điệp v1, yêu cầu gửi lên phải đặt tham số maxSupportedTransactionVersion: 1.

Theo tài liệu RPC, thông điệp v1 đi kèm đối tượng transactionConfig chứa giới hạn tính toán, giới hạn dung lượng dữ liệu và phí ưu tiên, cụ thể gồm computeUnitLimit, loadedAccountsDataSizeLimit và priorityFee. Cách làm này khác với phương thức cũ là chèn yêu cầu tài nguyên bằng một instruction riêng.

Cấu trúc kỹ thuật cũng thay đổi. SIMD-0385 mô tả giao dịch v1 sử dụng byte phiên bản 129, và thay vì dùng instruction ComputeBudgetProgram như trước, yêu cầu tài nguyên được đưa vào mặt nạ cấu hình (config mask) ngay trong header giao dịch. Định dạng v1 không hỗ trợ bảng tra cứu địa chỉ (Address Lookup Table - ALT).

ALT là cơ chế giúp giảm dung lượng giao dịch bằng cách tham chiếu đến một bảng địa chỉ bên ngoài thay vì liệt kê toàn bộ địa chỉ trong giao dịch. Định dạng v1 dựa trên giả định rằng với giới hạn 4.096 byte, phần lớn trường hợp có thể liệt kê trực tiếp danh sách địa chỉ mà không cần ALT. Tuy nhiên, hiệu quả mở rộng giới hạn có thể bị hạn chế đối với các tác vụ phụ thuộc nhiều vào ALT.

Thay đổi này giúp nhà phát triển có thêm không gian cho một giao dịch nguyên tử (atomic transaction) duy nhất — tức cấu trúc mà nhiều thao tác cùng thành công hoặc cùng thất bại. Solana Foundation cho biết các tác vụ như chứng minh không tiết lộ tri thức (zero-knowledge proof), đa chữ ký (multisig) quy mô lớn, xử lý theo lô (batch) và một số cấu trúc chữ ký on-chain trước đây khó gói gọn trong một giao dịch do giới hạn 1.232 byte.

Với các tác vụ DeFi phức tạp hoặc xử lý đa chữ ký cấp tổ chức, thay đổi này có thể giảm bớt việc phải chia nhỏ giao dịch thành nhiều bước. Như TokenPost từng đưa tin, lượng giao dịch hàng tuần của Solana tăng lên, nhưng mối liên hệ với doanh thu phí, hoạt động của nhà phát triển và nhu cầu token cần được xem xét bằng các chỉ số riêng — cho thấy các chỉ số xử lý mạng nên được nhìn nhận cùng với thay đổi hạ tầng.

Dù vậy, định dạng v1 không giải quyết mọi điểm nghẽn. Theo giải thích chính thức từ Solana, v1 giúp validator và các nhóm phát triển client đọc được yêu cầu phí và tài nguyên sớm hơn trong quá trình xử lý. Ngược lại, đối với nhà phát triển ứng dụng, giới hạn 64 tài khoản trong một giao dịch vẫn là một ràng buộc chưa được gỡ bỏ.

Trong các cuộc thảo luận trên GitHub, giới phát triển đưa ra cả kỳ vọng lẫn hoài nghi. Một số ý kiến cho rằng kích thước giao dịch lớn hơn sẽ hữu ích cho các thao tác hoán đổi (swap) phức tạp, DeFi thao tác một cú nhấp (one-click DeFi) và thanh lý nguyên tử (atomic liquidation). Ở chiều ngược lại, có ý kiến cho rằng hiệu năng mạng, việc phân mảnh gói tin, băng thông validator và thiết kế phí mới là những yếu tố quan trọng hơn.

Trên môi trường kiểm thử cục bộ, khả năng thử nghiệm đã được mở trước. Kho mã ví dụ của Solana cho biết cổng tính năng enable_tx_v1 đã được kích hoạt sẵn trên solana-test-validator. Tuy nhiên, mã runtime hiện quy định rằng nếu cổng tính năng chưa bật, giao dịch v1 sẽ bị từ chối với lỗi UnsupportedVersion, do đó cần kiểm tra riêng trạng thái kích hoạt trên từng cụm mạng (cluster).

Crypto Briefing đưa tin giao dịch v1 có thể được đưa vào testnet trong vài tuần tới. Tuy nhiên, theo tài liệu chính thức của Solana, trạng thái hiện tại vẫn là chờ kích hoạt. Việc áp dụng trên mainnet cũng như thời gian cụ thể cần được xác nhận dựa trên trạng thái kích hoạt tính năng chính thức.

Nhìn chung, đây là thay đổi thuộc về hạ tầng phát triển hơn là yếu tố liên quan đến biến động giá. Các ví, dịch vụ RPC, công cụ index và công cụ phát triển cần kiểm tra khả năng phân tích giao dịch v1 và hỗ trợ đối tượng transactionConfig. Giao dịch v0 và kiểu cũ vẫn tiếp tục hoạt động bình thường, nhưng các dịch vụ muốn sử dụng giao dịch 4.096 byte sẽ cần hỗ trợ định dạng mới này.