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

Giới thiệu

Bản phát hành lớn Agave v3.0 đánh dấu một cột mốc mới của Solana, mang đến hàng loạt nâng cấp nhằm cải thiện hiệu năng mạng, hoạt động của validator và trải nghiệm của nhà phát triển.

Những cập nhật đáng chú ý của Agave 3.0 

• Đại tu bộ nhớ đệm: tăng tốc độ xử lý transaction thêm 30–40%
• Nâng giới hạn tính toán cho một tài khoản: tăng giới hạn của một tài khoản lên 40% tổng CU của block
• Struct TransactionView mới cho bộ lập lịch: cải thiện hiệu quả lập lịch
• eXpress Data Path (XDP) cho Turbine: điều kiện tiên quyết để đạt block 100 triệu CU
• Tăng độ sâu lồng CPI: nâng giới hạn lồng CPI từ 4 lên 8
• Nới lỏng ràng buộc Entry: đơn giản hóa logic lập lịch và là điều kiện cần cho thực thi bất đồng bộ
• Thời gian khởi động nhanh hơn: node có thể trực tuyến trở lại nhanh hơn
• Đặc tả kích thước dữ liệu transaction đã tải: chuẩn hóa cách tính dữ liệu transaction đã tải
• Cải tiến RPC: cập nhật theo thời gian thực nhanh và đáng tin cậy hơn cho các dApp sử dụng PubSub WebSockets

Mỗi phần trong bài viết này đề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. Dù là đơn vị vận hành validator, nhà phát triển hay thành viên tích cực của cộng đồng, hướng dẫn về Agave v3.0 này sẽ cung cấp những cập nhật và 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.

Xu hướng liên quan đến client

Trước khi tìm hiểu chi tiết các tính năng mới của Agave v3.0, hãy xem dữ liệu gần đây cho thấy những tiến bộ của mạng Solana và client Agave như thế nào, từ chu kỳ phát hành nhanh hơn, mức độ chấp nhận client rộng hơn cho đến hiệu năng mạnh mẽ dưới áp lực cao.

Nhịp độ phát hành Agave

Anza đã tăng tốc đáng kể nhịp độ phát hành trong năm nay, rút ngắn khoảng cách giữa các phiên bản phụ của Agave xuống dưới ba tháng. Dòng Agave 2.2.* chỉ giữ vị trí phiên bản siêu đa số trong 11 tuần, còn Agave 2.3 đang đi theo một lộ trình tương tự.

Mạng đa client

Mức độ chấp nhận Firedancer trên mainnet đã tăng đáng kể trong những tháng gần đây. Hiện tại, 21,6% lượng stake đang chạy client Jito-Frankendancer, con số đã tăng chậm nhưng đều trong suốt năm nay (xem biểu đồ bên dưới). Mức độ chấp nhận dự kiến sẽ duy trì quanh ngưỡng 20% cho đến khi client Firedancer hoàn chỉnh sẵn sàng để triển khai chính thức trên mainnet.

Đây là một cột mốc quan trọng đối với chiến lược đa client của Solana, mục tiêu lâu dài nhằm cải thiện độ an toàn, tính sống còn và khả năng phục hồi của mạng. Sự đa dạng client cao hơn mang lại nhiều lựa chọn hơn cho các đơn vị vận hành validator, thúc đẩy cạnh tranh lành mạnh giữa các nhóm phát triển client và giúp nhiều người cùng rà soát mã nguồn client hơn. Điều này cũng giảm thiểu nguy cơ một lỗi nghiêm trọng duy nhất gây gián đoạn trên toàn mạng.

Một điểm đáng chú ý khác là lượng stake chạy client Agave nguyên bản, tức Agave không có các sửa đổi MEV của bên thứ ba như Jito, đã giảm từ khoảng 6% vào đầu năm xuống còn khoảng 2% hiện nay. Trong khi đó, mức độ chấp nhận Paladin-Agave đã tăng trong những tháng gần đây và hiện chiếm khoảng 6% tổng lượng stake.

Kiểm thử chịu tải mạng

Ngày 10 tháng 10, thị trường tiền mã hóa đã trải qua sự kiện thanh lý lớn nhất trong lịch sử, gây ra biến động cực mạnh trên tất cả các blockchain lớn. Bất chấp hoạt động mạng tăng vọt lên mức kỷ lục, mạng Solana và client validator Agave vẫn thể hiện khả năng phục hồi và độ ổn định đáng chú ý dưới áp lực.

Vào lúc cao điểm, Solana duy trì lưu lượng gấp sáu lần mức thông thường, với các leader tiếp nhận khoảng 100.000 gói transaction mỗi giây, đồng thời tạo ra các block đầy ở giới hạn 60 triệu CU.

Ngay cả trong những điều kiện này, Solana vẫn có diễn biến phí ổn định nhất trong số các mạng lớn, đồng thời xử lý throughput cao hơn cả một bậc độ lớn. TPS thực tế (không gồm transaction biểu quyết) vượt 3.200 tại thời điểm hoạt động đạt đỉnh.

Trong khoảng thời gian cao điểm kéo dài gần hai giờ, phí transaction trung vị (P50) của Solana chỉ tăng lên 0,007 USD, thấp hơn một xu. Phí trung bình có lúc đạt 0,10 USD và 1% transaction cao nhất (P99) đạt đỉnh chỉ hơn 1,00 USD. Mô hình này cho thấy hiệu quả của thị trường phí cục bộ, vốn chỉ giới hạn mức phí cao ở những transaction tương tác với các tài khoản nóng đang bị tranh chấp, trong khi người dùng thông thường thực hiện các giao dịch chuyển đơn giản (ví dụ: thanh toán bằng stablecoin) không bị ảnh hưởng.

Để so sánh, phí trung vị trên mainnet Ethereum và Arbitrum đã có lúc tăng vọt lên trên 100 USD cho mỗi transaction trong cùng giai đoạn. Base, L2 do Coinbase vận hành, cũng ghi nhận phí tăng mạnh với mức trung vị đạt đỉnh hơn 3 USD. Các mạng này không có thị trường phí cục bộ nên áp dụng điều chỉnh phí toàn cục, làm tăng chi phí đồng đều cho mọi người dùng khi mạng chịu tải cao.

Tăng trưởng trạng thái

Solana gần đây đã vượt qua một cột mốc lớn về tăng trưởng trạng thái on-chain, với tổng số tài khoản vượt 1 tỷ. Gần 67% số tài khoản này thuộc sở hữu của Token Program, trong đó 89,45% là associated token account và 10,55% là tài khoản đúc token.

Sự mở rộng trạng thái đều đặn này có tác động dài hạn đến các client Solana và nhà cung cấp hạ tầng. Khi số lượng tài khoản tăng, nhu cầu về dung lượng lưu trữ, kích thước snapshot và lập chỉ mục tài khoản cũng tăng theo, từ đó có thể ảnh hưởng đến hiệu năng và yêu cầu phần cứng. Các giải pháp như ZK Compression mang lại một hướng đi dài hạn đầy hứa hẹn để giảm tình trạng phình to của trạng thái.

Các cập nhật trong chu kỳ phát hành Agave 3.0

Đại tu bộ nhớ đệm

Agave 3.0 giảm đáng kể các thao tác runtime dư thừa. Việc đại tu toàn diện bộ nhớ đệm chương trình loại bỏ hàng trăm lần tra cứu tài khoản không cần thiết trong mỗi batch transaction, qua đó giúp xử lý transaction nhanh hơn khoảng 30–40% trong các benchmark nội bộ.

Nâng giới hạn tài khoản lên 40% CU của block

Trong chu kỳ phát hành Agave 3.0, Solana sẽ kích hoạt SIMD-0306: Nâng giới hạn CU của tài khoản. Thay đổi này nâng giới hạn CU trên mỗi tài khoản từ hằng số cố định 12 triệu lên 40% giới hạn CU của block. Hiện tại, mỗi tài khoản có thể tiêu thụ tối đa 12 triệu CU trong mỗi block. Như thể hiện trong biểu đồ bên dưới của Anza, những tài khoản bị tranh chấp nhiều nhất thường chạm ngưỡng này.

Với thay đổi này, giới hạn trên mỗi tài khoản ban đầu sẽ tăng từ 12 triệu lên 24 triệu CU, sau đó lên 40 triệu CU khi SIMD-0286 (block 100 triệu CU) được kích hoạt. Kết hợp với các cập nhật như việc ra mắt P-token program, nâng cấp này sẽ tăng đáng kể throughput cho các tài khoản nóng thường xuyên được truy cập trong mỗi block.

Các ràng buộc khác sẽ không thay đổi, bao gồm:

• Số đơn vị biểu quyết tối đa: giới hạn tổng CU của các transaction biểu quyết trên mỗi block là 36 triệu CU
• Mức thay đổi tối đa về kích thước dữ liệu tài khoản trong block: giới hạn tổng thay đổi dữ liệu tài khoản trên mỗi block là 100 megabyte.

Mặc dù việc tăng giới hạn CU trên mỗi tài khoản giúp cải thiện throughput cho trạng thái nóng, thay đổi này cũng có thể làm tăng thời gian thực thi tuần tự trong trường hợp xấu nhất, qua đó có khả năng kéo dài thời gian xác minh block hoặc thời lượng slot trong các tình huống tải cao.

Cuối cùng, cũng cần lưu ý đến đề xuất gần đây SIMD-0370: Loại bỏ giới hạn đơn vị tính toán của block, trong đó xem xét loại bỏ hoàn toàn giới hạn block dựa trên CU. Hướng đi này có thể sẽ được đánh giá lại sau bản nâng cấp Alpenglow.

eXpress Data Path (XDP) cho Turbine

eXpress Data Path (XDP) là công nghệ kernel Linux được thiết kế cho mạng hiệu năng cao. Công nghệ này cho phép ứng dụng bỏ qua phần lớn quy trình xử lý gói tiêu chuẩn của kernel, qua đó giảm cả số lần sao chép dữ liệu trung gian lẫn chuyển đổi ngữ cảnh giữa không gian người dùng và kernel. Bằng cách xử lý gói trực tiếp với card giao tiếp mạng (NIC) trong không gian người dùng, XDP cắt giảm đáng kể chi phí xử lý trên mỗi gói.

Hỗ trợ XDP trong Turbine lần đầu được giới thiệu ở Agave v2.3.8 và sẽ được bật theo mặc định từ Agave 3.1. Turbine là nút thắt chính về khả năng mở rộng khi giới hạn block tăng lên 100 triệu CU. Các leader chuyển tiếp shred của mình đến 200 peer, tạo ra tải mạng lớn. Trong điều kiện hiện tại, các validator lớn có nhiều slot leader hơn có thể đạt gần 150.000 gói gửi đi mỗi giây. XDP trực tiếp giải quyết nút thắt này, tăng tốc độ phân phối gói lên đến 100 lần và cho phép validator truyền các block lớn hiệu quả hơn nhiều. 

Độc giả muốn tìm hiểu sâu hơn về cách triển khai XDP trong Agave có thể tham khảo hướng dẫn thiết lập validator và cuộc phỏng vấn trước đây của chúng tôi với kỹ sư Anza Alessandro Decina, người dẫn dắt việc tích hợp XDP vào client Agave.

Đặc tả kích thước dữ liệu transaction đã tải

Trong nỗ lực liên tục nhằm đơn giản hóa và chuẩn hóa mô hình thực thi của Solana, SIMD-0186: Đặc tả kích thước dữ liệu transaction đã tải dự kiến sẽ được kích hoạt trên mainnet trong chu kỳ phát hành Agave 3.0.

Thay đổi này đưa ra một phương pháp an toàn về mặt đồng thuận để tính tổng dữ liệu tài khoản mà mỗi transaction tải. Mục tiêu là bảo đảm mọi client validator đều tính ra kích thước dữ liệu transaction giống nhau, loại bỏ những điểm không nhất quán khó nhận biết có thể khiến đồng thuận bị phân kỳ.

Hiện tại, logic xác định kích thước dữ liệu transaction của Solana quá phức tạp. Cách triển khai hiện có xử lý các chương trình LoaderV3 và BPF Upgradeable Loader theo cách đặc thù, và cả hai thường tính thiếu kích thước thực tế của dữ liệu chương trình đã tải. Những sai lệch này khiến các nhóm phát triển client độc lập khó triển khai logic tương thích.

Theo SIMD-0186, các quy tắc xác định kích thước giờ đây rõ ràng và dễ phân tích:

• Mỗi tài khoản được tải chỉ được tính đúng một lần
• Các chương trình sử dụng BPF Upgradeable Loader bao gồm cả dữ liệu chương trình liên quan
• Kích thước của mỗi tài khoản được tải được xác định bằng độ dài dữ liệu theo byte trước khi thực thi transaction, cộng thêm 64 byte cho metadata
• Mỗi Address Lookup Table (ALT) được tính cố định 8.248 byte

Đặc tả này chuẩn hóa cách xác định kích thước transaction trên tất cả các client và giúp hành vi của transaction dễ dự đoán hơn đối với nhà phát triển.

Giới hạn kích thước dữ liệu được tải có vai trò tương tự giới hạn CU trên mỗi transaction, giúp việc hạch toán tài nguyên cho các node validator trở nên dễ dự đoán. Theo mặc định, mỗi transaction có thể tải tối đa 64 MB dữ liệu tài khoản, tiêu thụ tám đơn vị tính toán (CU) cho mỗi 32 KB được tải, tương đương chi phí cơ sở 16.000 CU, ngay cả khi lượng dữ liệu thực tế được tải ít hơn. Nhà phát triển có thể giảm giới hạn này thông qua instruction setLoadedAccountsDataSizeLimit để giảm chi phí tính toán và cải thiện hiệu quả lập lịch.

Vì phương pháp xác định kích thước mới có thể tạo ra các giá trị khác nhau tùy theo cấu trúc transaction, nhà phát triển có thể cần điều chỉnh giới hạn kích thước dữ liệu tài khoản được tải được chỉ định trong các instruction ngân sách tính toán.

Struct TransactionView của bộ lập lịch

Với Agave 3.0, bộ lập lịch giới thiệu một cấu trúc dữ liệu gọn nhẹ mới có tên TransactionView, được thiết kế để hợp lý hóa cách phân tích cú pháp và xử lý transaction. Khác với các kiểu transaction SDK cũ vốn yêu cầu giải tuần tự hóa và cấp phát bộ nhớ nhiều lần, TransactionView cung cấp chế độ xem trực tiếp vào một transaction đã tuần tự hóa. Cấu trúc này phân tích cú pháp và lưu metadata về bố cục transaction vào bộ nhớ đệm mà không thực sự giải tuần tự hóa transaction.

Thời gian khởi động nhanh hơn

Hiệu năng khởi động client tiếp tục được cải thiện trong bản phát hành Agave v3.0, mang lại nâng cấp đáng kể về mức độ thuận tiện cho các đơn vị vận hành validator và RPC. Dù khởi động lại sau sự cố, nâng cấp hay bảo trì định kỳ, các node giờ đây có thể trực tuyến trở lại nhanh hơn đáng kể.

Khi khởi động từ kho lưu trữ snapshot, thời gian khởi động đã giảm xuống dưới ba phút rưỡi, chưa bằng một nửa thời gian cần thiết với Agave v2.2 (xem biểu đồ bên dưới). Cải tiến này mang lại bước tiến quan trọng về hiệu năng, vì việc khởi động nhanh hơn trực tiếp nâng cao khả năng phục hồi của mạng và thời gian hoạt động của validator bằng cách rút ngắn thời gian để node tham gia lại đồng thuận.

Trong tương lai, Agave v3.1 sẽ tiếp tục tinh giản quy trình này bằng cách loại bỏ việc xác minh tài khoản trong nền, cho phép validator bắt đầu biểu quyết ngay khi quá trình replay bắt đầu.

Nâng giới hạn lồng CPI

SIMD-0268: Nâng giới hạn lồng CPI tăng độ sâu tối đa của lệnh gọi Cross-Program Invocation (CPI) từ 4 lên 8. Thay đổi này thực tế tăng gấp đôi số lần một chương trình Solana có thể gọi các chương trình khác trong một transaction duy nhất.

CPI là cơ chế cho phép một chương trình Solana gọi một chương trình khác. Đây là tính năng nền tảng của runtime Solana, cho phép các chương trình xây dựng dựa trên logic của nhau.

Các giao thức on-chain phức tạp như giao dịch hoán đổi vĩnh viễn, ví thông minh và hệ thống ký quỹ chéo thường dựa vào nhiều lớp tương tác giữa các chương trình để quản lý vị thế, thanh lý và rủi ro. Giới hạn CPI 4 cấp trước đây đã hạn chế các thiết kế này, trong một số trường hợp buộc nhà phát triển phải chia logic thành nhiều transaction.

Các ứng dụng hiện có sẽ tiếp tục hoạt động như trước đây (trừ khi logic của chúng phụ thuộc vào giới hạn cũ để khiến transaction thất bại). Nhìn chung, thay đổi được yêu cầu thường xuyên này mở rộng không gian thiết kế cho nhà phát triển và củng cố khả năng kết hợp của Solana.

Nới lỏng ràng buộc Entry

SIMD-0083: Nới lỏng ràng buộc Entry, dự kiến được kích hoạt trong Agave 3.0, loại bỏ quy tắc cấm các transaction trong một entry của block xung đột với nhau. Trước đây, bất kỳ entry nào chứa các transaction xung đột (tức là cả hai cùng ghi vào một tài khoản hoặc một transaction đọc trong khi transaction khác ghi) đều khiến toàn bộ block mất hiệu lực.

Với bản cập nhật này, các xung đột như vậy giờ đây được cho phép. Khi xảy ra xung đột, các transaction chỉ đơn giản được thực thi tuần tự theo thứ tự xuất hiện. Thay đổi này đơn giản hóa các quy tắc đóng gói block, giúp leader linh hoạt hơn trong việc sắp xếp transaction và xây dựng block. Đây cũng là thay đổi cần thiết để Solana triển khai thực thi bất đồng bộ.

Cải tiến RPC

Agave v3.0 nâng cấp khả năng phản hồi của máy chủ subscription. Máy chủ giờ đây ưu tiên các thông điệp đến, chẳng hạn như yêu cầu subscription và PING, hơn các thông báo gửi đi. Thay đổi này mang đến các bản cập nhật theo thời gian thực nhanh hơn và đáng tin cậy hơn cho những dApp sử dụng PubSub WebSockets.

Ngoài ra, các thuộc tính slot đã được thêm vào dữ liệu lỗi phần thưởng epoch, giúp nhà phát triển gỡ lỗi và quan sát hệ thống tốt hơn.

Các thay đổi khác

• Kể từ Agave v3.0.0, Anza đã ngừng phát hành các binary agave-validator được dựng sẵn. Các đơn vị vận hành validator giờ đây phải biên dịch binary từ mã nguồn bằng cách làm theo hướng dẫn build được cung cấp.
• Với Agave v3.0, khoảng thời gian snapshot mặc định đã được kéo dài thành 100.000 slot một lần, tăng từ 50.000 trong v2.3 và 25.000 trong v2.2. Việc tăng khoảng thời gian này cải thiện đáng kể hiệu năng ổ đĩa, giảm các đợt tăng đột biến về IOPS (số thao tác đầu vào/đầu ra mỗi giây) trong quá trình tạo snapshot.
• Nhiều đối số và cờ CLI cũ đã ngừng dùng đã bị loại bỏ (xem danh sách đầy đủ tại đây).
• Hiện tại, instruction advance nonce trong một transaction có thể chỉ định bất kỳ tài khoản nào trong transaction làm tài khoản cần advance. Sau khi feature gate cho SIMD-0242: Chỉ tài khoản Nonce tĩnh được kích hoạt, instruction advance nonce sẽ chỉ có thể advance một tài khoản được đưa vào theo cách tĩnh.

Kết luận

Agave v3.0 là một bản nâng cấp client đáng kể, mang đến khả năng xử lý transaction nhanh hơn, giới hạn tính toán cao hơn, hiệu quả lập lịch tốt hơn cùng nhiều tối ưu hóa cho validator và RPC. Các cập nhật này kết hợp với nhau để củng cố cả hiệu năng mạng lẫn trải nghiệm của nhà phát triển.

Dữ liệu gần đây càng khẳng định tiến bộ này: nhịp độ phát hành nhanh hơn, mức độ đa dạng client ngày càng cao và độ ổn định mạng vượt trội khi nhu cầu đạt đỉnh đều cho thấy sự trưởng thành của Solana. Khi Agave 3.0 hiện đang vận hành mạng, Solana tiếp tục chứng minh khả năng mở rộng của mình.

Tài nguyên khác

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