4.096 byte giao dịch: Solana(SOL) rà soát tương thích hệ thống trước khi kích hoạt định dạng v1

Định dạng giao dịch mới v1 của Solana(SOL) đang được rà soát khả năng tương thích hạ tầng trước khi kích hoạt trên mainnet. Thay đổi lần này nâng kích thước tối đa của một giao dịch từ 1.232 byte lên 4.096 byte, nhưng điểm đáng chú ý không nằm ở nguy cơ gián đoạn đồng thuận của chuỗi, mà ở việc liệu RPC, indexer, gRPC và các dịch vụ tài trợ phí (fee sponsor) có đọc đúng định dạng mới hay không.

Quỹ Solana (Solana Foundation) cho biết trên trang nâng cấp mạng lưới rằng client Agave 4.2 đã được triển khai trên mainnet, nhưng tính năng “Larger Transaction Sizes” vẫn đang ở trạng thái chờ kích hoạt, tính đến ngày 4/9. Tính năng này mở rộng giới hạn giao dịch hiện tại lên khoảng 3,3 lần thông qua định dạng giao dịch v1.

Đây không đơn thuần là việc tăng kích thước. SIMD-0296 và SIMD-0385 đưa ra bối cảnh sử dụng gồm đa chữ ký (multisig) quy mô lớn, bằng chứng không tiết lộ thông tin (ZK proof) và chuyển giao theo lô. Trong v1, mức phụ thuộc vào bảng tra cứu địa chỉ (address lookup table) mà các giao dịch trước đây sử dụng được giảm bớt, đồng thời thông tin về phí và giới hạn tài nguyên được chuyển sang một cấu hình riêng gọi là transactionConfig.

Cách đọc dữ liệu của hệ thống hiện tại có thể gây vấn đề ở điểm này. Nếu indexer và dịch vụ tài trợ phí chỉ quét instruction ComputeBudget để tính phí ưu tiên hay giới hạn compute unit, họ có thể bỏ sót fee cap của giao dịch v1 hoặc đọc nhầm giá trị này bằng 0. Kho mã mẫu transaction-v1 của Quỹ Solana giải thích rằng message v1 chứa TransactionConfig thay vì instruction ComputeBudget.

Tài liệu RPC của Solana hướng dẫn rằng các lệnh gọi getTransaction, getBlock, blockSubscribe cần thêm tham số maxSupportedTransactionVersion: 1. Nếu bỏ qua tham số này hoặc để giá trị bằng 0, getTransaction có thể báo lỗi khi gặp giao dịch v1, còn getBlock có thể thất bại khi đọc toàn bộ khối chứa giao dịch đó.

Kênh đăng ký qua websocket cũng không ngoại lệ. blockSubscribe có thể trả về block: null nếu cấu hình không đúng. Tài liệu phát triển của Solana lưu ý cần xử lý trường hợp này như một lỗi, chứ không phải một khối rỗng. Giao dịch v1 được nhận diện qua byte đầu tiên của giao dịch đã serialize, có giá trị 129, tức 0x81.

Ở nhánh gRPC và Geyser, lỗi có thể xảy ra âm thầm hơn. Tài liệu phát triển của Solana cảnh báo rằng gRPC không có tùy chọn kiểu opt-in như maxSupportedTransactionVersion, và các stub protobuf cũ có thể làm mất trường Message.config. Trong trường hợp này hệ thống không dừng hoạt động, nhưng có thể coi giao dịch v1 như v0 và bỏ sót cấu hình phí.

Kho mã mẫu của Quỹ Solana đưa ra các phiên bản tối thiểu gồm @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0 và yellowstone-grpc geyser 15.1.1, đồng thời cung cấp riêng các ví dụ về đọc dữ liệu, gửi giao dịch, lập chỉ mục khối và gRPC.

Việc kiểm chứng ở phía công cụ lõi cũng đang tiếp diễn. Issue #831 trên kho solana-sdk của anza-xyz nêu vấn đề giới hạn tối đa 4.096 byte của v1 chưa được áp dụng chặt chẽ trong bộ giải mã (deserializer) và bộ kiểm tra hợp lệ (sanitizer). Dù vậy, trang trạng thái của Solana cho thấy tính đến ngày 4/9, các nút RPC của Mainnet Beta vẫn hoạt động bình thường và không ghi nhận sự cố nào trong ngày.

Vấn đề lần này mang tính chất kiểm tra tương thích hạ tầng liên quan đến việc mở rộng giới hạn giao dịch v1 của Solana. Nếu trước đây trọng tâm là giới hạn 4.096 byte và việc kích hoạt tính năng theo từng cụm mạng, thì lần này điểm mấu chốt là hệ thống backend có đọc được cấu trúc mới hay không khi giao dịch v1 thực sự xuất hiện.

Trang nâng cấp của Solana cho thấy tính năng “Larger Transaction Sizes” vẫn ở trạng thái chờ kích hoạt, tính đến ngày 4/9. Lịch trình này không phải một sự kiện thay đổi toàn bộ cấu trúc xử lý của Solana trong một lần, mà giống một lộ trình kỹ thuật đòi hỏi ví, RPC, indexer và công cụ phát triển lần lượt chuẩn bị sẵn sàng.

Về mặt kỹ thuật, giao dịch v1 không thay thế các giao dịch v0 và giao dịch legacy hiện có. Các định dạng cũ vẫn tiếp tục hoạt động bình thường, nhưng những ứng dụng muốn dùng kích thước giao dịch lớn hơn cùng transactionConfig bắt buộc phải hỗ trợ định dạng mới. Trong các đợt nâng cấp hạ tầng blockchain nói chung, rủi ro vận hành thực tế thường không chỉ nằm ở quy tắc đồng thuận, mà còn ở khả năng tương thích của các hệ thống xung quanh phụ trách đọc và lưu trữ dữ liệu.

Dịch vụ tài trợ phí và indexer là nhóm dễ chịu ảnh hưởng nhất. Nếu đọc sai mức phí tối đa hay giới hạn compute unit, các dịch vụ đứng ra trả phí thay người dùng có thể rơi vào cơ cấu chi phí khác với dự tính, còn hệ thống phân tích giao dịch cũng có thể ghi nhận sai cấu hình tài nguyên của giao dịch v1. Đây không phải sự cố khiến chuỗi ngừng hoạt động, nhưng vẫn là khu vực mà các đơn vị vận hành dịch vụ cần kiểm tra riêng.

Các sàn giao dịch và đơn vị cung cấp ví trong nước có vận hành nạp/rút và giám sát on-chain trên Solana cũng không nằm ngoài vấn đề này. Thay vì chỉ tập trung vào bản thân giao dịch, cần kiểm tra xem các đường xử lý tra cứu khối, giao dịch, lập chỉ mục, giám sát rủi ro và tính phí có xử lý được cấu trúc message v1 hay không. Đặc biệt, nếu sử dụng nhà cung cấp node bên ngoài hoặc dữ liệu dựa trên Geyser, cần tạo lại protobuf và kiểm tra phiên bản thư viện đang dùng.

Trước khi giao dịch v1 của Solana thực sự xuất hiện phổ biến, các hạng mục cần kiểm tra chính gồm △thiết lập maxSupportedTransactionVersion: 1 trong tùy chọn gọi RPC △phản ánh đường lưu trữ transactionConfig △tạo lại stub protobuf cho gRPC △khả năng nhận diện tiền tố phiên bản 0x81. Theo trang nâng cấp của Solana, tính năng “Larger Transaction Sizes” vẫn đang ở trạng thái chờ kích hoạt tính đến ngày 4/9.