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

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

• Tối ưu hóa hiệu suất trên diện rộng
• Tăng giới hạn block
• Giới thiệu bộ lập lịch tham lam (thử nghiệm)
• Hỗ trợ nguyên bản cho việc xác minh chữ ký Secp256r1 (Cập nhật: đã lùi sang Agave 2.2)
• Vô hiệu hóa việc thu phí rent và ghi lại rent
• Nới lỏng các ràng buộc đối với lỗi tải transaction
• Di chuyển các program Config và bảng tra cứu địa chỉ sang Core BPF

Mỗi phần trong bài viết này được thiết kế để có thể đọc độc lập, cho phép độc giả tự do điều hướng và tập trung vào những chủ đề họ quan tâm nhất. Dù bạn là người vận hành validator, nhà phát triển hay người dùng tích cực, phần tổng quan chuyên sâu về Agave 2.1 này sẽ cung cấp những thông tin cần thiết để tận dụng hiệu quả các cải tiến này.

Triển khai tính năng

Tại thời điểm viết bài, 88% stake đang chạy Agave phiên bản 2.1.11. Việc kích hoạt feature gate trên mainnet đã tạm dừng để Agave v2.1 được áp dụng rộng rãi hơn và dự kiến sẽ sớm tiếp tục theo thứ tự kích hoạt đã lên lịch. 

Hầu hết các tính năng hoàn chỉnh mới được thảo luận trong những phần sau hiện chưa hoạt động và dự kiến sẽ được triển khai trong suốt chu kỳ phát hành 2.1 bằng hệ thống feature gate. Các tính năng được kích hoạt tại những epoch nhất định dựa trên mức độ ưu tiên tương đối và thứ tự chúng được kích hoạt trên các cụm testnet và devnet.

Cải thiện hiệu suất

Các đơn vị vận hành validator và RPC đã ghi nhận mức cải thiện rõ rệt về độ ổn định và hiệu suất với Agave 2.1. Trong năm qua, Anza đã ưu tiên loại bỏ điểm nghẽn, tối ưu hiệu quả sử dụng tài nguyên và nâng cao hiệu suất tổng thể. Các bản phát hành client mới không chỉ giới thiệu tính năng mới mà còn tập trung cải thiện những yếu tố cốt lõi—tăng băng thông, giảm độ trễ. Trước khi đi vào chi tiết của bản cập nhật 2.1, chúng ta nên lùi lại một bước và định lượng những cải thiện hiệu suất đáng kể đạt được qua chuỗi bản cập nhật client gần đây.

Thời gian tạo block

Thời gian tạo block nhanh hơn trên Solana đang đưa thời gian slot trung bình xuống dưới 400ms, với các epoch gần đây có tiến độ hoàn tất chỉ trong chưa đầy hai ngày—nhanh nhất trong lịch sử mạng. Cả hai client đều đã sẵn sàng cho thời gian tạo block ngắn hơn. Sự tăng tốc này không chỉ giúp tăng thông lượng transaction. Vì phần thưởng staking gắn với lượng phát hành do lạm phát, vốn được tính theo "năm epoch" thay vì năm dương lịch, validator và người staking có thể hưởng lợi. Một năm epoch giả định có 182,5 epoch mỗi năm, dựa trên độ dài epoch tiêu chuẩn là hai ngày. Khi epoch ngắn hơn, sẽ có nhiều epoch hơn trong cùng một khoảng thời gian, qua đó tăng tốc độ phân phối phần thưởng staking trên thực tế.

Thời gian hoạt động

Solana đã thể hiện độ tin cậy gần như tuyệt đối trong suốt năm 2024 và đầu năm 2025, duy trì thời gian hoạt động 100% trong hơn một năm. Sự cố ngừng hoạt động gần nhất được ghi nhận vào ngày 6 tháng 2 năm 2024, khi một lỗi đã biết tạm thời làm gián đoạn quá trình hoàn tất block trên Mainnet. Vấn đề này nhanh chóng được xác định và vá. Kể từ đó, Solana đã tạo block liên tục, ngay cả trong những giai đoạn mạng hoạt động ở cường độ cao—chẳng hạn như đợt tăng đột biến gần đây do các đợt ra mắt token của gia đình Trump—qua đó chứng minh khả năng phục hồi dưới tải lớn.

Tỷ lệ bỏ lỡ slot

Tỷ lệ bỏ lỡ slot đo lường tần suất một validator được chỉ định làm leader cho một slot nhất định nhưng không tạo được block trong thời gian được phân bổ. Kể từ khoảng epoch 700 vào tháng 11 năm 2024, tỷ lệ bỏ lỡ slot đã giảm mạnh. Sau nhiều năm dao động từ 2% đến 5%, tỷ lệ này hiện đã giảm xuống gần bằng không đối với hầu hết validator được tối ưu tốt.  

Một yếu tố góp phần vào cải thiện này là việc giới thiệu phần thưởng epoch được phân vùng trên mainnet tại epoch 707. Bằng cách phân bổ phần thưởng stake trên nhiều block, thay đổi này giảm thiểu điểm nghẽn hiệu suất do việc phân phối phần thưởng tập trung vào block đầu tiên của mỗi epoch mới, giúp mạng vận hành mượt mà hơn.

Ngoài ra, Timely Vote Credits (TVC), được giới thiệu vào tháng 11 năm 2024, khuyến khích validator bỏ phiếu kịp thời đồng thời hạn chế việc bỏ phiếu chậm. Bằng cách giảm số lượng validator cố ý trì hoãn phiếu bầu, TVC cải thiện khả năng hội tụ của cụm, giúp xác nhận và hoàn tất nhanh hơn. Cơ chế này giúp giảm thiểu phân nhánh và rút ngắn thời gian tồn tại của nhánh. Vì điểm TVC hiện ảnh hưởng đến thứ hạng stake pool, các đơn vị vận hành đã nâng cấp phần cứng và tối ưu cấu hình validator để đạt hiệu suất tốt hơn.

Số transaction mỗi giây (TPS)

Số transaction mỗi giây (TPS) cao hơn cho thấy thông lượng chuỗi tăng lên. TPS không tính phiếu bầu của Solana (còn gọi là ‘TPS thực’) đã tăng đều kể từ cuối năm 2023. Dữ liệu mới nhất trong tuần đầu tiên của tháng 2 năm 2025 cho thấy mạng ghi nhận mức trung bình ở phân vị thứ 50 là 1.228 TPS, trong khi hiệu suất đỉnh ở phân vị thứ 99 đạt 2.520 TPS.  

Mức TPS cao nhất từ trước đến nay được ghi nhận trong tuần airdrop token PENGU kết thúc vào ngày 23 tháng 12 năm 2024, khi phân vị thứ 50 đạt trung bình 1.260 TPS và phân vị thứ 99 đạt đỉnh 3.252 TPS. Đà tăng trưởng bền vững này cho thấy khả năng mở rộng và hiệu quả xử lý transaction của Solana tiếp tục được cải thiện.

Phí ưu tiên

Cuối cùng, so sánh lượng phí ưu tiên thu được giữa Agave 2.1 và phiên bản 2.0 trước đó trong khoảng từ ngày 27 tháng 1 đến ngày 4 tháng 2 năm 2025 cho thấy Agave 2.1 liên tục thu được mức phí ưu tiên cao hơn một chút.

Tăng giới hạn block

Việc tăng giới hạn block, được đề xuất trong SIMD-0207: Tăng giới hạn block lên 50M, đã được lên lịch cho chu kỳ phát hành 2.1 của Solana. Hiện tại, giao thức giới hạn tổng tài nguyên tính toán trên mỗi block ở mức 48 triệu Compute Units (CU). Giới hạn block đảm bảo các node có thể theo kịp mạng bằng cách hạn chế khối lượng công việc mà một leader có thể đưa vào một block. Đội ngũ sáng lập đã lựa chọn giới hạn hiện tại dựa trên dữ liệu thực nghiệm về khối lượng mà validator có thể xử lý hợp lý để đạt thời gian tạo block 400 mili giây. 

Tuy nhiên, hoạt động trên mainnet hiện nay không bị giới hạn bởi thời gian thực thi, nghĩa là các block có thể chứa nhiều transaction hơn mà không vượt mục tiêu 400ms. Bản cập nhật này đưa ra mức tăng khiêm tốn 4% để từng bước mở rộng năng lực mạng, nâng giới hạn tính toán mỗi block từ 48M lên 50M CU. Mặc dù mức tăng mạnh hơn—chẳng hạn như tăng gấp đôi giới hạn—có thể khả thi, phương án này được xem là quá rủi ro cho thay đổi ban đầu. Việc mở rộng giới hạn block không chỉ ảnh hưởng đến validator mà còn tác động đến hạ tầng quan trọng như node RPC, bộ lập chỉ mục và dịch vụ lưu trữ, vốn cũng phải mở rộng tương ứng.

Các giới hạn khác của giao thức không thay đổi:

• Giới hạn tính toán trên mỗi account trong mỗi block vẫn là 12M CU.
• Mức tính toán tối đa trên mỗi transaction vẫn là 1,4M CU.

Giới hạn block dự kiến sẽ tiếp tục được tăng thông qua quy trình SIMD chính thức.

Bộ lập lịch tham lam

Bối cảnh: Bộ lập lịch trung tâm

Bản cập nhật lớn gần nhất cho bộ lập lịch—bộ lập lịch trung tâm—được giới thiệu trong Agave 1.18 vào tháng 5 năm ngoái. Bộ lập lịch này xây dựng biểu đồ phụ thuộc của N transaction có độ ưu tiên cao nhất, trong đó N hiện được đặt là 256. Sau đó, nó cố gắng lập lịch các transaction theo thứ tự ưu tiên, đảm bảo những transaction không xung đột được xử lý trước. Sau khi được lập lịch, các transaction này bị xóa khỏi biểu đồ, cho phép những transaction từng xung đột được ưu tiên. Bộ lập lịch sau đó bổ sung biểu đồ để duy trì hàng đợi gồm N transaction.

Cách tiếp cận này chủ yếu được thiết kế để tối ưu việc xử lý các batch lớn hơn, qua đó cải thiện thông lượng transaction tổng thể. Tuy nhiên, một nhược điểm lớn là việc xây dựng biểu đồ phụ thuộc và sắp xếp transaction tốn đáng kể thời gian, tạo ra điểm nghẽn. 

Hãy tham khảo bài viết trước đây trên blog Helius để xem tổng quan chi tiết hơn về Agave 1.18 và cách triển khai bộ lập lịch trung tâm.

Bộ lập lịch tham lam mới

Không giống bộ lập lịch trung tâm, bộ lập lịch tham lam không xây dựng biểu đồ phụ thuộc. Thay vào đó, nó áp dụng cách tiếp cận đơn giản hơn:

• Đầu tiên, chọn transaction có độ ưu tiên cao nhất.
• Nếu transaction không xung đột với một batch đang xử lý, nó sẽ được thêm vào một trong bốn hàng đợi của luồng worker.
• Nếu xảy ra xung đột, batch hiện tại sẽ được hoàn tất và gửi đi, còn transaction sẽ được thêm vào một batch mới.

Phương pháp này tăng đáng kể tốc độ lập lịch transaction nhưng tạo ra các batch nhỏ hơn, làm tăng chi phí xử lý trên mỗi transaction. Tuy nhiên, trong điều kiện thực tế trên mainnet, sự đánh đổi này là hợp lý vì thời gian thực thi chủ yếu dành cho xử lý BPF thay vì phân batch.

Bộ lập lịch trung tâm gặp khó khăn khi tải mạng cao, chủ yếu vì cần thời gian để sắp xếp transaction và xây dựng biểu đồ phụ thuộc. Bằng cách loại bỏ chi phí này, bộ lập lịch tham lam cải thiện khả năng phản hồi, đổi lại hiệu quả phân batch thấp hơn.

Hãy xem xét một tình huống trong đó các transaction thuộc ba nhóm xung đột: A, B và C. Các transaction xung đột khi một transaction muốn ghi vào một account mà transaction khác muốn đọc hoặc ghi. Transaction trong nhóm A có phí ưu tiên cao hơn transaction trong nhóm B hoặc C.

• Bộ lập lịch trung tâm sẽ lập lịch các transaction không xung đột A1, B1 và C1 cùng nhau trong một batch: [A1, B1, C1].
• Bộ lập lịch tham lam ưu tiên các transaction có phí cao nhất trước, lập lịch A1 thành một batch riêng rồi chuyển sang A2 trong batch tiếp theo.

Cách ưu tiên này đảm bảo lập lịch nhanh hơn nhưng có thể tạo ra các batch nhỏ hơn so với bộ lập lịch trung tâm.

Program nguyên bản để xác minh chữ ký Secp256r1

Solana đang giới thiệu một program nguyên bản mới để xác minh chữ ký đường cong elliptic secp256r1, cho phép hỗ trợ Passkeys trên chuỗi, tiêu chuẩn WebAuthn và các mô hình trừu tượng hóa account mới, bao gồm xác thực hai yếu tố (2FA). Cải tiến này mở đường cho phương thức xác thực không cần mật khẩu, vốn đã được sử dụng rộng rãi trong Web2, trở thành yếu tố thứ hai để bảo mật trên chuỗi.

Đường cong elliptic secp256r1 là một đường cong mật mã được NIST chuẩn hóa và được hỗ trợ rộng rãi trên các thiết bị hiện đại, bao gồm:

• WebAuthn: Tiêu chuẩn W3C dành cho xác thực dựa trên mật mã khóa công khai, được tất cả trình duyệt web lớn hỗ trợ.
• Secure Enclave của Apple: Môi trường thực thi tin cậy (TEE) dựa trên phần cứng, dùng để ký thông điệp và chỉ có thể truy cập thông qua xác thực sinh trắc học.
• Android Keystore: API để quản lý khóa riêng tư và các phương thức ký, tận dụng TEE của thiết bị để lưu trữ khóa an toàn.
• Passkeys: Tiêu chuẩn của FIDO Alliance và W3C thay thế mật khẩu bằng các cặp khóa mật mã và tương thích với mật mã đường cong elliptic.

Một số mạng khác, bao gồm Ethereum (EIP-7212), cũng đã nghiên cứu việc tích hợp hỗ trợ cho đường cong secp256r1.

Chi tiết về program Secp256r1

Program mới sẽ được triển khai với ID: Secp256r1SigVerify1111111111111111111111111

Cấu trúc instruction:

• Một bộ đếm u8 chỉ định số lượng chữ ký cần xác minh.
• Tiếp theo là một byte đệm.
• Với mỗi chữ ký, struct được tuần tự hóa sau đây sẽ được sử dụng:

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

Bản cập nhật này bắt nguồn từ SIMD-0048: Program nguyên bản cho Secp256r1 Sigverify, do đội ngũ Bunkr đề xuất. Secp256r1 SigVerify Precompile Program sẽ hoạt động tương tự như khả năng hỗ trợ hiện có của Solana dành cho secp256k1 và chữ ký ed25519.

Vô hiệu hóa việc thu phí rent và bỏ qua ghi lại rent

Hai bản cập nhật liên quan, được đề xuất trong SIMD-0084: Vô hiệu hóa việc thu phí rent và SIMD-0183: Bỏ qua ghi lại rent, sẽ loại bỏ phần lớn chi phí xử lý tồn đọng liên quan đến các account trả rent.

Thu phí rent là một thành phần phức tạp trong Bank. Việc vô hiệu hóa thành phần này sẽ đơn giản hóa cơ sở mã của client validator và tinh gọn quá trình phát triển mọi cách triển khai client validator, vì chúng không còn phải tái tạo logic thu rent. Rent sẽ không còn bị khấu trừ khỏi account và phí rent thu được cũng không còn được phân phối cho validator. Hiện đã không thể tạo account trả rent mới—mọi nỗ lực đều sẽ dẫn đến lỗi transaction.

Hiện tại, quy trình thu rent kiểm tra mọi account ít nhất một lần trong mỗi epoch, tải và lưu trữ account ngay cả khi chúng không thay đổi. Vì tất cả account Solana đều đã được miễn rent, việc duy trì quy trình này là công việc tính toán không cần thiết.

Việc ghi lại account liên quan đến rent sẽ bị loại bỏ, giúp giảm số account được lưu trữ trên mỗi slot. Nhờ đó, validator sẽ cải thiện hiệu suất vì có ít account hơn được đưa vào các phép tính accounts delta hash và incremental account hash. Thay đổi này cũng làm giảm kích thước của các snapshot gia tăng, qua đó tiếp tục giảm mức tiêu thụ tài nguyên.

Nới lỏng ràng buộc transaction: Lỗi tải

Hiện tại, transaction trên Solana phải tuân theo các ràng buộc nghiêm ngặt có thể khiến chúng thất bại trước khi được đưa vào block. Những lỗi xảy ra trước block này làm lãng phí tài nguyên tính toán của validator, vì tài nguyên đã được sử dụng nhưng không thu được phí transaction—về thực chất là thực hiện công việc mà không được đền bù.

Quá trình tạo block còn phức tạp hơn vì phải lọc bỏ các transaction gọi program không hợp lệ hoặc vượt quá giới hạn tối đa 64 MiB (~67,11 MB) đối với dữ liệu account được tải. Những hạn chế này làm tăng độ phức tạp của quá trình lắp ráp block và khiến việc xác định tính hợp lệ của block trở nên khó khăn hơn. Bằng cách nới lỏng các ràng buộc này, transaction có thể được đưa vào block và tính phí mà không cần tải cũng như xác minh trước dữ liệu program. Thay đổi này nhằm loại bỏ sự phụ thuộc vào trạng thái account khi xác thực block.

Những thay đổi này, được đề xuất trong SIMD-0191, có thể ảnh hưởng đến các công cụ như trình khám phá blockchain, vốn giả định rằng mọi transaction đều cố gắng thực thi. Ngoài ra, người dùng phải đảm bảo transaction của mình có thể thực thi để tránh tốn phí không cần thiết.

Di chuyển các program Config và bảng tra cứu địa chỉ sang Core BPF

Trong khuôn khổ quá trình chuyển đổi đang diễn ra từ các program nguyên bản được tích hợp sẵn sang program Berkeley Packet Filter (BPF), program Config và program Address Lookup Table sẽ được di chuyển sang Core BPF. Thay đổi này tách các program quan trọng khỏi runtime của validator, cho phép cập nhật linh hoạt hơn và bảo trì dễ dàng hơn.

Program BPF ít phức tạp hơn phiên bản nguyên bản tương ứng, giúp đơn giản hóa việc phát triển và bảo trì trên các client validator khác nhau. Với thay đổi này, các đội ngũ làm việc trên Firedancer và Anza sẽ không còn phải theo dõi và triển khai riêng các thay đổi của program trong runtime của mình. Thay vào đó, các bản cập nhật sẽ được áp dụng đồng nhất trên mọi client. 

Các program được triển khai lại sẽ duy trì ABI giống hệt phiên bản nguyên bản, đảm bảo khả năng tương thích đầy đủ và chỉ khác về mức sử dụng tài nguyên tính toán.

Kết luận

Bản cập nhật Agave 2.1 đánh dấu một bước tiến lớn của Solana, mang đến những cải tiến tính năng quan trọng và tối ưu hóa runtime. Bản phát hành này củng cố mạng bằng cách mở rộng chức năng, tinh chỉnh hiệu suất và đẩy xa giới hạn về những gì Solana có thể đạt được. Với khả năng hỗ trợ nguyên bản cho việc xác minh chữ ký Secp256r1, giới hạn block cao hơn, nhiều cải thiện hiệu suất và sự ra mắt sau này của bộ lập lịch tham lam, Agave 2.1 nâng cao cả hiệu quả lẫn khả năng mở rộng. Dù bạn là nhà phát triển, validator hay người dùng tích cực, bản cập nhật này mở ra những khả năng mới, giúp Solana nhanh hơn, linh hoạt hơn và mạnh mẽ hơn bao giờ hết.

Tài nguyên bổ sung

• Kho mã nguồn Agave Client
• Lịch phát hành Agave v2.1
• Các pull request được gắn thẻ Agave v2.1