ブロックチェーンのロールアップという言葉を聞くと、「L2の取引をまとめてL1に書き写している」と思いがちです。
でも実際にL2がL1に渡しているものは、取引そのものではありません。
渡しているのは、状態の結果です。
ここを、会計とGitの比喩で整理しようと思います。
ブロックチェーンの取引ログの他に「状態」も持つ
ブロックチェーンは、取引ログの集まりではなく、
- ある時点の取引ログの結果を状態（state）として持つ
- その状態がどう変わったか
を連続的に確定していく仕組みです。
stateとは、
- 口座残高
- コントラクトの変数
- アカウント情報
をまとめた「帳簿」です。
L2がやっていることを会計の比喩で考える
L2でやっていることは、
- 日々の仕訳を処理し
- 補助元帳を更新し
- 総勘定元帳を締める
ことに近い。
そう考えると、L2がL1に渡しているのは、
「この期間の帳簿の最終状態はこれです」
という**帳簿の指紋（state root）**です。
さらに、
- Optimistic Rollupなら
「仕訳データ全部（圧縮）」＋「異議申し立て可能」 - ZK Rollupなら
「この帳簿更新は正しいという証明書」
が添えられます。
L1は仕訳処理をやり直さない。
帳簿が会計ルールに従って更新されたかどうかだけを保証する。
このときL2とL1は子会社と親会社の経理部のような関係を持ち、
L2 = 子会社の経理部の持つ会計帳簿
L1 = 親会社の経理部の持つ会計帳簿
という構造に近いです。
L2でやっていることをGitの比喩で考える
L2のやっていることをGitで言うなら、
- L2はブランチ上で大量コミット
- L1に渡すのは “差分の結果”
特に近いのは
squashされたcommit + tree hash
です。
L2がやった細かい変更は、
最終的な「状態のハッシュ」に集約される。
L1は
- tree hash（state root）
- その変更のデータ
- または正しさの証明
を受け取るだけ。
中間コミットの詳細を逐一再実行しない。
改めてL2がL1に渡すものは？
整理すると、L2がL1に投稿するのは：
- 取引データ（calldata, 圧縮済）
- 更新後の state root
- （この文章ではあまり触れてないが）正当性を保証する仕組み
- 不正証明可能性（Optimistic）
- 暗号証明（ZK）
です。
L1はそれを自分のブロックに含め合意する。
すると、
「このL2の状態は正しい」と
L1の経済的保証のもとで確定する
ことになります。
ロールアップ時にL2がL1に渡さないもの
L2がL1に渡していないものがあります。
それは、
- L2のブロックそのもの
- L2の全履歴
- L2での合意プロセス
L1はL2を“再実行”しません。
L1は「正しい結果かどうか」だけということです。
L1はL2が持っている全履歴を合意しないということです。
だから、L2がL1に渡すものはL2で締めた会計帳簿の結果のみのようだし、
PRのsquash mergeされたようなものです。
ロールアップとはなにか？
ロールアップとは、
状態遷移を外で行い、
その結果を検証可能な形に圧縮してL1に提出する構造
です。
会計で言えば連結決算。
Gitで言えばsquash merge。
渡しているのは「履歴」である取引ログそのものではなく、
状態の結果なのです。