---
title: "ステートチャネル"
description: "ステートチャネルでは、固定された参加者が署名済みの状態更新をオフチェーンで交換しつつ、最新の有効な結果をオンチェーンで強制できる経路を維持します。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ステートチャネル

> 教育目的のみであり、投資またはセキュリティ上の助言ではありません。鍵、最新の状態データ、監視、またはオンチェーンで応答を送信する能力が利用できない場合、チャネル資金を失う可能性があります。

<a id="answer"></a>

## 要点

ステートチャネルは、固定された参加者がブロックチェーン上で資産をロックするか強制可能なルールを設定した後、認証済みの状態更新をオフチェーンで交換するプロトコルです。ブロックチェーンは更新を毎回処理せず、チャネルの終了時や不一致が起きた際の最終裁定者になります。

受理される更新は、対象チャネル、アプリケーション状態または配分、そして単調増加するターン番号や nonce などの順序値にコミットします。チャネルの規則に従い、新しい有効状態が古い状態に優先します。ペイメントチャネルは主に残高を追跡する限定的な形で、汎用ステートチャネルはゲームの手、取引など決定論的なアプリケーションデータも表せます。

低遅延、公開取引履歴からの一定のプライバシー、通常更新ごとのベースレイヤー手数料が不要という利点があります。ただし、参加者と資本は通常セッション中固定され、全員が最新状態を強制する証拠を保持し、紛争時にもベースチェーンが利用可能で手数料を支払えることが前提です。

<a id="mechanism"></a>

## 仕組み

1. **開設と資金拠出。** 参加者は本人情報、アプリ規則、チャレンジ期間、初期配分に合意し、オンチェーン裁定コントラクトに資金をロックするか、資金拠出済みチャネルから派生させます。拠出資金はチャネルを担保する間、通常のウォレット残高として使えません。
2. **署名済み状態の交換。** 次の有効状態を計算し、必要な署名またはプロトコルメッセージを交換します。状態を一意のチャネル ID と増加する順序値に結び付け、別チャネルや過去ラウンドの署名へのすり替えを防ぎます。
3. **強制執行用データの保存。** ウォレットやノードは、最新の支持済み状態、署名、保留中の条件付き送金、プロトコル固有の失効情報や秘密情報を保存します。シードフレーズで鍵を復元できても、変化し続けるオフチェーンデータまで戻るとは限りません。
4. **オフチェーンで継続。** 多数の更新をベースレイヤー取引なしで行えますが、送金は容量に制約されます。一方向に送れる額は現在の配分とプロトコル準備額までです。複数の支払チャネルを経由すれば、各ホップで流動性と稼働性への依存が増えます。
5. **可能なら協調終了。** 参加者が最終結果に署名し、プロトコルが要求する最小限のオンチェーン取引を送ります。協調終了は通常、チャレンジ競争を避け、単独終了より速いか安価です。
6. **紛争をオンチェーンへ移す。** 相手が消えたり古い状態を提案したりした場合、別の参加者が強制可能な証拠を提出します。裁定コントラクトは順序、タイムアウト、遷移規則を適用します。新状態で旧状態に異議を唱える設計もあれば、Lightning 型のように一般的な最大 nonce 競争ではなくコミットメントと失効規則を使う設計もあります。
7. **期限後に確定。** チャレンジ期間またはタイムロック後に結果を請求します。全出力が解決するまで、ソフトウェアはチェーン監視、再編への対応、期限付き取引の手数料引き上げを必要とする場合があります。

<a id="example"></a>

## 例

Alice と Bob がそれぞれ `5 ETH` を出して単純な双方向ペイメントチャネルを開くと、チャネルは `10 ETH` を管理します。共同署名した開始状態はターン `0` で、決済時に Alice は `5 ETH`、Bob は `5 ETH` を受け取ります。

Alice が Bob に `1 ETH` 支払い、両者は遷移を検証してターン `1` に署名します。配分は Alice が `4 ETH`、Bob が `6 ETH` です。その後 Bob が Alice に `2 ETH` 支払うと、ターン `2` は Alice に `6 ETH`、Bob に `4 ETH` を配分します。協調運用中、ベースチェーンに届く必要があるのは資金拠出と最終決済だけです。

後に Bob がターン `1` を提出したとします。最大ターンで裁定する設計では、Alice は期限前に完全に支持されたターン `2` を示す必要があります。成功すればコントラクトは古い結果を退けターン `2` で決済します。しかしターン `2` を失った、署名鍵を使えない、手数料用のベース資産がない、期限を超えてオフラインだった場合、プロトコルは非公開の履歴を推測できません。強制される結果が実際の最新合意と異なる可能性があります。

これは概念例です。実際のプロトコルは、状態を支持する署名、有効な遷移、条件付き支払いの解決、オンチェーン呼び出しと期限を厳密に定めます。この単純な計算だけを根拠に送金しないでください。

<a id="risks"></a>

## リスクと対策

- **古い状態での決済。** 最新かつ完全な強制執行用データを保持し、復元をテストします。対応するウォッチタワーへ渡すデータと権限を理解してから利用します。
- **チャレンジ期間の見逃し。** 全出力が確定するまで正しいチェーンを監視します。障害、再編、混雑、人の対応時間を現実的に見込みます。
- **手数料と混雑。** ロックされていないベース資産と手数料引き上げ手段を確保します。同時紛争により、緊急退出時ほど高価になり得ます。
- **鍵または状態データの喪失。** 実装の公式手順で状態をバックアップします。明示的に安全でない限り、稼働中チャネルを古いスナップショットから復元しません。
- **容量とルーティングの失敗。** 入出力流動性、準備額、条件付き送金上限、有効期限の余裕、全仲介者を確認します。ウォレット総額は利用可能容量ではありません。
- **相手方と稼働性。** 正しく保護された結果を相手が通常書き換えることはできませんが、更新や協調終了を拒み、遅い紛争経路を強いることはできます。
- **実装リスク。** クライアント、裁定コントラクト、署名ドメイン、遷移ロジック、アップグレード制御の欠陥は保証を破り得ます。実際のデプロイと監査を確認します。
- **プライバシー漏えい。** オフチェーン更新は自動的に匿名になりません。ピア、ルーター、観測者、バックアップ、紛争取引が関係やデータを明かす場合があります。

<a id="misconceptions"></a>

## よくある誤解

- **「オフチェーンならブロックチェーンなしでトラストレスだ。」** 相手への信頼を抑えるのは信頼できるオンチェーン強制経路であり、その安全性、可用性、手数料は重要です。
- **「双方が署名した状態なら何でも決済できる。」** 強制可能な証拠は、プロトコル固有の順序、有効性、確定、失効、期限規則で決まります。
- **「シードフレーズでチャネル全体を復元できる。」** 通常は鍵を戻すだけで、最新状態、失効用秘密、保留送金、ピア DB は戻らない場合があります。
- **「利用者は無期限にオフラインでよい。」** 多くの設計では、本人または委任監視サービスが期限内に観測し応答する必要があります。
- **「チャネル容量はウォレット残高と同じだ。」** 資金をチャネルにコミットする必要があり、方向、準備額、保留送金、ルート流動性にも左右されます。
- **「ステートチャネルは Rollup を全面的に置き換える。」** 既知の参加者同士の反復処理に適します。自由参加、共有グローバル状態、広いコンポーザビリティには Rollup や通常のオンチェーン実行が適する場合があります。

<a id="related"></a>

## 関連トピック

- [ガス手数料](/crypto/gas-fee/)
- [HTLC](/crypto/htlc/)
- [レイヤー 2](/crypto/layer2/)
- [Rollup](/crypto/rollup/)
- [スマートコントラクト](/crypto/smart-contract/)

<a id="sources"></a>

## 出典

- [General State Channel Networks](https://doi.org/10.1145/3243734.3243856) - ACM（参照日：2026-08-21）
- [Nitro Protocol](https://eprint.iacr.org/2019/219) - Cryptology ePrint Archive（参照日：2026-08-21）
- [States & Channels](https://docs.statechannels.org/protocol-tutorial/0010-states-channels/) - State Channels（参照日：2026-08-21）
- [BOLT #2：チャネル管理のピアプロトコル](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning Specifications（参照日：2026-08-21）
- [BOLT #5：オンチェーントランザクション処理の推奨事項](https://github.com/lightning/bolts/blob/master/05-onchain.md) - Lightning Specifications（参照日：2026-08-21）

Source: https://wiki.fcontext.com/ja/crypto/state-channels/index.mdx