---
title: "Слабая субъективность: доверенные контрольные точки и безопасная синхронизация PoS"
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.

# Слабая субъективность: доверенные контрольные точки и безопасная синхронизация PoS

> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

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

## Прямой ответ

Слабая субъективность — это модель безопасности на основе доказательства доли, в которой узел может проверять блоки, переходы состояния, голоса и выбор ветки в соответствии с правилами протокола после того, как он начинает работу с достаточно недавнего контрольного пункта, полученного через доверенный или социально подтверждённый канал. «Слабый» субъективный ввод является отправной точкой. Это не разрешение выбирать произвольные последующие блоки: как только узел закреплён, он должен отвергать истории, которые не содержат контрольного пункта, и проверять дальнейшие события в обычном режиме.

Проблема заключается в исторической неопределенности. Противник, который получает ключи от валидаторов, которые вышли и больше не могут быть экономически наказаны, может создать длинную альтернативную историю с подписями, похожими на действительные. Узел, который наблюдал за канонической цепочкой, пока эти валидаторы могли быть наказаны, сохраняет полезную память. Новый узел, узел, чья база данных была удалена, или узел, находившийся в офлайне дольше безопасного окна актуальности протокола, может не суметь определить социально каноническую историю, опираясь только на данные о генезисе и сообщения от одноранговых узлов.

На Ethereum контрольная точка слабой субъективности — это `epoch` и `block_root`, которые клиент воспринимает как абсолютную опору. Успешная синхронизация должна доказать, что канонический путь содержит этот корень на той эпохе; несоответствие является критической ошибкой, а не голосованием за вариант форка. Контрольная точка слабой субъективности также отличается от обычной финализированной контрольной точки: если узел впервые сталкивается с двумя противоречивыми финализированными историями без предварительной памяти, одни только правила финализации не определяют, какая социальная история является канонической.

Не универсализируйте механизм Ethereum. Лёгкие клиенты CometBFT начинаются с доверенного заголовка внутри настроенного `trusting_period` и передают доверие, используя пересечение наборов валидаторов, подписи, временные ограничения и свидетелей. Исследование Ouroboros Genesis, наоборот, определяет правило выбора цепочки, предназначенное для запуска от доверенного генезис-блока в соответствии с указанной моделью безопасности. «Доказательство доли» (proof of stake) поэтому не подразумевает один формат контрольной точки, одну формулу периода или одну процедуру запуска.

Также отделяйте слабую субъективность от синхронизационного ярлыка. Синхронизация через контрольную точку может сократить время запуска и обработку исторического состояния, но скорость не является определением безопасности. Доверенный корень не аутентифицирует веб-сайт, который его предоставил, не проверяет выполнение полезной нагрузки за пределами заявленных клиентом предположений, не восстанавливает удалённую историю, не доказывает доступность данных и не делает честными затенённые узлы.

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

## Как проверить загрузку слабо-субъективного бутстрэпа

### 1. Определите точный протокол и модель безопасности

Запишите `network`, `chain ID`, корень или хэш генезиса, активную ветку или среду выполнения, версию клиента, тип контрольной точки и спецификацию консенсуса. Определите, требует ли протокол недавней социальной контрольной точки, доверенного заголовка вместе с набором валидаторов, цепочки доказательства финальности, или только генезиса в другой модели. Никогда не переносите Ethereum's `compute_weak_subjectivity_period` или CometBFT's `trusting_period` в другую цепь без её правил.

### 2. Определите, является ли существующий траст все еще актуальным

Задокументируйте последний локально проверенный финализированный контрольный пункт узла, его эпоху или высоту и время, текущий источник времени и любые действия по восстановлению базы данных. Вычисляйте возраст, используя действующие правила и состояние протокола, а не запомнённую календарную оценку. Для Ethereum руководство Фазы 0 тестирует `current_epoch <= ws_state_epoch + ws_period`; Electra изменяет расчет периода в зависимости от общей активной суммы и изменения баланса. Если доверие истекло, получите новый якорь вне сети, а не пытайтесь сильнее работать с ненадежными узлами.

### 3. Получите и подтвердите контрольную точку

Получите тот же контрольный пункт через независимо управляемые и независимо обеспеченные каналы: например, через узел, который вы управляете, другого оператора, несколько команд клиентов и исследователей с разной инфраструктурой. Запишите каждый источник, время получения, сеть, `epoch` и полный корень. Пять URL-адресов, копирующих один и тот же источник, образуют одну область отказа. Простое большинство ответов не заменяет независимость источника, аутентифицированную передачу данных или социальный обзор инцидентов.

### 4. Свяжите каждое поле контрольного пункта

Проверьте сеть и идентичность генезиса до значения контрольной точки. Сохраните полный корень без усечения и сопоставьте его с точной эпохой или высотой, состоянием, если требуется, версией форка и временем приобретения. Руководство Ethereum использует `block_root:epoch_number`; инициализация CometBFT также связывает доверенный заголовок и набор валидаторов, а также параметры доверия. Правильный корень, прикрепленный к неправильной цепочке или высоте, не является допустимым якорем.

### 5. Обеспечить синхронизационный путь с закрытием при сбое

Настройте контрольную точку через задокументированный интерфейс клиента и сохраните журналы запуска. Во время синхронизации требуйте, чтобы канонический путь на эпохе контрольной точки соответствовал предоставленному `block_root`. Руководство Ethereum требует описательной критической ошибки и завершения процесса при сбое утверждения. Не отбрасывайте контрольную точку бесшумно, не возвращайтесь к большинству пирингов, не перезаписывайте её новым ответом пира и не сохраняйте подпись валидатора, пока его консенсусный вид остаётся неопределённым.

### 6. Разделите слои, которые были и не были проверены

Отслеживайте доверие контрольной точки консенсуса, верификацию маяка или блока консенсуса, статус полезной нагрузки выполнения, синхронизацию состояния выполнения, историческое восполнение и доказательства приложения отдельно. Оптимистичная синхронизация Ethereum позволяет предполагать `ExecutionPayload` якоря контрольной точки как `VALID` без предварочной передачи его исполнительному движку, в то время как оптимистичный узел не должен выполнять обязанности валидатора. Историческое восполнение контрольной точки Lighthouse проверяет целостность исторической цепочки хэшей и подписи предлагающих, но по умолчанию не восстанавливает каждое историческое состояние.

### 7. Обновляйте, контролируйте и отрабатывайте восстановление

Установите оповещение и обновляйте маржу с удобством в пределах применимого периода. Отслеживайте завершение, состояние часов, несогласие клиента, статус `execution_optimistic`, разнообразие участников, возраст контрольной точки и пробелы в обратной подкачке. Репетируйте восстановление из удалённой базы данных, истёкшей контрольной точки, противоречивых источников и недоступного поставщика. Храните подписанные записи об анкорах и решениях, но не позволяйте архивной контрольной точке стать постоянно доверенной устаревшей контрольной точкой.

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

## Рабочие примеры

### Контрольный пункт Ethereum с оставшимся запасом

Используйте иллюстративное состояние, для которого применимая ссылка на расчет Электры дает `ws_period = 3,532 epochs`. Предположим `current_epoch = 420,000`, а независимо подтвержденная контрольная точка — `checkpoint_epoch = 418,200`:

`checkpoint_age = 420,000 - 418,200 = 1,800 epochs`.

Тест актуальности гида — `420,000 <= 418,200 + 3,532`, поэтому контрольная точка находится в пределах периода. На `32 slots * 12 seconds = 6.4 minutes per epoch` его возраст составляет `1,800 * 6.4 / 1,440 = 8 days`. Оставшийся запас составляет `3,532 - 1,800 = 1,732 epochs`, или `1,732 * 6.4 / 1,440 = 7.6978 days`. Это использует период справочной таблицы, а не обещание живой сети; клиент должен вычислять исходя из фактической ветки и состояния.

### Истекший контрольный пункт не восстанавливается другими узлами

Предположим `current_epoch = 500,000`, `checkpoint_epoch = 496,000` и применимый `ws_period = 3,532 epochs`:

`checkpoint_age = 500,000 - 496,000 = 4,000 epochs`.

Поскольку `500,000 > 496,000 + 3,532`, контрольная точка устарела на `4,000 - 3,532 = 468 epochs`. При 6.4 минут на эпоху это на `468 * 6.4 / 60 = 49.92 hours` больше допустимого предела. Загрузка того же истекшего корня от 100 узлов не восстанавливает предположение; оператору нужна достаточно свежая контрольная точка из доверенных, подтвержденных каналов.

### Количество источников против независимости источника

Оператор получает пять ответов. Четыре сообщают `epoch = 600,000` и идентичный полный корень с маркировкой `root_A`, тогда как один сообщает другой полный корень с маркировкой `root_B`. Расследование показывает, что три согласующихся веб-сайта все используют один и тот же проксируемый узел; четвертый — это собственный узел оператора. Кажущееся согласие составляет `4 / 5 = 80%`, но оно представляет только две независимые линии. Согласно политике, требующей три независимых административных и информационных пути, контрольная точка еще не утверждена. Третий независимый оператор подтверждает `root_A`, отклоняющийся сервис изолирован, а запись происхождения объясняет решение.

### Бюджет на период доверия в стиле CometBFT

Рассмотрим цепочку, настроенную с `unbonding_period = 21 days`, и выбранный оператором `trusting_period = 14 days`, в соответствии с требованием, что период доверия должен быть короче периода разблокировки. Доверенный заголовок с возрастом `11 days` имеет `14 - 11 = 3 days` запас. Целевая ежедневная перезагрузка оставляет оперативный резерв. Если клиент возвращается после `16 days`, заголовок находится на два дня сверх своего периода доверия и должен быть заменен через новую инициализацию доверенного состояния; формулы эпох Ethereum не решают этот CometBFT случай.

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

## Риски и ошибки при проверке

- **Неверная сеть:** Действительный корень тестовой сети, форка, клона или другого генезиса может закрепить неверную историю.
- **Устаревшая контрольная точка:** Корень вне применимого периода больше не удовлетворяет предположению о недавнем наборе валидаторов.
- **Неверная формула периода:** Обновления форка, балансы, churn, анбондинг и параметры безопасности могут изменить границу.
- **Единый источник:** Несколько конечных точек могут использовать один узел, облачный аккаунт, базу данных, DNS-провайдера или оператора.
- **Скомпрометированное распространение:** Вредоносный релиз, сайт, пакет, DNS-ответ или сообщение поддержки может подменить контрольную точку.
- **Сокращенное сравнение:** Сравнение только префикса, снимка экрана или форматированного идентификатора может скрыть отличие полного корня.
- **Несовпадение полей:** Правильный корень с неверной эпохой, высотой, состоянием, форком или сетью не является той же контрольной точкой.
- **Откат к большинству пиров:** Узел под eclipse-атакой может видеть много враждебных пиров; их число не отменяет доверенный якорь.
- **Тихий откат:** Клиент или обертка, игнорирующие отклоненную точку, нарушают режим fail-closed.
- **Конфликтующие финализированные истории:** Новый узел не разрешает сбой консенсуса только потому, что обе ветви помечены финализированными.
- **Ошибка часов:** Неверное местное время искажает проверки слота, эпохи, возраста, периода доверия и будущих заголовков.
- **Путаница оптимистического состояния:** Импортированный консенсусный блок может содержать не полностью проверенный execution payload.
- **Преждевременные обязанности валидатора:** Подписание в оптимистическом, несинхронизированном или неопределенном состоянии может вызвать неверные голоса или слэшинг.
- **Путаница исторической полноты:** Синхронизация и backfill могут пропускать исторические состояния, даже если текущая вершина действительна.
- **Недействительные подписи backfill:** Исторический блок в хэш-цепочке все равно требует проверки подписи предлагающего.
- **Недостаточное доказательство исполнения или приложения:** Якорь консенсуса не доказывает произвольные значения RPC, утверждения контракта или внецепочечные индексы.
- **Пробел доступности данных:** Знание корня состояния не гарантирует доступ ко всем телам, Blob, свидетелям или историческим записям.
- **Истекший план восстановления:** Если истечение обнаружено во время сбоя, независимый источник точки может быть недоступен.
- **Захват социальной координации:** Управление, команды клиентов, обозреватели, биржи и операторы могут иметь общие стимулы или зависимости.
- **Ложная универсальность:** Другая конструкция PoS может использовать иные предположения, цепочки доказательств, периоды доверия или гарантии загрузки с генезиса.

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

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

### Означает ли слабая субъективность, что правила протокола являются субъективными после запуска?

Нет. Узел принимает конкретный недавний якорь через социальный или доверенный канал, затем применяет детерминированную проверку и правила выбора форка дальше. Блоки, которые конфликтуют с якорем, отклоняются.

### Является ли любой завершённый контрольный пункт автоматически безопасным контрольным пунктом загрузки?

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

### Удаляет ли синхронизация с генезиса проблему дальнобойной атаки?

Не подходит для протокола, модель безопасности которого требует недавней контрольной точки с слабой субъективностью. Повторное использование внутренне допустимых подписей с момента генезиса не сообщает новому узлу, какую из двух старых завершённых историй на самом деле соблюдала сеть. Другие протоколы могут обеспечивать различные гарантии начальной загрузки генезиса при иных предположениях.

### Синхронизация контрольной точки проверяет всю историческую работу и состояние?

Нет. Поведение клиента многослойное и зависит от реализации. Узел может доверять опорной точке или оптимистично её импортировать, синхронизировать текущее состояние выполнения отдельно и заполнять только ссылки на блоки и подписи предложивших, не восстанавливая все исторические состояния.

### Можно ли навсегда доверять жёстко закодированной контрольной точке?

Нет. Контрольная точка привязана к сети, и точка. Она может оставаться полезной в качестве аудиторской записи или исторического ограничения, но узлу, чье недавнее доверительное допущение истекло, требуется соответствующий недавно созданный якорь или процесс восстановления, указанный в этом протоколе.

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

## Связанные темы

- [Окончательность](/ru/crypto/finality/)
- [Правило выбора ветви](/ru/crypto/fork-choice-rule/)
- [Доказательство доли](/ru/crypto/proof-of-stake/)
- [Рубящий](/ru/crypto/slashing/)
- [Лёгкий клиент](/ru/crypto/light-client/)

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

## Источники

- [Слабая субъективность](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (доступ: 2026-08-19)
- [Фаза 0 -- Руководство Weak Subjectivity](https://ethereum.github.io/consensus-specs/specs/phase0/weak-subjectivity/) - Ethereum Спецификации консенсуса (доступ: 2026-08-19)
- [Electra -- Руководство Weak Subjectivity](https://ethereum.github.io/consensus-specs/electra/weak-subjectivity/) - Ethereum Спецификации консенсуса (доступ: 2026-08-19)
- [Фаза 0 -- P2P интерфейс](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Спецификации консенсуса (доступ: 2026-08-19)
- [Оптимистичная синхронизация](https://ethereum.github.io/consensus-specs/sync/optimistic/) - Ethereum Спецификации консенсуса (доступ: 2026-08-19)
- [Синхронизация контрольной точки](https://lighthouse-book.sigmaprime.io/advanced_checkpoint_sync.html) - Lighthouse Book (доступ: 2026-08-19)
- [Проверка ядра CometBFT](https://docs.cometbft.com/v0.38/spec/light-client/verification/) - CometBFT (доступ: 2026-08-19)
- [Ouroboros Genesis: Комбинируемые блокчейны Proof-of-Stake с динамической доступностью](https://eprint.iacr.org/2018/378.pdf) - IACR Cryptology ePrint Archive (доступ: 2026-08-19)

Source: https://wiki.fcontext.com/ru/crypto/weak-subjectivity/index.mdx