Slot rút còn 350ms, Solana(SOL) đồng thời hạ giới hạn tính toán mỗi slot

Solana(SOL) đang triển khai bản cập nhật giao thức nhằm rút ngắn dần thời gian slot – đơn vị tạo khối – từ 400 mili giây, đồng thời hạ giới hạn tính toán cho mỗi slot. Đây không đơn thuần là tăng tốc độ, mà là cách điều chỉnh khối lượng công việc mạng phải xử lý trong một lần, nhằm kiểm soát gánh nặng cho validator.

Solana Foundation cho biết trong nhật ký thay đổi (changelog) ngày 6 tháng 8 rằng cổng tính năng (feature gate) hạ slot từ 400 mili giây xuống 350 mili giây đã được đưa vào devnet và testnet. Nhật ký ngày 13 tháng 8 ghi nhận việc chuyển từ 350 mili giây xuống 300 mili giây đã hoàn tất trên testnet và devnet, còn việc chuyển từ 300 mili giây xuống 250 mili giây đang được triển khai trên testnet.

Trên mainnet, việc kích hoạt tính năng của Agave v4.2 được lên lịch bắt đầu từ ngày 17 tháng 8. Tuy nhiên, tài liệu lịch trình phát hành Agave v4.2 nêu rõ đây chỉ là mốc thời gian tạm thời và có thể thay đổi. Vì vậy, nên hiểu đây là giai đoạn bắt đầu kích hoạt tính năng trên mainnet, chứ chưa phải là mainnet đã hoàn tất chuyển sang slot 350 mili giây.

Điểm mấu chốt là việc rút ngắn thời gian slot và giảm giới hạn tính toán diễn ra song song. Bản dự thảo đề xuất cải tiến Solana SIMD-0525 đưa ra bốn giai đoạn hạ thời gian slot, từ 400 mili giây xuống lần lượt 350, 300, 250 và 200 mili giây. Mỗi giai đoạn vẫn giữ nguyên cấu trúc 64 tick, cửa sổ leader 4 slot và epoch 432.000 slot, nhưng giới hạn công việc trên mỗi slot sẽ được giảm tỷ lệ thuận theo thời gian slot mục tiêu.

Slot là đơn vị thời gian mà validator được phân bổ để tạo khối. Thời gian slot càng ngắn, cơ hội tạo khối càng đến thường xuyên hơn, nhưng gánh nặng xử lý, lan truyền và xác thực trong mỗi slot cũng tăng theo. Vì vậy, nếu mức độ rút ngắn không được điều chỉnh đồng bộ với giới hạn công việc, tỷ lệ bỏ qua khối (skip rate) hoặc lỗi tính toán thời gian ở các hệ thống bên ngoài có thể trở thành vấn đề.

Trước đó, Solana đã nâng giới hạn tính toán mỗi khối trên mainnet từ 60 triệu CU lên 100 triệu CU. Tài liệu 100M CU Blocks giải thích tính năng này đã được kích hoạt trên mainnet vào ngày 29 tháng 7, khi đó thời gian khối 400 mili giây vẫn được giữ nguyên. Bảng của SIMD-0525 lấy mốc 100 triệu CU làm chuẩn, đưa ra giới hạn CU tối đa mỗi khối là 87,5 triệu ở giai đoạn 350 mili giây, 75 triệu ở giai đoạn 300 mili giây, 62,5 triệu ở giai đoạn 250 mili giây và 50 triệu ở giai đoạn 200 mili giây.

Về bản chất, cấu trúc này thiên về việc tạo slot thường xuyên hơn nhưng giảm khối lượng công việc chứa trong mỗi slot, hơn là đẩy mạnh giới hạn xử lý lý thuyết mỗi giây. Tài liệu của Solana Foundation giải thích rằng slot ngắn hơn giúp giảm độ trễ xác nhận và tính chung cuộc (finality); nếu vẫn giữ cửa sổ leader 4 slot, thời gian leader phụ trách tạo khối sẽ giảm từ 1,6 giây (ở mốc 400 mili giây) xuống còn 1,4 giây (ở mốc 350 mili giây).

Bản dự thảo SIMD-0525 quy định rằng sau khi cổng tính năng được kích hoạt, giới hạn mới vẫn cần trải qua độ trễ 1 epoch mới có hiệu lực. Đây không phải là cơ chế áp dụng ngay tiêu chuẩn slot rút ngắn ngay sau khi kích hoạt, mà là thiết kế để mạng chấp nhận giới hạn mới ở epoch tiếp theo. Quy trình này nhằm giảm lỗi đánh giá tính hợp lệ có thể phát sinh nếu áp dụng giới hạn mới quá sớm trong quá trình xử lý Turbine và Shred.

Đợt điều chỉnh lần này nối tiếp một bài viết trước đó của TokenPost, trong đó cho biết dù đã qua mốc mục tiêu của Agave 4.2, việc kích hoạt cổng tính năng trên mainnet vẫn là một quy trình riêng biệt. Việc phát hành phần mềm và việc kích hoạt cổng tính năng giao thức không phải là một. Dù validator đã chuẩn bị sẵn client mới, thời điểm quy tắc mạng thực sự thay đổi vẫn phải được xác định dựa trên cả cổng tính năng lẫn quy tắc trễ epoch.

Thay đổi này cũng có thể ảnh hưởng đến ví, RPC và explorer. Bản dự thảo SIMD-0525 cảnh báo rằng các hằng số SDK và logic quy đổi slot sang thời gian có thể vẫn dựa trên mốc 400 mili giây trong một thời gian. Nếu cluster đang vận hành theo mốc 350, 300, 250 hoặc 200 mili giây nhưng hệ thống bên ngoài vẫn dùng cách tính thời gian cũ, thời gian hết hạn hoặc giá trị hiển thị có thể bị sai lệch.

Chi phí vận hành của validator cũng là vấn đề đáng chú ý. Trong một thảo luận trên GitHub, có ý kiến cho rằng nếu slot nhanh hơn, gánh nặng chi phí bỏ phiếu tính theo thời gian thực (wall clock) có thể tăng lên. Lập luận đưa ra là khi số lượng slot tăng, tần suất bỏ phiếu và xác thực cần xử lý trong cùng một khoảng thời gian thực tế cũng sẽ tăng theo.

Brennan Watt, đại diện của Anza, phát biểu trong cùng thảo luận này: “SIMD #525 has been merged and Agave implementation has been completed” (đề xuất cải tiến SIMD #525 đã được hợp nhất và việc triển khai trên Agave đã hoàn tất). Điều này cho thấy dù việc hợp nhất đề xuất cải tiến và triển khai trên Agave đã xong, chi phí vận hành và việc kiểm tra tính tương thích vẫn là những vấn đề còn bỏ ngỏ.

Tổng quan phát hành Agave v4.2 cho biết cùng với việc rút ngắn thời gian slot, bản phát hành này còn bao gồm việc mở rộng kích thước giao dịch và giảm chi phí rent. Điều này cho thấy bản cập nhật lần này không chỉ đơn thuần cải thiện tốc độ, mà là một gói nâng cấp gộp nhiều tính năng của cả client lẫn giao thức.

Đối với người dùng, bên cạnh tốc độ cảm nhận được, điều quan trọng không kém là việc ví, sàn giao dịch và các nhà cung cấp hạ tầng có phản ánh đúng tiêu chuẩn thời gian slot mới hay không. Dù thời gian slot đã giảm, nếu thời gian hết hạn, giá trị hiển thị và logic theo dõi giao dịch của các dịch vụ bên ngoài vẫn dựa trên mốc 400 mili giây, người dùng thực tế vẫn có thể gặp nhầm lẫn.

Tài liệu lịch trình Agave v4.2 ghi ngày bắt đầu kích hoạt tính năng trên mainnet là 17 tháng 8, ngày phát hành (delivery) là 18 tháng 8. Do lịch trình vẫn mang tính tạm thời, các bước tiếp theo cần được xác nhận dựa trên việc cổng tính năng có được kích hoạt hay không và quy tắc áp dụng epoch.

Nguồn kiểm chứng: SIMD-0525, Solana Changelog ngày 6 tháng 8, Solana Changelog ngày 13 tháng 8, Lịch trình Agave v4.2, 100M CU Blocks, Tổng quan Agave 4.2