solana雜談（1）

本文適用于“只需大致了解 Solana”的讀者，部分說法可能不夠準確或不夠深入。如需詳細了解，建議閱讀 Solana 的官方文檔：https://solana.com/zh/docs

solana賬戶模型

solana 上所有數據都是儲存在賬戶中，也就是說你可以通過賬戶信息拿到鏈上的任意狀態（將區塊鏈理解為一個大型狀態機）.
solana 賬戶結構如下：

• 錢包賬戶（Wallet Account）：data 字段為空。這類賬戶由橢圓曲線生成的公私鑰對管理，擁有私鑰的用戶可以通過簽署并發送交易來修改鏈上狀態。
• 程序賬戶（Program Account）：data 字段包含 Solana 程序的指令集及其 WASM 二進制代碼。
• 數據賬戶（Data Account）：data 字段包含所有編碼后的數據。

在 Solana 中，程序賬戶和數據賬戶的地址通常是通過特殊方式生成的，并非由橢圓曲線公私鑰對直接控制，因此無法直接通過私鑰生成簽名。它們的狀態修改通常通過程序派生地址（Program Derived Address, PDA）代理簽名，在狀態機內部進行。

賬戶租金

賬戶租金是solana避免數據臃余的處理方案（evm是通過釋放空間，返回eth的方式），對于solana上所有的用戶都需要支付租金（或者余額大于一定值免租）.

• 錢包賬戶：租金由賬戶所有者自己支付。
• 程序賬戶：租金通常由程序的創建者一次性支付，以確保程序的可持續運行。

租金豁免：如果賬戶中存儲的 SOL 數量足以支付該賬戶兩年期的租金，則該賬戶可以獲得租金豁免，無需再支付租金。這意味著賬戶將永久存在，除非被關閉。

• 數據賬戶（Data Account）：通常是程序用于保存數據的賬戶，其租金由創建該數據賬戶的交易發起者支付。

數據賬戶管理：對于核心項目數據，通常在程序部署時進行統一初始化，以防止意外刪除。對于用戶自行管理的數據賬戶（如鏈上的 Token 賬戶），則由用戶自己創建并管理租金。

rent_epoch：這是一個遺留字段，源于 Solana 曾經有一個機制會定期從賬戶中扣除 lamports。雖然此字段仍然存在于賬戶類型中，但自從租金收取被棄用后，它已不再使用。?? 租金已經被棄用了

solana的token標準

solana上的token不像evm有多種token執行標準（erc20/erc721/erc1155）,也不會每個token都上去部署一個合約。

solana上的token由token program統一管理（token progeam有兩個版本，這里不做展開），接下來我們從token的生命周期來看一下solana的脫可能標準

1. 項目方創建token
   項目方創建token實際上是向token program發送一個mintinit指令，在token program中登記一個token 以及記錄怎么發行token
   不同于evm，不是一個合約，由合約管理token

2. mint token
   在token初始化時制定了mint權限，擁有mint權限的賬戶合約mint token，注意每一個token有他獨立的mint account.mint account的權限

3. 創建token account
   錢包用戶通過token program，創建對應token 的token account(實際上也是一個數據賬戶)，用于保存錢包用戶的token的狀態

4. token transfer
   token transfer指令由錢包用戶發起，由token program執行，修改發送方/接收方的token account 里面的余額狀態，實現token的轉賬

另外還有銷毀和授權，這里不做展開

在solana上發行token不需要額外的部署代碼

對于nft類的token,solana并不嚴格區分token類型，nft和ft共享相同的指令集（指令里面也沒有區分這兩者）

solana上的nft

solana nft轉賬之類的操作在token program上實現，生命周期通常由類似 Metaplex這類token標準管理（這些token是社區推動的標準，不同于token program預編譯在solana主鏈上）

Metaplex這類標準通過控制token program mint不同的token來實現nft,也就是對于每一個nft的生成，實際上是在token program上執行 mintinit操作（！！！ 不是mint操作），每一個nft的mint相當于是發行一個token，Metaplex程序控制發行量，從而實現nft

solana合約標準

solana使用的BPF vm執行合約

合約生命周期有BPF loader系列系統合約管理.通常情況下需要將合約編碼成wasm的二進制碼然后部署在solana鏈上

對于合約開發，合約需要與solana鏈交互，所以并不是所有語言都可以開發solana合約，需要對應語言實現solana program sdk 并且可以編譯成wasm的二進制碼
目前來看只有（rust/c/c++）其他語言有一些社區實現的sdk,可能存在問題

solana的共識

Solana 采用的是一種混合共識機制，結合了以下幾個關鍵技術：

• Proof of History (PoH) — 歷史證明

這是 Solana 最核心的創新點。

PoH 通過一個加密哈希函數（SHA-256）以連續的方式產生可驗證的時間順序證明，相當于給所有交易和事件打上了時間戳。

這個機制讓網絡無需等待區塊時間戳驗證，極大地提高了交易處理速度和吞吐量。

• Tower BFT — 基于 PoH 的拜占庭容錯共識

Tower BFT 是 Solana 的一種優化的 Practical Byzantine Fault Tolerance (PBFT) 機制。

利用 PoH 生成的全局時間順序，節點可以在這個時間線上鎖定狀態，從而更高效地達成共識。

節點通過投票和鎖定投票權重防止雙重花費和惡意行為。

• Turbine — 高效的數據傳播協議

用于快速分發數據包，減少網絡擁堵，提高廣播效率。

• Gulf Stream — 交易轉發協議

允許交易在網絡中提前轉發給驗證者，減少確認時間。

• Sealevel — 并行智能合約運行時

允許同時處理多個交易，提高吞吐量。

Solana 共識流程簡要

1. 交易發起后，節點利用 PoH 來驗證交易的時間順序。

2. 驗證者節點基于 Tower BFT 達成共識，投票決定哪個區塊被接受。

3. 通過這種方式，Solana 可以實現每秒數千至數萬筆交易的處理速度。