---
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>

## 直接の答え

検閲耐性とは、特定のゲートウェイ、ピア、ビルダー、またはブロックプロデューサーがトランザクションを拒否した場合でも、有効なトランザクションに到達可能であり、最終的に含められる資格を維持できるネットワークの能力です。これは回復力の程度であり、すべてのトランザクションが次のブロックに入るという約束や、すべてのアクセス プロバイダーがすべてのユーザーにサービスを提供しなければならないという約束ではありません。

クレームでは、レイヤー、アクター、および時間ウィンドウに名前を付ける必要があります。ウォレット、フロントエンド、RPC エンドポイント、交換またはロールアップ シーケンサーがアクセスを即座にブロックする一方で、ベース チェーンは持続的なトランザクション検閲に抵抗する可能性があります。トランザクションは、無効な署名、間違ったノンス、不十分な残高、ローカルリレーポリシーを下回る料金、または限られたブロックスペースの競争など、検閲以外の理由によって遅延することもあります。

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

## 仕組み

1 つの署名済みトランザクションを個別の段階を通じて追跡します。

1. **作成と送信。** ウォレットはトランザクションを構築して署名し、RPC プロバイダー、プライベート ルート、またはピアツーピア ネットワークを通じて送信します。ゲートウェイは、基本プロトコルを変更せずにそれを拒否できます。
2. **アドミッションと伝播。** ノードはコンセンサスの有効性と、自身のメモリ プールまたはリレー ポリシーをチェックします。トランザクションはコンセンサスが有効であっても、特定のノードによって中継されない場合があります。複数の独立したピアと送信パスにより、1 つのゲートキーパーへの依存が軽減されます。
3. **ブロックの構築と提案。** マイナー、バリデーター、シーケンサー、または外部ビルダーがトランザクションとその順序を選択します。プロデューサーを交代させると、後のプロデューサーの意味のあるシェアがトランザクションを確認して含めることができる場合にのみ、1 人のアクターの拒否が一時的になります。
4. **検証とフォークの選択。** 他のノードは無効なブロックを拒否し、どの有効なブランチが正規であるかを決定します。独立した検証により、プロデューサが無効なトランザクションを有効にすることはできませんが、通常はプロデューサに特定の有効なトランザクションを強制的に含めることはありません。
5. **確認または最終性** 包含は永続的な決済と同じではありません。再組織化により、最近追加されたものが削除される場合があります。関連する確認またはファイナリティ ルールはチェーン固有です。

二値的なラベルを割り当てるのではなく、結果を測定します。 `t_seen` で最初に広く利用可能になり、`t_included` に含まれるトランザクションの場合:

`inclusion delay = t_included - t_seen`

この遅延を、同じ輻輳ウィンドウ内の同様の価格で同様に複雑なトランザクションと比較してください。もう 1 つの有用な手段は次のとおりです。

`eligible inclusion rate = included eligible transactions / observed eligible transactions`

「適格」には、有効性、ノンス、残高、料金、ガスまたは重量、タイミングおよび容量のルールを記載する必要があります。そうしないと、通常の料金選択や混雑が選択的検閲と誤解される可能性があります。

耐性は、ピア、RPC、自律オペレーター、プール、クライアント、ビルダー、リレー、シーケンサー、ホスティング プロバイダー、管轄区域など、障害ドメイン全体の多様性に依存します。多くのノードまたは検証キーが 1 つのコントローラーを共有する可能性があるため、生のノード数は誤解を招く可能性があります。強制包含パスまたは包含リストは保証を強化できますが、その展開ステータスと条件が重要です。たとえば、EIP-7805 は提案であり、現在導入されているイーサリアム保証ではありません。

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

## 例

有効なトランザクションがブロック高さ `840,000` でパブリック ネットワークに到達するとします。競争力のある料金を提供し、次の各ブロックに適合し、引き続き有効です。 3 人のプロデューサーはそれを省略しています。 4 番目には、高さ `840,004` が含まれます。

- 観測された遅延は、指定された開始点から `4 blocks` です。
- 3 つの省略だけでは調整を証明するものではありません。順序付け、伝播、およびプロデューサーのポリシーについては調査が必要です。
- 独立した 4 番目のプロデューサーが参加したことは、最初のプロデューサーが完全な拒否権を欠いていたことを示しています。
- 機会の `90%` を制御するプロデューサーが同じフィルターを適用する場合、単純化された独立スロット モデルにより、スロットごとの包含確率 `1 - 0.90 = 10%` と予想待機時間 `1 / 0.10 = 10 slots` が得られます。相関制御と実際の選択ルールは、このモデルを無効にする可能性があります。

検閲の疑いを文書化するには、署名されたトランザクションまたは識別子、独立したノードからの最初の観察結果、料金と有効性のチェック、メモリプールのポリシー、ブロックの内容、プロデューサーの帰属、および比較可能なトランザクションを保存します。 1 つの RPC エラーやエクスプローラー エントリの欠落だけでは十分ではありません。

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

## リスク

- **誤検知:** 無効、無効なナンス、資金不足、料金ポリシー、容量、または不十分な伝播は検閲のように見える可能性があります。
- **集中的な順序付け:** 支配的なプール、ビルダー、リレー、またはシーケンサーにより、選択的なフィルタリングが長い遅延に変わる可能性があります。
- **アクセス層の検閲:** ドメイン、アプリ ストア、フロントエンド、ウォレット、RPC プロバイダーは、直接プロトコル アクセスが可能なままでも実際のアクセスをブロックする可能性があります。
- **相関インフラストラクチャ:** 別々に見えるエンドポイントが、オペレーター、クラウド、クライアント、リレー、または法的リスクを共有する場合があります。
- **プライバシー漏洩:** 多くのサービスを介した再ブロードキャストにより、IP、タイミング、およびトランザクションのリンクが公開される一方で、リーチが向上する可能性があります。
- **弱いエスケープパス:** 強制的に含めると、料金、保証金、遅延、ウィンドウ、データ要件、または特権制御が発生する可能性があります。
- **組織再編とガバナンスのリスク:** 包含は最終的なものではない可能性があり、アップグレードや緊急権限によって前提が変更される可能性があります。

実用的な場合は、完全に独立したパスを使用してください。 RPC、リレー、または「検閲対策」サービスとシード フレーズや秘密キーを決して共有しないでください。また、ノンスと料金のルールを理解せずにトランザクションを置き換えたり再ブロードキャストしたりしないでください。

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

## よくある誤解

- **「有効とは、確実に含まれることを意味します。」** 有効性によって適格性が生まれます。より強力なルールが適用されない限り、プロデューサーは依然としてトランザクションを選択します。
- **「分散化とは検閲不可能であることを意味します。」** 本番、ビルダー、リレー、RPC、フロントエンド、またはガバナンスに集中したままにすることができます。
- **「ブロックされた 1 つの RPC はチェーン検閲を証明します。」** これは、ネットワーク全体の拒否権ではなく、1 つのアクセス パスが失敗したか、要求を拒否したことを証明します。
- **「高い料金はあらゆるフィルターに打ち勝つ。」** 競争力のある料金は、明示的なフィルターではなく、経済的な順序に対応します。
- **「最終的に組み込むだけで十分です。」** 運用期限を過ぎて組み込むことは役に立たない可能性があります。時間枠はクレームに含まれます。

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

## 関連トピック

- [ブロックチェーンのトリレンマ](/ja/crypto/blockchain-trilemma/)
- [ピアツーピアネットワーク](/ja/crypto/peer-to-peer-network/)
- [パーミッションレスブロックチェーン](/ja/crypto/permissionless-blockchain/)
- [提案者と施工者の分離](/ja/crypto/proposer-builder-separation/)
- [検証者](/ja/crypto/validator/)

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

## ソース

- [ビットコイン: ピアツーピア電子キャッシュ システム](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (アクセス: 2026-08-20)
- [トランザクション](https://developer.bitcoin.org/devguide/transactions.html) - Bitcoin.org (アクセス: 2026-08-20)
- [イーサリアム上に構築する理由](https://ethereum.org/latest/why-build-on-ethereum/) - Ethereum.org (アクセス: 2026-08-20)
- [EIP-7805: フォーク選択が強制された包含リスト](https://eips.ethereum.org/EIPS/eip-7805) - イーサリアム改善提案 (アクセス日: 2026-08-20)
- [ブロックチェーン技術の概要](https://doi.org/10.6028/NIST.IR.8202) - 米国国立標準技術研究所 (アクセス日: 2026-08-20)

Source: https://wiki.fcontext.com/ja/crypto/censorship-resistance/index.mdx