Solana 帳戶模型：技術指南

此 Solana 帳戶模型技術指南解釋了程式所依賴的運行時欄位和存取規則，包括所有權、可執行帳戶、代幣帳戶、租金豁免、程式衍生位址、關聯代幣帳戶和跨程式調用。

諸如租金處理、帳戶大小限制和用戶端 API 等實作細節可能會有所變更。開發者在部署前，應先查閱最新的 Solana 文件並查詢目前的網路參數。

Solana 上的每個交易都會觸及一個帳戶。您持有的每一個代幣、您部署的每一個程式、您鑄造的每一個 NFT：所有這些都存放在帳戶中。在編寫任何一行 Solana 程式碼之前，理解帳戶的工作原理並非可選的背景知識，而是其他一切的先決條件。

將 Solana 想像成一個檔案櫃。每個抽屜都裝有一個資料夾，每個資料夾都有一個標籤（其地址）、內容（其資料）、一個餘額印記，以及封面上的部門名稱，表明哪個程式有權編輯其中的內容。無論您是從以太坊遷移的開發者、正在評估 Solana 架構的研究者，還是正在建立鏈上狀態管理第一個心智模型的學生，本指南都涵蓋了全貌：帳戶結構、帳戶類型、所有權規則、租金機制、程式衍生位址、與以太坊的並列比較，以及用於實際建置的註解程式碼。

Solana 帳戶模型：技術指南概述

Solana 帳戶模型是 Solana 區塊鏈的資料儲存和狀態管理架構。Solana 上的每塊狀態，包括代幣餘額、程式邏輯、使用者資料和系統配置，都儲存在由獨特 256 位元公鑰識別的離散帳戶中。請參閱 Solana 官方帳戶文件) 以取得規範。

Solana 上的每塊狀態都存在於一個帳戶中。程式不會儲存自己的資料；它們會在執行期間讀取和寫入傳遞給它們的帳戶。這項單一的架構決策將 Solana 的設計與大多數其他區塊鏈區分開來。

檔案櫃的類比直接對應到資料結構：檔案櫃是 Solana 區塊鏈，資料夾是帳戶，每個資料夾的標籤是其公鑰（鏈上地址），資料夾的內容是 data 欄位，餘額印記是 lamports 欄位，而封面上的部門印記是 owner 欄位，記錄哪個程式擁有寫入權限。只有該印記上標示的部門才能變更其內容。

如果您來自以太坊，這個區別很重要：以太坊的智慧合約內部儲存自己的狀態，而 Solana 的程式是無狀態的。完整的比較將在下面的專用章節中進行。

Solana 帳戶的結構

每個 Solana 帳戶，無論是儲存 SOL、程式碼還是應用程式狀態，都由相同的五個欄位建構而成。

每個 Solana 帳戶的五個欄位

Solana 上的每個帳戶都確切地包含五個欄位，每個欄位都有獨特的功能。在檢視程式碼之前，以簡單的術語理解這些欄位，將使技術細節更容易內化。

lamports：此帳戶的 SOL 餘額，以 Lamports (Solana 的最小單位，下一節將解釋) 表示。在檔案櫃的類比中，這是蓋在資料夾封面上的貨幣價值。

data：一個原始位元組陣列 (Vec<u8>)，用於儲存擁有程式所需的任何狀態。對於程式帳戶，此欄位包含已編譯的 BPF 位元組碼。對於資料帳戶，它包含序列化的應用程式狀態。程式會定義自己的序列化格式 (通常是 Borsh)，以讀取和寫入結構化資料到此欄位。檔案櫃的對應物是資料夾內的實體內容。

owner：授權修改此帳戶 data 欄位的程式的公鑰。沒有其他程式可以寫入它。這是資料夾封面的部門印記。

executable：一個布林旗標。當設定為 true 時，帳戶儲存程式碼並可執行。當設定為 false 時，帳戶是資料容器。

rent_epoch：一個舊欄位，過去用於追蹤租金收取時間。此欄位正在被棄用，對於免租金帳戶（這是生產標準）沒有營運上的意義。

每個 Solana 帳戶都由一個獨特的 256 位元公鑰識別，該公鑰源自一個金鑰對，作為其地址和鏈上識別符。根據最近的協定升級，單一帳戶的最大 data 欄位大小為 10 MB；請參閱 Solana 的帳戶文件,) 查詢目前限制，因為此值在 Solana 的歷史中曾有變動。

Lamports：Solana 的最小單位

Lamport 是 SOL 的最小單位：1 SOL 等於 1,000,000,000 Lamports (10⁹)。此單位以 Leslie Lamport 命名，他是一位電腦科學家，其在分散式系統和容錯方面的著作是現代分散式運算理論的基礎。Lamports 的存在是因為所有鏈上算術運算，包括租金計算、交易費用和帳戶餘額，都必須使用整數算術來避免浮點數精度錯誤。以 Lamports 表示數值可以使每個計算都精確。

Solana 帳戶與錢包是相同的嗎？

Solana 帳戶與錢包並不相同。您手機上的 Phantom 或 Solflare 應用程式，您認為是您的錢包，是管理私鑰的鏈下軟體。鏈上實體是一個儲存您的 SOL 餘額的系統帳戶。您的錢包控制一個系統帳戶；它本身並非一個帳戶。代幣帳戶、程式帳戶和資料帳戶沒有錢包對應物：它們純粹是鏈上資料容器，沒有消費者錢包應用程式直接代表。

Solana 帳戶分為四種類型，每種類型由其擁有程式和 executable 旗標定義。

1. 系統帳戶：由系統程式擁有；用於 SOL 儲存和使用者錢包
2. 程式帳戶：儲存已編譯 BPF 位元組碼的可執行帳戶
3. 資料/狀態帳戶：由程式擁有；儲存應用程式特定狀態
4. 代幣帳戶：由 SPL 代幣程式擁有的特殊資料帳戶（其中關聯代幣帳戶是規範子集）

系統帳戶由系統程式擁有，使用者錢包也是系統帳戶。系統程式是 Solana 的原生程式，負責三項核心操作：建立新帳戶（分配鏈上資料空間）、指定帳戶所有權（將 owner 欄位設定為指定的程式）以及在帳戶之間轉移 SOL。Solana 上的每個新帳戶都從一個由系統程式擁有的系統帳戶開始。

系統程式有一個眾所周知的位置：11111111111111111111111111111111 (base58 中的 32 個 1)。請參閱 系統程式文件) 以了解其完整的指令集。當開發者為其程式建立資料帳戶時，他們會呼叫系統程式的建立帳戶指令，指定資料大小、免租金的 Lamport 儲值金額以及新擁有程式的公鑰。

程式帳戶儲存已編譯的 BPF 位元組碼，而非狀態。這些帳戶的 executable 標記設為 true。程式是無狀態的：當程式運行時，它透過交易指令接收要讀取或寫入的帳戶列表。它在呼叫之間不維持任何內部狀態。如果您來自 Ethereum，您可能知道鏈上可執行代碼為智慧合約，但 Solana 程式的工作方式根本上不同，因為它們不帶有自己的狀態。程式帳戶由 BPF Loader 程式擁有。一旦部署，程式帳戶即為不可變，除非在部署期間指定了升級權限金鑰對。

數據與狀態帳戶

數據帳戶持有程式在執行期間讀寫的應用程式狀態。這些帳戶的 executable 標記為 false。數據欄位儲存以 Borsh 序列化的程式定義狀態。範例包括使用者在 DeFi 協議中的借貸倉位、NFT 元數據或應用程式計數器。擁有者程式是唯一可以寫入此帳戶數據欄位的實體，這是一項在擁有權章節中詳細說明的規則。

代幣帳戶與關聯代幣帳戶

代幣帳戶是由 SPL Token 程式擁有的數據帳戶，每個帳戶為特定錢包持有特定代幣的餘額。單個錢包地址可以持有複數個代幣帳戶，每個帳戶對應其持有的代幣類型。

關聯代幣帳戶 (ATA) 是針對特定 [錢包地址, Mint 地址] 配對的規範代幣帳戶。ATA 是使用錢包地址和代幣 Mint 地址作為種子 (seeds)，以確定性方式衍生出的程式衍生地址 (PDA)。這確保了每個錢包在每種代幣類型中都有且僅有一個「官方」帳戶。ATA 是 Phantom 和 Solflare 等錢包、交易所及協議所使用的標準：當您在錢包介面中收到代幣時，它會進入該代幣對應的 ATA。

如果給定的 [錢包, Mint] 配對不存在 ATA，則必須在接收代幣前建立，且建立過程需要一筆免租金的 Lamport 儲值。這就是為什麼某些交易在錢包介面中會包含一小筆「帳戶建立費」。有關完整的 ATA 規範，請參閱 SPL 關聯代幣帳戶文件.。ATA 是一種代幣帳戶，但並非所有代幣帳戶都是 ATA，這種區別在調試代幣相關程式時非常重要。

帳戶擁有權：Solana 如何控制數據存取

Solana 中的帳戶擁有權是一種寫入權限機制，而非資產所有權概念。

擁有權規則

只有帳戶的擁有者程式可以修改其數據欄位。無論使用者在交易層級如何授權，其他程式都無法寫入。AccountInfo 中的 owner 欄位儲存持有此權限之程式的公鑰。非擁有者程式可以自由讀取數據欄位，但寫入則需要是指定的擁有者。

系統程式 (System Program) 在帳戶建立期間分配擁有權。當開發者為其程式建立數據帳戶時，Create Account 指令會將 owner 欄位設定為其程式的公鑰。擁有權可以重新分配，但僅限目前的擁有者程式使用 Assign 指令進行。任何外部第三方都無法單方面轉移擁有權。

擁有者 (Owner) vs. 權限者 (Authority)：關鍵區別

在 Solana 帳戶管理中，擁有者和權限者是兩個不同的概念。擁有者是記錄在帳戶 owner 欄位中的程式，意即可以寫入數據欄位的程式。權限者（或簽署者）是能為該帳戶簽署交易的金鑰對。

以代幣帳戶為例：您的錢包私鑰簽署交易（您是權限者），但 SPL Token 程式是您代幣帳戶的擁有者，且是唯一可以在數據欄位中修改您代幣餘額的實體。您可以授權一項移動代幣的交易，但實際對數據欄位的寫入是由 Token 程式執行的，而非由您直接執行。混淆這兩個概念是新手開發者在 Solana 上最常遇到的帳戶擁有權調試錯誤。

擁有權實作：DEX 範例

DEX 程式只能寫入其直接擁有的帳戶。若要從使用者的代幣帳戶（由 SPL Token 程式擁有，而非 DEX）轉移代幣，DEX 無法直接寫入該帳戶。程式可以在同一個交易中呼叫其他程式，這種模式稱為跨程式調用 (CPI)，允許 DEX 指示 Token 程式代表使用者移動代幣。DEX 向 Token 程式發送 CPI，提供使用者的簽署授權，隨後 Token 程式對使用者的代幣帳戶數據欄位執行寫入。這就是程式擁有權模型如何延伸到程式間互動的方式。如需完整演練，請參閱 Solana 開發者跨程式調用 (CPI) 指南。

帳戶租金與免租金

Solana 租金是一種存儲成本機制，而非週期性費用。

什麼是租金？

租金是 Solana 對鏈上存儲進行定價的機制。每個帳戶必須維持與其數據大小成比例的最低 SOL 餘額，以在鏈上保持活躍。大多數競爭對手內容漏掉的修正點是：租金在實務上並非週期性費用。生產標準是「免租金」，即預先儲值足夠支付約兩年存儲量的 SOL，使帳戶永久免於任何租金扣除。絕大多數已部署的帳戶都在免租金模式下運作。

免租金：實務標準

免租金是所有已部署 Solana 帳戶的生產標準。免租金的最低餘額約為 6,960 Lamports 乘以帳戶的數據位元組大小，外加零位元組帳戶約 890,880 Lamports 的基礎金額。

計算範例：一個 100 位元組的數據帳戶需要約 890,880 + (6,960 × 100) = 1,586,880 Lamports，或約 0.00159 SOL。這些數字為近似值且可能變動。請使用 Solana CLI 命令 solana rent <bytes> 或 Solana 租金文件. 驗證目前數值。截至本文撰寫時，將租金轉換為交易手續費模型的提議尚未啟用；請查閱最新文件以了解當前協議狀態。

帳戶的 SOL 用完會怎樣？

目前的帳戶建立通常要求免租金資金。開發者應查詢目前的 RPC 要求，而非依賴舊有的租金收取行為。正是這種行為引發了對帳戶被「刪除」的擔憂。

免租金帳戶絕不會被運行環境自動關閉。生產帳戶總是注資至免租金門檻，因此垃圾回收不會影響它們。刻意關閉帳戶是一個獨立、深思熟慮的模式：程式可以關閉數據帳戶以回收 Lamport 儲值。例如在 DeFi 協議中，關閉借貸倉位會將資助該倉位數據帳戶的 SOL 退還給使用者。這是一種常見的協議設計模式，而非非自願刪除。

程式衍生地址 (PDA) 詳解

程式衍生地址解決了一個特定問題：程式如何在沒有人持有對應私鑰的情況下控制帳戶。

什麼是程式衍生地址？

程式衍生地址 (PDA) 是使用 SHA-256 哈希，從程式 ID 和一個或多個種子值 (seed) 確定的生成帳戶地址。PDA 被刻意放置在 ed25519 橢圓曲線之外，這意味著它們沒有對應的私鑰。只有擁有者程式可以為 PDA 地址的帳戶簽署交易。請參閱 Solana 的 PDA 文件 了解完整規範。

所有一般 Solana 帳戶地址皆位於 ed25519 橢圓曲線上。PDA 則刻意被放置在該曲線之外。這種「離線曲線 (off-curve)」特性並非漏洞，而是一種設計機制，使私鑰在數學上變得不可能存在。沒有任何人類、硬體錢包或金鑰管理系統能為 PDA 產生私鑰，因為曲線上根本不存在這樣的金鑰。

為什麼 PDA 很重要：程式控制的託管

由於沒有私鑰，結果就是只有擁有該帳戶的程式才能授權 PDA 的交易。這實現了無需信任的程式控制託管：程式對帳戶擁有權限，而無需依賴任何人來保護私鑰。

將此與一般金鑰對帳戶進行比較，後者是誰持有私鑰誰就控制帳戶。如果金鑰遺失，存取權就消失了；如果金鑰被盜，帳戶就會被入侵。PDA 完全消除了這種依賴。程式的邏輯就是託管人，是可審計的程式碼而非個人。

三個真實世界的 PDA 使用案例

PDA 在 Solana 程式中以三種重複模式出現。

DEX 託管帳戶：去中心化交易所程式在 PDA 中持有代幣，直到交換的雙方都滿足所需條件。沒有受信任的中間人持有託管帳戶的私鑰。程式的邏輯控制釋放，且沒有參與者可以在協定規則之外抽走資金。

沒有任何個人可以針對 NFT 系列的鑄造權限進行「跑路」。NFT 鑄造權限的工作原理是讓 Metaplex 程式透過從鑄造地址衍生出的 PDA 來控制鑄造。由於此 PDA 不存在私鑰，系列作的鑄造規則在部署後僅由程式碼強制執行。

程式如何在不維護中心化索引的情況下儲存每個使用者的資料？每位使用者狀態儲存使用由 [program_id, user_pubkey] 衍生出的唯一 PDA。這會產生一個確定的、特定於使用者的帳戶地址，用於儲存該使用者的遊戲分數、借貸倉位或質押紀錄。程式始終知道在哪裡可以找到每位使用者的資料。

函式 findProgramAddress() 和 createProgramAddressSync() 透過使用遞增的 bump seed 測試候選地址，直到其中一個落在曲線之外，藉此定位有效的離線曲線地址。

您何時應該使用 PDA？

每當您的程式需要控制帳戶而又不依賴人類私鑰時，請使用 PDA。如果帳戶權限應該是程式邏輯而非個人，請使用 PDA。此規則涵蓋了託管帳戶、協定金庫、鑄造權限，以及程式本身必須擁有並管理跨多個使用者的任何狀態。

Solana 對比以太坊：帳戶模型如何比較

Solana 與以太坊帳戶模型的核心差異在於狀態存放的位置。

在以太坊中，智慧合約是有狀態的：它們在內部將自身狀態與程式碼一起儲存。Solidity 合約在以太坊虛擬機 (EVM) 管理的合約儲存空間內保留自己的映射和狀態變數。在 Solana 中，程式是無狀態的；所有狀態都存在於外部帳戶中，程式在執行期間會讀取和寫入這些帳戶。以太坊在 EVM 中執行程式，而 Solana 使用基於 BPF 的運行環境，針對交易中預先宣告的帳戶執行程式。

權衡是雙向的。以太坊的有狀態模型具有真正的開發者體驗優勢：更簡單的思維模型、無須顯式帳戶管理，對許多使用案例來說認知負荷較低。開發者可以編寫並部署 ERC-20 合約，而無需考慮資料帳戶大小、租金豁免儲值或 PDA 衍生。

Solana 的無狀態模型以這種簡單性換取了執行的並行性和關注點分離。每個交易要求的帳戶宣告是 Sealevel 排程演算法的輸入，該演算法會同時執行非衝突的交易。其他 Layer-1 區塊鏈（如 Aptos 和 Sui）採用了各自的資源型狀態分離變體，各有不同的權衡特性。以太坊的方法和 Solana 的方法都沒有絕對的優劣；它們反映了針對不同工作負載的不同設計優先順序。

為什麼這種架構很重要：Sealevel 與並行執行

無狀態程式並非設計限制，而是實現並行執行的機制。

從帳戶模型設計到效能的因果鏈如下：首先，Solana 程式是無狀態的。第二，因為程式不帶狀態，每個交易在執行開始前必須宣告它將存取的所有帳戶（包括讀取和寫入）。第三，Solana 的並行執行引擎 Sealevel 在排程前會分析這些帳戶存取清單。第四，存取非重疊帳戶集合的交易彼此之間沒有資料依賴關係，可以在多個處理器核心上同時執行。第五，結果就是網路能夠每秒處理數萬個交易。

Anatoly Yakovenko 在設計 Solana 架構時將並行交易處理作為明確目標，而將程式邏輯與帳戶狀態分離正是實現這一目標的關鍵。帳戶模型與 Solana 的其他架構創新協同工作，包括歷史證明 (PoH)——Solana 的加密時鐘機制。若要了解 PoH 如何對此吞吐量做出貢獻，請參閱 Solana 架構說明中的歷史證明工作原理。

使用帳戶進行開發：開發者實作

Solana 程式使用的每個帳戶在程式對其進行讀取或寫入之前，都必須先建立、注資並分配給所有者。

使用系統程式建立帳戶

Solana 程式使用 Rust（一種系統程式語言）編寫，並在部署前編譯為 BPF 位元組碼。在 Solana 上建立帳戶遵循以下步驟，每個步驟對應系統程式建立帳戶指令中的一個參數：

1. from_pubkey：識別資助建立帳戶的帳戶（付款人）
2. new_account_pubkey：指定新帳戶的地址
3. lamports：根據資料大小計算租金豁免餘額金額
4. space：設定為帳戶分配的資料大小（以位元組為單位）
5. owner：指定將擁有並寫入此帳戶的程式公鑰

// 使用系統程式建立新的資料帳戶
let create_account_ix = system_instruction::create_account(
    &payer.pubkey(),         // from_pubkey: 誰資助這個帳戶
    &new_account.pubkey(),   // new_account_pubkey: 帳戶地址
    rent_exempt_balance,     // lamports: 足以豁免租金的金額
    data_size as u64,        // space: 為帳戶資料分配的位元組
    &program_id,             // owner: 控制此帳戶的程式
);

此指令建立了帳戶所有權。執行後，只有位於 program_id 的程式才能寫入此帳戶的資料欄位。

使用 Anchor 框架

許多 Solana 程式是使用 Anchor 框架建構的，該框架提供了用於定義帳戶限制和程式指令的結構化巨集。請參閱 Anchor 文件) 以獲取完整的框架參考。

// Anchor：使用 #[derive(Accounts)] 巨集定義帳戶限制
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,                        // 如果此帳戶不存在，則建立它
        payer = user,                // 使用者支付免租金儲值
        space = 8 + MyData::LEN,    // 8 位元組識別碼 + 資料大小
    )]
    pub my_account: Account<'info, MyData>,     // 新的資料帳戶
    #[account(mut)]
    pub user: Signer<'info>,                    // 交易簽署者和付款人
    pub system_program: Program<'info, System>, // 帳戶建立所需
}

Anchor 會自動處理帳戶驗證的樣板程式碼，在您的指令邏輯執行前驗證所有權和簽署者狀態。當除錯所有權錯誤或設計 PDA 結構時，了解底層帳戶模型仍然是必要的，因為 Anchor 的巨集是對本文所述相同機制的抽象。

相關 Solana 架構資源

尋求更短實作路徑的開發者可以使用 專注於開發者的帳戶模型指南；Solana Program Library 總覽涵蓋了代幣程式的慣例。SOL 價格頁面 (https://www.bybit.com/en/price/solana/)) 和 SOL/USDT 現貨市場 (https://www.bybit.com/en/trade/spot/SOL/USDT)) 涉及市場存取，與帳戶所有權或程式權限無關。

常見問題：Solana 帳戶模型：技術指南

什麼是 Solana 中的帳戶？

Solana 帳戶是一個由唯一 256 位元公鑰識別的鏈上資料容器。每個帳戶儲存 Lamports 的 SOL 餘額、一個資料欄位（包含程式狀態或位元組碼的位元組陣列）、一個擁有者欄位（授權修改資料的程式的公鑰），以及一個指示帳戶是否儲存程式碼的可執行旗標。

在 Ethereum 中，智能合約會在其程式碼旁邊內部儲存其自身狀態。在 Solana 中，程式是無狀態的；所有狀態都存在於程式在執行期間讀寫的外部帳戶中。這種分離使得 Solana 的 Sealevel 運行時能夠偵測非重疊的帳戶存取模式並同時執行多個交易，從而實現大規模平行處理。

所有生產環境的 Solana 帳戶都會被充值到免租金門檻，使其永久免於儲存費用。租金是底層機制：帳戶必須維持與其資料大小成比例的最低 SOL 餘額，才能保持在鏈上活躍。免租金帳戶（充值超過門檻的帳戶）永遠不會被運行時自動關閉。

程式衍生位址 (PDA) 是使用 SHA-256 雜湊從程式 ID 和種子值（seed values）確定性生成的帳戶位址。PDA 脫離 ed25519 橢圓曲線，因此沒有對應的私鑰。只有擁有者程式才能簽署 PDA 位址的帳戶交易，從而實現信任最小化的程式控制託管，用於託管帳戶、鑄造權限和每個使用者的狀態儲存。

目前的帳戶建立通常需要免租金充值。開發者應查詢目前的 RPC 要求，而不是依賴舊的租金收取行為。正確部署的生產環境帳戶始終充值到免租金門檻，且永遠不會被自動刪除。程式也可以故意關閉帳戶以收回 SOL 儲值，這是 DeFi 協定中的常見模式。

Lamports 是 Solana 區塊鏈上 SOL 的最小面額：1 SOL 等於 1,000,000,000 Lamports (10⁹)。Lamports 以分散式計算先驅 Leslie Lamport 的名字命名，用於鏈上的所有 SOL 餘額、交易費用和租金計算。以 Lamports 為單位表示金額，可以避免在鏈上算術中使用部分 SOL 值時可能出現的浮點數精度錯誤。

System Program 是 Solana 的原生程式，負責三個核心操作：建立新帳戶（分配鏈上資料空間）、指定帳戶擁有權（將擁有者欄位設定為指定的程式）以及在系統帳戶之間轉移 SOL。每個新的 Solana 帳戶都從系統帳戶開始。開發者呼叫 System Program 的 Create Account 指令來為其程式配置資料帳戶。

Solana 帳戶主要有三種類型：(1) 系統帳戶，由 System Program 擁有，用於 SOL 餘額和使用者錢包；(2) 程式帳戶，是儲存已編譯 BPF 位元組碼的可執行帳戶；(3) 資料/狀態帳戶，由程式擁有，儲存應用程式特定的狀態。代幣帳戶是 SPL Token Program 所擁有的資料帳戶的特殊子集。

Solana 的帳戶模型比 Ethereum 的有狀態模型需要更多的預先思考，但這種認知投入正是實現平行執行的原因。

• Solana 上的每一份狀態都存在於一個帳戶中；程式在執行期間讀寫傳入的帳戶，而非內部儲存
• 每個帳戶有五個欄位：lamports、data、owner、executable 和舊的 rent_epoch
• 只有擁有者程式可以修改帳戶的資料欄位；這是 Solana 的主要存取控制機制
• 生產環境帳戶會充值到免租金門檻，且永遠不會被運行時自動垃圾回收
• 程式衍生位址透過使用沒有私鑰的曲線外位址，實現信任最小化的程式控制託管
• Solana 的 Sealevel 運行時透過分析跨非衝突交易聲明的帳戶存取列表來平行化交易執行

準備好在此基礎上進行建構了嗎？繼續閱讀：

• Solana 程式如何運作：無狀態執行的開發者指南
• Anchor 框架指南，用於建構 Solana 程式
• 解釋 Cross-Program Invocation (CPI)：Solana 程式如何互相呼叫
• 歷史證明 (Proof of History) 在 Solana 架構中的作用

如需最新的帳戶大小、租金計算和運行時行為的協議規格，請直接查閱 Solana 官方帳戶文件。