在 Solana 中,幾乎所有的鏈上狀態都是通過帳戶來表示的。與傳統的區塊鏈架構緊密結合程式碼和存儲不同,Solana 將可執行程式與狀態存儲分開。這種設計使得 Solana 的帳戶模型成為構建於此網絡上的開發者最重要的概念之一。
當使用錢包、SPL 代幣、NFT、PDA 或 DeFi 協議時,理解帳戶欄位是至關重要的。
Solana 帳戶的核心結構
Solana 帳戶通常在內部表示為:
pub struct Account {
pub lamports: u64,
pub data: Vec<u8>,
pub owner: Pubkey,
pub executable: bool,
pub rent_epoch: Epoch,
}
每個欄位在 Solana 運行時中擔任不同的角色。
Lamports
lamports
欄位儲存與該賬戶相關的 SOL 餘額。
pub lamports: u64
Lamports 是 SOL 的最小單位。
1 SOL = 1,000,000,000 lamports
這在概念上與以下內容相似:
- 以太坊中的 Wei
- 比特幣中的 Satoshi
Lamports 用於:
- 交易費用
- 租金免稅
- 持有 SOL 餘額
- 資助新賬戶
例如:
5 SOL = 5,000,000,000 lamports
在 Solana 上,每個帳戶必須保持一定的餘額,以保持在鏈上的活躍。
數據
data
欄位存儲任意的二進制數據。
pub data: Vec<u8>
這裡存放的是應用程序的狀態。
在 Solana 中,程序是無狀態的可執行文件,而數據帳戶則獨立地保存可變狀態。由於這種架構,幾乎每個去中心化應用程序都在很大程度上依賴帳戶數據佈局。
存儲的數據示例包括:
SPL 代幣帳戶
一個代幣帳戶通常存儲:
- 鑄造地址
- 擁有者地址
- 代幣數量
- 委託 information
- 帳戶狀態
NFT 元數據
NFT 元數據帳戶可能包含:
- 名稱
- 符號
- 元數據 URI
- 版稅配置
- 創作者地址
DeFi 協議
流動性池和 AMM 通常存儲:
- 池儲備
- 費用結構
- LP 供應量
- 管理設置
大多數 Solana 程式使用以下格式序列化帳戶數據:
- Borsh
- Anchor 序列化
- 原始字節佈局
擁有者
owner
欄位指定哪個程序控制該帳戶。
pub owner: Pubkey
這是其中之一
Solana 中最重要的安全機制之一。
只有擁有者程式被允許修改帳戶的數據欄位。
例如:
系統程式
11111111111111111111111111111111
系統程式擁有標準的 SOL 錢包帳戶。
SPL 代幣程式
SPL 代幣程式擁有:
- 代幣帳戶
- 鑄造帳戶
自訂程式
如果開發者為自訂協議創建 PDA 帳戶,擁有者欄位通常設定為專案的程式 ID。
這種擁有權模型在程式之間創造了嚴格的執行邊界,並防止未經授權的狀態修改。
可執行
executable
欄位決定該帳戶是否包含可執行的程式碼。
pub executable: bool
如果值為:
true
該帳戶將被視為程式帳戶。
程式帳戶存儲可以被 Solana 執行時執行的編譯後 BPF 位元組碼。
典型的例子包括:
帳戶類型可執行錢包帳戶:false 代幣帳戶:false PDA 帳戶:false 程式帳戶:true
在 Solana 上,大部分帳戶都是不可執行的數據帳戶。
租金週期
rent_epoch
欄位與 Solana 的租金系統有關。
pub rent_epoch: Epoch
因為鏈上儲存會消耗驗證者資源,Solana 最初引入了租金機制以防止儲存空間的無限增長。
餘額不足的帳戶最終可能會被網絡回收。
如今,大多數應用程序通過使帳戶免於支付租金來完全避免租金收取。
開發者通常會使用以下方法計算所需的最小餘額:
getMinimumBalanceForRentExemption(space)
一旦帳戶持有足夠的 lamports 滿足免租金的要求,則可以保持永久活躍。
帳戶地址和公鑰
在使用 RPC API 時,開發者通常會看到一個額外的
欄位:
{
"pubkey": "...",
"account": {
"lamports": 123,
"owner": "...",
"data": "...",
"executable": false,
"rentEpoch": 123
}
}
pubkey
是帳戶地址。
有趣的是,公鑰並不存儲在帳戶結構本身內部。相反,Solana 內部將地址映射到帳戶數據結構。
從概念上講,這類似於:
HashMap<Pubkey, Account>
為什麼 Solana 使用這種架構
帳戶模型是 Solana 實現極高吞吐量的原因之一。
在執行交易之前,Solana 要求交易必須…
宣告哪些帳戶將被讀取或寫入。
這讓運行時能夠確定:
- 哪些交易存在衝突
- 哪些交易可以並行執行
- 哪些狀態存取是隔離的
因此,Solana 可以同時處理許多獨立的交易,而不是順序執行所有內容。
這種並行執行模型與許多傳統區塊鏈根本不同。