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 可以實現每秒數千至數萬筆交易的處理速度。