Tóm tắt Agave 2.0

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

‍

• Tối ưu hóa và tái cấu trúc mã nguồn mở rộng
• Phần thưởng chia thành khoảng thời gian
• Phần thưởng đầy đủ phí ưu tiên cho người xác minh
• Bộ lập lịch trung tâm mới đã được kích hoạt mặc định
• Chương trình chứng minh ZK ElGamal
• Lấy Sysvar Syscall
• GetEpochStake Syscall
• MoveStake và MoveLamports
• Loại bỏ các phương thức RPC đã lỗi thời
• Đổi tên Crate

‍

Dù bạn là một validator, xây dựng trên nền tảng, hoặc sử dụng Solana một cách tích cực, bản tổng quan toàn diện về cập nhật Agave 2.0 sẽ trang bị cho bạn những hiểu biết cần thiết để hiểu và tận dụng những đổi mới mới nhất này.

Có gì đặc biệt trong phiên bản cập nhật lớn 2.0?

Không còn một ‘nhà xác nhận Solana’ duy nhất nữa. Agave 2.0 ôm trọn thế giới đa khách hàng mới của Solana và đánh dấu một sự chia tay sạch sẽ từ quá khứKho lưu trữ GitHub của Solana Labs. Kho lưu trữ của Solana Labs sẽ được lưu trữ dưới dạng bản lưu và các yêu cầu pull hoặc vấn đề mới sẽ không còn được chấp nhận nữa. Trước đây, kho lưu trữ này đã sao chép hoạt động từ kho lưu trữ Agave. Các nhà phát triển nên di dời tất cả các hoạt động sangKho lưu trữ Anza Agave trên GitHubnếu họ chưa làm điều đó.Quá trình chuyển đổi từ Solana Labs sang Agavebắt đầu vào ngày 1 tháng 3 và được công khai theo dõi trên GitHub của họ.

‍

Khi hệ sinh thái phát triển, các nhà điều hành phải thích nghi để chạy một hoặc nhiều khách hàng. Theo sự thay đổi này, một số crates được đổi tên, làm sạch không gian tên để hỗ trợ nhiều khách hàng - đặc biệt là Firedancer - do các nhóm phát triển độc lập quản lý. Các crates được duy trì bởi Anza sẽ được tiền tố với “agave,” làm cho chúng dễ dàng nhận biết là các phụ thuộc cụ thể của Anza trong môi trường đa khách hàng.

‍

‍

Các hộp bị ảnh hưởng là:

‍

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

‍

Như đã được miêu tả trong chúng tôihướng dẫn chuyển tiếp trước đó, bản cập nhật 2.0 giới thiệu một số thay đổi đột phá, đáng chú ý nhất là việc loại bỏ một số điểm cuối cũ và không còn sử dụng—các cập nhật quan trọng mà tất cả các nhà phát triển Solana nên biết từ bây giờ. Chi tiết đầy đủ về các thay đổi RPC được bao gồm ở cuối bài viết này.

Các tính năng Rollout

Tại thời điểm viết bài, ~ 20,7% trình xác thực đang chạy phiên bản 2.0.14. Kích hoạt cổng tính năng trên mainnet tạm thời bị tạm dừng để cho phép việc áp dụng v2.0 phù hợp hơn với các kích hoạt trên testnet và devnet. Khi cụm mainnet đã được áp dụng rộng rãi v2.0, các kích hoạt cổng tính năng dự kiến sẽ tiếp tục theolệnh kích hoạt được lên lịch.

‍

Những tính năng đầy đủ mới được thảo luận trong các phần sau hiện không hoạt động và sẽ được triển khai từ từ trong suốt vòng đời 2.0 bằng cách sử dụng hệ thống cổng tính năng. Các tính năng được kích hoạt tại các kỷ nguyên nhất định dựa trên ưu tiên tương đối và thứ tự mà chúng được kích hoạt trên các cụm testnet và devnet.

‍

Phí Ưu Tiên Đầy Đủ Thưởng Cho Người Xác Minh

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

Trên: Phí ưu tiên hàng tuần của Solana trong giá trị USD (nguồn)

‍

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

‍

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

‍

Từ nay về sau, tất cả các khoản phí ưu tiên sẽ được trao cho các nhà sản xuất khối. Điều này tạo ra sự phù hợp mạnh mẽ của động cơ và giảm khả năng các nhà xác minh tham gia vào các thỏa thuận ngoài giao thức để bao gồm giao dịch, điều này đã là một vấn đề trong quá khứ.

‍

Mặc dù việc loại bỏ phí gây tăng tỷ lệ lạm phát net của SOL một chút, nhưng việc phát hành token mới thông qua phần thưởng staking có tác động quan trọng hơn nhiều. Độc giả có thể tham khảo bài viết trước đó của chúng tôi về Helius trên blog.Lịch phát hành và lịch phát giấy tờ của Solanađể có một phân tích chi tiết hơn về những động lực này.

‍

Phần thưởng Epoch được phân tách

Phần thưởng vụ trụ được chia thành các kỷ nguyênnhằm phân phốithưởng cổ phầnqua nhiều khối, làm giảm các vấn đề về hiệu suất liên quan đến việc tập trung phân phối phần thưởng trong khối đầu tiên của mỗi kỷ nguyên mới. Điểm bottleneck chính trong quá trình này là yêu cầu ghi cập nhật trở lại số tài khoản cổ phần hoạt động ngày càng tăng trên mạng, hiện nay là khoảng 1,4 triệu.

Theo phương pháp mới này, việc tính toán và phân phối phần thưởng cổ phần tại ranh giới thời kỳ sẽ được chia thành hai giai đoạn riêng biệt:

‍

• Giai đoạn tính toán phần thưởng: Trong giai đoạn này, phần thưởng epoch cho tất cả các tài khoản cổ phần hoạt động được tính toán và phân phối được chia thành các khối được lập lịch.
• Phân phối Pha Thưởng: Phần thưởng vòng trước tính toán trước cho các tài khoản cổ phần hoạt động được phân phối tương ứng.

‍

Để tạo điều kiện thuận lợi và giám sát quá trình, một tài khoản Sysvar,EpochRewards, sẽ theo dõi và xác minh phân phối phần thưởng trong suốt giai đoạn phân phối. EpochRewards Sysvar ghi lại nếu giai đoạn phân phối phần thưởng đang diễn ra và thông tin cần thiết để tiếp tục phân phối khi bắt đầu từ ảnh chụp nhanh.

Tính toán Phần Thưởng

Các phép tính phần thưởng sẽ được thực hiện tại block đầu tiên của kỷ nguyên. Khi đã tính toán xong, phần thưởng sẽ được phân chia thành các đoạn phân phối được lưu trữ trong ngân hàng, 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ý khối trong giai đoạn phân phối phần thưởng và đảm bảo rằng mỗi khối phân phối một phần của phần thưởng theo một cách xác định, mục tiêu của 4.096 phần thưởng cổ phần sẽ được phân phối cho mỗi khối. Để bảo vệ chống lại sự tăng trưởng đột biến trong số lượng tài khoản cổ phần, số lượng khối được giới hạn ở 10% tổng số khe trong một kỷ nguyên. Chỉ khi đạt được giới hạn khối này, các tài khoản trên mỗi phân vùng mới được phép vượt qua mục tiêu 4.096.

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

Quá trình phân phối phần thưởng bắt đầu ngay sau giai đoạn tính toán phần thưởng, bắt đầu từ khối thứ hai của kỷ nguyên. Quá trình phân phối phần thưởng xảy ra ở đầu khối trước quá trình xử lý giao dịch bình thường.

‍

Kết quả là, người dùng có thể thấy những phần thưởng được ghi có trong tài khoản giao dịch cổ phần của họ một vài khối sau đó so với trước đây. Tuy nhiên, trải nghiệm tổng thể vẫn tương tự, vì thời gian khối đầu tiên kéo dài tại ranh giới thời đại trước đây đã làm chậm quyền truy cập của người dùng vào tài khoản giao dịch cổ phần. Lợi ích bổ sung của phương pháp này là các giao dịch không liên quan đến cổ phần vẫn có thể tiếp tục xử lý một cách mượt mà, trong khi trước đây, chúng bị chặn trong quá trình phân phối phần thưởng.

‍

Do to sự tỷ lệ số tài khoản bỏ phiếu tương đối thấp, khoảng 1.500, cơ chế hiện tại để phân phối phần thưởng bỏ phiếu tại khối đầu tiên của ranh giới kỷ nguyên sẽ không thay đổi. Chỉ có phần thưởng cổ phần được phân phối qua nhiều khối.

‍

Central Scheduler hiện đang được mặc định bật

Được giới thiệu lần đầu tiên như một tính năng phát hành trong bản cập nhật v1.18, trình lên lịch trung tâm, trước đây được biết đến với tên là 'trình lên lịch,' không được kích hoạt mặc định và phải được các nhà điều hành kích hoạt bằng cách sử dụng cờ --block-production-method central-scheduler khi bắt đầu một validator. Hiện nay, nó đã được bật mặc định. Cài đặt trình lên lịch trước đây đã gặp một số vấn đề có thể ảnh hưởng đến hiệu suất. Những chướng ngại về xử lý giao dịch thường dẫn đến độ trễ hoặc không nhất quán trong việc sắp xếp và ưu tiên giao dịch.

‍

Bản cài đặt mới thay thế mô hình trước đó của bốn luồng ngân hàng độc lập, mỗi luồng quản lý việc ưu tiên và xử lý giao dịch của riêng mình. Trong cấu trúc được sửa đổi này, trình lập lịch trung tâm là người nhận duy nhất của các giao dịch từ giai đoạn SigVerify của TPU. Nó xây dựng một hàng đợi ưu tiên và triển khai một đồ thị phụ thuộc, được biết đến là một prio-graph, để quản lý tốt hơn quá trình xử lý và ưu tiên của các giao dịch xung đột. Thiết kế trình lập lịch mới này tăng tính mở rộng và linh hoạt, cho phép tăng số luồng mà không còn lo ngại về sự xung đột khóa tăng. Việc triển khai ban đầu của trình lập lịch trung tâm đã được chứng minh tạo ra phần thưởng tốt hơn, dẫn đến thu nhập cải thiện cho nhiều người vận hành. Bài đăng Helius trước đó của chúng tôi về cập nhật Solana v1.18 đã được đề cập một cách chi tiếtcách trình 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 được lên kế hoạch đưa vào bản phát hành 1.17, hiện không còn được dùng nữa và sẽ được thay thế bằng một chương trình linh hoạt hơn, độc lập với ứng dụngchương trình chứng minh ZK ElGamal. Chương trình Chứng minh ZK ElGamal mới giữ lại các phần của chương trình Chứng minh ZK Token áp dụng rộng rãi trên các ứng dụng, như xác minh tính hợp lệ của một khóa công khai hoặc phạm vi các giá trị được mã hóa trong một văn bản ElGamal. Tuy nhiên, nó loại bỏ các yếu tố cụ thể của ứng dụng như xác thực chứng minh không biết của yêu cầu chuyển SPL Token. Chương trình Chứng minh ZK ElGamal mới sẽ được tích hợp vào danh sách chương trình tích hợp tại địa chỉ ZkE1Gama1Proof11111111111111111111111111111.

‍

Để biết thêm về Chương trình ZK Token Proof, hãy đọc bài viết của chúng tôibài viết gốc trên blog Helius.

Lấy Sysvar Syscall

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

‍

Sysvars tiết lộ thông tin trạng thái cụm, như hash khối gần đây và phần thưởng kỷ nguyên. Những tài khoản này được tạo ở các địa chỉ đã biết. Chương trình có thể truy cập Sysvars thông qua tài khoản Sysvar hoặc truy vấn chúng qua một Syscall. Các chương trình trên chuỗi sử dụng nhiều Sysvars cho nhiều trường hợp sử dụng và một số Sysvars cụ thể quan trọng cho hoạt động của mạng.

‍

Các cuộc gọi hệ thống Get-Sysvar, ban đầu được đề xuất trongSIMD-127 của kỹ sư Anza Joe Caulfield, 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 trước đây không thể tiếp cận, bao gồm SlotHashes và StakeHistory. Với giao diện mới này, các nhà phát triển có thể truy cập các đoạn cụ thể của dữ liệu Sysvar—như việc 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 chi phí khi sửa đổi bố cục dữ liệu Sysvar hoặc thêm Sysvar mới. Trước đây, mỗi Sysvar mới yêu cầu bổ sung một Syscall tương ứng, tạo ra một mối quan hệ kết hợp chặt chẽ làm tăng giao diện Syscall theo thời gian và bảo trì phức tạp. Giờ đây, một sol_get_Sysvar Syscall duy nhất sẽ phục vụ tất cả các 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.

‍

Giới thiệu Syscall mới giúp đơn giản hóa quá trình sửa đổi và thêm mới Sysvars. 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, cập nhật này mở đường cho việc mở rộng truy cập chương trình BPF vào dữ liệu Sysvar, cho phép các chương trình trên chuỗi đọc thêm thông tin Sysvar mà không ảnh hưởng đến kích thước giao dịch.

‍

GetEpochStake Syscall

Cổng mớiGetEpochStake Syscallsẽ giới thiệu một tính năng mà rất được yêu cầu để lấy lại sự đầu tư ủy quyền của một tài khoản biểu quyết cho thời kỳ hiện tại, cung cấp một phương pháp trực tiếp và hiệu quả hơn để lấy thông tin này trên chuỗi.

‍

Hiện tại, các chương trình không thể truy cập được dữ liệu thời gian thực về cổ phần được giao cho các tài khoản bỏ phiếu cụ thể cho thời kỳ hiện tại, tạo ra một rào cản đối với các trường hợp sử dụng như quản trị viên xác nhận và cơ chế đồng thuận phụ. Kích hoạt việc truy vấn dữ liệu trên chuỗi này sẽ mở khóa các ứng dụng này và mở đường cho các trường hợp sử dụng trong tương lai.

‍

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

‍

MoveStake và MoveLamports

Hai hướng dẫn chương trình cọc mới,MoveStake và MoveLamports, đang được giới thiệu để tạo điều kiện cho việc chuyển giá trị giữa các tài khoản cổ đông. Các hướng dẫn này, lần đầu tiên được đề xuất trongSIMD-0148, hỗ trợ các nhà phát triển bằng cách cho phép di chuyển quỹ giữa các tài khoản với các quyền hạn tương ứng mà không cần kiểm soát từ cơ quan rút tiền.

‍

Trước đây, các giao thức quản lý sự tham gia của người dùng đã đối mặt với những thách thức khi chia nhỏ sự tham gia của người dùng qua nhiều người xác thực và thường xuyên chuyển nhượng lại giữa chúng. Khi một giao thức chia sẻ sự tham gia của người dùng để vô hiệu hóa, nó phải cung cấp lượng lamports miễn thuê nhà cho tài khoản mới. Giao thức không thể thu hồi lượng lamports miễn thuê nhà khi hợp nhất các tài khoản đã chia tách này.

MoveStake: Hướng dẫn này cho phép di chuyển cổ phần hoạt động giữa các tài khoản, chuyển nó từ một tài khoản hoạt động sang tài khoản khác hoặc từ một tài khoản hoạt động sang một tài khoản không hoạt động, từ đó làm cho tài khoản trở lại hoạt động. Nếu toàn bộ sự uỷ quyền của tài khoản nguồn được di chuyển, tài khoản nguồn trở thành không hoạt động. Số dư miễn thuế thuê vẫn không bị ảnh hưởng trong tất cả các kịch bản, và các quy tắc tối thiểu uỷ quyền được duy trì cho các tài khoản hoạt động.

‍

MoveLamports: Chuyển lamports dư thừa từ một tài khoản hoạt động hoặc không hoạt động sang một tài khoản hoạt động hoặc không hoạt động khác, trong đó “lamports dư thừa” đề cập đến lamports không được giao quyền cược hoặc cần thiết cho miễn trừ tiền thuê. MoveLamports cho phép các nhiệm vụ quản lý như thu hồi lamports từ các tài khoản hợp nhất và tập trung quỹ không sử dụng.

‍

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

‍

Phần thưởng: The Solana-SVM Crate

Với việc phát hành Agave 2.0 đi kèm mộtthùng solana-svm hoàn toàn mớicung cấp cho các nhà phát triể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 được tối ưu hóa độc lập với khung xác thực đầy đủ. Điều này mở ra khả năng xử lý giao dịch hiệu suất cao của Solana cho các ứng dụng ngoài trình xác thực, chẳng hạn như các dịch vụ off-chain, khách hàng nhẹ, kênh trạng thái và rollups.

‍

Bằng cách tách API khỏi phần còn lại của thời gian chạy, thùng này loại bỏ sự cần thiết của các thành phần như Phiên bản ngân hàng, giảm chi phí hoạt động. Các nhà phát triển hiện có thể tận dụng các thành phần mạnh mẽ tương tự hỗ trợ mainnet-beta của Solana để xây dựng các dự án SVM tùy chỉnh như máy khách nhẹ, kênh trạng thái, bản tổng hợp và dịch vụ ngoài chuỗi. Cốt lõi của API này là cấu trúc TransactionBatchProcessor, cho phép các ứng dụng xử lý hàng loạt giao dịch Solana đã được khử trùng với bộ đầy đủ các thành phần Agave xuôi dòng, bao gồm BPF Loader, eBPF và máy ảo.

‍

Trên: bộ xử lý lô giao dịch (nguồn ảnh: Anza)

‍

Đọc sâu vàoNew SVM API của Anzađể biết thông tin chi tiết về sự phát triển hứa hẹn này.

‍

Các Điểm Kết Nối RPC Đã Được Xoá

Nhiều điểm cuối v1 Agave RPC lỗi thời và không còn hỗ trợ đã được loại bỏ. Nhóm Helius Devrel đã liên lạc với tất cả khách hàng đang sử dụng các điểm cuối này. Thông qua phân tích nội bộ, chúng tôi trước đó đã xác định một nhóm nhỏ khách hàng đang sử dụng các điểm cuối sau đây, mà đang được chuẩn bị loại bỏ:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Một lần nữa, chúng tôi mạnh dạn đề nghị tất cả các nhà phát triển kiểm tra các tham chiếu đến các cuộc gọi này và cập nhật chúng một cách thích hợp với các thay thế đề xuất.

‍

Trên: danh sách đầy đủ các điểm cuối RPC Agave phiên bản v1 đã cũ và không còn được sử dụng sẽ được loại bỏ

‍

N.B. Cách tiếp cận thay thế cho getAccountInfo được hiển thị trong hình ảnh có thể là:tìm thấy ở đây.

‍

Các thay đổi đột phá SDK bao gồm:

‍

• Hỗ trợ cho Borsh v0.9 đã bị gỡ bỏ, vui lòng sử dụng v1 hoặc v0.10#1440)
• Bản sao không còn được tạo ravề Rent và EpochSchedule; chuyển sang sử dụng clone()
• solana-sdk: các biểu tượng không còn được sử dụng) đã bị xóa
• solana-program: biểu tượng không còn được sử dụng đã bị xóa bỏ

‍

Đối với các nhà điều hành xác thực, một số đối số xác thực không còn được hỗ trợ sau khi Agave v2.0 được phát hành. Bạn có thể tìm thấy danh sách đầy đủ của chúngở đây.

‍

Kết luận

Cập nhật Agave 2.0 đánh dấu một bước tiến đáng kể cho Solana, bao gồm nhiều tính năng mới và tối ưu hóa thời gian chạy. Bản phát hành này tiếp tục đẩy giới hạn với các Syscall mới mạnh mẽ, chức năng mở rộng và housekeeping toàn diện, bao gồm việc đổi tên crate, loại bỏ phương thức RPC đã lỗi thời và đơn giản hóa đối số của trình xác thực. Agave 2.0 mở rộng khả năng của Solana và tinh chỉnh hiệu suất và tính khả dụng của nó. Cho dù bạn là một nhà phát triển, trình xác thực hoặc người dùng tích cực, cập nhật Agave 2.0 mở ra những khả năng mới thú vị cho mọi người trong hệ sinh thái Solana.

‍

Tài nguyên bổ sung / Đọc thêm

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

Chú ý:

1. Bài viết này được tái bản từ [gatehelius)]. Tất cả bản quyền thuộc về tác giả gốc [ Lạc lối]. Nếu có ý kiến phản đối bản in lại này, vui lòng liên hệ với Cổng Họcđội ngũ, và họ sẽ xử lý nó ngay lập tức.
2. Bản quyền từ chối trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không tạo thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi có ghi chú, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là cấm.