0x05 ソラナ.1 - [面包]MrTwoC

新しいコンセンサスメカニズム —— 歴史的証明メカニズム（PoH）
世界で最も速い「高速公链」——Solana
Solana の基本的なコンセンサスは PoS（すなわち一般的なステーク証明メカニズム）であり、簡単に言えば、ユーザーが保有する通貨の量と時間（通貨の年齢）に基づいて利息の額を決定する制度です。
歴史的証明メカニズム（PoH）は、Solana の巧妙で非常に実用的な革新です。従来のブロックチェーン、例えばビットコインやイーサリアムは、時間と状態を結びつけており、新しいブロックが誕生することでのみ全体的に一貫した状態が生成されます。Solana は、ハッシュに基づく時間チェーンと状態を巧妙に分離しており、各ブロックのハッシュをリンクするのではなく、ネットワーク内の検証者がブロック内のハッシュ自体をハッシュします。このメカニズムが PoH（Proof of history）です。
Solana 開発学習ノート (一)——Hello World から始める | 登链社区 | ブロックチェーン技術コミュニティ
 Solana プログラミングモデル：Solana 開発入門 | 登链社区 | ブロックチェーン技術コミュニティ

クラスター#

Solana アーキテクチャの核心であり、一群の検証者が共同で取引を処理し、単一の台帳（ledger）を維持します。Solana にはいくつかの異なるクラスターがあり、それぞれ特定の用途があります：
ローカルホスト：デフォルトポート 8899 のローカル開発クラスター。Solana コマンドラインインターフェース（CLI）には、開発者の個々のニーズに応じてカスタマイズ可能な内蔵のテスト検証者があり、エアドロップなしで速度制限もありません。
開発ネットワーク Devent：テストと実験のための無価値環境
テストネットワーク Testnet：コアメンバーが新しい更新や機能を実験する場所であり、性能テストも行えます。
メインネットベータ版 Mainnet Beta：リアルタイムで、許可なしに、実際の通貨取引を生成する場所です。

Solana アカウント#

データを保存するアカウント
実行可能なプログラムを保存するアカウント
ネイティブプログラムを保存するアカウント

機能に応じて区別できます：

実行可能アカウント
実行不可アカウント（コードを含まない）

各実行不可アカウントには異なるタイプがあります：

関連トークンアカウント - 特定のトークン情報、その残高、所有者情報を含むアカウント（例：アリスは 10 の USDC を持っている）
システムアカウント - システムプログラムによって作成され、所有されるアカウント
ステーキングアカウント - トークンを検証者に委託して潜在的な報酬を得るためのアカウント

アカウント構造#

pub struct AccountInfo<'a> {
    pub key: &'a Pubkey,
    pub lamports: Rc>,
    pub data: Rc>,
    pub owner: &'a Pubkey,
    pub rent_epoch: Epoch,
    pub is_signer: bool,
    pub is_writable: bool,
    pub executable: bool,
}

アカウントはそのアドレス（key）によって識別され、これはユニークな 32 バイトの公開鍵です。
lamports フィールドは、このアカウントが保有するlamportsの数を保存します。1 つの lamport は、Solana のネイティブトークン SOL の 10 億分の 1 に相当します。
data は、このアカウントが保存する生データのバイト配列を指します。これは、デジタル資産のメタデータからトークン残高まで、あらゆるものを保存でき、プログラムによって変更可能です。
owner フィールドには、このアカウントの所有者が含まれ、プログラムアカウントのアドレスで表されます。アカウント所有者に関するいくつかのルールがあります：

アカウントの所有者のみがそのデータを変更し、lamports を引き出すことができます
誰でもアカウントに lamports を預けることができます
アカウントの所有者は、アカウントのデータがゼロにリセットされることを前提に、新しい所有者に所有権を移転できます

rent_epoch フィールドは、このアカウントが次のエポック期間中に賃料を支払う必要があることを示します。エポックは、リーダーがスロットをスケジュールする数です。オペレーティングシステムの従来のファイルとは異なり、Solana 上のアカウントは lamports で表される寿命を持っています。アカウントの持続的な存在は、その lamport 残高に依存しており、これにより賃料の概念が導入されます。
is_signer フィールドは、取引が関与するアカウントの所有者によって署名されているかどうかを示すブール値です。言い換えれば、これは取引に関与するプログラムアカウントに対して、アカウントが署名者であるかどうかを示します。署名者であることは、アカウントが公開鍵に対応する秘密鍵を保持し、提案された取引を承認する権限を持つことを意味します。
is_writable フィールドは、アカウントのデータが変更可能かどうかを示すブール値です。Solana は、取引でアカウントを読み取り専用として指定することを許可し、並行処理を促進します。実行時は、異なるプログラムが同時に読み取り専用アカウントにアクセスすることを許可しますが、取引処理の順序を使用して潜在的な書き込み競合を処理します。これにより、競合のない取引のみが並行処理されることが保証されます。
executable フィールドは、アカウントが命令を処理できるかどうかを示すブール値です。これは、プログラムがアカウントに保存されていることを意味し、次のセクションで詳しく探ります。まず、賃料の概念を紹介する必要があります。

賃料（Rent）#

アカウントをアクティブに保ち、検証者のメモリ内にアカウントを保持するために発生するストレージコスト。賃料の徴収はエポック評価に依存し、これは時間単位で定義された時間単位です。

賃料徴収 - 賃料は各エポックごとに一度徴収されます。アカウントが取引で参照される場合にも賃料が徴収されることがあります
賃料配分 - 徴収された賃料の一部は破棄され、これは流通から永久に除去されることを意味します。残りの部分は各スロットの後に投票アカウントに配分されます
賃料支払い - アカウントに賃料を支払うための十分な lamports がない場合、そのデータは削除され、アカウントは「ガーベジコレクション」と呼ばれるプロセスで解放されます
賃料免除 - アカウントが 2 年分の賃料支払いの最低残高を維持している場合、そのアカウントは賃料免除となることができます。すべての新しいアカウントは、この賃料免除の閾値を満たす必要があり、これはアカウントのサイズに依存します
賃料回収 - ユーザーはアカウントを閉じて残りの lamports を回収できます。これにより、ユーザーはアカウントに保存されている賃料を回収できます

特定のアカウントサイズの賃料を推定するには、getMinimumBalanceForRentExemption RPC エンドポイントを使用できます。Test Driveは、usize 内のアカウントデータの長さを受け入れることでこのプロセスを簡素化します。Solana rent CLI サブコマンドも、アカウントが賃料免除になるために必要な最低 SOL 額を推定するために使用できます。例えば、この記事執筆時点で、コマンド solana rent 20000 を実行すると、賃料免除の最低値：0.14009088 SOL が返されます。

Solana アドレス#

Solana には 2 種類の「タイプ」アドレスがあります。
Solana はed25519を使用しており、これはSHA-512（SHA-2）とCurve22519楕円曲線を使用した EdDSA 署名スキームでアドレスを作成します。 32 バイトの公開鍵を生成し、これらは主要なアドレス形式として直接使用でき、ハッシュされていません。
アドレスを有効にするには、ed25519曲線上の点である必要があります。ただし、すべてのアドレスがこの曲線から派生する必要はありません。プログラム派生アドレス（PDA）は曲線の外で生成され、これは対応する秘密鍵を持たず、署名にも使用できません。PDA はシステムプログラムによって作成され、プログラムがアカウントを管理する必要があるときに使用されます。

Solana アカウントとイーサリアムアカウントの違い#

イーサリアムには 2 種類のアカウント（EOA、コントラクトアカウント）があり、コントラクトアカウントにはコントラクトコードが管理され、取引を開始することはできません。
Solana の任意のアカウントはプログラムになる可能性があります。コードとデータは分離されています。
Solana には状態がなく、さまざまなデータアカウントと相互作用し、冗長なデプロイを必要としません。異なるプログラム間で相互作用する際に資産を移動する必要はありません。
Solana は賃料を支払う必要があり、アクティブな状態を維持するために最低残高が必要です。使用されないか資金が不足している場合は回収されます。

プログラムとは何か#

プログラムは、BPF Loaderが所有する実行可能なアカウントです。これらはSolana Runtimeによって実行され、取引とプログラムロジックを処理するように設計されています。
Solana のプログラミングモデルの特徴：コードとデータは分離されています。プログラムには状態がなく、状態を保存しません。すべてのデータはアカウントに存在し、取引を通じて参照の形でプログラムに渡されます。
Solana プログラムの能力：

追加のアカウントを持つ
他のアカウントから資金を取得 / 読み取る
データを変更 / 所有するアカウントから差し引く

プログラムの 2 種類

オンチェーンプログラム - Solana 上にデプロイされたユーザーが作成したプログラム。これらは、そのアップグレード権限によってアップグレード可能で、アップグレード権限は通常プログラムをデプロイしたアカウントです
ネイティブプログラム - これらのプログラムは Solana コアに統合されています。これらは、検証者の実行に必要な基本機能を提供します。ネイティブプログラムは、ネットワーク全体のソフトウェア更新を通じてのみアップグレードできます。一般的な例には、システムプログラム、BPF Loader プログラム、および投票プログラムが含まれます。

通常、プログラム開発には Rust 言語が使用され、開発フレームワーク：Anchor を利用してプログラム作成を簡素化します。

取引とは何か#

これはチェーン上の活動の柱です。プログラムを呼び出し、状態変更を実施するメカニズムです。Solana 上の取引は、一連の命令の束です。
取引の構成：

読み取りまたは書き込みを行うアカウントの配列
1 つ以上の命令
1 つ以上の署名

Solana 取引構造は、ネットワーク処理と検証操作に必要な情報を提供します。

pub struct Transaction {
    pub signatures: Vec,
    pub message: Message,
}

signatures フィールドには、シリアライズされた Message に対応する一連の署名が含まれています。各署名は、Message の account_keys リスト内の 1 つのアカウントキーに関連付けられ、fee payer から始まります。fee payer は、取引処理中に取引手数料を支払う責任を持つアカウントです。これは通常、取引を開始するアカウントです。必要な署名の数は、メッセージの MessageHeader 内で定義された num_required_signatures に等しいです。
message 自体は Message 型の構造体です。これは次のように定義されています：

pub struct Message {
    pub header: MessageHeader,
    pub account_keys: Vec,
    pub recent_blockhash: Hash,
    pub instructions: Vec,
}

header には、必要な署名の数（すなわち num_required_signatures）、読み取り専用署名者の数、および読み取り専用非署名者の数という 3 つの符号なし 8 ビット整数が含まれています。
account_keys フィールドは、取引に関与するすべてのアカウントアドレスを列挙します。読み書きアクセス権を要求するアカウントが最初に表示され、その後に読み取り専用アカウントが続きます。
recent_blockhash は、最近のブロックハッシュで、32 バイトの SHA-256 ハッシュを含みます。これは、クライアントが最後に台帳を観察した時間を示し、最近の取引のライフサイクルとして機能します。検証者は、古いブロックハッシュを持つ取引を拒否します。さらに、最近のブロックハッシュの含有は、重複取引を防ぐのに役立ちます。なぜなら、以前と完全に同じ取引は拒否されるからです。何らかの理由で、取引がネットワークに提出される前に長時間署名される必要がある場合、持続取引 nonceを使用して最近のブロックハッシュの代わりにすることで、ユニークな取引であることを保証できます。
instructions フィールドには、1 つ以上の CompiledInstruction 構造が含まれ、各構造はネットワーク検証者に特定の操作を実行するよう指示します。

命令#

命令は、単一の Solana プログラム呼び出しに対する指示です。これはプログラム内で実行されるロジックの最小単位であり、Solana 上で最も基本的な操作単位です。プログラムは、命令から渡されたデータを解釈し、指定されたアカウントに対して操作を行います。Instruction 構造は次のように定義されています：

pub struct Instruction {
    pub program_id: Pubkey,
    pub accounts: Vec,
    pub data: Vec,
}

program_id フィールドは、実行されるプログラムの公開鍵を指定します。これは、命令を処理するプログラムのアドレスです。この公開鍵によって指示されたプログラムアカウントの所有者は、プログラムの初期化と実行を担当するローダーを指定します。ローダーはデプロイされると、チェーン上の Solana バイトコード形式（SBF）プログラムを実行可能としてマークします。Solana の実行時は、実行可能としてマークされていないアカウントを呼び出そうとする取引を拒否します。
accounts フィールドは、命令が読み取りまたは書き込みを行う可能性のあるアカウントを列挙します。これらのアカウントは AccountMeta 値として提供する必要があります。命令によってデータが変更される可能性のあるアカウントは、書き込み可能として指定する必要があり、そうでない場合は取引が失敗します。これは、プログラムが所有していないアカウントや必要な権限を持たないアカウントに書き込むことができないためです。これは、アカウントの lamports を変更することにも当てはまります：プログラムが所有していないアカウントから lamports を減算することは取引の失敗を引き起こし、任意のアカウントに lamports を追加することは許可されています。accounts フィールドは、プログラムが読み取りまたは書き込みを行わないアカウントを指定することもできます。これは、実行時にプログラム実行のスケジューリングに影響を与えるためですが、これらのアカウントは無視されます。
data は、プログラムに渡される入力として使用される 8 ビット符号なし整数の一般的なベクターです。このフィールドは重要であり、プログラムが実行するエンコードされた命令を含んでいます。
Solana の命令データの形式は不可知です。しかし、bincode と borsh（ハッシュ用のバイナリオブジェクト表現シリアライザー）に対するサポートが組み込まれています。シリアル化は、複雑なデータ構造を転送または保存可能なバイトの系列に変換するプロセスです。データのエンコード方法の選択は、デコードのオーバーヘッドを考慮する必要があります。なぜなら、これらすべてがチェーン上で発生するからです。通常、Borshシリアル化が好まれ、bincodeよりも安定した仕様を持ち、JavaScript 実装があり、通常はより効率的です。
プログラムは、命令の構築を簡素化するために補助関数を使用します。例えば、システムプログラムは SystemInstruction::Assign 命令を構築するための補助関数を提供します：

pub fn assign(pubkey: &Pubkey, owner: &Pubkey) -> Instruction {
    let account_metas = vec![AccountMeta::new(*pubkey, true)];
    Instruction::new(
        system_program::id(),
        &SystemInstruction::Assign { owner: *owner },
        account_metas,
    )
}

この関数は、処理時に指定されたアカウントの所有者を提供された新しい所有者に変更する命令を構築します。
単一の取引には複数の命令を含めることができ、これらの命令は順番に実行され、原子性を持ちます。これは、すべての命令が成功するか、すべてが失敗することを意味します。これにより、命令の順序が重要である可能性があります。プログラムは、潜在的な利用を防ぐために、あらゆる可能性のある命令シーケンスを安全に処理できるように強化される必要があります。
例えば、去初期化中に、プログラムはその lamport 残高をゼロに設定することでアカウントを去初期化しようとするかもしれません。これは、Solana の実行時がそのアカウントを削除することを前提としています。この前提は取引間では有効ですが、命令間やプログラム呼び出しを越えて（後の文章でプログラム呼び出しを紹介します）は無効です。プログラムは、去初期化プロセス中の潜在的な欠陥を強化するために、アカウントのデータを明示的にゼロにする必要があります。そうでないと、攻撃者は後続の命令を発出して、仮定された削除を利用することができます。例えば、取引が完了する前にそのアカウントを再利用することができます。