Agave v2.0 更新，你需要知道的一切
Agave 2.0 摘要
Agave 驗證器客戶端 v2.0 的發布標誌著 Solana 在追求更強大、多客戶端生態系統的旅程中達到了一個重要的里程碑。此次更新引入了幾項關鍵改進，以提升網絡性能、可靠性和效率。此次更新的主要變化包括：
- 廣泛的代碼庫重構和優化
- 分區時代獎勵
- 將完整的優先費用獎勵給驗證者
- 新的中央排程器現在默認情況下已啟用
- ZK ElGamal證明程序
- Get-Sysvar Syscall
- GetEpochStake 系統調用
- MoveStake和MoveLamports
- 移除已棄用的RPC方法
- 创建重命名
無論您是運行驗證器、在平台上建立應用，還是積極使用Solana，這份關於Agave 2.0更新的全面概述將為您提供洞察力，幫助您理解並利用這些最新創新。
2.0 是一個重大版本更新的原因是什麼？
再也没有单一的‘Solana验证器’。Agave 2.0拥抱Solana的新的多客户端世界，与旧世界划清界限。Solana Labs GitHub 儲存庫.Solana Labs 儲存庫將被存檔，新的拉取請求或問題將不再被接受。以前，此存儲庫鏡像了龍舌蘭存儲庫中的活動。開發人員應將所有活動遷移到Anza Agave GitHub存儲庫如果他們還沒有這樣做的話。Solana Labs to Agave遷移過程於3月1日開始，並在其GitHub上公開追踪。
隨著生態系統的演變，運營商必須適應運行一個或多個客戶端。在這一變化之後，一些庫正在改名，清理命名空間以支持多個客戶端——最重要的是Firedancer——由獨立開發團隊管理。 Anza 維護的庫現在將以“agave”作為前綴，使它們在多客戶端環境中易於識別為 Anza 特定的依賴項。
受影響的貨箱是：
solana-validator、solana-ledger-tool、solana-watchtower、solana-install、solana-geyser-plugin-interface、solana-cargo-registry
如詳細說明先前的过渡指南，2.0 更新引入了幾項重大更改，最引人注目的是刪除了幾個過時和已棄用的端點——所有 Solana 開發人員現在都應該知道的關鍵更新。本文末尾包含 RPC 更改的完整詳細資訊。
功能推出
在撰寫本文時，約有20.7%的驗證人正在運行2.0.14版本。主網上的功能閘門激活暫時暫停，以便讓v2.0的採用更加貼近測試網和開發網上的激活。一旦主網集群廣泛採用v2.0，預計功能閘門的激活將恢復正常，按照預定啟動訂單.
以下部分討論的新完整功能目前尚未上線，將會在2.0生命周期內逐步通過功能閘門系統進行推出。功能會根據相對優先順序和它們在測試網絡和開發網絡叢集上啟用的順序在特定時期激活。
將完整的優先手續費獎勵給驗證者
這個備受期待的廣受爭議的經濟更新正在根據提案進行實施，SIMD-0096，其在五月份經過驗證器治理投票。投票於第620個時間單位結束，有51.17%的權益參與並有77.77%的選票贊成。這個特性閘門更新將從根本上改變網絡的處理方式。優先費用與目前的模型不同，該模型將100％的優先手續費直接分配給驗證器，而不是將費用分成50％燃燒和50％獎勵給驗證器。注意：翻譯中如出現“gate”一詞，請翻譯成“gate”而非翻譯為其他詞語。
上面：Solana每週優先手續費以美元價值計算（來源)
雖然優先費在技術上是可選的，但隨著Solana經濟活動的增加，它們已成為標準做法。這些費用是使用以下公式以每個計算單位的微埠（百萬分之一的lamport）計算的：
優先費=計算單位價格(微拉姆波特) x 計算單位限制
未來，所有優先費將授予區塊生產者。這創造了更強烈的激勵措施，減少了驗證人員從事協議外交易納入的可能性，這在過去曾經是一個問題。
儘管取消手續費燃燒會稍微提高 SOL 的淨通脹率，但通過鎖定獎勵發行新代幣對此的影響更大。讀者可以參考我們早期的 Helius 博客文章。Solana的發行和通脹時間表對於這些動態的更詳細分析。
分區紀元獎勵
分區紀元獎勵旨在分發貨幣權益獎勵跨多個區塊，減輕了將獎勵分配集中在每個新時期的第一個區塊內的性能問題。這個過程中的主要瓶頸是需要將更新寫回到網絡上日益增多的活動權益帳戶，目前總數約為140萬。
在這種新方法下，紀元邊界的質押獎勵計算和分配將分為兩個不同的階段：
- 獎勵計算階段：在此階段，計算所有活躍質押帳戶的紀元獎勵，並將分配分解為計劃的塊。
- 獎勵分配階段：根據活躍股份賬戶的預先計算的時期獎勵進行分配。
為了便於監控和管理過程，需要一個Sysvar帳戶，時代獎勵，將在整個分配階段跟蹤和驗證獎勵分配。EpochRewards Sysvar 會記錄獎勵分配階段是否正在進行中，以及從快照開始時恢復分配所需的資訊。
獎勵計算
獎勵計算將在時期的第一個區塊中執行。一旦計算完成，獎勵將被劃分為存儲在銀行中的分發塊，並將在獎勵分發階段進行分發。
為了盡量減少獎勵分配階段對區塊處理時間的影響，並確保每個區塊以確定的方式分配獎勵的子集，每個區塊將分配 4,096 個質押獎勵的目標。為了防止質押賬戶數量急劇增長，區塊數量上限為紀元內總插槽的 10%。僅當達到此塊上限時，每個分區的帳戶才允許超過 4,096 個目標。
獎勵分配
獎勵分配始於獎勵計算階段的第二個區塊，即時開始。獎勵分配在正常交易處理之前的區塊頂部進行。
因此，用戶可能會看到獎勵比之前晚幾個區塊才記入他們的權益帳戶。然而，整體體驗保持相似，因為在時代邊界的延長第一區塊時間之前，用戶訪問權益帳戶的時間被推遲。此方法的額外好處是非權益交易可以繼續順利處理，而之前在獎勵分配期間它們被阻塞。
由於相對較少的投票帳戶（約 1,500 個），在時代邊界的第一個區塊中分發投票獎勵的現有機制將保持不變。只有股份獎勵將分佈在多個區塊上。
中央排程器現在默認情況下已啟用
首次作為v1.18更新中的一個功能發布，中央排程器，以前被稱為“排程器”，不是默認啟用的，操作員需要在啟動驗證器時使用--block-production-method central-scheduler標誌來啟用。現在默認已啟用。以前的排程器實現存在一些問題，可能會對性能產生不利影響。交易處理中的瓶頸經常導致交易排序和優先級的抖動或不一致。
較新的實現取代了以前的四個獨立銀行線程模型，每個線程管理自己的事務優先順序和處理。在這個修訂后的結構中，中央調度程式是TPU的SigVerify階段交易的唯一接收者。它構建優先順序佇列並部署依賴關係圖（稱為 prio-graph），以更好地管理衝突事務的處理和優先順序排序。這種新的調度程式設計提高了可擴展性和靈活性，允許增加線程數，而不必擔心以前增加鎖衝突。中央調度程式的初始推出已被證明可以產生更好的回報，從而提高許多運營商的收入。我們之前關於 Solana v1.18 更新的 Helius 帖子廣泛涵蓋了中央調度程序的工作原理.
ZK ElGamal 證明程式
原计划在1.17版本中包含的ZK Token Proof程序现已弃用，并将被一种更加通用、应用无关的替代方案所取代。ZK ElGamal證明程序.新的ZK ElGamal證明程式保留了ZK令牌證明程式中廣泛適用於應用程式的部分，例如驗證公鑰的有效性或在ElGamal密文中加密的值範圍。但是，它省略了特定於應用程式的元素，例如SPL令牌傳輸指令所需的零知識證明驗證。新的ZK ElGamal證明程式將被納入該位址的內置程式清單中ZkE1Gama1Proof11111111111111111111111111111.
要了解有關ZK令牌證明計劃的更多信息，請閱讀我們的Helius博客上的原始文章.
取得Sysvar系統呼叫
Syscalls，或系統呼叫，是從操作系統內核請求服務的方式。在Solana的上下文中，Syscall使得在Solana虛擬機器（SVM）內運行的程序能夠與外部資源和服務進行互動。
Sysvars公開集群狀態信息，例如最近的區塊哈希和時代獎勵。這些帳戶是在已知地址上填充的。程序可以通過Sysvar帳戶訪問Sysvars，或者通過Syscall查詢它們。鏈上程序對於各種用例使用許多Sysvars，而某些Sysvars對於網絡的運作至關重要。
Get-Sysvar Syscall，最初在SIMD-127 由 Anza 工程師 Joe Caulfield 設計引入了一個統一的Syscall接口，用於訪問Sysvar數據。此升級使得之前無法訪問的Sysvar數據，包括SlotHashes和StakeHistory，可以被檢索到。通過這個新接口，開發者可以訪問Sysvar數據的特定片段，比如調用。SlotHashes::get_slot(slot)和StakeHistory::get_entry(epoch)—無需複製整個數據結構。
此更新還最大限度地減少了修改 Sysvar 數據佈局或添加新 Sysvar 時的開銷。以前，每個新的 Sysvar 都需要添加相應的 Syscall，從而創建緊密耦合的關係，隨著時間的推移使 Syscall 介面膨脹並導致維護變得複雜。現在，單個sol_get_Sysvar Syscall將為所有Sysvar介面提供服務，從而實現從任何Sysvar進行一致且高效的數據檢索。
新的Syscall的引入简化了修改和添加新的Sysvar的过程。它显著降低了Syscall接口的复杂性和维护要求。此外，此更新为扩展BPF程序访问Sysvar数据铺平了道路，使得链上程序可以在不影响交易大小的情况下读取更多Sysvar信息。
取得 Epoch Stake Syscall
新的GetEpochStake Syscall將為檢索當前時期的投票帳戶的委派股份引入一項高度要求的功能，提供一種更有效、直接的方法，在鏈上檢索此信息。
目前，程序無法在當前時期存取特定投票帳戶委託的即時數據，這對於驗證器治理和次要共識機制等用例造成了障礙。啟用鏈上查詢此數據將解鎖這些應用並為未來用例鋪平道路。
使用GetEpochStake，開發者提供一個32字節的投票帳戶地址，系統調用將返回一個u64整數，表示當前委託給該投票帳戶的總活躍權益。如果提供的地址不對應有效的投票帳戶或不存在，系統調用將返回0。
MoveStake和MoveLamports
兩個新的質押計劃說明，MoveStake和MoveLamports为了促进股份账户之间的价值转移，我们正在引入这些指令，这些指令最初是在提出的SIMD-0148通過允許具有匹配權限的帳戶之間的資金移動，而不受提款權限的控制，來協助開發人員。
以前，管理使用者權益的協定在將權益分配給多個驗證者並定期在它們之間重新委託時面臨挑戰。當協定拆分使用者的權益以進行停用時，它必須為新帳戶的租金減免提供資金。協議無法在合併這些拆分帳戶時收回租金豁免。
MoveStake：此指令允許將活躍的權益在帳戶之間轉移，將其從一個活躍帳戶轉移到另一個活躍帳戶，或從活躍帳戶轉移到非活躍帳戶，從而重新激活帳戶。如果整個源帳戶的委託被轉移，源帳戶將變為非活躍。在所有情況下，租金免除餘額保持不變，並且對活躍帳戶保持最低委託規則。
MoveLamports：將多餘的Lamport從一個活躍或不活躍的帳戶轉移到另一個活躍或不活躍的帳戶，其中“多餘的Lamports”是指既不是委託股權也不是免租要求的Lamports。MoveLamports 支援內務管理任務，例如從合併帳戶中回收 Lamports 和合併未使用的資金。
為了簡化實施過程，這些更改不支持啟用或停用帳戶，也不會影響部分啟用的權益帳戶。這些新的程式指示不會改變現有的功能。
獎金：Solana-SVM箱
隨著 Agave 2.0 的釋出全新的索拉納-SVM板條箱通過簡化的 API，開發人員可以直接訪問核心 SVM 組件，而無需完整的驗證人框架。這為 Solana 的高性能交易處理打開了應用領域，包括驗證人以外的應用，如鏈下服務、輕量級客戶端、狀態通道和 Rollup。
通過將 API 與運行時的其餘部分分離，此板條箱消除了對 Bank 實例等元件的需求，從而降低了運營開銷。開發人員現在可以利用支援 Solana 主網測試版的相同強大元件來構建自定義 SVM 專案，例如輕用戶端、狀態通道、匯總和鏈下服務。此 API 的核心是 TransactionBatchProcessor 結構，它允許應用程式使用全套下游龍舌蘭元件（包括 BPF Loader、eBPF 和虛擬機）處理批量清理的 Solana 事務。
上圖：交易批次處理器（圖片來源：Anza）
閱讀深入探討Anza的新SVM API有關這一令人興奮的發展的詳細信息，請參閱。
刪除了RPC端點
已刪除多個過時和棄用的v1 Agave RPC端點。Helius Devrel團隊已聯繫使用這些端點的所有客戶。通過內部分析，我們之前已經識別出一小部分正在使用以下即將刪除的端點的客戶：
getRecentBlockhash、getConfirmedSignatureForAddresses2、getConfirmedTransaction、getConfirmedBlock、getStakeActivation、getFees
同樣，我們強烈建議所有開發人員檢查對這些調用的引用，並使用建議的替換進行適當更新。
上述:一份完整的被淘汰和棄用的v1 Agave RPC端點清單，將會被移除
N.B. 圖片中顯示的getAccountInfo的替代方法可以是在这里找到.
SDK破壞性變更包括:
- 已刪除對Borsh v0.9的支援，請使用v1或v0.10#1440)
- 複製特性不再衍生在租用和EpochSchedule上；切換到使用clone()
- solana-sdk: 不推薦的符號) 移除
- solana-program：已棄用的符號已移除
對於驗證者運營商而言，在發布 Agave v2.0 後，將刪除幾個已棄用的驗證者參數。這些參數的完整列表可在以下位置找到這裡.
結論
Agave 2.0 更新標誌著 Solana 的重大進步，包括眾多功能實現和運行時優化。此版本持續突破界限，擁有強大的新系統呼叫、擴展功能和全面的系統維護，包括創建重命名、停用的 RPC 方法移除和精簡的驗證器參數。Agave 2.0 擴展了 Solana 的功能，並完善了其性能和易用性。無論您是開發人員、驗證器還是活躍用戶，Agave 2.0 更新為 Solana 生態系統中的每個人開啟了令人興奮的新可能性。
更多資源/進一步閱讀
免責聲明：
相關文章
在加密貨幣中，完全稀釋市值（FDV）是什麼？
個人護衛和附庸，Puffer UniFi（基於Rollup）和主流Rollups
解讀Starknet智能合約模型與原生AA：特立獨行的技術巨匠
Agave v2.0 更新，你需要知道的一切
Agave 2.0 摘要
將完整的獎勵優先費用分配給驗證者
分區紀元獎勵
中央排程器現在是默認啟用的
ZK 埃爾賈瑪律證明計劃
Get-Sysvar Syscall
GetEpochStake Syscall
MoveStake和MoveLamports
獎勵：Solana-SVM存儲箱
已移除 RPC 端點
結論
其他資源 / 進一步閱讀
Agave 2.0 摘要
Agave 驗證器客戶端 v2.0 的發布標誌著 Solana 在追求更強大、多客戶端生態系統的旅程中達到了一個重要的里程碑。此次更新引入了幾項關鍵改進，以提升網絡性能、可靠性和效率。此次更新的主要變化包括：
- 廣泛的代碼庫重構和優化
- 分區時代獎勵
- 將完整的優先費用獎勵給驗證者
- 新的中央排程器現在默認情況下已啟用
- ZK ElGamal證明程序
- Get-Sysvar Syscall
- GetEpochStake 系統調用
- MoveStake和MoveLamports
- 移除已棄用的RPC方法
- 创建重命名
無論您是運行驗證器、在平台上建立應用，還是積極使用Solana，這份關於Agave 2.0更新的全面概述將為您提供洞察力，幫助您理解並利用這些最新創新。
2.0 是一個重大版本更新的原因是什麼？
再也没有单一的‘Solana验证器’。Agave 2.0拥抱Solana的新的多客户端世界，与旧世界划清界限。Solana Labs GitHub 儲存庫.Solana Labs 儲存庫將被存檔，新的拉取請求或問題將不再被接受。以前，此存儲庫鏡像了龍舌蘭存儲庫中的活動。開發人員應將所有活動遷移到Anza Agave GitHub存儲庫如果他們還沒有這樣做的話。Solana Labs to Agave遷移過程於3月1日開始，並在其GitHub上公開追踪。
隨著生態系統的演變，運營商必須適應運行一個或多個客戶端。在這一變化之後，一些庫正在改名，清理命名空間以支持多個客戶端——最重要的是Firedancer——由獨立開發團隊管理。 Anza 維護的庫現在將以“agave”作為前綴，使它們在多客戶端環境中易於識別為 Anza 特定的依賴項。
受影響的貨箱是：
solana-validator、solana-ledger-tool、solana-watchtower、solana-install、solana-geyser-plugin-interface、solana-cargo-registry
如詳細說明先前的过渡指南，2.0 更新引入了幾項重大更改，最引人注目的是刪除了幾個過時和已棄用的端點——所有 Solana 開發人員現在都應該知道的關鍵更新。本文末尾包含 RPC 更改的完整詳細資訊。
功能推出
在撰寫本文時，約有20.7%的驗證人正在運行2.0.14版本。主網上的功能閘門激活暫時暫停，以便讓v2.0的採用更加貼近測試網和開發網上的激活。一旦主網集群廣泛採用v2.0，預計功能閘門的激活將恢復正常，按照預定啟動訂單.
以下部分討論的新完整功能目前尚未上線，將會在2.0生命周期內逐步通過功能閘門系統進行推出。功能會根據相對優先順序和它們在測試網絡和開發網絡叢集上啟用的順序在特定時期激活。
將完整的優先手續費獎勵給驗證者
這個備受期待的廣受爭議的經濟更新正在根據提案進行實施，SIMD-0096，其在五月份經過驗證器治理投票。投票於第620個時間單位結束，有51.17%的權益參與並有77.77%的選票贊成。這個特性閘門更新將從根本上改變網絡的處理方式。優先費用與目前的模型不同，該模型將100％的優先手續費直接分配給驗證器，而不是將費用分成50％燃燒和50％獎勵給驗證器。注意：翻譯中如出現“gate”一詞，請翻譯成“gate”而非翻譯為其他詞語。
上面：Solana每週優先手續費以美元價值計算（來源)
雖然優先費在技術上是可選的，但隨著Solana經濟活動的增加，它們已成為標準做法。這些費用是使用以下公式以每個計算單位的微埠（百萬分之一的lamport）計算的：
優先費=計算單位價格(微拉姆波特) x 計算單位限制
未來，所有優先費將授予區塊生產者。這創造了更強烈的激勵措施，減少了驗證人員從事協議外交易納入的可能性，這在過去曾經是一個問題。
儘管取消手續費燃燒會稍微提高 SOL 的淨通脹率，但通過鎖定獎勵發行新代幣對此的影響更大。讀者可以參考我們早期的 Helius 博客文章。Solana的發行和通脹時間表對於這些動態的更詳細分析。
分區紀元獎勵
分區紀元獎勵旨在分發貨幣權益獎勵跨多個區塊，減輕了將獎勵分配集中在每個新時期的第一個區塊內的性能問題。這個過程中的主要瓶頸是需要將更新寫回到網絡上日益增多的活動權益帳戶，目前總數約為140萬。
在這種新方法下，紀元邊界的質押獎勵計算和分配將分為兩個不同的階段：
- 獎勵計算階段：在此階段，計算所有活躍質押帳戶的紀元獎勵，並將分配分解為計劃的塊。
- 獎勵分配階段：根據活躍股份賬戶的預先計算的時期獎勵進行分配。
為了便於監控和管理過程，需要一個Sysvar帳戶，時代獎勵，將在整個分配階段跟蹤和驗證獎勵分配。EpochRewards Sysvar 會記錄獎勵分配階段是否正在進行中，以及從快照開始時恢復分配所需的資訊。
獎勵計算
獎勵計算將在時期的第一個區塊中執行。一旦計算完成，獎勵將被劃分為存儲在銀行中的分發塊，並將在獎勵分發階段進行分發。
為了盡量減少獎勵分配階段對區塊處理時間的影響，並確保每個區塊以確定的方式分配獎勵的子集，每個區塊將分配 4,096 個質押獎勵的目標。為了防止質押賬戶數量急劇增長，區塊數量上限為紀元內總插槽的 10%。僅當達到此塊上限時，每個分區的帳戶才允許超過 4,096 個目標。
獎勵分配
獎勵分配始於獎勵計算階段的第二個區塊，即時開始。獎勵分配在正常交易處理之前的區塊頂部進行。
因此，用戶可能會看到獎勵比之前晚幾個區塊才記入他們的權益帳戶。然而，整體體驗保持相似，因為在時代邊界的延長第一區塊時間之前，用戶訪問權益帳戶的時間被推遲。此方法的額外好處是非權益交易可以繼續順利處理，而之前在獎勵分配期間它們被阻塞。
由於相對較少的投票帳戶（約 1,500 個），在時代邊界的第一個區塊中分發投票獎勵的現有機制將保持不變。只有股份獎勵將分佈在多個區塊上。
中央排程器現在默認情況下已啟用
首次作為v1.18更新中的一個功能發布，中央排程器，以前被稱為“排程器”，不是默認啟用的，操作員需要在啟動驗證器時使用--block-production-method central-scheduler標誌來啟用。現在默認已啟用。以前的排程器實現存在一些問題，可能會對性能產生不利影響。交易處理中的瓶頸經常導致交易排序和優先級的抖動或不一致。
較新的實現取代了以前的四個獨立銀行線程模型，每個線程管理自己的事務優先順序和處理。在這個修訂后的結構中，中央調度程式是TPU的SigVerify階段交易的唯一接收者。它構建優先順序佇列並部署依賴關係圖（稱為 prio-graph），以更好地管理衝突事務的處理和優先順序排序。這種新的調度程式設計提高了可擴展性和靈活性，允許增加線程數，而不必擔心以前增加鎖衝突。中央調度程式的初始推出已被證明可以產生更好的回報，從而提高許多運營商的收入。我們之前關於 Solana v1.18 更新的 Helius 帖子廣泛涵蓋了中央調度程序的工作原理.
ZK ElGamal 證明程式
原计划在1.17版本中包含的ZK Token Proof程序现已弃用，并将被一种更加通用、应用无关的替代方案所取代。ZK ElGamal證明程序.新的ZK ElGamal證明程式保留了ZK令牌證明程式中廣泛適用於應用程式的部分，例如驗證公鑰的有效性或在ElGamal密文中加密的值範圍。但是，它省略了特定於應用程式的元素，例如SPL令牌傳輸指令所需的零知識證明驗證。新的ZK ElGamal證明程式將被納入該位址的內置程式清單中ZkE1Gama1Proof11111111111111111111111111111.
要了解有關ZK令牌證明計劃的更多信息，請閱讀我們的Helius博客上的原始文章.
取得Sysvar系統呼叫
Syscalls，或系統呼叫，是從操作系統內核請求服務的方式。在Solana的上下文中，Syscall使得在Solana虛擬機器（SVM）內運行的程序能夠與外部資源和服務進行互動。
Sysvars公開集群狀態信息，例如最近的區塊哈希和時代獎勵。這些帳戶是在已知地址上填充的。程序可以通過Sysvar帳戶訪問Sysvars，或者通過Syscall查詢它們。鏈上程序對於各種用例使用許多Sysvars，而某些Sysvars對於網絡的運作至關重要。
Get-Sysvar Syscall，最初在SIMD-127 由 Anza 工程師 Joe Caulfield 設計引入了一個統一的Syscall接口，用於訪問Sysvar數據。此升級使得之前無法訪問的Sysvar數據，包括SlotHashes和StakeHistory，可以被檢索到。通過這個新接口，開發者可以訪問Sysvar數據的特定片段，比如調用。SlotHashes::get_slot(slot)和StakeHistory::get_entry(epoch)—無需複製整個數據結構。
此更新還最大限度地減少了修改 Sysvar 數據佈局或添加新 Sysvar 時的開銷。以前，每個新的 Sysvar 都需要添加相應的 Syscall，從而創建緊密耦合的關係，隨著時間的推移使 Syscall 介面膨脹並導致維護變得複雜。現在，單個sol_get_Sysvar Syscall將為所有Sysvar介面提供服務，從而實現從任何Sysvar進行一致且高效的數據檢索。
新的Syscall的引入简化了修改和添加新的Sysvar的过程。它显著降低了Syscall接口的复杂性和维护要求。此外，此更新为扩展BPF程序访问Sysvar数据铺平了道路，使得链上程序可以在不影响交易大小的情况下读取更多Sysvar信息。
取得 Epoch Stake Syscall
新的GetEpochStake Syscall將為檢索當前時期的投票帳戶的委派股份引入一項高度要求的功能，提供一種更有效、直接的方法，在鏈上檢索此信息。
目前，程序無法在當前時期存取特定投票帳戶委託的即時數據，這對於驗證器治理和次要共識機制等用例造成了障礙。啟用鏈上查詢此數據將解鎖這些應用並為未來用例鋪平道路。
使用GetEpochStake，開發者提供一個32字節的投票帳戶地址，系統調用將返回一個u64整數，表示當前委託給該投票帳戶的總活躍權益。如果提供的地址不對應有效的投票帳戶或不存在，系統調用將返回0。
MoveStake和MoveLamports
兩個新的質押計劃說明，MoveStake和MoveLamports为了促进股份账户之间的价值转移，我们正在引入这些指令，这些指令最初是在提出的SIMD-0148通過允許具有匹配權限的帳戶之間的資金移動，而不受提款權限的控制，來協助開發人員。
以前，管理使用者權益的協定在將權益分配給多個驗證者並定期在它們之間重新委託時面臨挑戰。當協定拆分使用者的權益以進行停用時，它必須為新帳戶的租金減免提供資金。協議無法在合併這些拆分帳戶時收回租金豁免。
MoveStake：此指令允許將活躍的權益在帳戶之間轉移，將其從一個活躍帳戶轉移到另一個活躍帳戶，或從活躍帳戶轉移到非活躍帳戶，從而重新激活帳戶。如果整個源帳戶的委託被轉移，源帳戶將變為非活躍。在所有情況下，租金免除餘額保持不變，並且對活躍帳戶保持最低委託規則。
MoveLamports：將多餘的Lamport從一個活躍或不活躍的帳戶轉移到另一個活躍或不活躍的帳戶，其中“多餘的Lamports”是指既不是委託股權也不是免租要求的Lamports。MoveLamports 支援內務管理任務，例如從合併帳戶中回收 Lamports 和合併未使用的資金。
為了簡化實施過程，這些更改不支持啟用或停用帳戶，也不會影響部分啟用的權益帳戶。這些新的程式指示不會改變現有的功能。
獎金：Solana-SVM箱
隨著 Agave 2.0 的釋出全新的索拉納-SVM板條箱通過簡化的 API，開發人員可以直接訪問核心 SVM 組件，而無需完整的驗證人框架。這為 Solana 的高性能交易處理打開了應用領域，包括驗證人以外的應用，如鏈下服務、輕量級客戶端、狀態通道和 Rollup。
通過將 API 與運行時的其餘部分分離，此板條箱消除了對 Bank 實例等元件的需求，從而降低了運營開銷。開發人員現在可以利用支援 Solana 主網測試版的相同強大元件來構建自定義 SVM 專案，例如輕用戶端、狀態通道、匯總和鏈下服務。此 API 的核心是 TransactionBatchProcessor 結構，它允許應用程式使用全套下游龍舌蘭元件（包括 BPF Loader、eBPF 和虛擬機）處理批量清理的 Solana 事務。
上圖：交易批次處理器（圖片來源：Anza）
閱讀深入探討Anza的新SVM API有關這一令人興奮的發展的詳細信息，請參閱。
刪除了RPC端點
已刪除多個過時和棄用的v1 Agave RPC端點。Helius Devrel團隊已聯繫使用這些端點的所有客戶。通過內部分析，我們之前已經識別出一小部分正在使用以下即將刪除的端點的客戶：
getRecentBlockhash、getConfirmedSignatureForAddresses2、getConfirmedTransaction、getConfirmedBlock、getStakeActivation、getFees
同樣，我們強烈建議所有開發人員檢查對這些調用的引用，並使用建議的替換進行適當更新。
上述:一份完整的被淘汰和棄用的v1 Agave RPC端點清單，將會被移除
N.B. 圖片中顯示的getAccountInfo的替代方法可以是在这里找到.
SDK破壞性變更包括:
- 已刪除對Borsh v0.9的支援，請使用v1或v0.10#1440)
- 複製特性不再衍生在租用和EpochSchedule上；切換到使用clone()
- solana-sdk: 不推薦的符號) 移除
- solana-program：已棄用的符號已移除
對於驗證者運營商而言，在發布 Agave v2.0 後，將刪除幾個已棄用的驗證者參數。這些參數的完整列表可在以下位置找到這裡.
結論
Agave 2.0 更新標誌著 Solana 的重大進步，包括眾多功能實現和運行時優化。此版本持續突破界限，擁有強大的新系統呼叫、擴展功能和全面的系統維護，包括創建重命名、停用的 RPC 方法移除和精簡的驗證器參數。Agave 2.0 擴展了 Solana 的功能，並完善了其性能和易用性。無論您是開發人員、驗證器還是活躍用戶，Agave 2.0 更新為 Solana 生態系統中的每個人開啟了令人興奮的新可能性。
更多資源/進一步閱讀
免責聲明：
相關文章
在加密貨幣中，完全稀釋市值（FDV）是什麼？
個人護衛和附庸，Puffer UniFi（基於Rollup）和主流Rollups