Solana cập nhật phần mềm validator và công cụ phát triển quanh đợt chuyển đổi Alpenglow

Quỹ Solana (Solana Foundation) đã công bố các phiên bản mới của phần mềm validator và công cụ phát triển trước và sau khi mạng lưới chuyển sang cơ chế đồng thuận Alpenglow. Các bản cập nhật cũng đề cập đến điều kiện vận hành validator và cách xử lý dữ liệu khối.

Theo nhật ký thay đổi dành cho nhà phát triển do Quỹ Solana đăng ngày 22 tháng 10, các bản cập nhật gồm Agave v4.3.2, Firedancer (Firedancer) bản mainnet v26.10.4, Web3.js v3.1.1 và một số SDK JavaScript. Trong đó có SDK cho bảng tra cứu địa chỉ và các chương trình stake, system, token. SDK là bộ công cụ dùng để phát triển ứng dụng và chương trình.

Các phiên bản được phát hành vào những ngày khác nhau: Agave v4.3.2 ngày 15 tháng 10, Web3.js v3.1.1 ngày 19 tháng 10 và Firedancer v26.10.4 ngày 21 tháng 10. Agave và Web3.js ra mắt trước khi Alpenglow được kích hoạt; Firedancer ra mắt cùng ngày, nên chỉ dựa vào ngày phát hành thì không thể xác định bản này ra mắt trước hay sau thời điểm kích hoạt.

Solana (SOL) kích hoạt Alpenglow trên mainnet tại epoch 1064, bắt đầu lúc 22 giờ 36 ngày 21 tháng 10 (giờ Hàn Quốc, KST). Quá trình chuyển đổi này thay đổi cách các validator thống nhất thứ tự giao dịch và trạng thái cuối cùng.

Hướng dẫn chuyển đổi của Quỹ Solana cho biết mạng lưới duy trì TowerBFT trong khoảng 5.000 slot, sau đó cơ chế đồng thuận mới bắt đầu hoạt động từ slot thứ 459.653.000. Trong thông báo về đợt chuyển đổi ngày 21 tháng 10, quỹ đặt mục tiêu rút thời gian hoàn tất giao dịch từ khoảng 12,8 giây xuống khoảng 150 mili giây.

Mốc 150 mili giây chưa phải kết quả đo thực tế. TokenPost từng đưa tin thời gian hoàn tất trong giai đoạn đầu vận hành mainnet là 6,6 giây và mục tiêu 0,15 giây vẫn chưa đạt được.

Alpenglow không làm thay đổi cách thực thi chương trình, định dạng giao dịch hay cơ chế phí. Tuy nhiên, giao dịch bỏ phiếu của validator đã bị loại khỏi khối, còn hai trạng thái giao dịch 'confirmed' và 'finalized' nay chỉ cùng một trạng thái. Các mục tick của Proof of History (PoH) cũng không còn trong luồng dữ liệu.

Những nhà phát triển thống kê số giao dịch trong khối hoặc lập chỉ mục luồng dữ liệu cần rà soát lại tiêu chí xử lý. Các chỉ số từng tính cả giao dịch bỏ phiếu có thể khó so sánh theo cùng một cơ sở giữa trước và sau chuyển đổi. Thay đổi này xuất phát từ việc kích hoạt Alpenglow, độc lập với các bản cập nhật SDK.

Ghi chú phát hành Firedancer v26.10.4 cho biết bản cập nhật sửa lỗi khiến lưu lượng và tải xử lý tăng do bảng gossip giữa Agave và Firedancer không nhất quán. Thuật toán khôi phục khi nút bị tụt lại cũng được điều chỉnh. Nhật ký thay đổi của quỹ ghi nhận Firedancer đã tham gia cơ chế đồng thuận mới.

Tuy vậy, điều kiện hỗ trợ tại thời điểm chuyển đổi là vấn đề riêng. Hướng dẫn của Quỹ Solana nêu rõ khi đó Firedancer và Frankendancer (Frankendancer) chưa hỗ trợ quá trình di chuyển, nên validator phải dùng ứng dụng khách dựa trên Agave. Không nên nhầm các bản phát hành sau đó hoặc ghi nhận về việc tham gia cơ chế mới với tình trạng sử dụng tại thời điểm chuyển đổi.

Validator phải giữ trong tài khoản bỏ phiếu lượng SOL cao hơn số dư tối thiểu được miễn trừ ít nhất 0,8 SOL. Quỹ cho biết khoản này được dùng cho 'Vé tham gia validator' (Validator Admission Ticket). Validator không đáp ứng điều kiện có thể mất quyền bỏ phiếu và tạo khối ở epoch tiếp theo.

Nhật ký thay đổi Agave cũng nêu một số cải tiến vẫn đang được thực hiện: điều chỉnh bộ đệm để giảm lỗi trang trong hoạt động vào ra của hệ thống tệp; xử lý thông điệp gossip có tính đến quy mô stake; và tải snapshot ít phụ thuộc hơn vào danh sách stake của tài khoản. Một bước kiểm tra CLI để loại các phiên bản chương trình sBPF không được hỗ trợ trước khi tải lên cũng đang được chuẩn bị.

Web3.js v3.1.1 là bản cập nhật tiếp theo của dòng v3. TokenPost từng đưa tin ngày 6 tháng 10 rằng việc Web3.js v3 ra mắt khiến một số ứng dụng hiện có cần sửa mã bất đồng bộ.

Nhật ký thay đổi Web3.js cũng đề cập đến việc xem xét chỉ hỗ trợ Transaction V1. Đây là phương án được thảo luận trong trường hợp có đề xuất SIMD riêng nhằm hạn chế định dạng giao dịch legacy và V0, không có nghĩa việc loại bỏ các định dạng cũ đã hoàn tất.