Solanaアカウントモデルの解説

Solanaアカウントモデルは、残高、プログラムコード、トークン保有状況、およびアプリケーションの状態を、明示的な所有権ルールを持つ個別のストレージユニット（アカウント）に保存します。このわかりやすいガイドでは、フィールド、アカウントタイプ、レント免除、および実例に進む前に、一般的な読者向けにこのモデルを解説します。

レントの取り扱い、アカウントサイズの制限、クライアントAPIなどの実装詳細は変更される可能性があります。開発者はデプロイ前に最新のSolanaドキュメントを確認し、現在のネットワークパラメータを照会する必要があります。

Ethereumの経験がある方にとって、Solanaのアカウントモデルは最初は逆転しているように感じるでしょう。その反応は正しい出発点です。Ethereumで構築したメンタルモデルはそのままでは通用せず、無理に当てはめようとするとあらゆる段階で混乱を招きます。

Solanaアカウントモデルは、すべてのオンチェーン状態を「アカウント」と呼ばれる個別のストレージユニットに保存するアーキテクチャシステムです。すべてのウォレット残高、プログラム、トークン保有状況、およびアプリケーションの状態記録は、定義された所有者、lamport残高、および誰が読み書きできるかを規定する明示的なルールを持つ個別の勘定に存在します。Solanaにおいて、アカウントの外には何も存在しません。

Solanaをグローバルなファイリングシステムだと考えてください。すべてのデータは「アカウント」と呼ばれる個別のファイルに収められています。プログラムはそれらのファイルを読み書きするアプリケーションですが、プログラムは自分が所有するファイルしか変更できません。ランタイムは、プロトコルレベルでそれらの所有権ルールを例外なく強制します。

この記事では、すべてのSolanaアカウント内にある5つのフィールド、5つの異なるアカウントタイプ、レント（賃借料）とレント免除の仕組み、プログラム派生アドレス（PDA）とは何かとその存在理由、アカウントの作成と閉鎖方法、そしてこのアーキテクチャがなぜSolanaの並列トランザクション処理を可能にしているのかについて解説します。SolanaプログラムはRust（またはC/C++）で書かれますが、Anchorのようなフレームワークがアカウント管理のボイラープレートの多くを抽象化してくれます。この記事では、その両方に必要な概念的基盤をカバーします。

Solanaアカウントモデル：アカウントの構造

Solanaアカウントは、ネットワーク上のラベル付きストレージスロットであり、lamports単位の残高、任意のデータペイロード、および誰がそれを所有し、何ができるかを定義する一連のメタデータフィールドを保持しています。Solanaでは、ウォレットの残高からプログラムの状態、トークンの保有状況に至るまで、すべてのデータがアカウントに保存されます。

Lamportsは、ネットワークのネイティブトークンであるSOLの最小単位です。ドルに対するセントのようなものですが、精度は小数点以下9桁です（1 SOL = 1,000,000,000 lamports）。すべてのアカウントは、ネットワーク上でのアカウントの存続を維持し、転送可能な価値を表すlamportの残高を保持しています。

すべてのSolanaアカウントには、正確に5つのフィールドが含まれています。

• lamports (u64): lamports単位のアカウント残高。このフィールドはレントの支払いに使用され、他のアカウントに転送することもできます。
• data (byte array): 生のバイナリストレージ。実行可能アカウントでは、このフィールドにコンパイル済みのBPF/SBFバイトコードが保持されます。データアカウントでは、構造化されたアプリケーションの状態が保持されます。現在のメインネットのパラメータでは、データフィールドの最大サイズは10 MBです。
• owner (Pubkey): このアカウントのデータフィールドに対して独占的な書き込み権限を持つプログラムの32バイトのパブリックキー。これはEthereumの開発者にとって最も直感に反するフィールドです。あなたのウォレットアドレスは、プロトコルレベルではあなたによって所有されているのではなく、System Program（システムプログラム）によって所有されています。所有者フィールドの詳細については、アカウントの所有権と権限セクションで説明します。
• executable (bool): ブーリアンフラグ。trueの場合、データフィールドにはプログラムのバイトコードが含まれ、アカウントはプログラムとして機能します。falseの場合、アカウントは状態を保存するか、残高を保持します。
• rent_epoch (u64): 最後にレントが徴収されたエポックを追跡するレガシーフィールド。2024年現在、レント徴収は廃止され、「デフォルトでのレント免除」モデルが採用されています。このフィールドはアカウント構造体に残っていますが、現在は使用されていません。

データ構造としてのウォレットアカウントの見た目は次のとおりです。

{
  "lamports": 1000000000,
  "data": [],
  "owner": "11111111111111111111111111111111",
  "executable": false,
  "rent_epoch": 0
}

owner（所有者）フィールドはプロトコルレベルの概念であり、データフィールドへの書き込みアクセスを制御するプログラムを指します。Authority（権限）は、トークンアカウント内の転送権限フィールドのように、プログラムが管理するデータ内に保存される別の慣習です。これらは同じものではありません。所有権セクションでこの区別を正確に行います。

5種類のSolanaアカウント

Solanaには5つの異なるアカウントタイプがあり、それぞれがownerフィールドとexecutableフラグによって決定される特定のアーキテクチャ上の役割を担っています。タイプは別のフィールドとして保存されるのではなく、誰がアカウントを所有しているか、および実行可能コードが含まれているかによって推論されます。

システム所有アカウント（ウォレットアカウント）

システム所有アカウントは、ユーザーのSOL残高のみを保持します。所有者は常にSystem Program（11111111111111111111111111111111）であり、executableフラグはfalse、データフィールドは空です。PhantomやSolflareでウォレットアドレスを共有する場合、システム所有アカウントのアドレスを共有していることになります。プライベートキーでトランザクションに署名することでアカウントを制御しますが、プロトコルレベルの所有者はSystem Programです。

プログラムアカウント（実行可能アカウント）

プログラムアカウントは、コンパイル済みのBPF/SBFバイトコードを含む実行可能アカウントです。executableフラグはtrueで、所有者はBPF Loaderです。プログラムアカウントは設計上ステートレス（無状態）であり、コードのみを保持し、状態は保持しません。Ethereumでは、スマートコントラクトは1つのコントラクトアドレスにコードと状態の両方を保存します。Solanaでは、コードはプログラムアカウントに置かれ、状態は個別のデータアカウントに置かれ、常に切り離されて保存されます。

プログラムアカウントは実行可能コードを保存でき、executable = true でデータフィールドにBPF/SBFバイトコードが入ります。非実行可能なデータアカウントは executable = false であり、代わりに状態を保存します。

データアカウント（プログラム所有アカウント）

データアカウントは、特定のプログラムによって所有される非実行可能アカウントであり、そのデータフィールドにプログラムの状態を保存します。executableフラグはfalseです。所有者は、そのアカウントを作成し管理しているプログラムです。あなたのUSDCトークン残高、DeFiのレンディングポジション、NFTのメタデータレコード：これらはそれぞれ、関連するプログラムによって所有される専用のデータアカウントに存在します。

ネイティブプログラムアカウント

ネイティブプログラムアカウントは、ネットワークのジェネシス（創設）時に固定アドレスにデプロイされた組み込みプログラムです。これには、System Program、BPF Loader、Vote Program、Stake Programが含まれます。これらはコアインフラプログラムであり、ユーザーが置き換えたりアップグレードしたりすることはできません。これらのexecutableフラグはtrueです。

Sysvarアカウント

Sysvarアカウントは、Solanaランタイムによってあらかじめデータが入れられた読み取り専用のアカウントで、プログラムが現在のネットワーク状態にアクセスできるようにします。Sysvarアカウントは、裁判所にある政府の掲示板のようなものだと考えてください。誰でも読むことができ、権限のある情報源によって維持されていますが、民間人が修正することはできません。SysvarC1ock11111111111111111111111111111111にあるClock sysvarは、現在のブロックのタイムスタンプとスロット番号を提供します。Rent sysvarは現在のレントパラメータを提供します。

Solanaのプログラムはステートレスです。すべての状態（ステート）は、プログラムが所有および制御するデータアカウント内に存在します。このロジックと状態の分離こそが、この記事の他のすべての内容を可能にする設計上の決定です。

プログラム vs データアカウント：ロジックと状態の分離

Solanaプログラムはステートレスです。プログラム自体はデータを保持せず、操作するすべての状態は、実行時にプログラムに渡される個別のデータアカウントに存在します。

Solanaプログラムを銀行の取引処理ソフトウェア、データアカウントを個々の顧客の口座記録と考えてください。ソフトウェアは入金や出金の処理方法を知っていますが、実際の残高はソフトウェアの内部ではなく、顧客のファイルの中にあります。Ethereumでは、ソフトウェアとすべての顧客の記録が同じ鍵のかかった部屋を共有している銀行のようなもので、プログラムとその状態は単一のアドレスで切り離せません。

Solanaプログラムがアカウントとどのように相互作用するかを定義する4つの特性があります。

• プログラムは命令を処理し、呼び出し時に渡されたアカウントの読み取りまたは書き込みを行います。プログラム自身は状態を保持しません。
• プログラムは一度デプロイされると、デプロイ時に開発者がアップグレーダブルローダーを選択していない限り、不変（イミュータブル）です。
• データアカウントを所有するプログラムのみが、そのアカウントのデータフィールドを変更できます。誰でもプログラムを呼び出すことができますが、アカウントへの書き込みアクセスは所有権によって制限されています。
• executable（実行可能）フラグは、プロトコルレベルでこの区別を強制し、デプロイ後に変更することはできません。

Solanaプログラムはステートレスですが、Solanaシステム全体としてはステートフルです。状態は永続的であり、データアカウントの中に存在します。その違いは、状態は常にプログラムの外部にあり、プログラムの内部にバンドルされることは決してないという点です。

この分離はパフォーマンスに影響を与えます。すべてのトランザクションは実行開始前にどのアカウントを読み書きするかを宣言する必要があるため、Sealevelランタイムは重複しないトランザクションを特定し、それらを同時に実行できます。アカウントモデルがいかに並列実行を可能にするかについての詳細な説明は後述します。

アカウントの所有権と権限：Solanaで誰が何を制御するか

Solanaアカウントのowner（所有者）フィールドは、そのアカウントのデータを変更する独占的な許可を持つプログラムを特定します。プロトコルレベルでデータフィールドに書き込みができるのは、そのプログラムだけです。

ownerフィールドには32バイトのプログラムのパブリックキーが保存されます。ウォレットアカウントの場合、所有者はSystem Programです。トークンアカウントの場合、所有者はSPL Token Programです。カスタムデータアカウントの場合、所有者はそれを作成したプログラムです。所有権はアカウント作成時に設定され、すべてのトランザクションでSolanaランタイムによって強制されます。

銀行の貸金庫を想像してください。銀行がその箱を所有しており、物理的に中身を開けて変更できる唯一の主体です。あなたはその箱をどうするか銀行に指示するための鍵を持っていますが、中身に触れるのは銀行だけです。Solanaでは、プログラムが銀行であり、あなたは鍵を持つアカウント保持者です。

「所有者（Owner）」と「権限（Authority）」の区別は、多くのEthereum開発者を混乱させます。

• 所有者 (Owner) (プロトコルフィールド): アカウントのdataフィールドを変更できるプログラムID。アカウント作成時に設定されます。プログラムのロジックではなく、Solanaランタイムによって強制されます。
• 権限 (Authority) (データコンベンション): 所有プログラムによってアカウントのdataフィールド内に保存されるパブリックキー。そのプログラムのロジック内の特定の操作を許可します。ランタイムではなく、プログラム自身によって強制されます。

USDCトークンアカウントの場合、Token Programが所有者（owner）であり、データフィールドに保存されている残高を変更できます。あなたのウォレットは転送権限（authority）であり、これはToken Programが転送を実行する前に確認する、データフィールド内に記録されたパブリックキーです。これらは異なる機能を果たす異なるキーです。これらを混同することは、Solana開発の初心者における最も一般的なエラーの1つです。

Solanaのアカウントレント（賃貸料）とレント免除の解説

Solanaのレント（Rent）とは、オンチェーンの状態を維持するためにバリデータに補償するためにアカウントに課される、lamports単位のストレージ手数料です。最小限のlamport残高（レント免除のしきい値）を保持するアカウントは、レントの支払いが永久に免除され、ランタイムによって削除されることはありません。

Solanaのレントとは？

バリデータはすべてのアクティブなアカウント状態をメモリに保存する必要があります。残高ゼロのアカウントが際限なく増えることは、ネットワークに対するサービス拒否（DoS）攻撃のベクトルとなるため、Solanaはストレージコストを支払うコミットメントとして、アカウントに最低限のlamport残高を保持することを要求します。当初のレントモデルでは、データサイズに比例したエポックごとの手数料を課し、最低額を下回るアカウントはガベージコレクションの対象となっていました。そのモデルは廃止されました。

現在のSolanaメインネットのパラメータ（SIMD-0084で正式化）では、すべての新しいアカウントは作成時にレント免除（rent-exempt）である必要があります。アカウント構造内のrent_epochフィールドは現在、レガシーフィールドとなっています。

レント免除の仕組み

アカウントをレント免除にするには、作成トランザクションを送信する際に、そのデータサイズに応じた最低lamport残高以上の資金を投入します。現在のネットワークパラメータでは以下の通りです。

• 0バイトのアカウント (ウォレット): 約890,880 lamports (約0.00089 SOL)
• 165バイトのアカウント (標準的なトークンアカウント): 約2,039,280 lamports (約0.00204 SOL)
• 1,024バイトのデータアカウント: 約7,180,800 lamports (約0.00718 SOL)

これらの値は概算であり、ランタイムのパラメータ変更により変わる可能性があります。正確な現在の最低額は、Solana CLIまたはgetMinimumBalanceForRentExemption RPCメソッドを使用して計算してください。

solana rent 0       # 0バイトアカウントのレント免除額
solana rent 165     # 標準トークンアカウントのレント免除額

レント免除は、貸し倉庫の保証金のようなものです。ネットワーク上でのアカウントの存在を保証するために、最低限のlamport残高をロックします。手数料とは異なり、この保証金は完全に回収可能です。アカウントを閉じると、それらのlamportはあなたに返還されます。

レントの計算で使用されるlamportの単位については、アカウント構造のセクションで定義されています。プログラムがデータアカウントを作成する際にレント免除にするには、作成トランザクションを構築する前にクライアント側でgetMinimumBalanceForRentExemption(dataSize)を呼び出し、そのlamport額をインストラクションに含めてください。

Solana vs Ethereum vs Bitcoin：アカウントモデルの比較

SolanaアカウントとEthereumアカウントの違いは何ですか？

Ethereumでは、スマートコントラクトはそのコードと状態を1つのアドレスにまとめてバンドルします。コントラクトアカウントは、ロジックとそのロジックが操作するデータの両方を保持します。Solanaでは、コードと状態は常に別々のアカウントにあります。プログラム（ロジック）は実行可能（executable）なアカウントに存在し、すべての状態（ステート）はそれらのプログラムが所有する個別のデータアカウントに存在します。この分離こそが、Solanaが行うすべての異なるアプローチのアーキテクチャ上の基盤です。

Bitcoinは全く異なるアプローチをとっており、UTXO（Unspent Transaction Output）モデルを使用しています。UTXOは小切手帳の未使用の小切手のようなもので、各トランザクションは既存の出力を消費し、新しい出力を作成します。時間を超えて残高を保持する永続的なアカウントは存在しません。あなたの残高は、あなたのキーに関連付けられた未使用の出力の合計です。Bitcoinのモデルはプログラム可能な状態という概念よりも前に作られたため、そのスマートコントラクト機能はBitcoin Scriptに限定されています。

Ethereum、Polygon、BNBチェーン、Avalanche C-Chainを含むEVM互換ネットワークはすべて、Solanaが採用していないものと同じアカウントモデルを共有しています。一つの比較でこれらすべてをカバーできます。

Ethereumでは、ユーザーのウォレットは外部所有アカウント (EOA) と呼ばれます。Solanaでは、これに相当するものはキーペアによって制御されるシステム所有のアカウントです。メカニズムは似ていますが、所有者フィールドは暗黙的ではなく、明示的にシステムプログラムに設定されます。

Ethereumデベロッパーが忘れなければならないこと

機能するSolanaプログラムを作成する前に、3つのメンタルモデルの転換が必要です。

1. プログラムは独自の状態を保持しません。データアカウントが保持します。プログラムアドレスで状態を探すのはやめましょう。
2. ウォレットの所有者は、プロトコルレベルではあなたではありません。あなたは署名することによってアカウントを制御しますが、データフィールドを所有しているのはシステムプログラムです。
3. ストレージは無料ではありません。すべてのデータアカウントには、賃貸免除のためのlamportの入金が必要です。アカウントを作成するプログラムを設計する際は、このコストを予算に組み込んでください。

Solanaのコードと状態の厳格な分離は並列実行の前提条件であり、この関係についてはSealevelと並列実行のセクションで詳しく説明します。

アカウントモデルがSolanaのスピードを支える仕組み：Sealevelと並列実行

Solanaのアカウントモデルは、すべてのトランザクションが実行開始前に、読み取りまたは書き込みを行うアカウントの完全なリストを明示的に宣言する必要があるため、並列処理を可能にします。Solanaの並列スマートコントラクトランタイムであるSealevelは、それらの事前の宣言を使用して、異なるアカウントに接触するトランザクションを特定し、それらを同時に実行します。

ステップごとの因果関係は以下の通りです。

1. Solanaのトランザクションには、実行が行われる前に、アクセスするすべてのアカウントの完全なリストが含まれており、それぞれに読み取り専用または読み書き可能のマークが付けられています。
2. Sealevelは、現在のスロットにあるすべての保留中のトランザクションを検査します。
3. 少なくとも1つの読み書きアカウントを共有するトランザクションは順序付けされます。完全に異なるアカウントにアクセスするトランザクションは、非競合として特定されます。
4. 非競合のトランザクションは、複数のCPUコアで同時に実行されます。

EthereumのEVMは、共有されたグローバル状態に対してトランザクションを順次実行します。コントラクトの状態がコントラクトコードと同じ場所に配置されているため、読み取り/書き込みの競合を判断するには、まずトランザクションを実行する必要があり、実行前の静的なスケジューリングは不可能です。

Sealevelを、多くのレジがあるスーパーマーケットのように考えてください。各トランザクションは、宣言されたアイテムのリストを持つ買い物客です。2人の買い物客が同じアイテムに手を伸ばさない限り、彼らは同時にチェックアウトします。アカウントモデルが事前の宣言を強制するため、Solanaは各トランザクションが何を必要としているかを事前に正確に把握しています。

Solanaの共同創設者であるAnatoly Yakovenkoによって発明された歴史証明 (PoH) は、バリデーターがリアルタイムの調整なしにトランザクションの順序に同意できるようにする暗号クロックを提供します。Solanaはコンセンサスにプルーフ・オブ・ステーク (PoS) を使用し、バリデーターはブロック生成に参加するためにSOLをステーキングします。PoHはタイミングレイヤーとして使用されます。アカウントモデルの事前の宣言と組み合わせることで、このアーキテクチャにより、Sealevelは各ステップでネットワーク全体の確認を待つことなく、非競合のトランザクションを並列に処理できます。

アカウントモデルは、単独のストレージスキームではありません。それは並列処理の前提条件であり、Solanaのスループットとスケーラビリティの優位性の技術的な根源です。

実例：Solanaにおけるトークンアカウント、NFT、そして DeFi

Solana上のすべての資産、トークン残高、NFT、DeFi のポジションは、特定のデータレイアウトを持つSolanaアカウントです。上記の抽象的なアーキテクチャは、すべてのSolanaユーザーが遭遇する3つのパターンで具体化されます。

SPLトークンアカウント

EthereumのERC-20トークンに相当するSolanaのSPLトークンは、ネットワーク上のすべてのトークンアカウントを所有するSPLトークンプログラムによって管理されます。あなたのウォレットアドレスにはSOL (lamports) のみが保持されます。USDC、JTO、BONK、あるいはその他の保持している各トークンは、SPLトークンプログラムによって所有される専用のトークンアカウントに存在します。

トークンアカウントのデータフィールドには、トークンミントアドレス（そのアカウントが保持しているトークン）、所有権限パブリックキー（送金を承認するあなたのウォレットアドレス）、および現在のトークン残高の3つの情報が保存されます。Ethereumでは、特定のトークンのすべてのERC-20残高はトークンコントラクトの内部マッピング内に存在します。Solanaでは、各（ユーザー、トークン）のペアに専用のアカウントが必要です。

これが、新しいトークンを初めて受け取る際にSolanaウォレットがトークンアカウントの作成を求める理由です。その作成には、現在のネットワークパラメータにおける標準的な165バイトのアカウントで、約0.00204 SOLの賃貸免除lamport入金が必要です。

関連トークンアカウント (ATA)

関連トークンアカウント (ATA) とは、ウォレットアドレスとトークンのミントアドレスから決定論的に導出されたPDAをアドレスとするトークンアカウントのことです。アドレスが決定論的であるため、どのプロトコルもルックアップテーブルを保存することなく、あなたのUSDCアカウントがどこにあるべきかを計算できます。ATAは、事実上すべてのSolanaウォレットとプロトコルで使用される標準的なトークンアカウントタイプです。

ATAはPDA導出の応用です。同じミントに対して複数のトークンアカウントを持つことができますが、ATAはプロトコルがデフォルトで使用する正規のアカウントです。

Solana上のNFT

Solana上の NFT は、少なくとも2つのアカウントで構成されます。1つは、トークンの供給量を正確に1と定義する、トークンプログラムによって所有されるミントアカウントです。もう1つは、NFT の名前、シンボル、画像URI、およびロイヤリティ設定を保存する、Metaplexトークンメタデータプログラムによって所有されるメタデータアカウントです。NFT の画像はオンチェーンには保存されず、メタデータアカウントにはそれを指し示すURIのみが保存されます。トークン残高 (1 NFT) は、他のSPLトークンと同様にトークンアカウントに保存されます。

分散型取引所、レンディングプラットフォーム、流動性プールを含むSolana上の DeFi プロトコルは、すべてのユーザーポジション、プール状態、およびプロトコル設定を専用のデータアカウントに保存し、プログラムが所有するPDAがプールされた資金を自律的に制御します。

なぜSolanaのアカウントモデルがSOLにとって重要なのか

注意: このセクションでは、SolanaのアカウントモデルがSOLの技術的な有用性にどのように影響するかを説明します。この記事のいかなる内容も、財務上のアドバイスや投資勧誘を構成するものではありません。

アカウントモデルは開発者だけの関心事ではありません。主要な暗号資産取引所で利用可能なSOLは、ネットワークのネイティブユーティリティトークンとして機能します。アカウントモデルは、ネットワークレイヤーでSOLが需要され、使用される主要なメカニズムです。

SOLは、3つの異なるメカニズムを通じてアカウントモデルで使用されます。

賃貸免除の入金: Solana上のすべてのアカウントは、ネットワーク上に存在するためにlamportの残高を保持する必要があります。数百万のトークンアカウント、プログラムデータアカウント、NFT の記録、および DeFi の状態アカウントが常にアクティブであるため、これによりSOLに対する継続的なベースライン需要が生まれます。これらのlamportはアカウントにロックされ、アカウントが開設されている限り、流動的な循環から除外されます。

トランザクション手数料: アカウントを作成または変更するすべてのトランザクションは、ランポートで基本料金を支払います。現在の料金体系では、各手数料の一部がバーン（焼却）され、トランザクションごとに循環供給量が減少します。

バリデータのステーキング: バリデータはSOLをステーキングして、Solanaのプルーフ・オブ・ステーク（PoS）メカニズムの下でコンセンサスに参加し、ネットワーク全体のアカウントステート遷移を検証することで報酬を獲得します。

オンチェーンのアクティビティが活発になり、DeFiプロトコル、NFTコレクション、トークンのローンチが増えるにつれて、アカウント数も比例して増加します。アカウントが増えるほど、賃料免除の入金としてロックされるSOLも多くなります。

賃料免除アカウントにロックされたランポートは、ネットワークが保持する保証金のように機能します。消費されることはありませんが、アカウントが開設されている限り預けられます。アカウントが閉鎖されると、これらのランポートは所有者に返還されます。

関連するSolanaアーキテクチャリソース

トークンアカウントはSolanaプログラムライブラリと併せて理解するのが簡単です。また、並列処理についてはSealevel並列処理のガイドで説明されています。読者はSOL価格ページ;)を確認できます。ステーキング関連製品を検討しているユーザーは、現在の規約とリスクを含むSOL Earn,)を別途確認できます。

FAQ：Solanaアカウントモデル

SolanaアカウントとEthereumアカウントの違いは何ですか？

Ethereumでは、スマートコントラクトはそのコードとステートの両方を1つのアドレスに保存します。Solanaでは、コードとステートは常に別々のアカウントにあります。プログラムはステートレスな実行可能アカウントであり、すべてのステートはそれらのプログラムが所有する個別のデータアカウントに保持されます。この分離により、Sealevelは競合しないトランザクションを並列実行できます。これは、ステートが同じ場所に配置されているEthereumのモデルでは不可能です。

Solanaの賃料（レント）とは何ですか？どのように機能しますか？

Solanaの賃料とは、ネットワーク上にデータを保存するためのコストで、ランポート単位で表記されます。継続的に手数料を支払うのではなく、ランタイムによる消去を避けるために、アカウントは事前に最低限のランポート残高（賃料免除しきい値）を入金する必要があります。この入金は回収可能です。アカウントが閉鎖されると、ランポートは所有者に返還されます。標準的な165バイトのトークンアカウントの場合、現在のネットワークパラメータでは入金額は約0.00204 SOLです。

Solanaのプログラム派生アドレス（PDA）とは何ですか？

PDAは、プログラムIDと一連のシード値から決定論的に派生するSolanaアカウントアドレスです。対応するプライベートキーを持たないため、それを派生させたプログラムのみが、プログラム間呼出し（CPI）を通じてその代理でトランザクションを承認できます。PDAは、DeFiプロトコル、NFTエスクロー、および関連トークンアカウントに必要な、アカウントに対する自律的で信頼不要（トラストレス）な制御をプログラムに与えます。

Solanaのアカウントモデルはどのように並列処理を可能にしますか？

すべてのBybitトランザクションは、実行前に読み取りまたは書き込みを行うアカウントの完全なリストを宣言する必要があります。Solanaの並列スマートコントラクトランタイムであるSealevelは、これらの宣言を使用して、競合しないトランザクションを特定し、複数のCPUコアで同時に実行します。この静的スケジューリングは、コードとステートが別々の明示的に所有されたアカウントにあるためにのみ可能であり、実行開始前に読み取り/書き込みの競合を検出できるようになります。

Solanaアカウントのownerフィールドとは何ですか？

ownerフィールドは、アカウントのdataフィールドを変更する権限を持つプログラムを特定する32バイトのパブリックキーです。ウォレットアカウントの場合、オーナーはSystem Programです。トークンアカウントの場合、オーナーはSPL Token Programです。ownerフィールドは、Solanaランタイムによって強制されるプロトコルレベルの概念です。これは、トークンアカウントなどの特定のプログラム管理データアカウント内にある「authority」フィールドとは異なります。

アカウントモデルでSOLはどのように使用されますか？

SOLは、アカウントモデルにおいて3つのメカニズムを通じて使用されます。すなわち、すべてのアカウントはネットワーク上に存在するためにランポート残高（SOL）を保持する必要があり、アカウントの作成には賃料免除の入金資金としてSOLが必要であり、アカウントステートを処理および保存するバリデータはコンセンサスに参加するためにSOLをステーキングする必要があります。ネットワークが成長するにつれて、SOLに対する構造的な需要も高まります。

Sealevelとは何ですか？アカウントとどのように関係していますか？

Sealevelは、Solanaの並列スマートコントラクトランタイムです。Solanaのアカウントモデルでは、各トランザクションがどのアカウントを読み取りまたは書き込みするかを事前に宣言する必要があるため、複数のトランザクションを同時に実行できます。Sealevelはこれらの宣言を使用して、競合しないトランザクションを特定し、並列実行するようにスケジュールします。アカウントモデルの事前の宣言がなければ、この静的スケジューリングは不可能です。

Solanaにおけるウォレットアカウントとプログラムアカウントの違いは何ですか？

ウォレットアカウントは、キーペアによって制御され、SOL残高のみを保持する、データフィールドが空のシステム所有アカウントです。プログラムアカウントは、コンパイルされたBPF/SBFバイトコードを含む、executable = trueの実行可能アカウントです。これはBPF Loaderによって所有され、それ自体にはステートを保持しません。Solanaアカウントの5つのタイプセクションのアカウントタイプ表には、5つのバリエーションすべてが並んで示されています。

Solanaのトランザクションはいくつのアカウントを参照できますか？

現在のメインネットのパラメータでは、単一のSolanaトランザクションで最大64個のアカウントを参照できます。これは、アドレスルックアップテーブル（ALT）により、当初の32個から増加しました。各アカウントは、実行開始前に読み取り専用か読み書き可能かを宣言する必要があります。この事前の宣言こそが、競合を検出するために最初にトランザクションを実行することなく、Sealevelが並列実行をスケジュールすることを可能にしています。

1つのSolanaアカウントで複数のトークンを保持できますか？

いいえ。各SPLトークンタイプには、専用のトークンアカウントが必要です。ウォレットアドレスはSOLのみを保持します。追加のトークンごとに、その権限（authority）フィールドを通じてウォレットにリンクされた個別のトークンアカウントが必要になります。そのため、Solanaウォレットでは、これまで保持したことのないトークンを受け取る際に新しいトークンアカウントの作成を求められ、その作成には少額の賃料免除ランポートの入金が必要になります。

主な要点

• Solanaのすべてのオンチェーンステートは、lamports（ランポート）、data（データ）、owner（オーナー）、executable（実行可能）、rent_epoch（レントエポック）の5つのフィールドを持つアカウントに保存されます。
• プログラムはステートレスです。すべてのステートは、プログラムが所有および制御する別個のデータアカウントに保持されます。
• アカウントをネットワーク上に維持するには、ランポートの入金（賃料免除）が必要です。この入金は、アカウントを閉鎖する際に回収可能です。
• PDAはプライベートキーを持たないアドレスであり、プログラムIDとシードから決定論的に派生し、CPIを通じてそれを作成したプログラムのみが署名できます。
• すべてのトランザクションは、事前にアクセスするアカウントリストを宣言します。Sealevelはこれらの宣言を使用して、競合しないトランザクションを同時に実行します。

次のステップ

• 実装の詳細については、docs.solana.comのSolanaアカウントドキュメント)を参照してください。
• 初めてのSolanaプログラムを構築する開発者は、アカウント管理のボイラープレートの多くを抽象化するAnchorフレームワーク,)から始めることができます（プログラムはRustまたはC/C++で記述されます）。
• JavaScript/TypeScriptでの実践的なコードレシピや動作例については、Solana Cookbook)が実用的なリファレンス資料を提供しています。