Solanda每天新增約100萬個新帳戶，總帳戶超過5億，副本大小約70GB。 PCI磁碟容量預計到2024年可達0.5TB到1TB。帳戶資料壓縮和索引壓縮是最佳化的重點，如Avocado和Firedancer提出的方案。帳戶運行狀態快取由所有實例確定性管理，並提出了冷帳戶概念。酪梨提出狀態和索引壓縮方法，以減少空間使用。流動性矽橡膠方案引入租金制度，以確保過去的廢棄帳戶被壓縮。這些方案旨在降低狀態資料大小並改善系統效率。
作者：toly, Solana
撰稿：Felix，PANews
每天大約有100萬個新帳戶被添加到Solana中，現在的總狀態已超5億，而副本大小約為70GB。隨著硬體的改進，這些數字本身是完全可管理的，但是SVM運行時提供了最便宜的硬體存取方式，為了實現這一點，必須在當前硬體限制內管理狀態和記憶體。
PCI 磁碟
截至2024年，最新的PCI容量可達0.5 Tbs到1 Tb的吞吐量。或每秒64GB到128GB。雖然聽起來很大，但如果一個tx讀取/寫入為128MB，128GBps的PCI容量將鏈的TPS限制在1000左右。實際上，大多數txs存取是最近載入並快取到RAM中的記憶體。理想的設計應該是允許載入1000個具有128MB新狀態的txs，再加上10k或更多讀取和寫入現有快取狀態的txs。
帳單
一個帳戶需要證明該帳戶目前不存在。這通常是在每個驗證器上自動完成的，因為每個驗證器都有當前所有有效的帳戶索引。即使帳戶資料不在本機存儲，只儲存的資料雜湊值，5億個帳戶的特點是32位元組的金鑰+32位元組的資料雜湊或每個64位元組，即32 GB。這已經足夠可以保證RAM和磁碟的分離。
份量大小
針對某些副本大小（Snapshot Size）下，如果部分網路發生硬體故障，啟動新系統所需的時間足以延長最壞情況的重新啟動時間。隨著頻寬和硬體的改進，情況一直在變化，而Solana 並沒有接近這個限制，但該限制在任何時間點都存在。
概要
: 如果SVM不區分，則交易必須針對最壞情況進行製定，交易期間所有帳戶資訊至少必須可用，並且總帳戶資料將影響RAM和PCIi容量利用率。 理想的解決方案是：
允許將更多不需要PCI資源的txs打包到區塊中管理總索引大小和副本大小
Chilly、Avocado、LSR。簡單的名字是一種優秀軟體設計的標誌。 Anza和Firedancer的工程師想出了以下方案。
寒冷
帳戶運行時的快取由所有實例進行確定性管理。從更高層次看，這是存取狀態的LRU快取。在區塊建置和調度期間，此實作可以輕鬆檢查帳戶，不需要鎖定或迭代LRU快取。快取是用一個非常簡單的計數器實作。
總載入位元組被追蹤為Bank::loaded_bytes:u64 每個帳戶都在目前執行統計資料account::load_counter:u64進行標記載入帳戶時，如果Bank::loaded_bytes – Account::load_counter > CACHE_SIZE，則帳號被視為冷帳戶，其大小須根據每個區塊的LOAD_LIMIT計算新帳戶load_counter為0，因此所有新帳戶都是冷帳戶Leader的調度程序將LOAD_LIMIT作為一個水印，類似於寫鎖CU限制。
這種設計妙就妙在，它自然適合當前的調度程式。用戶只需要擔心他們的優先費。調度程序必須處理合併的tx和帳戶寫鎖的tx放入背包問題。最高資料的tx可以先載入並載入LOAD_LIMIT。一旦達到這個限制，我們仍然可以放入一個區塊中。因此，驗證器可以最大化符合txs的快取局部性。
酪梨
Avacado由兩部分組成，狀態壓縮和索引壓縮。首先用哈希替換帳戶數據，然後將它替換為二進制Trie樹或patricia Trie樹。新帳戶必須提供證明，證明它們不在“trie”中。
狀態壓縮
大致設計如下：
在分配期間，每個帳戶每個位元組綁定X個lamps。 如果X 壓縮是一個多步驟的過程，運行在一個epoch上帳戶資料被替換為雜湊值（data） 帳戶金鑰仍處於引用壓縮服務解壓需要上傳模擬程式壓成本應該與分配新帳戶的成本相同
估計75%的帳戶在超過6個月的時間裡沒有被訪問，而且很可能永遠不會被訪問。壓縮它們可以節省50%的帳戶大小。
索引壓縮
這是比較難解決的問題。透過狀態壓縮，驗證器仍然擁有該系統所有可能的帳戶。我們的帳戶需要檢查資料庫的儲存容量，以及使用者帳戶成本是否過低。要保證現有帳戶不會與任何衝突。
二元樹挖礦
二元樹作為副本的一部分被追蹤想要獲得額外的sol驗證者可以創建一個交易，從狀態刪除壓縮的帳戶kv對，並添加到串流二進制Trie中用戶可以在解壓縮過程中將kv 從Trie 中移除，從而在不允許的情況下執行此操作（這可能依賴解壓縮時進行Atom操作，從而引入後台服務壓縮帳戶時更容易）。 對於驗證器，無論它包含多少kv對，Trie根的大小都是恆定的使用zkp，每個tx可以壓縮約30個帳戶假設每個區塊只有一個，那麼壓縮5億個區塊需要大約80天的時間
進程金鑰不符合要求，驗證者將獲得獎勵，但並非所有驗證者都受此操作的約束。如果所有驗證器均受此操作的約束，則所有驗證器均受此操作的約束，這表示整個狀態都需要經過驗證。想要維護整個狀態的驗證器應該提交一個交易，將其中的N個帳戶壓縮到Trie中。
新契約證明
要建立一個新帳戶，用戶必須證明該帳戶在Trie中不存在。維護整個狀態的驗證器可以產生帳戶而不在Trie中產生證明。這給用戶帶來了負擔，他們必須始終與大型狀態提供機構連接以產生這些證明。
為了確保帳戶安全，我們建立了PoH雜湊表，以便我們能夠根據最新情況制定支援計劃。
產生新的PKI 帳戶位址是哈希（最近的PoH哈希，PKI::public_key）
由於Trie中的帳戶必須先進行狀態壓縮，這需要一個完整的epoch。 Trie中的任何一個帳戶都不可能使用最近的PoH雜湊來產生位址。
其他支援方PKI創建本身可以作為一個證明，證明私鑰是用雜湊（使用者隱藏的秘密，最近的PoH雜湊）創建的。
流動性矽橡膠
輕量級Simple Rent，又稱Less Stupid Rent。如何為分配新帳戶的預算進行製定，以確保過去的廢棄帳戶最終得到壓縮，並減少系統的整體負載和新用戶的價格？
需要恢復租金（Rent）制度。租金是指當前階段的帳戶應該支付X美元/位元組/天費用，就像AWS的帳戶支付儲存費用一樣。
租金率聯合曲線
租金率= K*(state_size)^N
目前狀態如何，如果很小，速率應該很低，如果接近影像限制，速率應該非常高。
分配最低保證價格
帳戶必須至少保存一個epoch。分配後帳戶將帶入Hot狀態。熱帳戶應該在保存期間保存。
新帳戶債券= Epoch Slots * RentRate * 帳戶::size
新帳戶餘額中必須至少有這麼多的燈泡才能創建。
熱門帳號燒錢
lruturnverrate = 每個帳戶在LRU快取中平均佔用的時間，最大值為1個epoch。這個值可以是一個常數，也可以在鏈下計算，並作為中位數權益加權常數報告給SVM。
壓縮
當（current slot – account::creation_slot) * RentRate * account::size > account::lampors時，壓縮帳戶並燒毀所有lampors。
解決方案，應該會讓國家便宜一些，因為儲存空間，未使用的帳戶最終會達到lports 0，將被壓縮。所以資料美元會減少，甚至索引美元也會減少，因此減少目前狀態的大小。減少狀態的大小將降低超二次分配成本。
相關閱讀：Solana最新研究：生態充滿韌性，成長與挑戰並存
資訊來源：0x資訊編譯自網際網路。版權歸作者Felix所有，未經許可，不得轉載