﻿---
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. **Создание и отправка.** Кошелек создает и подписывает транзакцию, а затем отправляет ее через поставщика RPC, по частному маршруту или через одноранговую сеть. Шлюз может отказаться от него, не меняя базовый протокол.
2. **Прием и распространение.** Узлы проверяют достоверность консенсуса и свою собственную политику мемпула или ретрансляции. Транзакция может быть действительной по консенсусу, но не ретранслироваться конкретным узлом. Несколько независимых узлов и путей отправки уменьшают зависимость от одного привратника.
3. **Создание и предложение блоков.** Майнер, валидатор, секвенсор или внешний строитель выбирает транзакции и их порядок. Ротация производителей делает отказ одного участника временным только в том случае, если значительная часть последующих производителей сможет увидеть и включить транзакцию.
4. **Проверка и выбор ветки.** Другие узлы отклоняют недействительные блоки и решают, какая действительная ветвь является канонической. Независимая проверка не позволяет производителю сделать недействительную транзакцию действительной, но обычно она не заставляет этого производителя включать конкретную действительную транзакцию.
5. **Подтверждение или окончательность.** Включение – это не то же самое, что долгосрочное урегулирование. Реорганизации могут удалить недавнее включение; соответствующее правило подтверждения или окончательности зависит от цепочки.

Измеряйте результаты вместо присвоения двоичной метки. Для транзакции, впервые широко доступной по адресу `t_seen` и включенной в `t_included`:

`inclusion delay = t_included - t_seen`

Сравните эту задержку с аналогичными по цене и столь же сложными транзакциями в том же окне перегрузки. Еще одна полезная мера:

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

«Правомочный» должен указать правила действительности, одноразового номера, баланса, комиссии, газа или веса, времени и мощности. В противном случае обычный сбор платы или перегруженность могут быть ошибочно приняты за выборочную цензуру.

Устойчивость зависит от разнообразия областей сбоя: одноранговых узлов, RPC, автономных операторов, пулов, клиентов, сборщиков, ретрансляторов, секвенсоров, хостинг-провайдеров и юрисдикций. Необработанное количество узлов может ввести в заблуждение, поскольку многие узлы или ключи валидатора могут использовать один контроллер. Пути принудительного включения или списки включения могут усилить гарантии, но статус и условия их развертывания имеют значение. Например, EIP-7805 — это предложение, а не гарантия Ethereum, используемая в настоящее время.

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

## Пример

Предположим, что действительная транзакция достигает общедоступной сети на высоте блока `840,000`. Он предлагает конкурентоспособную плату, помещается в каждый следующий блок и остается в силе. Three producers omit it; четвертый включает его на высоте `840,004`.

- Наблюдаемая задержка составляет `4 blocks` от указанной начальной точки.
- Три упущения сами по себе не доказывают координации; порядок заказа, распространение и политика производителей требуют изучения.
- Включение независимого четвертого продюсера показывает, что у первых продюсеров не было полного права вето.
- Если производители, контролирующие возможности `90%`, применяют один и тот же фильтр, упрощенная модель независимых слотов дает вероятность включения для каждого слота `1 - 0.90 = 10%` и ожидаемое ожидание `1 / 0.10 = 10 slots`. Коррелированные правила контроля и реального отбора могут сделать эту модель недействительной.

Чтобы задокументировать предполагаемую цензуру, сохраните подписанную транзакцию или идентификатор, первые наблюдения независимых узлов, проверки комиссий и действительности, политики мемпула, содержимое блоков, атрибуцию производителя и сопоставимые транзакции. Одной ошибки RPC или отсутствия записи в проводнике недостаточно.

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

## Риски

- **Ложные срабатывания**: недействительность, устаревший одноразовый номер, недостаточность средств, политика оплаты, пропускная способность или плохое распространение могут выглядеть как цензура.
- **Концентрированное упорядочение:** доминирующий пул, сборщик, ретранслятор или секвенсор могут превратить выборочную фильтрацию в длительные задержки.
- **Цензура на уровне доступа:** домены, магазины приложений, интерфейсы, кошельки и провайдеры RPC могут блокировать практический доступ, в то время как прямой доступ по протоколу остается возможным.
- **Коррелированная инфраструктура:** отдельные конечные точки могут иметь общего оператора, облако, клиента, ретранслятор или юридическое лицо.
- **Утечка конфиденциальной информации:** ретрансляция через множество сервисов может улучшить охват, одновременно раскрывая IP, время и связь транзакций.
- **Слабые пути выхода:** принудительное включение может повлечь за собой сборы, залог, задержки, окна, требования к данным или привилегированный контроль.
- **Риск реорганизации и управления:** включение может быть не окончательным, а обновления или чрезвычайные полномочия могут изменить предположения.

Используйте по-настоящему независимые пути там, где это практически возможно. Никогда не передавайте начальные фразы или закрытые ключи службам RPC, ретрансляции или «антицензуры», а также не заменяйте и не ретранслируйте транзакцию без понимания правил nonce и комиссий.

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

## Распространенные заблуждения

- **"Действительность означает гарантированное включение".** Действительность создает право на участие; производители по-прежнему выбирают транзакции, если не применяется более строгое правило.
- **«Децентрализовано — значит не подвергается цензуре».** Концентрация может сохраняться в производстве, сборщиках, ретрансляторах, RPC, интерфейсах или управлении.
- **«Один заблокированный RPC доказывает наличие цензуры в цепочке».** Это доказывает, что один путь доступа не выполнен или отклонен запрос, а не общесетевое вето.
- **«Высокая плата побеждает любой фильтр».** Конкурентоспособная плата направлена ​​на экономический порядок, а не на явный фильтр.
- **«Возможного включения достаточно».** Включение после истечения срока эксплуатации может оказаться бесполезным; временное окно принадлежит иску.

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

## Похожие темы

- [Трилемма блокчейна](/ru/crypto/blockchain-trilemma/)
- [Одноранговая сеть](/ru/crypto/peer-to-peer-network/)
- [Блокчейн без разрешений](/ru/crypto/permissionless-blockchain/)
- [Разделение предлагающего и строителя](/ru/crypto/proposer-builder-separation/)
- [Validator](/ru/crypto/validator/)

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

## Источники

- [Биткойн: одноранговая электронная денежная система](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (дата обращения: 20 августа 2026 г.)
- [Транзакции](https://developer.bitcoin.org/devguide/transactions.html) - Bitcoin.org (дата обращения: 20 августа 2026 г.)
- [Зачем строить на Ethereum](https://ethereum.org/latest/why-build-on-ethereum/) - Ethereum.org (дата обращения: 20 августа 2026 г.)
- [EIP-7805: Списки включения с обязательным выбором форка](https://eips.ethereum.org/EIPS/eip-7805) - Предложения по улучшению Ethereum (дата обращения: 20 августа 2026 г.)
- [Обзор технологии блокчейн](https://doi.org/10.6028/NIST.IR.8202) - Национальный институт стандартов и технологий (дата обращения: 20 августа 2026 г.)

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