T5 · EVM Account Model

現実の問題

三人のうち二人が同意しないと出金できない、チームの金庫を作ります。

設計会議では「マルチシグウォレットのアドレスで受け取る」と「金庫コントラクトを配備する」という二案が出ます。成果物を外から見ると同じです。どちらも 0x で始まる四十桁の十六進文字列で、資金を受け取れ、エクスプローラーで残高を調べられます。

そこで三つ質問しますが、明快な答えがありません。

• このアドレスは自分から取引を開始できますか。
• このアドレスへの送金は失敗し得ますか。
• このアドレスの規則を変更できるのは誰ですか。

さらに根本的な疑問があります。**配備したコードと、そのコードが覚えているデータはどこに保存されていますか。**データベースのように読み出せますか。

同じ見た目の二つのアドレスは、どこが違うのでしょう。

思考実験

チェーン全体を世界に一台だけのコンピューターと考えます。巨大な表を一つだけ持ちます。

key はアドレス、value は四フィールドです。

nonce         カウンター
balance       残高
codeHash      コードのダイジェスト
storageRoot   このアドレス専用の小さな表のダイジェスト

違いは codeHash が空かどうかに尽きます。

空なら鍵に対応する位置で、所有者が秘密鍵で署名して取引を開始でき、専用の小さな表は常に空です。

空でなければコードと専用の表を持ちます。自分から何も開始できませんが、呼ばれるとコードが実行され、その表を読み書きできます。

ここから三つを導きます。

**第一に、このコンピューターには時計がありません。**cron、タイマー、バックグラウンドスレッドはありません。取引が届き、実行し、状態を変え、次の取引を待つだけです。二つの取引の間は完全に静止します。

第二に、すべての計算に料金が必要です。 各ノードが同じコードを実行し結果を保存します。 各操作に価格があり、最も高いのは小さな表への書き込みです。すべてのノードが永久保存するからです。

**第三に、支払えるのは第一種のアドレスだけです。**コントラクトには秘密鍵がなく署名できません。実行連鎖は必ず秘密鍵を持つ人の取引から始まります。複雑なコントラクトも、その連鎖に動かされます。

冒頭の二案は同一ではありません。表の第三フィールドが違えば、自分で動けるか、入金時にコードが動くか、規則をどこに書くかが変わります。

あなたが決める

預金者へ毎日一回利息を渡す預金コントラクトを、どう実装しますか。

結果を観察する

共通する構造は、すべての状態変化で、秘密鍵を持つ人が取引に署名し、その変化に支払う必要があることです。

ここから一般的な二つの結論が得られます。

**一、誰が払うかは製品設計の問題です。**費用の置き場所が機能の形を決めます。ユーザーの費用をゼロにすれば、自社が負担し、ホットウォレットと運用が必要になります。

二、コントラクトのデータ構造は Gas によって決まります。従来のバックエンドで一行のループでも、全ユーザー走査はここでは失敗する取引です。累積指数、遅延精算、Merkle リストなど、一見奇妙な設計は同じ制約から生まれます。

モデルを作る

一つの表、四つのフィールド：

アドレス → {
  nonce         EOA：送信した取引数；コントラクト：作成したコントラクト数
  balance       wei 単位のネイティブ通貨残高
  codeHash      空 → EOA；非空 → コントラクトアカウント
  storageRoot   このアドレスの storage ツリーのルート
}

二種のアカウントの比較：

最後の二行が金庫の問いの答えです。コントラクトへの送金は失敗し得ることを覚えてください。受取ロジックがなければロールバックされますが、手数料は引かれます（T3）。

storage の構造：

各コントラクトは独立したアドレス空間を持ち、0 から始まる各スロットは 32 バイトです。配置規則は決定的です。

**チェーン上に非公開変数はありません。**Solidity の private は他コントラクトのコードからの読み取りを制限するだけで、チェーン外からスロット番号で読むことは防ぎません。「実例」で大きな損失の例を扱います。

Gas の構造：

取引費用の構成を、高価なものから大まかに並べます。

storage をゼロから非ゼロへ書く     最も高い。全ノードが新たに永久保存する
非ゼロの storage を更新する       高いが、上より明らかに安い
storage を読む                    中程度。同じ取引の二度目はかなり安い
memory で計算する                 安い。取引終了で破棄する
calldata を読む                   最も安い。すでに取引に含まれる
取引の基礎費用 + calldata のバイト料金  コードと無関係の固定部分

実装に直結する三つの推論です。

1. Gas 節約は storage 書き込みの削減が最優先、次が読み取り、最後が計算です。O(n) を O(log n) にするより、一度の書き込みをループ外へ出すほうが効く場合があります。
2. **同じ取引でも、初回のスロットアクセスと後続では価格が大きく違います。**T8 のコールド／ウォームアクセスで、最適化には実測が必要になります。
3. **数字はプロトコル更新で変わるので暗記しません。**相対関係と、eth_estimateGas と実際のレシートで測る習慣を覚えます。

何と呼ぶか

実践

curl -s -X POST <自分の-RPC-アドレス> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode",
       "params":["<あるアドレス>","latest"]}'

curl -s -X POST <自分の-RPC-アドレス> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionCount",
       "params":["<あるコントラクトアドレス>","latest"]}'

curl -s -X POST <自分の-RPC-アドレス> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getStorageAt",
       "params":["<あるトークンコントラクトアドレス>","0x0","latest"]}'

curl -s -X POST <自分の-RPC-アドレス> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
        "to":"<同じトークンコントラクトアドレス>",
        "data":"<totalSupply の四バイトセレクター>"},"latest"]}'

スロット番号 = keccak256( 32バイトへ左ゼロ埋めしたアドレス  ++  32バイトへ左ゼロ埋めした宣言スロット番号 )

curl -s -X POST <自分の-RPC-アドレス> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getStorageAt",
       "params":["<トークンコントラクトアドレス>","<計算したスロット番号>","latest"]}'

AI Lab

第一段階：
この Solidity コードを一回呼ぶ際の Gas を分解してください。
基礎費用、calldata、storage の読み書き、メモリと計算、ログです。
各数値と根拠、合計を示し、どのプロトコル版の価格か明記してください。

第二段階：
同じアドレスからの初回と二回目では、Gas はどれだけ違いますか。
どの項目が違い、なぜですか。

第三段階：
三つの書き換え案を示し、それぞれの節約量と犠牲を説明してください。

curl -s -X POST <自分のテストネット-RPC-アドレス> \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["<ハッシュ>"]}'

実例

変数を一つ変える

持ち帰る問い

章末チェック