昨日イーサリアムのブロック構造と合意するアルゴリズム - Qiita でイーサリアムのブロックについて調べましたが、トランザクションと関係ある state_root とか receipts_root とか、分かっないので、今日トランザクション周りを調べてみます。

トランザクションのデータ構成

nonce: トランザクション毎に +1 する数値
gasprice: ガスの単価
gas: ガス制限値
to: 宛先アドレス
value: ETHの値
data: コントラクトに対するトランザクションの場合、呼び出す関数に必要なパラメータ
v: 暗号化周りのデジタル署名関連???
r: 暗号化周りのデジタル署名関連???
s: 暗号化周りのデジタル署名関連???

state_root

イーサリアムがビットコインと違うところですが、アカウント毎の最新情報とそれらに基づいたブロックチェーン全体の最新情報を持っている。詳細の説明は参考記事のほうが詳しいので割愛します。自分の理解ですと、なんか git のデータ構成や仕組みと似ている部分もあったりします。git を理解している方は、より理解し易いかもしれません。

イーサリアム	git
各アカウント情報	リポジトリの各ファイル
各トランザクション	各ファイル差分情報
ブロック	コミット(リポジトリ全体の差分
ワールドステート	変更後の最新ファイル
ブロックチェーン最新のデータ	リポジトリの最後修正した後のデータ

一個前のブロックに各アカウントの残高など全体のステータスを持っているとして、新しいトランザクションがある場合、アカウント A からアカウント B に 10 ETH を送金することを例に上げると
- アカウントAの残高から 10 ETH を減らす　＝＝　git でのファイルAに対して、10 行テキストを削除
- アカウントBの残高に 10 ETH を増やす　＝＝　git でのファイルBに対して、10 行テクストを追加
上記のように、あるブロックにある全てのトランザクション情報を差分として一個前のブロックに適用すれば、ブロックチェーンの最新情報になる
ブロックを生成する側（マイナー）は、上記の処理した後、全アカウントの最新データから要約しハッシュ値を算出する。全アカウントのハッシュ値をマークル木の形にし、最終的に status_root １つのハッシュ値をヘッダー部に格納する
ブロックチェーンから新しいブロックをした側は、上記のハッシュ値とデータの差分から再度算出するハッシュ値を比較して、一致していれば、検証OKになる

参考記事

トランザクションレベルで理解する。イーサリアムの具体的な仕組みを解説
Ethereum入門(4) - スマートコントラクトにおけるトランザクションとブロックを見ていく - Qiita
[Japanese] Ethereum Development Tutorial · ethereum/wiki Wiki