Solana(SOL) bỏ phiếu đổi cách tính phí giao dịch theo tài nguyên

Solana(SOL) đang tiến hành bỏ phiếu on-chain về phương án chuyển cách tính phí giao dịch, từ tính theo số chữ ký sang tính theo tài nguyên yêu cầu. Bất kể kết quả bỏ phiếu ra sao, vấn đề đang nổi lên là mức độ chính xác khi ví, router và ứng dụng giao dịch yêu cầu tài nguyên tính toán, bởi điều này ảnh hưởng trực tiếp đến chi phí người dùng phải trả.

Tài liệu cải tiến Solana mang mã SIMD-0553 đề xuất tách mức phí 5.000 lamport cho mỗi chữ ký hiện tại thành hai phần: phí cơ bản cố định 2.500 lamport và phí tài nguyên tính theo requested_cost_units (đơn vị chi phí tài nguyên được yêu cầu). Phí tài nguyên được đốt toàn bộ, trong khi phí ưu tiên vẫn thuộc về validator như cơ chế hiện hành.

Tài liệu chính thức về phí của Solana mô tả mức phí cơ bản hiện nay là 5.000 lamport cho mỗi chữ ký, trong đó một nửa bị đốt và một nửa chuyển cho validator. Tài liệu về ngân sách tính toán (compute budget) của Solana cũng nêu rõ phí ưu tiên được tính dựa trên giới hạn đơn vị tính toán (compute unit) mà giao dịch yêu cầu, chứ không dựa trên lượng tài nguyên thực tế đã sử dụng.

Điểm mấu chốt của đề xuất lần này không đơn thuần là tăng phí. Đây là cấu trúc phản ánh sát hơn lượng tài nguyên mà một giao dịch đòi hỏi từ mạng lưới vào giá phí. Trước đây, phí cơ bản chủ yếu xoay quanh chi phí xác minh chữ ký, nhưng đề xuất mới đưa thêm các yếu tố như khóa ghi (write lock), dữ liệu lệnh (instruction data), thực thi chương trình và kích thước dữ liệu tài khoản được tải vào căn cứ tính phí.

requested_cost_units là đơn vị chi phí tài nguyên được yêu cầu trước khi giao dịch thực thi. Căn cứ tính phí là giá trị yêu cầu trước, không phải tài nguyên thực tế đã tiêu tốn. Ứng dụng nào đặt ngân sách tính toán càng rộng rãi thì gánh nặng chi phí trong cấu trúc mới càng có thể tăng.

Đề xuất đưa ra cơ chế feature gate, nâng dần tỷ lệ phí tài nguyên qua các mốc 1/10, 1/4 rồi 1/2 lamport, thay vì áp dụng ngay mức phí cuối cùng. Đây là thiết kế kích hoạt theo từng giai đoạn. Tuy nhiên, việc tài liệu được thông qua không đồng nghĩa với việc áp dụng ngay trên mainnet.

Crypto Briefing dẫn kết quả mô phỏng cho biết lượng SOL bị đốt mỗi ngày có thể tăng từ khoảng 648 SOL hiện nay lên mức 1.500-9.000 SOL nếu áp dụng mức phí cuối cùng. Cùng báo cáo này nhận định các ứng dụng và router xử lý khối lượng lớn như Jupiter, Titan, DFlow có thể chịu áp lực tăng phí trung bình. Đây là con số ước tính theo mô hình, không phải số liệu quan sát thực tế.

Mức độ ảnh hưởng có thể khác nhau giữa từng ứng dụng, tùy vào việc yêu cầu tài nguyên được tính toán chính xác đến đâu. Ứng dụng dạng router thường xử lý nhiều đường dẫn giao dịch và tài khoản cùng lúc, nên quy mô tài nguyên yêu cầu có xu hướng lớn hơn. Ngược lại, một số phân tích cho rằng giao dịch xác nhận (vote transaction) hiệu quả có thể có chi phí thấp hơn trong cấu trúc mới.

Solana Company, trong thông báo ngày 21, tuyên bố phản đối SGP-0003. Công ty này cho rằng mức phí cố định giúp người dùng tổ chức dễ dự trù ngân sách hơn. Theo giải thích của công ty, nếu biến động chi phí giao dịch trước khi hệ sinh thái kịp thích ứng, rủi ro trong việc ước tính chi phí sẽ chuyển sang cho người dùng và bên vận hành.

Cuộc thảo luận lần này gắn liền hai văn bản: SIMD-0553 là tài liệu kỹ thuật quy định cách tính phí, còn SGP-0003 là đề xuất quản trị mang tính bỏ phiếu tín hiệu on-chain, hỏi liệu mạng lưới có nên đi theo hướng đó hay không. Tài liệu quản trị của Solana nêu rõ một SGP sẽ chuyển sang giai đoạn bỏ phiếu chính thức nếu nhận được sự ủng hộ từ 15% cổ phần đang hoạt động (active stake).

Bản cập nhật dành cho nhà phát triển Solana ngày 23 tháng 7 cho biết SIMD về phí tài nguyên và phí bao gồm (Resource and Inclusion Fees) đã đạt trạng thái “accepted”. Điều này đồng nghĩa tài liệu đã được thông qua, nhưng chưa xác định thời điểm kích hoạt trên mainnet hay áp dụng feature gate. Trang Validator Info hiện hiển thị SGP-0003 ở trạng thái đang bỏ phiếu (Voting).

Thời điểm kết thúc bỏ phiếu được các nguồn công bố không thống nhất. Một số nguồn quy đổi thời điểm kết thúc là 0h30 ngày 27 theo giờ Hàn Quốc, tương đương khoảng 22h30 ngày 26 theo giờ Việt Nam, trong khi nguồn khác lại ghi ngày 27 hoặc ngày 28. Tại thời điểm bài viết được thực hiện, chưa thể xác định một mốc thời gian duy nhất cho việc kết thúc bỏ phiếu.

Đợt bỏ phiếu này là phần tiếp nối của thông tin TokenPost từng đưa, theo đó các validator của Solana đang bỏ phiếu cho một đề xuất quản trị xử lý đồng thời tốc độ phát hành mới và cấu trúc phí giao dịch.

Cũng trong thông báo ngày 21, Solana Company cho biết ủng hộ SGP-0001 nhưng phản đối SGP-0003. Điểm tranh cãi chính không nằm ở việc có cần thay đổi cấu trúc kinh tế của mạng lưới hay không, mà nằm ở thời điểm thực hiện và khả năng dự đoán chi phí.

Chi phí thực tế mà người dùng phải trả, cũng như mức điều chỉnh khác nhau giữa các ứng dụng, sẽ chỉ rõ ràng sau khi có kết quả bỏ phiếu, sau khi feature gate được áp dụng và sau khi ví cùng SDK được cập nhật. Điều có thể xác nhận ở thời điểm hiện tại là Solana đang dùng quy trình on-chain để hỏi liệu mạng lưới có nên phản ánh thêm chi phí cho các giao dịch yêu cầu nhiều tài nguyên, trong khi vẫn giữ lợi thế phí thấp vốn có.