﻿---
title: "Атаки stake grinding: смещение случайности в Proof of Stake"
description: "При stake grinding атакующий ищет среди допустимых ключей, блоков или вкладов случайности результат, улучшающий будущий выбор валидаторов. Разберите пути атаки, преимущество перебора и защиты протокола."
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.

# Атаки stake grinding: смещение случайности в Proof of Stake

> Только учебный анализ безопасности протокола. Случайность, выбор лидера, штрафы и стоимость атаки зависят от протокола и версии; проверяйте действующие спецификацию и реализацию до выводов о безопасности или стейкинге.

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

## Краткий ответ

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

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

Хеш, проверяемая случайная функция (VRF) или commit-reveal сами по себе не делают весь процесс несмещённым. Важны автор каждого входа, момент раскрытия eligibility, число альтернатив, дополнительный выбор через отказ и временное отделение seed от выбранных им лидеров. Проверять нужно точную версию протокола.

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

## Путь атаки и анализа

1. **Зафиксируйте правило.** Запишите сеть, версию, эпоху или раунд, снимок stake, вывод seed, тест eligibility, fork choice, награды и штрафы.
2. **Опишите выбор противника.** Учтите ключи до регистрации, корректные порядки, необязательные поля, блоки-родители, публикацию, reveal и отказы; важен лишь выбор, меняющий принятые состояние или seed.
3. **Измерьте бюджет перебора.** Оцените число кандидатов до срока, независимость и затраты вычислений, потерянных наград, депозитов, задержек или наказуемых действий.
4. **Свяжите seed с властью.** Определите горизонт выбора proposer или комитетов, видит ли атакующий результат до обязательства и создаёт ли успех новый перебор.
5. **Оцените принятие и накопление.** Кандидат обязан пройти правила перехода, времени, подписи и fork choice. Моделируйте повторы как процесс с состоянием, не считая раунды независимыми.
6. **Проверьте каждую защиту.** Отложенные seed, VRF, регистрация, штрафы, пороговые маяки и проверяемые функции задержки покрывают разные возможности и допущения.

Сохраняйте блоки или commitments, точные хеши и домены, время, снимки, реализованный расчёт seed и контрфактические результаты. Серия предложений не доказательство: честная лотерея тоже создаёт кластеры.

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

## Развёрнутый пример

Упрощённый протокол даёт атакующему `10%` вероятности стать следующим proposer. При одном фиксированном seed это `0.10`. Ошибка позволяет почти бесплатно проверить `20` независимых корректных seed и опубликовать любой.

Вероятность выбора хотя бы одним равна `1 - (1 - 0.10)^20`, примерно `87.8%`. У атакующего не `87.8%` stake: протокол ошибочно дал `20` розыгрышей и выбор после просмотра результатов.

Это иллюстрация, не прогноз. Корреляция, сроки, расходы, потеря наград, наказание за удержание и ограниченная власть proposer снижают эффект. Их следует измерить до оценки экономического либо консенсусного ущерба.

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

## Защита и контрольный список

### Построение случайности

- Выводите случайность из входов, зафиксированных до того, как участники узнают или смогут контролировать назначения.
- Разделяйте вклад, commitment, reveal и использование, чтобы лидер не перебирал дёшево seed непосредственного преемника.
- Учитывайте последнего раскрывающего: commit-reveal остаётся смещаемым, если удержание даёт выбор результата.
- Применяйте пороговые или распределённые маяки с явными допущениями о честности, liveness, восстановлении и составе.

### Eligibility и личность

- Привязывайте VRF-ключи и stake к снимку до раскрытия seed, иначе офлайн-генерация становится перебором ключей.
- Разделяйте домены по chain, версии, раунду, роли и назначению, исключая повторное применение доказательств.
- Используйте скрытую eligibility, где уместно; она снижает раннее нацеливание, но не исправляет смещённый seed.
- Ограничьте дешёвую смену личностей и определите участие делегированного stake, пулов и меняющихся наборов.

### Экономика и эксплуатация

- Оцените пропущенные блоки и награды, замороженный капитал, выявляемую equivocation и коррелированные штрафы; не любой законный выбор наказуем.
- Отслеживайте вклады, пропущенные reveal, необычных кандидатов, частоты proposer и разнообразие ПО на значимых интервалах.
- Изолируйте критическую случайность от произвольных builder, relay и сортировки, если их безвредность не доказана.
- Тестируйте fallback: механизм, несмещённый лишь при ответе всех, может пожертвовать liveness.

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

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

- **Хеши случайны, значит перебор невозможен.** Непредсказуемый для одного входа хеш можно сместить выбором среди многих входов.
- **VRF устраняет весь grinding.** Она доказывает выход; ключи, seed, регистрация и выборочная публикация остаются отдельными вопросами.
- **Commit-reveal автоматически несмещён.** Последний участник может выбирать между reveal и отказом, если эта опция не нейтрализована.
- **Нужно большинство stake.** Меньшинство с дешёвыми попытками повышает шанс; для нарушения безопасности нужны дополнительные условия.
- **Последовательные предложения доказывают манипуляцию.** Случайность создаёт серии; нужны статистическая модель и технические доказательства.
- **Grinding и nothing at stake одинаковы.** Первый смещает случайность или eligibility, второй касается стимула поддерживать конкурирующие истории.

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

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

- [Proof of stake](/ru/crypto/proof-of-stake/)
- [Валидаторы](/ru/crypto/validator/)
- [Криптографические хеши](/ru/crypto/cryptographic-hash/)
- [Правила fork choice](/ru/crypto/fork-choice-rule/)
- [Nothing at stake](/ru/crypto/nothing-at-stake/)

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

## Источники

- [Криптовалюты без Proof of Work](https://arxiv.org/abs/1406.5694) - arXiv (дата обращения: 2026-08-21)
- [Ouroboros: доказуемо безопасный блокчейн-протокол Proof of Stake](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (дата обращения: 2026-08-21)
- [Ouroboros Praos: адаптивно безопасный полусинхронный протокол Proof of Stake](https://eprint.iacr.org/2017/573) - IACR Cryptology ePrint Archive (дата обращения: 2026-08-21)
- [Algorand: масштабирование византийского соглашения для криптовалют](https://doi.org/10.1145/3132747.3132757) - ACM (дата обращения: 2026-08-21)
- [Спецификации консенсуса Ethereum: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (дата обращения: 2026-08-21)

Source: https://wiki.fcontext.com/ru/crypto/stake-grinding-attack/index.mdx
