見出し画像

【技術者向けテックノート01】 ブロックチェーンでは何が動くのか

Meridian House

ステーブルコインやトークン化預金を実装するには、「ブロックチェーンに記録される」という説明だけでは足りません。署名された取引がどこへ送られ、どの段階で確定し、いつ金融業務として完了するのかを、EVM系ブロックチェーンを主なモデルとして、トランザクションの生成からL1・L2のファイナリティ、監視・照合までを一つの処理として解剖します。
対象範囲
本稿はEthereumおよびEVM互換チェーンを主なモデルとして説明します。Canton、Hyperledger Fabricなど、実行・合意モデルが異なる基盤には、そのまま当てはまらない部分があります。各チェーンの詳細は別の章で解説します。

ステーブルコインを送る。
トークン化預金を発行する。
スマートコントラクトを実行する。
こうした処理は、しばしば「ブロックチェーンに記録される」という一言で説明されます。しかし、実際のシステムを設計しようとすると、それだけでは足りません。
ウォレットで署名された取引は、どこへ送られるのでしょうか。ノードは何をしているのでしょうか。トランザクションハッシュが返ってきた時点で、支払いは完了したのでしょうか。L2で「成功」と表示された取引は、L1でも確定しているのでしょうか。
取引を送信した ≠ ブロックに取り込まれた ≠ 技術的に確定した ≠ 金融業務として完了した


1．最初に結論

ブロックチェーン上の取引は、概ね次の順番で処理されます。
取引データを作る
      ↓
秘密鍵で署名する
      ↓
RPCを通じてノードへ送る
      ↓
ノードが取引を受け付ける
      ↓
ブロック生成者またはSequencerが順序を決める
      ↓
EVMが取引を実行する
      ↓
ブロックに取り込まれる
      ↓
コンセンサスにより確定する
      ↓
業務システムが結果を確認・照合する

重要なのは、ブロックチェーン上の技術的な状態と、銀行・決済事業者の業務状態を分けることです。ステーブルコイン送金の実行が成功していても、受取人への通知、銀行側残高との照合、AML/CFTモニタリング、会計仕訳、手数料計上、顧客画面への反映などが残っている可能性があります。
この回の中核メッセージ
ブロックチェーンのファイナリティと、金融取引全体の完了は同じではありません。

2．トランザクションはどのように流れるのか

ウォレットAからウォレットBへ100単位のステーブルコインを送る例を考えます。取引は、アプリケーション、署名基盤、RPC、ノード、ブロック生成主体、EVM、監視・業務システムを通過します。

図1　トランザクションの基本アーキテクチャ

3．ウォレットは「トランザクションを作り、署名する」

ウォレットは、トークンそのものを保存する箱ではありません。トークン残高はブロックチェーン上のスマートコントラクトが管理しています。ウォレットの重要な役割は、利用者のアドレスを管理し、トランザクションを組み立て、秘密鍵を使って署名することです。
署名されたトランザクションには、概ね次の情報が含まれます。

  • 送信元

  • 送信先

  • 呼び出すスマートコントラクト

  • 実行する関数と引数

  • Nonce

  • Chain ID

  • Gas上限

  • 手数料条件

  • 電子署名

Nonceは、同じアカウントから送る取引の順番を管理し、同じトランザクションが繰り返し実行されることを防ぐための番号です。Chain IDは、Ethereum Mainnetや特定のL2など、どのネットワーク向けの取引であるかを識別します。

4．RPCはブロックチェーンへの接続窓口

RPC（Remote Procedure Call）は、アプリケーションからブロックチェーンノードの機能を呼び出すインターフェースです。EVM系チェーンでは一般にJSON-RPCが使われ、共通メソッドを通じてトランザクション送信、状態照会、ログ取得などを行います。[1]

JSON例：トランザクション結果の照会

{
  "jsonrpc": "2.0",
  "method": "eth_getTransactionReceipt",
  "params": ["0x8a3f...91cd"],
  "id": 1
}

簡略化したレスポンス例です。
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "transactionHash": "0x8a3f...91cd",
    "blockNumber": "0x12ab34",
    "status": "0x1",
    "gasUsed": "0x9c40",
    "effectiveGasPrice": "0x59682f00",
    "logs": [{
      "address": "0xTokenContract...",
      "topics": ["0xddf252ad..."],
      "data": "0x..."
    }]
  }
}

status: 0x1は、トランザクションの実行が成功したことを示します。しかし、このレスポンスだけで「金融取引が最終的に完了した」と判断してはいけません。Receiptは、取り込まれたブロック、Gas使用量、実行成否などを示しますが、コンセンサス上のファイナリティや業務処理の完了そのものを保証するものではありません。

5．ノードは何をしているのか

ノードは、ブロックチェーンのデータを保持し、トランザクションやブロックを検証するコンピューターです。Ethereumのノードは、現在、大きくExecution ClientとConsensus Clientから構成されます。[2]


Transaction Poolとは

Transaction Poolは、ノードが受け付けたものの、まだブロックに取り込まれていないトランザクションを保持する領域です。一般にMempoolとも呼ばれます。ただし、ネットワーク全体で一つの共通データベースがあるわけではなく、各ノードがそれぞれローカルなPoolを持っています。
そのため、あるRPCノードがトランザクションを受け付けても、次のような事象が起こり得ます。

  • 他のノードへ十分に伝播しない

  • 手数料条件が低く、ブロックに選ばれない

  • Nonceの不整合で保留される

  • 同じNonceを使う別トランザクションに置換される

  • RPC事業者の障害により状態を取得できない

「RPCがトランザクションハッシュを返した」という状態だけで、顧客へ完了通知を出さない設計が必要です。


6．ブロックに入ると何が起きるのか

トランザクションはブロック生成者によって選択され、順番を付けられます。EVMはトランザクションを順番に実行し、その結果としてブロックチェーンの状態を更新します。ステーブルコインの送金であれば、概念的には次のような状態遷移が起こります。
送信前
Wallet A：1,000
Wallet B：  200

      ↓ 100を移転

送信後
Wallet A：  900
Wallet B：  300

実際にはスマートコントラクト内のStorageが更新され、同時にTransfer Eventが出力されます。Eventは、顧客アプリ、入出金管理、AML/CFTモニタリング、会計、残高照合、エクスプローラーなど、チェーン外部のシステムが取引を検知するために使います。
ただし、Eventを検知しただけで業務処理を確定させると、ブロックの再編成（Reorg）やL2固有の確定遅延に対応できない可能性があります。

7．Gasは「手数料」ではなく計算資源の単位

Gasは、EVM上で処理を実行するために必要な計算資源を測る単位です。単純なネイティブトークン送金、ERC-20のTransfer、複雑なスマートコントラクトでは、必要な処理量が異なります。

取引手数料 ＝ 使用したGas量 × Gas単価

EthereumではEIP-1559により、基本手数料であるBase Feeと優先手数料であるPriority Feeを中心とする手数料モデルが導入されています。[3]

Gas Limitが不足すると、処理途中でOut of Gasとなり、状態変更はRevertされます。トークン残高の変更は取り消されても、そこまでの計算に使用したGasの手数料は発生します。

金融システムで必要なGas管理

  • Gas代を顧客と事業者のどちらが負担するか

  • Gas代に使うネイティブトークンを誰が保有するか

  • Gas単価の上限

  • Gas高騰時に取引を止めるか

  • Gas不足時に自動補充するか

  • L1とL2の費用をどう配賦するか

  • 再送時の手数料を誰が負担するか

  • 顧客にどのように手数料を表示するか

Gasは単なる利用手数料ではなく、システムの可用性、原価管理、顧客体験に直接関わる運用項目です。

8．トランザクションハッシュは完了証明ではない

トランザクションをRPCへ送信すると、通常、トランザクションハッシュが返されます。しかし、この時点で分かるのは、少なくとも一つのノードがそのトランザクションを受け付けた、ということにすぎません。

  • まだブロックに入っていない

  • 手数料が低く、長時間保留されている

  • Nonce不整合で実行できない

  • 同じNonceの別取引に置換された

  • 実行されたがRevertした

  • ブロックに入った後にReorgされた

  • L2では処理されたがL1へまだ反映されていない

四つの状態を分ける

この状態管理は、ブロックチェーン外部のデータベースにも保持する必要があります。

9．ファイナリティとは何か

ファイナリティとは、ブロックに記録された取引が、後から取り消されたり別の履歴へ置き換えられたりしないと判断できる状態です。EthereumのProof of Stakeでは、Validatorの投票によりCheckpointがJustified、さらにFinalizedへ進みます。[4]
金融実務でいう決済ファイナリティには、技術的な確定だけでなく、法的な取消不能性や債務消滅の時点も関係します。

ブロックチェーンを採用しただけで、法的ファイナリティが自動的に決まるわけではありません。規約、契約、システム設計、例外処理を含めて定義する必要があります。

10．L2では処理がもう一段増える

L1は高いセキュリティと分散性を持つ一方、処理能力やGasコストに制約があります。L2は取引の実行をL1の外側で行い、結果、取引データ、証明などをL1へ送ることで処理能力を高めます。Ethereumのセキュリティを利用する代表的な方式がRollupです。[5]

図2　L2 Rollupの基本アーキテクチャ

Sequencerとは

Sequencerは、L2上でトランザクションを受け付け、順序を決め、L2ブロックやバッチを作る役割を持ちます。利用者画面では、Sequencerが取引を受け付けた直後に「完了」と表示される場合がありますが、それはL2上の早期確認であり、L1上での確定とは限りません。
Sequencerが停止した場合、新規取引の受付停止、取込遅延、L1へのバッチ送信停止、L2からL1への出金遅延、取引順序の公平性や検閲などの問題が起こり得ます。L2選定では、速度やGas代だけでなく、障害時の代替経路や強制取込機能も確認する必要があります。

11．Optimistic RollupとZK Rollup

Optimistic Rollup

Optimistic Rollupは、L2で実行した取引結果を原則として正しいものとしてL1へ送ります。その後、一定のChallenge Periodを設け、誤った状態更新に対して異議を申し立てられるようにします。そのため、L2からL1への通常の出金には待機期間が設けられる場合があります。[6]

ZK Rollup

ZK Rollupは、L2上の状態遷移が正しいことを示すValidity ProofをL1へ提出します。L1上のRollup Contractが証明を検証することで、状態更新の正しさを確認します。証明生成、証明提出、L1での検証など、複数の処理段階があります。[7]

12．Data Availabilityとは何か

Data Availability（データ可用性）は、単にサーバーが稼働しているという意味ではありません。L2の状態を第三者が再現し、取引の正当性を検証し、必要に応じて不正を証明するためのデータが利用可能であることを意味します。[8]
Sequencerが「残高は正しく更新された」と主張しても、その計算に使った取引データが提供されなければ、第三者は状態を再現できません。Optimistic Rollupでは不正を検証するために取引データが必要です。ZK Rollupでも、Validity Proofが状態遷移の正しさを示すことと、利用者やノードが現在の状態を再構築できることは別の問題です。
Ethereumでは、L2が取引データをCalldataやBlobとしてL1へ掲載する方法があります。BlobはRollupのデータ掲載コストを抑えるためのデータ形式です。[9]

金融機関が確認すべき点

  • 取引データはどこへ保存されるか

  • データを誰が取得できるか

  • データ保持期間

  • Sequencer停止時に状態を再構築できるか

  • L1上に掲載されるデータの範囲

  • 外部のData Availability層を使っているか

  • 障害時に資産をL1へ退避できるか

  • 監査証跡として必要な期間保存できるか

13．L2における「確定」は一つではない

1．Sequencerが取引を受け付けた
              ↓
2．L2ブロックに取り込まれた
              ↓
3．バッチやデータがL1へ送られた
              ↓
4．Fraud Proof期間が終了した
  またはValidity Proofが検証された
              ↓
5．L1上でFinalizedされた
              ↓
6．金融機関の業務処理が完了した

どの段階で顧客画面を「完了」にするかは、ユースケースによって異なります。少額の加盟店決済であればL2上の早期確認で商品を引き渡すことが考えられます。一方、高額資産決済や銀行間決済では、より強い確定状態を求める可能性があります。
ファイナリティポリシーは、取引金額、取引相手、商品・サービス、取消可能性、信用補完、不正リスク、法的要件に応じて定義します。

14．ステーブルコイン送金のシーケンス

L2上でステーブルコインを送るPoCを想定します。企業システムは、Tx Hashの取得だけでなく、L2確認、L1確定、Event監視、照合完了を段階的に管理します。

図3　L2上のステーブルコイン送金シーケンス

　

15．オフチェーン側で持つべき取引状態

PoCであっても、最低限、次のような取引管理レコードを持つべきです。
{
  "requestId": "PAY-2026-00001234",
  "chainId": 42161,
  "network": "l2-testnet",
  "tokenContract": "0x1234...abcd",
  "fromAddress": "0xaaaa...1111",
  "toAddress": "0xbbbb...2222",
  "amount": "100000000",
  "tokenDecimals": 6,
  "nonce": 183,
  "transactionHash": "0x8a3f...91cd",
  "transactionStatus": "INCLUDED",
  "finalityStatus": "L2_CONFIRMED",
  "businessStatus": "RECONCILING",
  "includedBlockNumber": 8453120,
  "l1BatchTransactionHash": null,
  "gasUsed": "40000",
  "submittedAt": "2026-07-19T07:31:04Z",
  "includedAt": "2026-07-19T07:31:07Z",
  "finalizedAt": null,
  "lastCheckedAt": "2026-07-19T07:31:15Z",
  "retryCount": 0,
  "errorCode": null
}


16．PoCでも決めるべき実装チェックリスト

ネットワーク

  • □ 利用するL1・L2を特定している

  • □ Chain IDを固定している

  • □ TestnetとMainnetの設定を分離している

  • □ Rollup方式とL1への確定方法を確認している

  • □ Data Availabilityの構成を確認している

RPC・ノード

  • □ RPC接続先を複数用意している

  • □ 接続先ごとのBlock Heightを比較している

  • □ RPCタイムアウトを定義している

  • □ RPC再送時に同じ支払いを二重作成しない

  • □ WebSocket切断時の再接続方式を定義している

  • □ 自前ノードと外部RPCサービスの役割を整理している

トランザクション

  • □ Nonceを一元管理している

  • □ 同じNonceを使う取引の競合を検知できる

  • □ Gas見積もり失敗時の処理を定義している

  • □ Gas単価上限を定義している

  • □ Pending取引の再送条件を定義している

  • □ Revert理由を取得・記録している

  • □ Tx Hashを業務上の受付番号と紐付けている

ファイナリティ

  • □ Submitted、Included、Finalizedを区別している

  • □ L2確認とL1確定を区別している

  • □ 取引金額別の確定基準を定義している

  • □ Reorg発生時の状態戻しを設計している

  • □ Challenge PeriodまたはValidity Proofの扱いを確認している

  • □ 顧客画面の「処理中」「完了」の定義を決めている

監視

  • □ RPC障害を監視している

  • □ Block生成停止を監視している

  • □ Sequencer停止を監視している

  • □ L1へのバッチ送信遅延を監視している

  • □ Gas高騰を監視している

  • □ Transfer Eventを監視している

  • □ 想定外アドレスへの送金を検知できる

  • □ 同一Eventの重複処理を防止している

業務・照合

  • □ オンチェーン残高と業務システム残高を照合している

  • □ 手数料を含む会計処理を定義している

  • □ 入金通知の発信条件を定義している

  • □ AML/CFT確認の実施時点を定義している

  • □ 未完了取引を抽出できる

  • □ 手動補正時の承認・記録方法を定義している

  • □ 障害復旧後に全取引を再照合できる

17．よくある誤解


誤解1　トランザクションハッシュが返れば送金完了

トランザクションハッシュは取引を追跡する識別子です。ブロックへの取り込み、実行成功、ファイナリティをそれぞれ確認する必要があります。

誤解2　ReceiptのStatusが1なら最終確定

Statusが1でも、ブロック自体がまだ確定していない可能性があります。L2では、L1へのデータ送信や証明検証などが残っている可能性があります。

誤解3　L2は安くて速いEthereum

L2には独自のSequencer、ブロック、障害モード、L1への反映プロセスがあります。L1と同じ運用をそのまま適用できるとは限りません。

誤解4　ブロックチェーンなので照合は不要

チェーン内部の状態が整合していても、銀行勘定、顧客台帳、会計、手数料、AML/CFT処理との間に差異が発生する可能性があります。

誤解5　技術的ファイナリティが法的な決済完了を決める

技術上の取消困難性と、法的な債務消滅の時点は別の論点です。利用規約、契約、業務ルール、適用法令を含めて定義します。

18．オンチェーン金融で本当に設計すべきもの

オンチェーン金融の実装では、スマートコントラクトだけを作ればよいわけではありません。必要なのは、次の一連の制御です。
取引要求
  ↓
本人・権限確認
  ↓
署名
  ↓
RPC送信
  ↓
トランザクション状態管理
  ↓
L1・L2のファイナリティ確認
  ↓
Event監視
  ↓
業務システムとの照合
  ↓
会計・AML/CFT・通知
  ↓
例外処理・監査証跡

第1回のまとめ
ブロックチェーンは、取引を書き込む一枚の台帳ではありません。署名、通信、実行、合意、データ可用性、監視、照合から構成される分散システムです。

チェーン上で処理されたことと、金融業務として決済が完了したことを分けて設計する。これがオンチェーン金融実装の出発点です。


次回

スマートコントラクトは契約書ではない

次回は、ブロックチェーン上でプログラムを実行するEVMとスマートコントラクトを取り上げます。Storage、Memory、Calldata、msg.sender、関数、Event、Revert、コントラクト間呼出し、Reentrancy、ERC-20／721／1155／4626の状態構造を、コードと金融業務を対応させながら読み解きます。

参考資料

[1] Ethereum.org, JSON-RPC API
[2] Ethereum.org, Nodes and clients
[3] EIP-1559: Fee market change
[4] Ethereum.org, Proof-of-stake
[5] Ethereum.org, Scaling
[6] Ethereum.org, Optimistic rollups
[7] Ethereum.org, Zero-knowledge rollups
[8] Ethereum.org, Data availability
[9] Ethereum.org, Transactions

免責事項
本稿は技術・業務の一般的な解説を目的とするものであり、特定のシステム、プロトコル、金融商品への投資・導入を推奨するものではありません。実装時には、採用するチェーン、L2、ウォレット、スマートコントラクトの最新仕様と、適用される法令・契約・社内規程を確認してください。

いいなと思ったら応援しよう！