Solanaの「Hello Solana」チュートリアルを進めながらSolanaの基礎を理解しよう！

マクロとは、プログラミング言語において、コードの一部を自動的に生成したり、繰り返し利用するための仕組みのことを指します。
マクロを利用することで、開発者はより少ないコードでより多くの作業を自動化し、繰り返しや共通のパターンを簡単に実装できるようになります。
マクロは、コンパイル時に展開され、プログラムに組み込まれるコードの一部となります。

Rust言語におけるマクロは非常に強力で、プログラムの書き方を大きく効率化することができます。例えば、Rustのprintln!やvec!などの関数はマクロです。
これらはコンパイル時に特定のコードに展開され、それによってプログラムの実行時の挙動が決定されます。

マクロは以下のような場合に特に有用です。

• コードの繰り返しを避ける
  • 同じコードパターンが複数の場所で必要な場合、マクロを使ってそのパターンを一箇所に定義し、必要な場所で繰り返し使用できます。
• 抽象化と再利用性の向上
  • 共通の機能をマクロとして定義することで、異なるコンテキストで簡単に再利用することができます。
• 条件付きコンパイル
  • 特定の条件下でのみコードを含めたり除外したりする場合、マクロを利用してコンパイル時の条件分岐を行うことができます。

Rustのマクロは強力ですが適切に使用することが重要です。
マクロの乱用はコードの可読性を下げる可能性があるため、必要な場合にのみ使用することが推奨されます。

「クレート（crate）」とは、コードのパッケージ、またはライブラリのことを指します。
Rustのプロジェクトは1つ以上のクレートで構成され、これらクレートはコンパイルされると実行可能ファイルやライブラリとなります。
クレートはRustのモジュールシステムの最上位に位置し、プロジェクトのビルド、配布、依存関係の管理における基本的な単位となります。

クレートには大きく分けて二つのタイプがあります。

1. バイナリクレート（Binary Crate）
   • 実行可能ファイルを生成するクレートです。
   • プログラムのエントリポイント（main関数）を含み、単独で実行することを目的としています。
   • プロジェクトには通常、一つのバイナリクレートが存在します。
2. ライブラリクレート（Library Crate）
   • 再利用可能なコードを提供するクレートで、他のプログラムやライブラリによって利用されることを意図しています。
   • ライブラリクレートは、関数、型、トレイトなどを提供し、これらを他のクレートから利用できるようにすることで、コードの再利用性を高めます。

クレートタイプ

Cargo.tomlファイルにおいて、クレートタイプは以下のように指定されることがあります。

• cdylib
  • ダイナミックリンクライブラリ（.so, .dll, .dylibなど）を生成する。
  • これは、他の言語の実行可能ファイルやアプリケーションからRustのコードを呼び出すために使われることがあります。
• rlib
  • Rustのライブラリクレートをコンパイルするための標準フォーマット。
  • 他のRustのクレートとリンクする際に使用されます。

依存関係管理

クレートはCargo（Rustのパッケージマネージャーとビルドシステム）によって管理され、Cargo.tomlファイルに記述された情報に基づき、依存関係の解決、ビルド、テスト、ドキュメント生成などが行われます。
Cargoは、プロジェクトの依存関係を自動的にダウンロードし、コンパイルするため、開発者は依存関係管理にかかる手間を大幅に削減できます。

クレートはRustのエコシステムにおいて中心的な役割を果たし、コードのモジュール性、再利用性、共有を促進します。
Rustの公式パッケージレジストリであるcrates.ioでは、さまざまなクレートが公開されており、開発者はこれらを自由に利用することができます。

参考

https://doc.rust-jp.rs/book-ja/ch07-01-packages-and-crates.html

cdylibは、Rustでコンパイルされるクレートタイプの1つで、C言語の動的リンクライブラリ（DLL）として利用可能なバイナリを生成します。
このタイプのクレートは、Rustで書かれたライブラリをC言語や他の言語から呼び出すために使用されることが多いです。

cdylibの特徴と用途

• 互換性
  • 生成された動的リンクライブラリは、C言語のABI（Application Binary Interface）に準拠しているため、C言語を含む多くのプログラミング言語から利用することができます。
• プラットフォーム間での共有
  • .so（Linux）、.dll（Windows）、.dylib（macOS）など、様々なプラットフォームでサポートされる形式でライブラリを提供できます。
• アプリケーションとの統合
  • Rustで書かれたコンポーネントやライブラリを、既存のC言語や他の言語で書かれたアプリケーションに統合する際に便利です。

cdylibの利用シナリオ

• 外部アプリケーションのプラグイン
  • Rustで安全かつ効率的なプラグインや拡張機能を開発し、それを既存のアプリケーションに動的にロードして使用する。
• 既存のシステムへの統合
  • Rustの強力な型システムとパフォーマンスの利点を活用して、特定の処理を実装し、それをC言語などで書かれた既存のシステムに組み込む。
• 言語間の橋渡し
  • Rustで高性能なライブラリを開発し、PythonやRubyなどの他の言語から呼び出すことで、アプリケーション全体のパフォーマンスを向上させる。

cdylibタイプのクレートを使用する際は、Cargo.tomlファイルに以下のように指定します。

[lib]
crate-type = ["cdylib"]

この設定により、Cargoはクレートをコンパイルする際にC言語互換の動的リンクライブラリを生成します。
これにより、Rustで書かれたライブラリが他の言語からより容易に利用できるようになります。

このコードは、Solanaブロックチェーン上で動作するRust言語のスマートコントラクト（またはプログラム）の基本的な骨組みを示しています。
具体的には、Solanaプログラムのエントリポイント（ブロックチェーンからプログラムが呼び出されたときに最初に実行される関数）の定義方法を示しています。

エントリポイントの定義

• #[cfg(not(feature = "no-entrypoint"))]
  • この属性（attribute）は、Cargoの機能フラグを使って、特定の条件下でのみモジュールをコンパイルするかを制御します。
  • ここでは、no-entrypointというフィーチャーが有効になっていない場合にのみ、以下のentrypointモジュールがコンパイルされるように指定しています。
  • これは、テストや他のコンテキストでエントリポイントが不要な場合に、そのコードを除外するために使われます。
• pub mod entrypoint { ... }
  • entrypointという公開モジュールを定義しています。
  • このモジュール内で、プログラムのエントリポイントとなる関数やロジックを定義します。

Solanaプログラムライブラリの使用

• use solana_program::{...};
  • Solanaプログラム開発に必要な型や関数をsolana_programクレートからインポートしています。
  • ここでインポートされているのはAccountInfo、entrypointマクロ、ProgramResult、そしてPubkeyです。

エントリポイント関数のセットアップ

• entrypoint!(process_instruction);
  • entrypoint!マクロを使用して、process_instruction関数をプログラムのエントリポイントとして登録しています。
  • これにより、Solanaランタイムはプログラムが呼び出された際にこの関数を実行するようになります。

エントリポイント関数

• pub fn process_instruction(...)
  • 実際のプログラムロジックを含むエントリポイント関数です。
  • この関数は、プログラムID、アカウント情報のリスト、および指示データを引数として受け取ります。
  • program_id: &Pubkey
    • このプログラムの公開鍵（ID）です。
  • accounts: &[AccountInfo]
    • トランザクションに関連するアカウントの情報を含むリストです。
  • instruction_data: &[u8]
    • このトランザクションに対する指示（またはコマンド）をエンコードしたデータです。
• -> ProgramResult
  • この関数は、ProgramResultを返します。
  • ProgramResultはResult<(), ProgramError>のエイリアスで、プログラムの実行が成功したか、あるいは何らかのエラーが発生したかを示します。

実装するべきロジック

• todo!()
  • この部分には、実際にトランザクションを処理するためのコードを記述します。
  • 現在はtodo!()マクロが置かれており、この部分の実装がまだ完了していないことを示しています。

このコードスニペットは、Solanaプログラムの基本的な構造を示しており、プログラム開発者この骨組みをベースとして、具体的なビジネスロジックやトランザクション処理ロジックを実装していきます。

Cargo.tomlファイルは、Rustプロジェクトの設定ファイルで、プロジェクトのビルドシステムとパッケージマネージャであるCargoによって使用されます。
このファイルには、プロジェクトのメタデータ（名前、バージョン、作者など）、依存関係、ビルドの設定など、プロジェクトに関する様々な情報が含まれています。
Cargo.tomlファイルの構造はTOML（Tom's Obvious, Minimal Language）形式で記述されており、読みやすく、編集しやすいのが特徴です。

主なセクション

• [package]
  • このセクションには、プロジェクトの名前、バージョン、作者、ライセンス情報など、プロジェクトのメタデータが含まれます。
  • これらの情報は、crates.ioなどのパッケージレジストリにプロジェクトを公開する際に重要になります。
• [dependencies]
  • プロジェクトが依存する外部クレート（ライブラリやフレームワーク）を指定します。
  • 各依存関係はクレート名とバージョン番号で指定され、Cargoはこれらの情報をもとに依存クレートをダウンロードし、プロジェクトのビルド時にリンクします。
• [dev-dependencies]
  • テストや例のコードなど、開発時にのみ必要な依存関係を指定します。
  • これらの依存関係は、プロジェクトの本番ビルドには含まれません。
• [build-dependencies]
  • ビルドスクリプトの実行に必要な依存関係を指定します。
  • ビルドスクリプトは、プロジェクトがコンパイルされる前に実行されるコードで、通常はプロジェクトのビルド環境を構成するために使用されます。
• [lib]
  • ライブラリクレートの設定を行います。
  • 例えば、クレートタイプ（crate-type）を指定することができ、これはクレートがライブラリとしてどのようにビルドされるか（例: cdylib, rlibなど）を制御します。
• [features]
  • Cargoのフィーチャー機能を使って、オプショナルな機能や構成を定義することができます。
  • これにより、特定の機能を有効にしたり、コンパイル時にコードの一部をオプションとして扱ったりすることが可能になります。

例

[package]
name = "my_crate"
version = "0.1.0"
authors = ["Author Name <author@example.com>"]
edition = "2018"

[dependencies]
serde = "1.0"

[dev-dependencies]
tokio = "0.2"

[build-dependencies]
cc = "1.0"

[lib]
crate-type = ["cdylib", "rlib"]

[features]
default = []

この例では、プロジェクトの基本的なメタデータ、いくつかの依存関係、ライブラリクレートのタイプ、そして空のデフォルトフィーチャーが定義されています。

Cargo.tomlファイルはプロジェクトの根幹をなす部分であり、プロジェクトのビルドや管理において中心的な役

割を果たします。

Cargoのfeatures機能は、Rustプロジェクトで条件付きのコンパイルやオプショナルな機能の管理を行うために使われます。
これにより、開発者はプロジェクトの特定の部分を有効化したり無効化したりすることができ、異なる構成や機能セットでコードをコンパイルする柔軟性を持たせることが可能です。

基本的な概念

• 機能の定義
  • Cargo.tomlファイルの[features]セクションで、プロジェクトの機能（features）を定義します。
  • 各機能は名前と、その機能が有効化されたときに含まれる依存関係や他の機能のリストを持ちます。
• デフォルト機能
  • defaultという特別な機能名があり、これはプロジェクトが依存された時にデフォルトで有効化される機能のリストを指定します。
  • 開発者は、ユーザーが特に指定しない限り常に有効になるべき機能をdefaultに含めることができます。
• オプショナル依存関係
  • 依存関係は、特定の機能と関連付けられることがあり、その機能が有効化されているときにのみコンパイルに含まれます。

使用例

Cargo.tomlにおける機能の定義例です。

[features]
# オプショナルな機能 "gui" を定義
gui = ["serde/json", "tokio"]

# デフォルトで有効化される機能のリスト
default = ["cli"]

この例では、guiとcliという二つの機能が定義されています。
gui機能は、serdeのjsonフィーチャーとtokioクレートが有効化されるときに含まれます。
default機能はcliを含んでいますが、このcli機能が何を指すかは示されていません。
実際には、プロジェクト内のコードで#[cfg(feature = "cli")]のような条件付きコンパイルを使って、cli機能が有効な場合にのみコンパイルされるコードを指定できます。

コンパイル時の機能の指定

Cargoコマンドラインツールを使用して、特定の機能を有効化または無効化することができます。
例えば、cargo build --features "gui"コマンドを実行すると、gui機能が有効化されてビルドが行われます。

featuresによって、プロジェクトの異なるユーザーや使用状況に合わせて、コードベースを柔軟に管理することが可能になります。
例えば、いくつかの機能を実験的に提供したり、特定の環境に特化した機能を提供したりする場合に有効です。

rbpf VM（Rust-based Berkeley Packet Filter Virtual Machine）は、eBPF（extended Berkeley Packet Filter）の命令セットに基づいた、Rustで実装された仮想マシンです。
eBPFはもともとLinuxカーネルでパケットフィルタリングなどの目的で使用される技術で、高度なデータパケット処理やシステムコールのフィルタリング、パフォーマンスモニタリングなどに利用されます。
eBPFは高い柔軟性とパフォーマンスを提供するため、近年ではさまざまな用途での応用が進んでいます。

rbpf VMは、このeBPFを基盤としながら、Solanaブロックチェーンプラットフォームでの使用に特化しています。
Solanaでは、スマートコントラクトやプログラムがrbpf VM上で実行され、ブロックチェーン上でのトランザクション処理やアカウント管理などを効率的に行うことができます。

rbpf VMの主な特徴

• 高性能
  • rbpf VMは高速な実行速度を実現しており、Solanaのような高トランザクション速度を必要とするブロックチェーンプラットフォームに適しています。
• 安全性
  • eBPFの設計はセキュリティを重視しており、不正なメモリアクセスや無限ループなどのリスクを最小限に抑える機能が備わっています。
  • rbpf VMもこれらの安全性の高い特性を継承しています。
• 柔軟性
  • eBPF命令セットは高度なプログラミングが可能で、複雑なビジネスロジックやデータ処理が実装できます。
  • これにより、Solana上で実行されるプログラムは、多様な機能やサービスを提供することが可能です。
• プログラムの独立性
  • rbpf VM上で実行されるプログラムは、他のプログラムやシステムのリソースと隔離されて動作します。
  • これにより、プログラム間の干渉を防ぎ、安定した実行環境を確保しています。

Solanaプラットフォームでは、rbpf VMを通じてスマートコントラクトや各種プログラムが効率的かつ安全に実行されることで、高速なトランザクション処理と柔軟なブロックチェーンアプリケーションの開発が実現しています。
これにより、Solanaは分散型アプリケーション（dApps）や金融サービス、その他多くのブロックチェーンベースのソリューションの開発において、重要な役割を果たしています。

ed25519は、デジタル署名に使用される公開鍵暗号アルゴリズムの1つです。
高速な署名生成と検証、高いセキュリティレベル、および耐衝撃性（collision resistance）を特徴としています。
ed25519は、Elliptic Curve Digital Signature Algorithm（ECDSA）の一種であり、Edwards-curve Digital Signature Algorithm（EdDSA）の特定の実装を指します。
このアルゴリズムは、Curve25519という楕円曲線上で動作し、特に高速な演算が可能で、さまざまなセキュリティ脅威に対して堅牢です。

主な特徴

• セキュリティ
  • ed25519は128ビットのセキュリティレベルを提供します。
  • これは、現代のコンピュータ技術を使っても、十分な時間内に鍵を破ることが不可能であると考えられているレベルです。
• 高速な署名と検証
  • ed25519は、署名の生成と検証が非常に高速です。
  • これにより、リソースが限られている環境や、大量の署名を扱う必要がある場合でも効率的に使用できます。
• 耐衝撃性
  • ed25519は耐衝撃性に優れており、同じ鍵で異なるメッセージに対して同じ署名が生成されるリスクが非常に低いです。
• 短い鍵と署名
  • ed25519の公開鍵は256ビット（32バイト）、署名は512ビット（64バイト）と、非常に短いです。
  • これにより、通信のオーバーヘッドを最小限に抑えることができます。

用途

ed25519は、SSH認証、TLS、暗号通貨（例：Solana、Bitcoin）など、セキュリティが要求される幅広い分野で使用されています。
特に、ブロックチェーン技術においては、トランザクションの署名やウォレットアドレスの生成などに利用されることが多いです。

Solanaとed25519

Solanaブロックチェーンでは、アカウントの識別やトランザクションの署名にed25519公開鍵を使用します。
これにより、トランザクションの安全性を保ちながら、高速な処理を実現しています。
Solanaでは、アカウントアドレスはed25519公開鍵から導出され、対応する秘密鍵によって管理されます。
これにより、ユーザーは自分の資産やデータに対するコントロールを安全に行うことができます。

Solanaブロックチェーンでプログラム間の相互作用を行うためのメカニズム、「クロスプログラム呼び出し（Cross-Program Invocation、CPI）」について説明します。
CPIを利用することで、あるプログラムが別のプログラムの命令を実行できるようになります。
これにより、複数のプログラムが連携してより複雑な操作を実現できるようになります。

CPIの基本的な流れ

1. 命令の準備
   • あるプログラムが、別のプログラムによって実行される命令（例：トークンの支払い、トークンの送付など）を準備します。
2. invoke関数の使用
   • 呼び出し元のプログラムは、invokeまたはinvoke_signed関数を使用して、準備した命令を呼び出します。
     この関数はSolanaのランタイムに組み込まれており、指定された命令を該当するプログラムIDにルーティングします。
3. アカウントの検証
   • 呼び出し元のプログラムが命令を実行する時、Solanaランタイムは、該当する命令に必要なすべてのアカウントが正しく提供されていることを確認します。
   • これは、命令が実行可能なプログラム（executable account）を除くすべての関連アカウントを呼び出し元が提供する必要があるためです。

セキュリティと整合性の確保

• Solanaランタイムは、命令実行前と実行後のアカウントの状態を比較し、プログラムが他のプログラムが所有するアカウントを不正に変更していないことを保証します。
• これにより、プログラム間で安全にデータや資産のやり取りが行えるようになります。

CPIの使用例

• 支払いとアクションの組み合わせ
  • あるクライアントが、アリスからのトークン支払いとボブへのミサイル発射という2つのアクションを組み合わせたトランザクションを作成する場合、acmeプログラムはクライアントに代わってtokenプログラムのpay()命令を呼び出すことができます。
  • これにより、複数のプログラムが連携して一連の操作を行うことが可能になります。

CPIは、Solanaプラットフォームにおけるプログラムの柔軟性と機能性を大きく拡張する重要なメカニズムです。
これにより、開発者は異なるプログラムの機能を組み合わせて、より複雑なアプリケーションやサービスを構築できるようになります。

let message = Message::new(vec![
    token_instruction::pay(&alice_pubkey),
    acme_instruction::launch_missiles(&bob_pubkey),
]);
client.send_and_confirm_message(&[&alice_keypair, &bob_keypair], &message);

このコードは、Solanaブロックチェーン上でクライアントがトランザクションを作成し、そのトランザクションをネットワークに送信するプロセスを示しています。
トランザクションは、特定の命令（instructions）を含むメッセージ（Message）で構成され、これらの命令はブロックチェーン上で実行されるアクションを定義します。
具体的に、この例では2つの異なるプログラムへの命令が含まれています。

1. token_instruction::pay(&alice_pubkey)
   • この命令は、トークンプログラム（token_instruction）を使用して、アリスの公開鍵（alice_pubkey）に対して支払いを行います。
   • 具体的に何をするか（例えば、どの量のトークンを転送するか）は、pay関数の実装に依存しますが、一般的には、アリスにトークンを送る操作を指します。
2. acme_instruction::launch_missiles(&bob_pubkey)
   • こちらは、acme_instructionプログラムを使用して、ボブの公開鍵（bob_pubkey）に関連する何らかのアクション（この例では象徴的に「launch_missiles」とされています）を行う命令です。
   • この命令の具体的な挙動も、launch_missiles関数の実装によります。

これらの命令はMessage::new関数を通じてメッセージオブジェクトにまとめられ、その後client.send_and_confirm_message関数によってSolanaネットワークに送信されます。
この関数は、トランザクションをネットワークに送信し、その実行が確認されるまで待機します。
トランザクションに署名するためには、関連するアカウントの秘密鍵が必要であり、この例ではアリスとボブのキーペア（alice_keypair、bob_keypair）が使用されています。

このコードは、Solanaプラットフォームで複数のプログラムに対する操作を一つのトランザクションで実行する方法を示しており、ブロックチェーン上で複雑なアクションのシーケンスを効率的に実行する能力を示唆しています。

let message = Message::new(vec![
    acme_instruction::pay_and_launch_missiles(&alice_pubkey, &bob_pubkey),
]);
client.send_and_confirm_message(&[&alice_keypair, &bob_keypair], &message);

このコードは、Solanaブロックチェーン上で、特定のプログラム（ここでは架空のacme_instructionプログラム）が提供する複合的な操作を実行するためのクライアント側の命令を示しています。
具体的には、acme_instructionプログラム内で定義されたpay_and_launch_missiles関数を呼び出し、それによってアリスからボブへの支払いと「launch_missiles」という二つの操作を一つのトランザクション内で実行します。

コードの詳細

• メッセージの作成
  • Message::new関数を用いて、実行したい命令（インストラクション）を含む新しいメッセージオブジェクトを作成します。
  • ここでは、acme_instruction::pay_and_launch_missiles関数を呼び出し、その引数としてアリスとボブの公開鍵（alice_pubkeyとbob_pubkey）を渡しています。
  • この命令は、アリスからボブへの支払いと、何らかのアクションを一緒に行うことを意図しています。
• トランザクションの送信と確認
  • client.send_and_confirm_message関数によって、作成したメッセージ（トランザクション）をSolanaネットワークに送信し、その処理が完了するまで待機します。
  • トランザクションには署名が必要であり、この例ではアリスとボブのキーペア（alice_keypair、bob_keypair）が署名者として使用されています。

このコードの意義

このコードは、Solanaプラットフォームのクロスプログラム呼び出し（CPI）を活用して、一つのトランザクション内で複数の異なる操作を連携させる方法を示しています。
pay_and_launch_missilesのような複合的な関数をプログラム内に定義することで、複数のステップを含むビジネスロジックを効率的に実装できます。
これにより、アプリケーションはより高度な機能を、ユーザーに対して透明で簡単な方法で提供することが可能になります。

このアプローチは、特に分散型金融（DeFi）アプリケーションや、複数の異なる条件下で特定のアクションを自動的にトリガーする必要があるシナリオで有用です。
Solanaの高速なトランザクション処理能力と組み合わせることで、複雑な操作も迅速に実行できます。

mod acme {
  use token_instruction;

  fn launch_missiles(accounts: &[AccountInfo]) -> Result<()> {
      ...
  }

  fn pay_and_launch_missiles(accounts: &[AccountInfo]) -> Result<()> {
      let alice_pubkey = accounts[1].key;
      let instruction = token_instruction::pay(&alice_pubkey);
      invoke(&instruction, accounts)?;

      launch_missiles(accounts)?;
  }

上記のコードは、Solanaブロックチェーンのプログラム開発におけるモジュールと関数の例を示しています。
ここでは、acmeという名前のモジュール内で、token_instructionを使用してトークンの支払いを行い、その後特定のアクションを実行する2つの関数が定義されています。

コードの概要

• モジュール定義
  • mod acmeは、acmeという名前のモジュールを定義しています。
  • このモジュール内で、特定の操作を行うための関数が定義されています。
• 外部モジュールの使用
  • use token_instruction;は、token_instructionモジュール（またはクレート）からの関数や構造体を現在のスコープに導入しています。
  • これにより、token_instruction::payなどの関数を直接呼び出すことができます。

関数の説明

• launch_missiles関数
  • 特定のアクションを象徴する関数です。
  • 実際に何をするかは、...（省略された部分）に具体的な実装が含まれることになります。
  • この関数は、アカウント情報の配列を受け取り、Result<()>型を返します。
• pay_and_launch_missiles関数
  • この関数は、トークンの支払いと「launch_missiles」という2つのアクションを連続して実行します。
  • 具体的には、次のステップを含みます。
    • アカウント情報の配列からAliceの公開鍵を取得します。
    • token_instruction::pay関数を使用して、支払い命令を作成します。この命令は、Aliceに対してトークンを支払うものです。
    • invoke関数を呼び出して、支払い命令を実行します。この命令が成功した場合、次のステップに進みます。
    • launch_missiles関数を呼び出して、「launch_missiles」というアクションを実行します。

CPI（クロスプログラム呼び出し）の使用

このコード例は、Solanaのクロスプログラム呼び出し（CPI）の概念を示しています。
invoke関数は、他のプログラム（この例ではtoken_instructionによって定義されたプログラム）の命令を現在のプログラムから実行するために使用されます。
CPIを使用することで、プログラムは他のプログラムの機能を組み合わせて複雑な操作を行うことができます。

権限が必要な命令

Solanaランタイムがプログラム間の呼び出し（クロスプログラム呼び出し、CPI）で特定の権限をどのように扱うかについて説明します。
ここでの「権限」とは、特に署名者（signers）と書き込み可能（writable）なアカウントを指します。

権限の拡張

Solanaでは、あるプログラム（呼び出し元）が別のプログラム（呼び出し先）を呼び出す時、呼び出し元プログラムに付与された権限を基に、呼び出し先プログラムにどの権限を拡張できるかをランタイムが決定します。
例えば、呼び出し元プログラムが処理中の命令に署名者や書き込み可能なアカウントが含まれている場合、その署名者やアカウントを含む命令を呼び出し先プログラムに対して発行することができます。

この権限の拡張は、プログラムが不変であるという事実に依存しています。
プログラムのアップグレードという特別なケースを除いて、プログラムのコードは変更されません。

実際の例：acmeプログラム

acmeプログラムの例では、ランタイムはトランザクションの署名を、トークン命令の署名として安全に扱うことができます。
ランタイムがアリスの公開鍵（alice_pubkey）を参照するトークン命令を見た場合、それがacme命令内で署名済みのアカウントに対応するキーであるかどうかを確認します。
この場合、該当するキーが署名済みのアカウントであれば、ランタイムはトークンプログラムがアリスのアカウントを変更することを認可します。

このプロセスにより、Solanaはプログラム間のセキュアな相互作用を実現し、あるプログラムが持つ権限を別のプログラムに安全に「委譲」することが可能になります。
これによって、複雑なアプリケーションロジックや資産の移動など、様々な操作を効率的かつ安全に行うことができるようになります。

プログラム署名済みアカウント

Solanaプログラムがプログラム派生アドレス（Program Derived Addresses、PDAs）を使用して、元のトランザクションで署名されていないアカウントを含む命令を発行する方法について述べています。
PDAsを使用することで、プログラムは自身が「署名者」として機能し、特定のアカウントへの変更を承認することができます。

プログラム派生アドレス（PDAs）

• PDAsは、特定のプログラムに紐づいているが、対応する秘密鍵を持たない特殊なアドレスです。
  • これらは、プログラム自体やその他のパラメータ（シードとしての文字列など）から決定論的に生成されます。
• PDAsを使用することで、プログラムはトランザクションに直接署名することなく、特定の操作を承認することができます。

invoke_signed関数

• invoke_signed関数は、他のプログラムの命令を呼び出し、その命令に含まれるアカウントをプログラムが「署名」することを可能にします。
  • これにより、PDAが「署名者」として機能することができます。
• この関数の引数には、実行する命令、命令に関連するアカウントのリスト、そしてPDAを生成するために使用されるシードのリストが含まれます。

使用例

• 上記のコード例では、invoke_signed関数を使って、ある命令を発行しています。
  • この命令では、PDAsを「署名者」として使用しているため、命令に含まれるアカウントに対する操作が承認されます。
• シードのリスト（&["First addresses seed"]、&["Second addresses first seed", "Second addresses second seed"]）は、PDAsの生成に使用されるシードの情報を提供します。
  • これにより、ランタイムは提供されたアカウントがPDAsによって正しく「署名」されていることを検証できます。

PDAsとinvoke_signed関数を使用することで、Solanaのプログラムは他のプログラムの命令を安全に呼び出し、特定のアカウントに対する操作を承認することができます。
これにより、プログラムは自身の秘密鍵を公開することなく、トランザクションの一部としてアカウントに署名する能力を持つことができます。

Callの深さ

クロスプログラム呼び出し（Cross-program invocations、CPI）は、Solanaのプログラムが他のプログラムを直接呼び出すことを可能にします。
これにより、プログラム間で機能を共有したり、複合的な操作を実行することができます。
ただし、現在Solanaでは、このような呼び出しの深さ（call depth）には制約があり、最大4レベルまでとなっています。

呼び出しの深さとは

呼び出しの深さとは、あるプログラムから別のプログラムを呼び出し、さらにそのプログラムが他のプログラムを呼び出す、という連鎖が何層にもわたって続くことを指します。
例えば、プログラムAがプログラムBを呼び出し、プログラムBがプログラムCを呼び出す場合、この呼び出しの深さは2となります。

制約の意義

Solanaにおける呼び出しの深さの制約（現在は4レベル）は、システムの安定性とセキュリティを確保するために設けられています。
無制限にプログラム呼び出しができると、無限ループや予期しない複雑な相互作用が発生し、システムのパフォーマンスに悪影響を与えたり、セキュリティ上の脆弱性が生じる可能性があります。
また、計算リソースの消費を適切に管理するためにも、このような制約が必要です。

実践への影響

この制約は、Solanaプログラムを設計する時に考慮すべき重要な点です。
プログラムが他のプログラムを呼び出す際には、この深さの限界を超えないように計画を立てる必要があります。
複雑な操作を実現するために多くのプログラムの連携が必要な場合は、この制約を考慮して設計を行うか、呼び出しの構造を工夫する必要があります。

リリエントランシー

再帰性（Reentrancy）とは、プログラムが実行中に自身を再度呼び出すことを指します。
Solanaにおいて、再帰性は直接的な自己再帰に限定されており、その深さは固定された値で上限が設けられています。
この制限は、プログラムが中間状態から別のプログラムを呼び出した後、予期せずに再度そのプログラム自体が呼び出される状況を防ぐために設けられています。

再帰性の制限の目的

• 状態管理の明確化
  • 直接的な自己再帰により、プログラムは自身が再度呼び出された時点での状態を完全にコントロールできます。
    これにより、プログラムの状態が予期せずに変更されることを防ぎ、より安定した実行が可能になります。
• セキュリティと安定性の向上
  • 中間状態からの再帰的な呼び出しを制限することで、予期しない動作やセキュリティリスク（例えば、再帰による無限ループなど）を最小限に抑えます。
    これにより、プログラム全体の安定性と信頼性が向上します。

実践への影響

この制限は、プログラムの設計と開発において重要な考慮事項です。
特に、プログラムが自身の処理の一部として再帰的な動作を必要とする場合、直接的な自己再帰のみが許可されていること、およびその深さに上限があることを意識する必要があります。
開発者は、これらの制約のもとで効率的かつ安全に動作するプログラムを設計するために、再帰の使用を慎重に計画する必要があります。

Solanaのこのような設計は、プログラムの振る舞いをより予測可能にし、複雑な相互作用が生じるリスクを軽減することを目的としています。
これにより、開発者はプログラムの正確な実行フローをより確実に管理できるようになります。