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

Tóm tắt Agave 2.0

Việc phát hành client validator Agave v2.0 đánh dấu một cột mốc quan trọng trong hành trình hướng tới hệ sinh thái đa client mạnh mẽ hơn của Solana. Bản cập nhật này giới thiệu một số cải tiến thiết yếu nhằm nâng cao hiệu suất, độ tin cậy và hiệu quả của mạng. Những thay đổi chính trong bản cập nhật bao gồm:

• Tái cấu trúc và tối ưu hóa sâu rộng codebase
• Phần thưởng epoch được phân vùng
• Trao toàn bộ phí ưu tiên cho validator
• Bộ lập lịch trung tâm mới hiện được bật theo mặc định
• Chương trình ZK ElGamal Proof
• Syscall Get-Sysvar
• Syscall GetEpochStake
• MoveStake và MoveLamports
• Loại bỏ các phương thức RPC lỗi thời
• Đổi tên các crate

Dù đang vận hành validator, xây dựng trên nền tảng hay tích cực sử dụng Solana, phần tổng quan toàn diện về bản cập nhật Agave 2.0 này sẽ cung cấp những thông tin cần thiết để bạn hiểu và tận dụng các cải tiến mới nhất.

Điều gì khiến Agave 2.0 trở thành một bản cập nhật phiên bản lớn?

Không còn chỉ một ‘validator Solana’ duy nhất. Agave 2.0 đón nhận thế giới đa client mới của Solana và đánh dấu sự tách biệt hoàn toàn khỏi kho lưu trữ GitHub của Solana Labs cũ. Kho lưu trữ Solana Labs sẽ được lưu trữ và không còn tiếp nhận pull request hoặc issue mới. Trước đây, kho lưu trữ này phản chiếu hoạt động từ kho lưu trữ Agave. Nếu chưa thực hiện, các nhà phát triển nên chuyển toàn bộ hoạt động sang kho lưu trữ GitHub Anza Agave. Quy trình chuyển đổi từ Solana Labs sang Agave bắt đầu vào ngày 1 tháng 3 và được theo dõi công khai trên GitHub của họ.

Khi hệ sinh thái phát triển, các đơn vị vận hành phải thích nghi với việc chạy một hoặc nhiều client. Theo sau thay đổi này, một số crate đang được đổi tên, giải phóng namespace để hỗ trợ nhiều client—đáng chú ý nhất là Firedancer—do các nhóm nhà phát triển độc lập quản lý. Các crate do Anza duy trì giờ đây sẽ có tiền tố "agave", giúp dễ dàng nhận diện chúng là các dependency dành riêng cho Anza trong môi trường đa client.

‍Các crate bị ảnh hưởng gồm: 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

Như đã trình bày chi tiết trong hướng dẫn chuyển đổi trước đây, bản cập nhật 2.0 giới thiệu một số thay đổi không tương thích ngược, đáng chú ý nhất là việc loại bỏ một số endpoint lỗi thời và không còn được hỗ trợ—những cập nhật quan trọng mà mọi nhà phát triển Solana giờ đây đều cần biết. Thông tin đầy đủ về các thay đổi RPC được trình bày ở cuối bài viết này.

Triển khai tính năng

Tại thời điểm viết bài, ~20,7% validator đang chạy phiên bản 2.0.14. Việc kích hoạt feature gate trên mainnet tạm thời bị tạm dừng để mức độ áp dụng v2.0 đồng bộ hơn với các đợt kích hoạt trên testnet và devnet. Sau khi cluster mainnet áp dụng rộng rãi v2.0, việc kích hoạt feature gate dự kiến sẽ tiếp tục theo thứ tự kích hoạt đã lên lịch. 

Các tính năng hoàn chỉnh mới được đề cập trong những phần sau hiện chưa hoạt động và sẽ được triển khai dần trong suốt vòng đời 2.0 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 cluster testnet và devnet.

Trao toàn bộ phí ưu tiên cho validator

Bản cập nhật kinh tế được tranh luận nhiều và rất được mong đợi này hiện đang được triển khai theo đề xuất SIMD-0096, vốn đã trải qua cuộc bỏ phiếu quản trị của validator vào tháng 5. Cuộc bỏ phiếu kết thúc vào cuối epoch 620, với 51,17% lượng stake tham gia và 77,77% bỏ phiếu ủng hộ. Bản cập nhật được kiểm soát bằng feature gate sẽ thay đổi căn bản cách mạng xử lý phí ưu tiên. Thay vì mô hình hiện tại, trong đó 50% phí bị đốt và 50% được trao cho validator, mô hình mới sẽ phân bổ trực tiếp 100% phí ưu tiên cho validator.

Mặc dù về mặt kỹ thuật phí ưu tiên là tùy chọn, chúng đã trở thành thông lệ tiêu chuẩn khi hoạt động kinh tế trên Solana gia tăng. Các khoản phí này được tính bằng micro-lamport (một phần triệu lamport) trên mỗi đơn vị tính toán theo công thức:

‍phí ưu tiên = giá đơn vị tính toán (micro-lamport) x giới hạn đơn vị tính toán

Trong tương lai, toàn bộ phí ưu tiên sẽ được trao cho nhà sản xuất block. Điều này tạo ra sự đồng thuận lợi ích mạnh mẽ hơn và giảm khả năng validator tham gia các thỏa thuận ngoài giao thức để đưa transaction vào block, vốn từng là một vấn đề trong quá khứ.

Mặc dù việc ngừng đốt phí làm tăng nhẹ tỷ lệ lạm phát ròng của SOL, lượng token mới được phát hành thông qua phần thưởng staking có tác động lớn hơn nhiều. Độc giả có thể tham khảo bài viết trước đây trên blog Helius về lịch phát hành và lạm phát của Solana để xem phân tích chi tiết hơn về các động lực này.

Phần thưởng epoch được phân vùng

Phần thưởng epoch được phân vùng nhằm phân phối phần thưởng stake trên nhiều block, qua đó giảm bớt các vấn đề hiệu suất do tập trung việc phân phối phần thưởng vào block đầu tiên của mỗi epoch mới. Nút thắt chính trong quy trình này là yêu cầu ghi ngược các bản cập nhật vào số lượng tài khoản stake đang hoạt động ngày càng tăng trên mạng, hiện tổng cộng khoảng 1,4 triệu tài khoản.

Theo cách tiếp cận mới này, việc tính toán và phân phối phần thưởng stake tại ranh giới epoch sẽ được chia thành hai giai đoạn riêng biệt:

• Giai đoạn tính phần thưởng: Trong giai đoạn này, phần thưởng epoch cho tất cả tài khoản stake đang hoạt động được tính toán và chia thành các phần được lên lịch để phân phối.
• Giai đoạn phân phối phần thưởng: Phần thưởng epoch đã được tính trước cho các tài khoản stake đang hoạt động được phân phối tương ứng.

Để hỗ trợ và giám sát quy trình, một tài khoản Sysvar, EpochRewards, sẽ theo dõi và xác minh việc phân phối phần thưởng trong suốt giai đoạn phân phối. Sysvar EpochRewards ghi lại liệu giai đoạn phân phối phần thưởng có đang diễn ra hay không và thông tin cần thiết để tiếp tục phân phối khi khởi động từ snapshot. 

Tính phần thưởng

Việc tính phần thưởng sẽ được thực hiện tại block đầu tiên của epoch. Sau khi được tính, phần thưởng được phân chia thành các phần phân phối lưu trong bank và sẽ được phân phối trong giai đoạn phân phối phần thưởng.

Để giảm thiểu ảnh hưởng đến thời gian xử lý block trong giai đoạn phân phối phần thưởng và bảo đảm mỗi block phân phối một tập hợp con phần thưởng theo cách xác định, mục tiêu là phân phối 4.096 phần thưởng stake trên mỗi block. Để phòng ngừa số lượng tài khoản stake tăng mạnh, số block được giới hạn ở mức 10% tổng số slot trong một epoch. Chỉ khi đạt giới hạn block này, số tài khoản trên mỗi phân vùng mới được phép vượt mục tiêu 4.096.

Phân phối phần thưởng

Việc phân phối phần thưởng bắt đầu ngay sau giai đoạn tính phần thưởng, từ block thứ hai của epoch. Phần thưởng được phân phối ở đầu block, trước khi xử lý transaction thông thường.

Do đó, người dùng có thể thấy phần thưởng được ghi có vào tài khoản stake muộn hơn trước vài block. Tuy nhiên, trải nghiệm tổng thể vẫn tương tự vì trước đây thời gian kéo dài của block đầu tiên tại ranh giới epoch đã làm chậm khả năng truy cập tài khoản stake của người dùng. Một lợi ích khác của cách tiếp cận này là các transaction không liên quan đến staking có thể tiếp tục được xử lý trơn tru, trong khi trước đây chúng bị chặn trong quá trình phân phối phần thưởng.‍

Do số lượng tài khoản vote tương đối thấp, khoảng 1.500 tài khoản, cơ chế hiện tại để phân phối phần thưởng vote tại block đầu tiên của ranh giới epoch sẽ không thay đổi. Chỉ phần thưởng stake được phân phối trên nhiều block.

Bộ lập lịch trung tâm hiện được bật theo mặc định

Lần đầu được giới thiệu dưới dạng tính năng trong bản cập nhật v1.18, bộ lập lịch trung tâm, trước đây gọi là “bộ lập lịch”, không được bật theo mặc định và đơn vị vận hành phải kích hoạt bằng cờ --block-production-method central-scheduler khi khởi động validator. Giờ đây, nó được bật theo mặc định. Cách triển khai bộ lập lịch trước đây có một số vấn đề có thể ảnh hưởng tiêu cực đến hiệu suất. Các nút thắt trong quá trình xử lý transaction thường dẫn đến độ dao động hoặc thiếu nhất quán trong thứ tự và mức độ ưu tiên của transaction.

Cách triển khai mới thay thế mô hình trước đây gồm bốn luồng banking độc lập, mỗi luồng tự quản lý việc ưu tiên và xử lý transaction. Trong cấu trúc đã sửa đổi này, bộ lập lịch trung tâm là nơi duy nhất nhận transaction từ giai đoạn SigVerify của TPU. Nó xây dựng hàng đợi ưu tiên và triển khai một đồ thị dependency, được gọi là prio-graph, để quản lý tốt hơn việc xử lý và ưu tiên các transaction xung đột. Thiết kế bộ lập lịch mới này tăng khả năng mở rộng và tính linh hoạt, cho phép tăng số lượng luồng mà không còn lo ngại về xung đột khóa gia tăng như trước. Đợt triển khai ban đầu của bộ lập lịch trung tâm cho thấy khả năng tạo ra phần thưởng tốt hơn, giúp nhiều đơn vị vận hành cải thiện thu nhập. Bài viết trước đây của Helius về bản cập nhật Solana v1.18 đã trình bày chi tiết cách bộ lập lịch trung tâm hoạt động.

Chương trình ZK ElGamal Proof

Chương trình ZK Token Proof, ban đầu dự kiến được đưa vào bản phát hành 1.17, hiện đã ngừng được hỗ trợ và sẽ được thay thế bằng chương trình ZK ElGamal Proof linh hoạt hơn, không phụ thuộc vào ứng dụng. Chương trình ZK ElGamal Proof mới giữ lại các phần của chương trình ZK Token Proof có thể áp dụng rộng rãi trên nhiều ứng dụng, chẳng hạn như xác minh tính hợp lệ của public key hoặc phạm vi giá trị được mã hóa trong ElGamal ciphertext. Tuy nhiên, chương trình này loại bỏ các thành phần dành riêng cho ứng dụng, như việc xác thực bằng zero-knowledge proof cần thiết cho các lệnh chuyển SPL Token. Chương trình ZK ElGamal Proof mới sẽ được đưa vào danh sách chương trình tích hợp sẵn tại địa chỉ ZkE1Gama1Proof11111111111111111111111111111

Để tìm hiểu thêm về ZK Token Proof Program, hãy đọc bài viết ban đầu của chúng tôi trên blog Helius.

Syscall Get-Sysvar

Syscalls, hay các lệnh gọi hệ thống, yêu cầu dịch vụ từ kernel của hệ điều hành. Trong ngữ cảnh Solana, Syscall cho phép các chương trình chạy trong Solana Virtual Machine (SVM) tương tác với các tài nguyên và dịch vụ bên ngoài. 

Sysvars cung cấp thông tin trạng thái cluster, chẳng hạn như block hash gần đây và phần thưởng epoch. Các tài khoản này được điền dữ liệu tại những địa chỉ đã biết. Chương trình có thể truy cập Sysvar thông qua tài khoản Sysvar hoặc truy vấn chúng qua Syscall. Các chương trình on-chain sử dụng nhiều Sysvar cho nhiều trường hợp sử dụng khác nhau và một số Sysvar là thiết yếu đối với hoạt động của mạng.

Syscall Get-Sysvar, ban đầu được đề xuất trong SIMD-127 bởi kỹ sư Joe Caulfield của Anza, giới thiệu một giao diện Syscall thống nhất để truy cập dữ liệu Sysvar. Nâng cấp này cho phép truy xuất dữ liệu Sysvar mà trước đây không thể truy cập, bao gồm SlotHashes và StakeHistory. Với giao diện mới này, nhà phát triển có thể truy cập các phần cụ thể của dữ liệu Sysvar—chẳng hạn như gọi SlotHashes::get_slot(slot) và StakeHistory::get_entry(epoch)—mà không cần sao chép toàn bộ cấu trúc dữ liệu.

Bản cập nhật cũng giảm thiểu overhead khi sửa đổi layout dữ liệu Sysvar hoặc thêm Sysvar mới. Trước đây, mỗi Sysvar mới đều yêu cầu thêm một Syscall tương ứng, tạo ra mối quan hệ liên kết chặt chẽ khiến giao diện Syscall ngày càng phình to và khó bảo trì. Giờ đây, một Syscall sol_get_Sysvar duy nhất sẽ phục vụ mọi giao diện Sysvar, cho phép truy xuất dữ liệu nhất quán và hiệu quả từ bất kỳ Sysvar nào.

Việc giới thiệu Syscall mới giúp đơn giản hóa quy trình sửa đổi và thêm Sysvar mới. Nó giảm đáng kể độ phức tạp và yêu cầu bảo trì của giao diện Syscall. Ngoài ra, bản cập nhật này mở đường cho việc mở rộng quyền truy cập dữ liệu Sysvar của chương trình BPF, cho phép các chương trình on-chain đọc thêm thông tin Sysvar mà không ảnh hưởng đến kích thước transaction.

Syscall GetEpochStake

Syscall GetEpochStake mới sẽ bổ sung một tính năng được yêu cầu nhiều để truy xuất lượng stake được ủy quyền cho tài khoản vote trong epoch hiện tại, cung cấp phương thức trực tiếp và hiệu quả hơn để truy xuất thông tin này on-chain.

Hiện tại, các chương trình không thể truy cập dữ liệu theo thời gian thực về lượng stake được ủy quyền cho từng tài khoản vote cụ thể trong epoch hiện tại, tạo ra rào cản đối với các trường hợp sử dụng như quản trị validator và cơ chế đồng thuận thứ cấp. Việc cho phép truy vấn dữ liệu này on-chain sẽ mở khóa các ứng dụng đó và mở đường cho những trường hợp sử dụng trong tương lai.

Với GetEpochStake, nhà phát triển cung cấp địa chỉ tài khoản vote dài 32 byte và syscall sẽ trả về một số nguyên u64 đại diện cho tổng lượng stake đang hoạt động hiện được ủy quyền cho tài khoản vote đó. Nếu địa chỉ được cung cấp không tương ứng với một tài khoản vote hợp lệ hoặc không tồn tại, Syscall sẽ chỉ trả về 0.

MoveStake và MoveLamports

Hai lệnh mới của chương trình stake, MoveStake và MoveLamports, đang được giới thiệu để hỗ trợ chuyển giá trị giữa các tài khoản stake. Những lệnh này, lần đầu được đề xuất trong SIMD-0148, hỗ trợ nhà phát triển bằng cách cho phép chuyển tiền giữa các tài khoản có authority trùng khớp mà không cần quyền kiểm soát của withdrawer authority.

Trước đây, các giao thức quản lý stake của người dùng gặp nhiều khó khăn khi chia stake cho nhiều validator và thường xuyên ủy quyền lại giữa chúng. Khi một giao thức chia stake của người dùng để hủy kích hoạt, giao thức phải cấp lamport miễn tiền thuê cho tài khoản mới. Giao thức không thể thu hồi lamport miễn tiền thuê khi hợp nhất các tài khoản đã tách này.

MoveStake

MoveStake: Lệnh này cho phép di chuyển stake đang hoạt động giữa các tài khoản, chuyển stake từ một tài khoản đang hoạt động sang tài khoản đang hoạt động khác hoặc từ tài khoản đang hoạt động sang tài khoản không hoạt động, qua đó kích hoạt lại tài khoản. Nếu toàn bộ phần ủy quyền của tài khoản nguồn được di chuyển, tài khoản nguồn sẽ chuyển sang trạng thái không hoạt động. Số dư miễn tiền thuê không thay đổi trong mọi trường hợp và các quy tắc ủy quyền tối thiểu vẫn được duy trì cho tài khoản đang hoạt động.

MoveLamports

MoveLamports: Di chuyển số lamport dư thừa từ một tài khoản đang hoạt động hoặc không hoạt động sang một tài khoản đang hoạt động hoặc không hoạt động khác, trong đó "lamport dư thừa" là những lamport không thuộc stake được ủy quyền và cũng không cần thiết để được miễn tiền thuê. MoveLamports hỗ trợ các tác vụ dọn dẹp như thu hồi lamport từ các tài khoản đã hợp nhất và hợp nhất nguồn tiền chưa sử dụng.

Để đơn giản hóa việc triển khai, những thay đổi này không hỗ trợ kích hoạt hoặc hủy kích hoạt tài khoản và không ảnh hưởng đến tài khoản stake đang hoạt động một phần. Các lệnh chương trình mới này không thay đổi chức năng hiện có.

Bổ sung: Crate Solana-SVM

Cùng với bản phát hành Agave 2.0 là một crate solana-svm hoàn toàn mới, cung cấp cho nhà phát triển quyền truy cập trực tiếp vào các thành phần SVM cốt lõi thông qua một API tinh gọn, độc lập với framework validator đầy đủ. Điều này mở rộng khả năng xử lý transaction hiệu suất cao của Solana cho các ứng dụng ngoài validator, như dịch vụ off-chain, client gọn nhẹ, state channel và rollup.

Bằng cách tách API khỏi phần còn lại của runtime, crate này loại bỏ nhu cầu sử dụng các thành phần như instance Bank, qua đó giảm overhead vận hành. Giờ đây, nhà phát triển có thể tận dụng chính các thành phần mạnh mẽ đang hỗ trợ mainnet-beta của Solana để xây dựng các dự án SVM tùy chỉnh như light client, state channel, rollup và dịch vụ off-chain. Thành phần cốt lõi của API này là struct TransactionBatchProcessor, cho phép ứng dụng xử lý hàng loạt transaction Solana đã được làm sạch bằng toàn bộ bộ thành phần Agave phía sau, bao gồm BPF Loader, eBPF và máy ảo.

Đọc bài phân tích chuyên sâu về API SVM mới của Anza để biết đầy đủ chi tiết về bước phát triển thú vị này.

Các endpoint RPC đã bị loại bỏ 

Nhiều endpoint RPC Agave v1 lỗi thời và không còn được hỗ trợ đã bị loại bỏ. Đội ngũ Devrel của Helius đã liên hệ với tất cả khách hàng đang sử dụng các endpoint này. Qua phân tích nội bộ, trước đây chúng tôi đã xác định được một nhóm nhỏ khách hàng đang tích cực sử dụng các endpoint sau, vốn được lên kế hoạch loại bỏ:

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

Lưu ý: Có thể xem phương pháp thay thế cho getAccountInfo được minh họa trong hình tại đây.

Các thay đổi không tương thích ngược của SDK bao gồm:

• Đã loại bỏ hỗ trợ Borsh v0.9, vui lòng sử dụng v1 hoặc v0.10 (#1440)
• Copy trait không còn được derive trên Rent và EpochSchedule; hãy chuyển sang sử dụng clone()
• solana-sdk: Đã loại bỏ các symbol không còn được hỗ trợ 
• solana-program: Đã loại bỏ các symbol không còn được hỗ trợ

Đối với đơn vị vận hành validator, một số đối số validator không còn được hỗ trợ sẽ bị loại bỏ khi Agave v2.0 được phát hành. Có thể xem danh sách đầy đủ tại đây.‍

Kết luận

Bản cập nhật Agave 2.0 đánh dấu một bước tiến quan trọng của Solana, tích hợp nhiều tính năng mới và tối ưu hóa runtime. Bản phát hành này tiếp tục mở rộng giới hạn với các Syscall mới mạnh mẽ, chức năng mở rộng và hoạt động dọn dẹp toàn diện, bao gồm đổi tên crate, loại bỏ các phương thức RPC không còn được hỗ trợ và tinh gọn các đối số validator. Agave 2.0 mở rộng năng lực của Solana, đồng thời cải thiện hiệu suất và khả năng sử dụng. Dù là nhà phát triển, validator hay người dùng tích cực, bản cập nhật Agave 2.0 mở ra những khả năng mới đầy hứa hẹn cho mọi người trong hệ sinh thái Solana.

Tài nguyên bổ sung

• Lịch phát hành Agave v2.0
• Nhật ký thay đổi Agave v2.0
• Các phiên bản phát hành Agave