Cập nhật Agave v2.3: Mọi điều bạn cần biết

Giới thiệu

Bản phát hành v2.3 của client validator Agave đánh dấu một bước tiến quan trọng khác của Solana. Tương tự các bản cập nhật trước, phiên bản mới này mang đến những cải tiến thiết yếu nhằm nâng cao cả hiệu suất mạng lẫn trải nghiệm của nhà phát triển.

Những cập nhật đáng chú ý trong Agave 2.3 

• TPU Client mới tpu-client-next
• Tối ưu hóa AccountsDB, giảm mức sử dụng I/O ổ đĩa
• Lịch leader hiện được lập khóa theo tài khoản biểu quyết của validator
• Xác minh sự kiện có thể bị cắt giảm stake
• Bộ lập lịch tham lam được bật theo mặc định
• Cải tiến snapshot
• Nâng cấp gossip
• Chuyển epoch nhanh hơn

Mỗi phần trong bài viết này đều độc lập, giúp người đọc dễ dàng chuyển đến những chủ đề phù hợp nhất với mình. Dù bạn là đơn vị vận hành validator, nhà phát triển hay người dùng tích cực, hướng dẫn toàn diện về Agave 2.3 này sẽ cung cấp những thông tin chuyên sâu cần thiết để tận dụng tối đa các cải tiến mới nhất.

Anza đang đẩy nhanh tiến độ phát hành Agave. Chưa đầy ba tháng sau phiên bản 2.2, phiên bản 2.3 đã đi vào hoạt động, với 13% tổng lượng stake hiện đang chạy các phiên bản của client mới. Mức độ áp dụng dự kiến sẽ tăng nhanh trong những tuần tới. Trong thời gian này, việc kích hoạt feature gate trên mainnet đã tạm dừng trong quá trình triển khai và sẽ sớm tiếp tục theo trình tự kích hoạt đã định.

TPU Client mới

Agave 2.3 giới thiệu một cách triển khai mới cho client của Transaction Processing Unit (TPU), thay thế ConnectionCache trước đây. TPU client này chịu trách nhiệm gửi các transaction đã tuần tự hóa đến validator qua mạng bằng giao thức QUIC. Thiết kế mới, được gọi là tpu-client-next, là một bản làm lại toàn diện nhằm cải thiện đáng kể hiệu suất, giảm mức sử dụng tài nguyên và đơn giản hóa kiến trúc tổng thể.

TPU client được sử dụng trong hai trường hợp chính: trong ForwardingStage, nơi validator chuyển tiếp transaction đến leader sắp tới, và trong SendTransactionService, được RPC sử dụng để chuyển tiếp transaction đến leader.

Cách triển khai trước đây, ConnectionCache, được xây dựng để hỗ trợ cả giao thức UDP và QUIC, khiến nó phức tạp một cách không cần thiết. ConnectionCache dựa vào một hàng đợi bất đồng bộ nội bộ để lưu trữ transaction thay vì một kênh rõ ràng, đồng thời có logic làm nóng bộ nhớ đệm bằng cách gửi các gói tin rỗng. Nó cũng liên tục gặp vấn đề liên quan đến việc quản lý endpoint của Quinn (tức một cách triển khai QUIC bằng Rust).

tpu-client-next mới giải quyết những vấn đề này bằng một thiết kế bất đồng bộ, tinh gọn. Bên trong, nó tuân theo mô hình dựa trên agent, trong đó các tác vụ worker riêng lẻ xử lý từng kết nối QUIC. Các worker này giao tiếp với ConnectionWorkersScheduler tập trung thông qua các kênh bất đồng bộ. 

Khi bộ lập lịch nhận được một lô transaction, lô này sẽ được truyền phát đến tập hợp worker phù hợp theo chiến lược đã cấu hình. Kiến trúc này loại bỏ hoàn toàn multistreaming, qua đó giảm phân mảnh lưu lượng. Các kết nối cũng được thiết lập trước, giúp loại bỏ độ trễ do phải mở stream mới tại thời điểm gửi.

tpu-client-next cho thấy mức cải thiện hiệu suất rõ rệt. 

• Trong các thử nghiệm RPC trên testnet, cả client cũ và mới đều đạt TPS trung bình tương tự khi chịu tải; tuy nhiên, tpu-client-next có độ dao động thấp hơn đáng kể. 
• Trong các trường hợp sử dụng validator, ForwardingStage tăng 10% khối lượng transaction được chuyển tiếp, đồng thời duy trì mô hình lưu lượng ổn định hơn và giảm 30% mức sử dụng CPU.
• Công cụ kiểm thử tải mã nguồn đóng của Anza, transaction-bench, được xây dựng bằng client mới nhất. Công cụ này tạo ra số transaction mỗi giây gấp đôi công cụ kiểm thử trước đó, bench-tps.

tpu-client-next hoàn toàn tương thích ngược và hiện là cách triển khai mặc định cho các node Agave. Nếu phát sinh vấn đề, đơn vị vận hành có thể quay lại hành vi trước đây bằng cách khởi chạy node với cờ --use-connection-cache để khôi phục cách triển khai cũ.

Tóm lại, tpu-client-next mang lại:

• Kiến trúc dựa trên agent, thân thiện với xử lý bất đồng bộ
• Lưu lượng ổn định với độ dao động thấp hơn
• Giảm mức sử dụng CPU và bộ nhớ
• Chính sách lập lịch và xếp hàng có thể cấu hình
• Tích hợp đơn giản hơn và bề mặt API gọn gàng hơn

Lịch leader được lập khóa theo tài khoản biểu quyết

Trong chu kỳ phát hành Agave 2.3, Solana sẽ kích hoạt SIMD-0180: Sử dụng địa chỉ tài khoản biểu quyết để lập khóa cho lịch leader. Thay đổi này điều chỉnh cách mạng xác định validator nào được lên lịch sản xuất block, chuyển từ việc sử dụng địa chỉ danh tính validator sang địa chỉ tài khoản biểu quyết làm khóa chính trong lịch leader.

Quá trình chuyển đổi này giải quyết một điểm mơ hồ tồn tại lâu nay trong giao thức Solana: không thể liên kết đáng tin cậy một validator sản xuất block với một lượng stake cụ thể. Theo thiết kế hiện tại, lịch leader được lập khóa theo địa chỉ danh tính validator. Tuy nhiên, nhiều tài khoản biểu quyết có thể ủy quyền cho cùng một danh tính validator, khiến việc truy ngược hoạt động sản xuất block của một slot cụ thể về một tập hợp stake được ủy quyền trở nên khó khăn.

Bằng cách lập khóa cho lịch leader theo địa chỉ tài khoản biểu quyết, thay đổi này thiết lập mối liên kết rõ ràng và trực tiếp giữa stake được ủy quyền với vai trò leader của validator. Điều chỉnh tưởng chừng nhỏ này mở ra một số khả năng quan trọng.

Thứ nhất, nó cung cấp nền tảng cần thiết cho việc phân phối phần thưởng block, như được quy định trong SIMD-0123, vốn đã vượt qua cuộc biểu quyết quản trị chính thức vào tháng 3. Điều này cho phép validator đặt tỷ lệ hoa hồng trên phí block và phân phối phần doanh thu còn lại theo tỷ lệ cho những người ủy quyền. Hệ thống này tương tự mô hình chia sẻ phần thưởng hiện dùng cho phần thưởng staking do lạm phát, giúp các động lực kinh tế giữa validator và người stake cho họ đồng nhất hơn.

Thứ hai, sử dụng địa chỉ tài khoản biểu quyết để lập khóa cho lịch leader là điều thiết yếu nhằm hỗ trợ cơ chế cắt giảm stake theo chương trình, vốn phạt các validator vi phạm quy tắc mạng bằng cách gửi block trùng lặp hoặc bỏ phiếu trên nhiều fork. Điều này dẫn chúng ta đến cập nhật tiếp theo.

Xác minh sự kiện có thể bị cắt giảm stake

Cắt giảm stake là cơ chế xử phạt validator độc hại bằng cách xác minh hành vi sai phạm on-chain và đốt một phần stake được ủy quyền cho họ. Đây là biện pháp răn đe quan trọng đối với hành vi đe dọa tính bảo mật hoặc ổn định của mạng.

Có hai mô hình cắt giảm stake chính:

Cắt giảm stake theo đồng thuận xã hội (Hệ thống hiện tại trên Solana)

Solana hiện dựa vào cách tiếp cận đồng thuận thủ công do cộng đồng thúc đẩy, được gọi là cắt giảm stake theo đồng thuận xã hội. Theo mô hình này, nếu một validator có hành vi độc hại, chẳng hạn làm tổn hại đến khả năng hoạt động liên tục hoặc tính an toàn của mạng, những người tham gia trung thực có thể phối hợp off-chain để khởi tạo hard fork, khởi động lại mạng và cắt giảm stake của bên vi phạm. Mặc dù phương pháp này cho phép đánh giá linh hoạt theo từng trường hợp, nó đòi hỏi chi phí phối hợp đáng kể và vốn mang tính phản ứng.

Cắt giảm stake theo chương trình (Cắt giảm stake trong giao thức)

Ngược lại, cơ chế cắt giảm stake theo chương trình được thực thi hoàn toàn on-chain. Nếu validator vi phạm quy tắc giao thức, bằng chứng mật mã về hành vi vi phạm có thể được gửi đến một program chuyên dụng, sau đó program này tự động kích hoạt việc cắt giảm stake. Mô hình này giảm sự phụ thuộc vào phối hợp của con người và cho phép xử lý các vi phạm nhỏ mà không làm gián đoạn hoạt động mạng, mở đường cho cơ chế quy trách nhiệm phi tập trung có khả năng mở rộng.

Cắt giảm stake gồm hai bước chính:

• Phát hiện và quy kết lỗi: xác định hành vi sai phạm và validator chịu trách nhiệm.
• Thực thi hình phạt: trừng phạt bên vi phạm về mặt kinh tế bằng cách cắt giảm stake và buộc họ chịu trách nhiệm.

Trong chu kỳ phát hành Agave 2.3, Solana dự kiến kích hoạt một feature gate cho Slashing Program như được nêu trong SIMD: SIMD-0204: Xác minh sự kiện có thể bị cắt giảm stake. Đây là bước đầu tiên hướng tới việc hỗ trợ cắt giảm stake theo chương trình trên Solana, tập trung vào phát hiện và quy kết lỗi. Thay đổi này giới thiệu một program on-chain cho phép bất kỳ ai báo cáo và ghi lại hành vi có thể bị cắt giảm stake, đặt nền móng cho việc thực thi tự động trong tương lai.

Program này không thay đổi stake hoặc phần thưởng; nó chỉ xác minh và ghi lại vi phạm, đóng vai trò là hồ sơ on-chain về hành vi sai phạm của validator. Một nguyên mẫu ban đầu của program đã được triển khai trên Testnet (ví dụ: transaction DuplicateBlockProof mẫu). 

Ban đầu, program sẽ tập trung phát hiện và ghi lại việc sản xuất block trùng lặp, đồng thời dự kiến hỗ trợ thêm các vi phạm khác trong tương lai, chẳng hạn bỏ phiếu hai lần. Điều quan trọng là cắt giảm stake theo chương trình chỉ áp dụng cho hành vi sai phạm có thể chứng minh rõ ràng. Do đó, việc xử lý những vấn đề mang tính chủ quan hoặc hệ thống hơn, chẳng hạn cố ý sản xuất block chậm hoặc khai thác MEV, khó khăn hơn đáng kể và nhiều khả năng sẽ không được chương trình cắt giảm stake giải quyết.

Bằng chứng được gửi bao gồm hai shred xung đột cho cùng một slot, cả hai đều do cùng một validator ký. Chương trình cắt giảm stake xác minh bằng chứng bằng cách bảo đảm các shred tạo thành một bằng chứng block trùng lặp hợp lệ, xác nhận chúng thuộc cùng một slot và được validator vi phạm ký chính xác. Logic này tương tự cách giao thức gossip của Solana xử lý bằng chứng block trùng lặp trong quy trình lựa chọn fork. 

Sau khi bằng chứng được xác minh thành công, kết quả được lưu trữ trong Program-derived Address (PDA) để tham chiếu sau này. Nhờ đó, có thể dễ dàng xây dựng dashboard hiển thị dữ liệu liên quan đến cắt giảm stake chỉ bằng cách chạy getProgramAccounts trên chương trình cắt giảm stake. Validator có thể dùng dữ liệu này để kiểm tra xem mình có bị báo cáo vi phạm hay không và thực hiện hành động khắc phục khi cần.

Một SIMD trong tương lai sẽ giải quyết việc thực thi hình phạt kinh tế của cơ chế cắt giảm stake, bao gồm các tham số như mức phạt stake cho từng loại vi phạm. Vì những quyết định này ảnh hưởng đến tính kinh tế của việc vận hành validator Solana, mọi thay đổi được đề xuất đều phải được phê duyệt thông qua một cuộc biểu quyết quản trị đầy đủ.

Chuyển epoch nhanh hơn

Agave 2.3 mang đến một cải tiến lớn về tốc độ chuyển epoch. Việc tính phần thưởng epoch hiện hoàn tất trong chưa đầy 500 mili giây. Nhờ đó, số slot bị bỏ qua giảm xuống và transaction được đưa vào chuỗi đáng tin cậy hơn quanh ranh giới epoch.

Ngoài ra, nếu slot leader đầu tiên của epoch mới bị bỏ qua, Agave 2.3 bảo đảm phép tính phần thưởng không được chạy lại. Thay vào đó, các kết quả đã tính trước đó được tái sử dụng, loại bỏ phép tính dư thừa và giúp epoch mới khởi đầu mượt mà hơn.

Tối ưu hóa AccountsDB

Hiệu quả lưu trữ đã được cải thiện đáng kể trong bản phát hành này. Mức sử dụng I/O ổ đĩa giảm khoảng 75% và lượng yêu cầu sửa chữa giảm khoảng 85%. Kết hợp lại, các tối ưu hóa này giúp hiệu suất node nhất quán và đáng tin cậy hơn, đặc biệt trong những giai đoạn mạng chịu tải cao.

Bộ lập lịch tham lam được bật theo mặc định

Trong Agave 2.3, bộ lập lịch tham lam hiện được bật theo mặc định. Bộ lập lịch trung tâm trước đây thường trở thành nút thắt cổ chai khi mạng chịu tải nặng do thời gian cần thiết để sắp xếp transaction và xây dựng đồ thị phụ thuộc. Phương pháp tham lam mới tăng tốc đáng kể việc lập lịch transaction nhờ logic đơn giản hơn và kích thước lô nhỏ hơn.

Độc giả có thể tìm hiểu thêm về bộ lập lịch tham lam trong bài viết trước đây trên blog Helius.

Phiên bản shred của gossip

Agave 2.3 siết chặt việc yêu cầu phiên bản shred phải khớp trong mạng gossip. Giờ đây, node chỉ được phép thiết lập kết nối gossip đến nếu phiên bản shred của chúng khớp với cluster, giúp loại bỏ sớm các node được cấu hình sai.

Trước đây, node do thám có thể tham gia mạng mà không cần khớp phiên bản shred của cluster. Với thay đổi này, mọi node, kể cả những node ở chế độ do thám, đều phải lấy đúng phiên bản shred từ một entrypoint của cluster hoặc bằng cách đặt rõ ràng qua dòng lệnh.

Bản cập nhật này tiếp nối những nỗ lực gần đây nhằm giảm chi phí gossip. Trong những tháng gần đây, lưu lượng gossip đầu vào đã giảm khoảng 61%, nhờ ngừng hỗ trợ ba loại thông điệp gossip và loại bỏ việc quảng bá slot epoch từ các validator không có stake.

Mô phỏng RPC bao gồm mức sử dụng tài nguyên

Để tăng khả năng quan sát mức sử dụng tài nguyên của transaction, một trường mới đã được thêm vào phương thức RPC `simulateTransaction` mặc định: `loadedAccountsDataSize`. Trường này báo cáo tổng số byte dữ liệu tài khoản được tải trong quá trình mô phỏng.

Phần bổ sung này cho phép nhà phát triển ước tính chi phí transaction và tinh chỉnh phí ưu tiên chính xác hơn. Việc tải dữ liệu tài khoản tiêu thụ đơn vị tính toán (CU) ở mức 8 CU trên mỗi 32 KB, dựa trên kích thước cấp phát trang heap của Solana. Bằng cách hiển thị chỉ số này, nhà phát triển có thể tối ưu hóa hiệu quả chi phí tốt hơn khi xây dựng và gửi transaction.

Cải tiến snapshot

Snapshot đóng vai trò là các điểm lưu định kỳ, cho phép node khôi phục trạng thái. Node liên tục tạo các snapshot này và theo thời gian thay thế phiên bản cũ bằng phiên bản mới hơn.

Bản phát hành này mang đến một số cải tiến về tính tiện dụng cho hoạt động của snapshot:

• Cập nhật khoảng thời gian mặc định: Khoảng thời gian mặc định giữa các snapshot đầy đủ đã tăng từ 25.000 lên 50.000 slot, giúp giảm tần suất tạo snapshot.
• Cờ mới để tắt snapshot: Cờ `--no-snapshots` mới đã được giới thiệu để tắt rõ ràng việc tạo snapshot. Phương thức trước đây sử dụng `--snapshot-interval-slots 0` hiện không còn được khuyến nghị.
• Cải thiện hoạt động của Geyser: Khi khôi phục từ snapshot, các thông báo tài khoản gửi qua Geyser không còn bị loại bỏ trùng lặp.

Một lợi ích khác của việc kéo dài khoảng thời gian giữa các snapshot là hiệu suất ổ đĩa ổn định hơn, giảm các đợt tăng vọt IOPS (số thao tác đầu vào/đầu ra mỗi giây).

Cải tiến bộ công cụ SBPF

Agave 2.3 mang đến một số nâng cấp về tính tiện dụng cho các nhà phát triển làm việc với bộ công cụ SBPF:

• Nhắm mục tiêu phiên bản: Nhà phát triển hiện có thể nhắm mục tiêu rõ ràng đến các phiên bản BPF VM cụ thể (v0–v3) khi biên dịch program, qua đó có quyền kiểm soát tốt hơn.
• Chỉ dùng Rust cho SBPFv3: Kể từ SBPFv3, chỉ bộ công cụ dựa trên Rust được hỗ trợ. Bộ công cụ C cũ không còn tương thích với các phiên bản trong tương lai.
• Cờ tối ưu hóa mới: Cờ build `--optimize-size` mới đã được thêm vào để tạo binary program nhỏ hơn khi triển khai. Điều này có thể giúp giảm dung lượng lưu trữ, dù có thể làm tăng nhẹ mức sử dụng đơn vị tính toán (CU).

Các thay đổi khác

Các cập nhật bổ sung trong bản phát hành này:

• Tự động khôi phục cluster: Một tính năng khôi phục cluster mới, `wen-restart`, đã được giới thiệu để tự động kích hoạt khởi động lại cluster nếu chuỗi gặp sự cố.
• Cập nhật ABI ghi log: ABI ghi log `TimedTracedEvent` đã được cập nhật để bổ sung một số thông tin chẩn đoán mới. Do đó, validator phải cập nhật mọi công cụ truy vết hoặc phân tích bên ngoài phụ thuộc vào các log này để bảo đảm khả năng tương thích. Dữ liệu truy vết hiện có nên được xóa sau khi nâng cấp để tránh sai lệch định dạng.
• Cải tiến CLI: Đã bổ sung withdraw-stake AVAILABLE để đơn giản hóa việc rút toàn bộ lamport không được stake, đồng thời cập nhật solana-test-validator để mặc định liên kết dịch vụ RPC với localhost (127.0.0.1), qua đó tăng cường bảo mật.
• Khởi động nhanh hơn: Thời gian khởi động validator đã giảm đáng kể. Node hiện mất khoảng 3 phút để khởi động và tải ledger, cùng khoảng 5 phút để bắt kịp phần đầu chuỗi. Tuy nhiên, fastboot hiện yêu cầu tắt đúng quy trình bằng cờ --wait-for-exit mới. Đơn vị vận hành phải cho phép tiến trình validator tự kết thúc hoàn toàn trước khi khởi động lại, thay vì phát lệnh khởi động lại ngay lập tức.

Kết luận

Agave 2.3 đánh dấu một cột mốc quan trọng khác đối với giao thức Solana. Những điểm nổi bật chính bao gồm việc ra mắt TPU client mới (`tpu-client-next`), giảm đáng kể I/O ổ đĩa thông qua các tối ưu hóa AccountsDB, nâng cao hiệu suất snapshot, cải tiến mạng gossip, cùng khả năng chuyển epoch và khởi động nhanh hơn. Kết hợp lại, các cập nhật này giúp mạng vững chắc hơn, đồng thời cải thiện trải nghiệm cho cả nhà phát triển lẫn đơn vị vận hành validator.

Solana tiếp tục tiến đều đặn tới một mạng đa client vững chắc, với hơn 8% tổng lượng stake đang vận hành Firedancer và tỷ lệ này vẫn tiếp tục tăng. Gần một năm rưỡi hoạt động liên tục phản ánh mức độ trưởng thành và ổn định ngày càng cao của phần mềm cốt lõi trên mạng. Trong khi đó, tốc độ phát hành cả phiên bản lớn lẫn nhỏ đang tăng lên.

Tiếp theo: Agave 3.0!

Tài nguyên khác

• Lịch phát hành Agave 2.3
• Nhật ký thay đổi Agave 2.3
• Các pull request của Agave 2.3
• Ghi chú bản vá Agave 2.3 - Blog Anza 
• Bài thuyết trình về tpu-client-next - Solana Core Community Call, ngày 20 tháng 6 năm 2025