Bản cập nhật Agave 4.0: Mọi điều bạn cần biết

Giới thiệu

Với Agave 4.0, client validator cốt lõi của Solana tiến thêm một bước, cải thiện các luồng hiệu năng trọng yếu đồng thời chuẩn bị mạng cho những block lớn hơn và bản cập nhật cơ chế đồng thuận Alpenglow rất được mong đợi.

Những cập nhật đáng chú ý trong chu kỳ phát hành Agave 4.0

• XDP tăng tốc đáng kể quá trình truyền lại của Turbine
• Replay Stage có độ trễ thấp hơn
• Sẵn sàng cho Alpenglow: marker chuyển giao leader nhanh và xác thực ID block theo chuỗi*
• Mở rộng hỗ trợ mật mã: phép toán G2 và syscall BLS12-381*
• Cải thiện tuần tự hóa bằng Wincode
• Tăng mức ủy quyền stake tối thiểu với Stake Program v5*
• Kích hoạt lại ZK ElGamal Proof program*
• Hỗ trợ chương trình SBPFv3*

* các nâng cấp được kiểm soát bằng feature gate

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

Tại thời điểm viết bài, Agave v4.0.0-rc.0 được xem là ứng viên nâng cấp mainnet (MUC), và Anza đang tìm kiếm tình nguyện viên để giúp bản phát hành đạt 25% tổng lượng stake. Các validator: đã đến lúc nâng cấp!

XDP đã sẵn sàng để được áp dụng rộng rãi hơn

XDP (viết tắt của eXpress Data Path) là luồng mạng hiệu năng cao mà Agave sử dụng để tăng tốc Turbine. Công nghệ này cho phép Agave tải một chương trình eBPF gần card giao tiếp mạng, nhờ đó lưu lượng shred có thể bỏ qua phần lớn luồng xử lý gói tin tiêu chuẩn của Linux.

Điều này rất quan trọng vì Turbine trở thành nút thắt cổ chai chính khi Solana hướng tới giới hạn block cao hơn. Các leader phải phân phối shred đến hàng trăm peer, và trong điều kiện hiện tại, các validator lớn đã có thể đạt gần 150.000 gói tin gửi đi mỗi giây. Khi mạng tiến tới mục tiêu lâu dài là các block 100 triệu CU, hiệu năng điều phối và truyền lại gói tin phải mở rộng tương ứng với thông lượng thực thi. XDP tạo ra dư địa đó bằng cách tăng tốc đáng kể quá trình truyền block.

Với Agave 4.0, XDP hiện đã sẵn sàng để được các validator áp dụng rộng rãi hơn. Công nghệ này đã được kiểm thử tải nặng trong nhiều cấu hình, được gia cố thêm và trải qua các cải tiến định tuyến bổ sung. Kết quả trong môi trường production rất đáng khích lệ, khi tốc độ truyền lại của Turbine tăng nhanh hơn nhiều bậc độ lớn.

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

5:25 SA 22 thg 4, 2026

Để hiểu thêm vì sao XDP là một cải tiến quan trọng đến vậy, hãy xem cuộc phỏng vấn trước đây của chúng tôi với kỹ sư Alessandro Decina của Anza.

Replay Stage nhanh hơn

Agave 4.0 tăng tốc quá trình replay bằng cách chuyển hai bước xác minh tốn kém ra khỏi luồng xử lý trọng yếu của các thread replay. Trong v4.0, việc xác minh entry và chữ ký giao dịch đều được điều phối bất đồng bộ, cho phép replay tiếp tục xử lý trong khi các tác vụ nền xác nhận slot hợp lệ.

Thay đổi đầu tiên chuyển quá trình xác minh entry PoH sang chạy nền. Trước đây, replay xác minh chuỗi hash của entry ngay trong luồng trước khi tiếp tục. Thay đổi thứ hai áp dụng cùng ý tưởng cho chữ ký giao dịch, nhưng có một điểm phân tách quan trọng: Agave giờ đây tách việc xác minh hash/message của giao dịch khỏi việc xác minh chữ ký Ed25519. Luồng hash vẫn chạy trước để giao dịch có thể được làm sạch và thực thi an toàn, còn các bước kiểm tra chữ ký tốn kém hơn sẽ chạy nền và được hợp nhất trước khi block được chấp nhận.

Tác động thực tế là Replay Stage ít bị chặn hơn nhiều, đặc biệt trong các slot bận rộn, khi số bước kiểm tra chữ ký tăng theo số lượng giao dịch.

Mở rộng áp dụng Wincode

Wincode là một thư viện tuần tự hóa và giải tuần tự hóa do Anza phát triển, được xây dựng để khởi tạo tại chỗ và ghi trực tiếp vào bộ nhớ nhằm giảm thiểu bộ đệm trung gian. Thư viện này mang lại hiệu năng hàng đầu trong số các trình tuần tự hóa Rust, đồng thời vẫn hoàn toàn tương thích với bincode phổ biến hơn.

Trong Agave 4.0, nhiều luồng tuần tự hóa trọng yếu về hiệu năng hơn đang chuyển từ bincode sang wincode. Vì gần như mọi dữ liệu được ghi xuống đĩa hoặc gửi qua mạng trong Solana đều dựa vào bincode, việc tối ưu các luồng này có tác động rộng lớn.

Tăng mức ủy quyền stake tối thiểu (Stake Program v5)

Một bản cập nhật quan trọng cho Stake Program sẽ ra mắt cùng Agave 4.0. Thay đổi được kiểm soát bằng feature gate này, trình bày trong SIMD-0490, là bước chuẩn bị cho nỗ lực rộng lớn hơn của Solana nhằm giảm khoản ký quỹ stake (hay rent).

Thay đổi đáng chú ý nhất là mức ủy quyền stake tối thiểu tăng từ 1 lamport lên 1 SOL. Điều này ngăn chi phí tạo và duy trì tài khoản stake giảm xuống quá thấp khi yêu cầu rent giảm, từ đó tránh tạo ra một phương thức tấn công tiềm ẩn. Dù có nhiều tài khoản stake nhỏ hơn ngưỡng này, chúng chỉ chiếm 0,02% tổng lượng stake đang hoạt động và sẽ được miễn áp dụng hồi tố khi bản cập nhật đi vào hoạt động.

Bản nâng cấp cũng tinh giản một số phần trong quy trình xử lý tài khoản stake. Bản nâng cấp chuyển các phép tính rent sang sử dụng Rent sysvar thay vì phụ thuộc vào rent_exempt_reserve được lưu trữ trong từng tài khoản, biến đầu vào tài khoản sysvar thành tùy chọn đối với các thao tác của stake program, đồng thời viết lại phần triển khai Split để khắc phục các trường hợp biên tồn tại lâu nay. 

Cộng đồng vận hành validator đã bày tỏ sự đồng thuận với mức tối thiểu mới là 1 SOL. Các công cụ và dapp tương tác với stake program sẽ cần kiểm tra logic để tính đến mức tối thiểu mới.

Cải thiện hỗ trợ mật mã 

Một số đợt kích hoạt tính năng trong chu kỳ phát hành Agave 4.0 nhằm mở rộng các khả năng mật mã tích hợp của Solana, qua đó hỗ trợ tốt hơn cho những trường hợp sử dụng hiện đại, bao gồm bằng chứng ZK và chữ ký BLS.

Kích hoạt lại ZK ElGamal Proof Program

ZK ElGamal Proof program là một chương trình Solana tích hợp dùng để xác minh các bằng chứng không tiết lộ tri thức được sử dụng trong giao dịch chuyển tiền bảo mật của Token-2022, cho phép xác thực số dư và giao dịch được mã hóa mà không tiết lộ dữ liệu bên dưới. Chương trình đóng vai trò là trình xác minh tổng quát cho các bằng chứng mật mã dựa trên ElGamal, tạo thành một thành phần cốt lõi trong chức năng token bảo vệ quyền riêng tư của Solana. 

Chương trình đã bị vô hiệu hóa trên mainnet sau sự cố bảo mật vào tháng 6 năm 2025. Trong sự cố này, một lỗ hổng trong logic xác minh bằng chứng, cụ thể là thiếu một thành phần trong quá trình hash bản ghi Fiat-Shamir, khiến kẻ xấu có thể tạo ra các bằng chứng giả mạo vượt qua bước xác minh. Dù không ghi nhận trường hợp khai thác nào trong thực tế, tác động tiềm ẩn khiến chương trình bị tắt bằng feature gate và các giao dịch chuyển tiền bảo mật bị tạm dừng trong khi hoàn tất bản sửa lỗi và kiểm toán. Sau khi các vấn đề đã được xử lý và phần triển khai được gia cố, chương trình hiện đã được lên lịch kích hoạt lại trên mainnet.

Phép toán G2 cho alt_bn128

SIMD-0302: Thêm syscall G2 cho alt_bn128 mở rộng các syscall mật mã BN254 (alt_bn128) hiện có của Solana để hỗ trợ thao tác tích hợp trên các điểm thuộc đường cong G2, bao gồm phép cộng, phép trừ và phép nhân vô hướng. G1 và G2 là hai nhóm đường cong elliptic được sử dụng trong mật mã dựa trên phép ghép cặp, trong đó G2 được định nghĩa trên một trường mở rộng lớn hơn.

Điều này lấp đầy một khoảng trống quan trọng trong tập syscall hiện tại, vốn chủ yếu tập trung vào các thao tác G1, đồng thời mở ra khả năng hỗ trợ đầy đủ hơn cho mật mã dựa trên phép ghép cặp ngay trên chain, đặc biệt đối với các trường hợp sử dụng như xác minh chữ ký BLS và những hệ thống bằng chứng ZK nâng cao.

Khi chưa có hỗ trợ G2 tích hợp, một số dự án đã dựa vào các phần triển khai tùy chỉnh như solana-alt-bn128-bls, một thư viện chữ ký BLS toàn diện do Dean Little của Blueshift xây dựng dựa trên các syscall hiện có. Việc kích hoạt thao tác G2 ở cấp syscall sẽ loại bỏ nhu cầu sử dụng những giải pháp thay thế này, giúp việc xây dựng các giao thức mật mã cấp production theo cách tích hợp trên Solana trở nên dễ dàng hơn.

Hỗ trợ little-endian cho alt_bn128

SIMD-0284: Thêm khả năng tương thích little-endian cho alt_bn128 mở rộng các syscall mật mã alt_bn128 hiện có của Solana để hỗ trợ định dạng đầu vào và đầu ra little-endian. Trước đây, các syscall này chỉ chấp nhận mã hóa big-endian, gây trở ngại cho nhà phát triển sử dụng công cụ và thư viện, đặc biệt là những công cụ và thư viện từ hệ sinh thái Ethereum, vì hầu hết đội ngũ ZK trên Solana đều sử dụng ark-bn254, vốn hoạt động theo little-endian. Thay đổi này tương thích ngược và mở rộng khả năng hỗ trợ cho các trường hợp sử dụng hiện có liên quan đến thao tác đường cong elliptic trên alt_bn128.

Syscall BLS12-381

Cuối cùng, SIMD-0388: Syscall BLS12-381 giới thiệu khả năng hỗ trợ tích hợp cho các phép toán mật mã trên đường cong elliptic BLS12-381, mang đến cho các chương trình Solana một đường cong hiện đại, thân thiện với phép ghép cặp và có mức bảo mật 128 bit. Cho đến nay, Solana vẫn dựa vào BN254 (alt_bn128) cho mật mã dựa trên phép ghép cặp, nhưng đường cong này không đáp ứng tiêu chuẩn bảo mật nói trên và hạn chế khả năng tương thích với các hệ sinh thái được áp dụng rộng rãi khác như Ethereum.

Thay vì giới thiệu một giao diện syscall hoàn toàn mới, bản nâng cấp này mở rộng các syscall đường cong hiện có bằng những mã định danh mới cho thao tác BLS12-381 G1 và G2. Điều này cho phép nhà phát triển thực hiện phép toán nhóm, xác thực điểm, giải nén và kiểm tra ghép cặp hàng loạt bằng một giao diện quen thuộc, đồng thời mở rộng đáng kể khả năng mật mã.

Ngoài những cải tiến chung cho bằng chứng không tiết lộ tri thức và xác minh chữ ký BLS, công trình này còn là yếu tố hỗ trợ then chốt cho cơ chế đồng thuận Alpenglow. Cụ thể, nó cho phép validator xác minh BLS Proofs of Possession trên chain, qua đó ngăn chặn các cuộc tấn công rogue-key. Điều này dẫn chúng ta đến phần tiếp theo.

Sẵn sàng cho Alpenglow

Các syscall BLS12-381 chỉ là một trong số nhiều đợt kích hoạt feature gate trong chu kỳ phát hành Agave 4.0 nhằm đặt nền móng cho bản nâng cấp cơ chế đồng thuận Alpenglow. Dưới đây là những đợt kích hoạt bổ sung góp phần vào quá trình triển khai, hiện dự kiến ra mắt trên mainnet vào quý 3 năm 2026 cùng Agave 4.1.

Xác thực ID block theo chuỗi

SIMD-0340: Xác thực ID block theo chuỗi xác định cách validator phải xác minh nguồn gốc block để bảo đảm một chain chuẩn, nhất quán trong cả cơ chế đồng thuận TowerBFT và Alpenglow. Vì chỉ riêng số slot không thể định danh duy nhất các block, đặc biệt trong trường hợp equivocation khi nhiều block có thể được tạo cho cùng một slot, các client không thể dựa vào thứ tự slot để xác định chính xác quan hệ cha-con.

Thay đổi này đưa ra các quy tắc xác thực chain rõ ràng để bảo đảm mỗi block tham chiếu chính xác đến block cha, ngăn chặn phân kỳ và giúp mạng hội tụ về một lịch sử duy nhất. Trong TowerBFT, quy tắc này được thực thi bằng cách yêu cầu các tập FEC tham chiếu đến Merkle root của block cha cả trong cùng slot lẫn giữa các slot. Alpenglow sử dụng cấu trúc Merkle root kép trên tất cả các tập FEC trong một slot. Nếu các bước kiểm tra này thất bại, block hoặc slot sẽ bị đánh dấu là dead. Việc thực thi các quy tắc này tăng cường tính an toàn của cơ chế đồng thuận và bảo đảm validator có thể phục hồi sau khi nhận được các block không chính xác hoặc xung đột.

Marker chuyển giao leader nhanh

SIMD-0337: Marker cho quá trình chuyển giao leader nhanh của Alpenglow xác định các quy tắc phát tín hiệu rõ ràng để validator biết khi nào một slot cha đã hoàn tất đầy đủ và an toàn để xây dựng tiếp, đây là điều kiện tiên quyết cho quá trình chuyển đổi leader nhanh. Thay đổi này đưa ra yêu cầu nghiêm ngặt hơn về vị trí của DATA_COMPLETE_SHRED cùng một marker “parent ready” mới, bảo đảm có thể xác định rõ ràng tính hoàn chỉnh của một block ngay từ chính luồng shred.

Hiện nay, sự mơ hồ về việc một slot đã được truyền đầy đủ hay chưa có thể làm chậm leader tiếp theo, vì họ có thể phải chờ thêm shred hoặc chấp nhận rủi ro xây dựng trên dữ liệu chưa hoàn chỉnh. Bằng cách tiêu chuẩn hóa cách phát tín hiệu hoàn tất, thay đổi này cho phép leader tiếp theo tự tin bắt đầu tạo block sớm hơn mà không cần phối hợp bổ sung hay phỏng đoán.

Đây là một khối nền tảng quan trọng trong thiết kế chuyển giao leader nhanh của Alpenglow, nơi việc giảm thiểu khoảng trống giữa các leader trực tiếp cải thiện thông lượng mạng.

Cập nhật mô hình chi phí giao dịch biểu quyết

SIMD-0458: Ngừng sử dụng chi phí giao dịch SimpleVote cố định loại bỏ việc sử dụng chi phí CU cố định cho các giao dịch biểu quyết, đưa chúng về cùng mô hình chi phí giao dịch tiêu chuẩn được sử dụng cho các giao dịch không phải biểu quyết. 

Hiện nay, các giao dịch biểu quyết đơn giản bị tính mức cố định 3.428 CU dựa trên những giả định cũ về chi phí thực thi có tính xác định. Theo mô hình mới, giao dịch biểu quyết sẽ được đo động như mọi giao dịch khác, giúp hạch toán chi phí nhất quán hơn và loại bỏ nhu cầu về một giới hạn CU riêng cho Vote.

Mặc dù mức tiêu thụ CU thực tế khi chạy giao dịch biểu quyết vẫn giữ nguyên, cách hạch toán chúng trong quá trình đóng gói block sẽ thay đổi. Cụ thể, các giao dịch biểu quyết giờ đây sẽ bao gồm thêm khoảng ~16 nghìn CU ước tính, chẳng hạn như chi phí tải dữ liệu tài khoản, dẫn đến mức dự phòng CU ban đầu cao hơn khi leader xây dựng block.

Thay đổi này tiếp nối SIMD-0387 (Quản lý khóa công khai BLS trong tài khoản biểu quyết), vốn đã loại bỏ giả định rằng Vote program có hồ sơ thực thi cố định.

Các nâng cấp đáng chú ý khác

Các điểm nổi bật khác trong chu kỳ phát hành Agave 4.0 bao gồm hỗ trợ chương trình SBPFv3, khả năng tạo tài khoản được cấp vốn trước và I/O trực tiếp để giải nén snapshot.

Hỗ trợ chương trình SBPFv3

Chu kỳ phát hành Agave 4.0 bao gồm một feature gate cho phép triển khai và thực thi các chương trình SBPFv3. Solana Berkeley Packet Filter (SBPF) là bản fork eBPF dựa trên Rust của Solana: định dạng bytecode cấp thấp và máy ảo mà các chương trình on-chain được biên dịch sang trước khi thực thi. Bản cập nhật này kết hợp công việc được trình bày trong ba SIMD: SIMD-0178, SIMD-0189 và SIMD-0377. 

SIMD-0178 giới thiệu syscall tĩnh, cho phép phân giải các tham chiếu syscall tại thời điểm liên kết thay vì thông qua quá trình tái định vị ELF khi chạy. Hiện nay, các quá trình tái định vị này làm tăng độ phức tạp cho trình tải chương trình; việc loại bỏ chúng giúp đơn giản hóa quá trình thực thi và giảm rủi ro bảo mật.

Sau đó, SIMD-0189 thắt chặt bố cục ELF được phép cho các chương trình, yêu cầu cấu trúc tệp nghiêm ngặt hơn để validator phải phân tích ít trường hợp biên hơn và xử lý ít dữ liệu ngoài dự kiến hơn. Thay đổi này không ảnh hưởng đến nhà phát triển vì bộ công cụ linker được kỳ vọng sẽ tự động tạo ra các tệp nhị phân tuân thủ yêu cầu.

Cuối cùng, SIMD-0377 cập nhật máy ảo SBPF để tương thích tốt hơn với tập lệnh eBPF hiện đại do LLVM tạo ra, bao gồm hỗ trợ các lệnh bổ sung như thao tác nhảy 32 bit. Mục tiêu là giúp VM của Solana tương thích hơn với các công cụ upstream, đồng thời cho phép chương trình được biên dịch thành bytecode hiệu quả hơn. Đối với nhà phát triển, kết quả thực tế là tải chương trình nhanh hơn, bề mặt tấn công nhỏ hơn và khả năng giảm mức sử dụng tài nguyên tính toán mà không cần thay đổi logic ứng dụng.

Tạo tài khoản được cấp vốn trước

SIMD-0312: CreateAccountAllowPrefund dự kiến sẽ được kích hoạt trên mainnet trong chu kỳ phát hành Agave 4.0. SIMD này giới thiệu một instruction mới trong system program, loại bỏ yêu cầu tài khoản mới tạo phải bắt đầu với số dư bằng 0 lamport. Nhờ đó, tài khoản có thể được cấp vốn trước khi tạo, giúp đơn giản hóa một quy trình làm việc phổ biến của nhà phát triển và giảm các instruction không cần thiết.

Trước đây, instruction CreateAccount sẽ thất bại nếu tài khoản đích đã có lamport. Do đó, nhà phát triển phải chia quá trình khởi tạo tài khoản thành nhiều bước, thường là chuyển tiền, sau đó cấp phát và chỉ định, làm tăng độ phức tạp và phát sinh thêm chi phí tính toán. Mô hình này đặc biệt phổ biến trong các chương trình cấp vốn trước cho tài khoản.

Instruction mới hợp nhất các bước này vào một lệnh gọi duy nhất bằng cách cho phép khởi tạo trực tiếp các tài khoản được cấp vốn trước. Trên thực tế, điều này làm giảm chi phí CPI và có thể tiết kiệm hàng nghìn đơn vị tính toán trong các luồng phổ biến, mang lại cho nhà phát triển một phương thức gọn gàng và hiệu quả hơn trong tương lai. Vì đây là một instruction mới chứ không phải thay đổi đối với các instruction hiện có, nó vẫn hoàn toàn tương thích ngược.

I/O trực tiếp để giải nén snapshot 

Agave 4.0 chuyển quá trình giải nén snapshot sang sử dụng I/O trực tiếp theo mặc định, thay vì định tuyến các thao tác ghi snapshot qua bộ nhớ đệm trang của hệ điều hành, qua đó cải thiện thời gian khởi động và hiệu năng khôi phục snapshot. Điều này đặc biệt hữu ích vì dữ liệu snapshot thường được truyền liên tục xuống đĩa và không cần đẩy dữ liệu validator được truy cập thường xuyên hơn ra khỏi bộ nhớ. Đơn vị vận hành có thể tắt tính năng này bằng --no-accounts-db-snapshots-direct-io nếu hệ thống tệp không hỗ trợ O_DIRECT. I/O trực tiếp dự kiến sẽ được mở rộng sang quá trình tạo snapshot trong một bản phát hành tương lai. 

Kết luận

Agave v4.0 là một bản nâng cấp client đáng kể, mang đến nhiều cải tiến hiệu năng và tối ưu hóa runtime. Những thay đổi này được thiết kế để giúp mạng nhanh hơn, an toàn hơn và dễ phát triển ứng dụng hơn.

Trong thời gian tới, cột mốc tiếp theo là Agave 4.1 và bản cập nhật cơ chế đồng thuận Apenglow.

Tài nguyên bổ sung

• Lịch phát hành Agave 4.0
• Lịch theo dõi Feature Gate
• Nhật ký thay đổi Agave 4.0
• Các pull request của Agave 4.0