Solanaが難しすぎるのでsolscanを読む@自己送金
solanaをpythonで触るのが目標なのですが、難しすぎるので下記記事に触発されて、まずはsolscanを読むことから始めます。
中でもおそらく一番簡単？な気がする自己送金トランザクションを見てみます。
下記記事、とても分かりやすかったです！ありがとうございます！
自己送金する
まずは、自己送金してみます。
phantomウォレットで自分のアドレスに0.1SOL送金を試みると下記の注意が表示されました。
なので、結果もそうなっているはずです。
かまわず送金しました。
結果を解析する
SOL Balance Change
まずはネイティブコイン（SOL）の推移。
登場人物は3名で、FEE PAYERは当然私のウォレットアドレス。
そのアカウントから手数料分だけSOLが減っています。その他は増減なし。
当初の忠告通りです。
また、このトランザクションにかかわるアカウントは3つ、ということになります。
WRITABLE属性も私のアドレスのみ。アカウント内のデータを書き換え可能であることを示す属性。
それぞれのアカウントについて確認しておくと、私のウォレットアドレスのOwnerはSystem Programになっています。
System Programについては、OwnerはNative Loaderになっています。
https://solscan.io/account/11111111111111111111111111111111
Compute BudgetのOwnerもNative Loaderですね。
https://solscan.io/account/ComputeBudget111111111111111111111111111111
じゃあNative Loaderって誰だ？ってなるんですが、そこにOwnerの情報はありませんでした。
https://solscan.io/account/NativeLoader1111111111111111111111111111111
Native Loaderは、solana上にプログラムをデプロイするためのプログラムの内の1つであって、現在の一般的なプログラムデプロイでは使用されないようです。
プログラムデプロイの方法（合計3つある）
1.BPF Loader (BPFLoader1111111111111111111111111111111111)
レガシーなBPFプログラムのデプロイ
アップグレード不可
現在はほぼ使われない
2.Upgradeable BPF Loader (BPFLoaderUpgradeab1e11111111111111111111111)
現在の標準的なデプロイ方法
プログラムのアップグレードが可能
通常のSolanaプログラムはこれを使う
3.Native Loader
BPF以外のネイティブプログラムのデプロイに使用
Solanaのシステムプログラムの一部
一般的なプログラムデプロイでは使用しない
System ProgramやCompute Budget ProgramはSolanaのコア部分に組み込まれているシステムプログラムなのでNative Loaderを使ってデプロイされる。
Native LoaderはSolanaのネイティブ（組み込み）プログラムをロードするための特別なローダーで、一般的なSolanaプログラム（スマートコントラクト）はBPF LoaderやUpgradable BPF Loaderを使ってデプロイされる。
System ProgramやCompute Budget ProgramはSolanaのカーネルレベルで直接動作するネイティブコードで、直接Solanaのランタイムに統合されているため、BPFプログラムのように外部からデプロイするものではない。
BPFプログラムは、開発者がSolana上にデプロイするスマートコントラクトで、一方System ProgramやCompute Budget ProgramはSolanaの基本機能を提供するためBPFの仕組みを使う必要がなくNative Loaderで直接管理されている。
System Program：
アカウント作成、SOLの送金、プログラムのデプロイなど基本的なトランザクション処理を担当
Compute Budget Program：
トランザクションの計算コストを管理
Token Balance Change
Token Program内でトランザクションにかかわったアカウント。
無しです。つまり、Token Programはこのトランザクションには関係なかったということでしょうか。
header@overview
Feeについて、基本手数料の0.000005SOLにPriority Feeの0.00015SOLが上乗せ（CPU使用量に応じて加算）されています。
System ProgramのTransferを呼び出して、自身のウォレットから自身のウォレットに0.1SOL移動。Interact withはユーザーが直接呼び出したProgram。
instruction Details@overview
#1～#3はこのトランザクションが直接呼び出したInstructionが3つあるという意味（1つのトランザクションの中に複数個のInstructionを含めることができる）。
#1について
1ComputeUnit当たりの上乗せ料金を300lamportsに設定している。
ComputeBudgetのコードを見ると、
つまり、最初の2文字（03）でSetComputeUnitPriceを選択している。
ちなみに、
00→Unused
01→RequestHeapFrame
02→SetComputeUnitLimit
04→SetLoadedAccountsDataSizeLimit
そして、SetComputeUnitPriceを見るとu64とあるので、64bitつまり8バイトの文字列で表すことになる。
ここで残りの文字列を見ると（00a3e11100000000）の16文字なので16進数表記2文字で1バイトと考えれば（00, a3, e1, 11, 00, 00, 00, 00）の8バイトになっていることが分かる。
リトルエンディアンで解釈して（数値のバイト列を下位バイトから上位バイトの順に並べる方式）、
（00, 00, 00, 00, 11, e1, a3, 00）つまり（0000000011e1a300）として、
10進数に変換すると
この単位がmicrolamportsなので300lamportsとなる。
※単位についてはコードに言及あり。
次に、
#2について、
どの程度のComputeUnitを使用するかを指定している（500 compute unitsらしい）。
まずは、02なのでSetComputeUnitLimitを意味する。
そしてu32なので4バイト（f4, 01, 00, 00）。
リトルエンディアンで解釈して（000001f4）。
10進数に直すと、500。
#1, #2を通して、
500ComputeUnits対して、1ComputeUnit当たり300lamportsの追加料金を指定しているので、500×300で150000lamportsとなる。
つまり、0.00015SOL（1SOL = 10の9乗lamports）。
headerのところで見た、0.000005SOL（基本料金）に対する上乗せ額0.00015SOLと一致する。
#3について。
ソースコードを見ると、下記のように関数定義されている。
深く突っ込みだすとここでは終わらないと思いますが、本トランザクションに関してはある程度解釈できたのでここまでとします。