本日は、Solanaにおける、アカウントをしっかりと見ていきます。

これらのドキュメントもぜひ参考にしてみてください。

１　アカウントの種類

１　イーサリアムの場合

まずは、イーサリアムとの比較で考えてみましょう。

イーサリアムには、「EOA」と「コントラクトアカウント」という２つがあります。

なお、EOAはメタマスクなどで作るアカウントです。

２　Solanaの場合

一方、Solanaには「データアカウント」「プログラムアカウント」「ネイティブアカウント」の３つがあります。

下のような対応関係になっています。

「ネイティブアカウント」はSolanaのネイティブプログラムを意味しますが、今回の記事では省略します。

２　アカウントの中身について

１　イーサリアムの場合

まず、イーサリアムの場合は、下のように、「nonce」「balance」「storage hash」「code hash」から構成されています。

大まかに、下のようになっています。

なお、EOAの場合は、「storage hash」「code hash」がありません。

今回のメインのテーマから外れるため、詳細は割愛します。

２　Solanaの場合

Solanaのアカウントは、「lamports」「owner」「executable」「data」「rent_epoch」の５つがあります。

一つずつ見ていきましょう。

２ー１　lamportsについて

こちらは、イーサリアムで言うところの、「balance(残高)」に該当します。

イーサリアムの最小単位の「wei」に対応するものが、「lamport」であり、いくら持っているのかを表しています。

２ー２　ownerについて

その名の通り、「owner(所有者)」です。

これは、イーサリアムのアカウントには対応するものがありません。

大事な点なので、第４章で詳しく見ていきます。

２ー３　rent_epochについて

上で見たように、アカウントには所有者がいました。

そのため、アカウントを使用するには、レント（賃貸料）を支払う必要があります。

エポックとは、時間を区切る単位のことで、レントを支払った最後のエポックが保存されます。

レントについては、第６章で詳しく扱います。

２ー４　executableについて

アカウントが、プログラムを持ち、実行可能かどうかを格納します。

そのため、「プログラムアカウント」は基本「true」で「データアカウント」は「false」です。

イーサリアムとの直接の対比ではないですが、イーサリアムでは「code」の中身があるかどうかで「コントラクトアカウント」かを判定できます。

２ー５　dataについて

この「data」は注意が必要です。

保存されたデータかバイトコードのどちらかを含めることができます。

そのため、イーサリアムの「storage hash」「code hash」の両方（どちらかしか含まない）に相当します。

下の図がイメージしやすいと思います。

この例では、「データアカウント」では「counter」というカウントした値を保持したデータを持っています。

一方、左側の「プログラムアカウント」ではバイトコードを保持しています。

３　スマートコントラクトとプログラム

Solanaでは、スマートコントラクトのことをプログラムと呼びます。

なぜこのように呼び方が異なるのでしょう。

１　イーサリアムの場合

イーサリアムでは、コントラクトアカウントの中に、「コード（ロジック）」と「値」が両方入っています。

この理由から、コントラクトは更新することができません。

今回、その辺りの詳細は触れませんが、ご興味のある方は、こちらもご参考ください。

一方、イーサリアムには、「アップグレーダブル」コントラクトがあります。

これは、値を保持するコントラクトとロジックのコントラクトを分離しています。

Solanaはまさにこれと同じような構成になっています。

２　Solanaの場合

Solanaでもアップグレーダブルコントラクトのようにロジックと値が分離されています。

そして、ロジック部分のアカウントのことを、「プログラムアカウント」といいます。

そして、下の例では、紐づいている「データアカウント」の所有者が、「プログラムアカウント」になっています。

これは、次の章で触れますが、「所有者でないとアカウントを変更できない」というルールがあります。

そのため、この場合、「プログラムアカウント」からしか変更ができないようにしています。

４　Owner(所有者)について

１　定義について

Solanaでの「owner(所有者)」とは、「owner」に設定されているアカウントです。

つまり、実際に秘密鍵を持っているかどうかとは直接関係がありません。

２　所有者の特徴

所有者の特徴は「所有者のみがデータの変更ができる」ということです。

これが具体的に何を指すのか、丁寧に見てみましょう。

３　新しく作成したアカウントの所有者について

では、新しく、キーペア（秘密鍵と公開鍵）から作成されるアカウントの所有者を見ていきましょう。

それは、下のような、「System Program」というアカウントです。

つまり、こんな関係になります。

ちなみに、今回できたアカウントは「ユーザーアカウント」と呼びます。

このアカウントに６SOL入っているとします。

４　ユーザーアカウントの変更者は？

この残高を変更することができるのは、先ほどの通り、所有者である、「System Program」だけです。

つまり、秘密鍵を持っているアカウント自身ではありません。

これは、違和感があると思いますが、最終的には腹落ちすると思いますので、もう少し進めてみましょう。

５　秘密鍵保持者による署名

まず、アカウントを変更できるのは、所有者である、「System Program」だけでした。

ただし、実行するためには、「署名」付きのトランザクションを実行する必要があります。

そして、有効な署名を行うことができるのが、秘密鍵の保持者です。
（漏洩・紛失がなければ、ユーザーアカウント）

そのため、実際問題としては、ユーザーアカウントは自身の残高を送付などすることができます。

５　プログラムアカウントの作成について

１　プログラムアカウントの生成について

では、次はプログラムアカウントの生成についても見てみましょう。

まずは、このように、今までと同じようにアカウントがあります。

２　プログラムのアップロード

このアカウントに、コードの中身自身である、プログラムをアップロードします。

これによって、「プログラムアカウント」になります。

３　フィールドの更新

そして、アカウントには、第２章で扱ったように、フィールドが存在します。

データにバイトコードを設定し、「executable」を「true」にします。

４　ownerの更新

なお、更新可能なプログラムアカウントにした場合、Ownerは下のようになります。

ちなみに、更新可能な場合、この「BPF Upgradable Loader」によってデプロイされています。

こんな感じです。

５　データアカウントの作成

第３章で扱ったように、Solanaでは「ロジック」と「値」は分離されています。

そして、データアカウントには、PDA(プログラム派生アドレス)などが使われます。

これについては、こちらの記事をご参照ください。

６　レント（賃貸料）について

１　レント（賃貸料）について

今回は、ユーザーアカウントを例に考えてみます。

ユーザーアカウントの所有者は、あなたではなく、「System Program」でした。

そのため、使用し続けるには、レント（賃貸料）を支払う必要があります。

２　レント導入の理由

Solanaがレントの制度を採用している理由の一つは「ストレージの効率的な利用」です。

不要なアカウントが作られることを防ぎ、リソースの無駄な利用を防いでいます。

だからこそ、レントは、アカウントのサイズによって計算されます。

３　レント免除について

レントの主目的は、「ストレージの効率的な利用」であるため、レント免除という仕組みがあります。

これは、２年分のレントに相当する残高がある場合は、レントが免除されるというものです。

今回は、アカウントについて丁寧に見てみました。

以上です。