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

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

Очередь выхода валидатора ограничивает скорость, с которой консенсусный вес может покидать активный набор валидаторов. Это не обязательно тот же самый механизм, что и очередь запросов на снятие, задержка разъединения или ответственности, автоматическая обработка доступных балансов, инициированная пользователем заявка или очередь выкупа у поставщика стейкинга. Полезный вопрос не "какова длина очереди?", а "в каком состоянии находится эта позиция, какой переход следующий и какое условие делает актив доступным для его владельца?"

Разделите эти этапы и требования:

- **Принятие запроса:** подписанное сообщение, транзакция, вызов контракта или инструкция провайдера действительны включены и приписаны правильному валидатору, аккаунту или позиции.
- **Выходная мощность или способность к деактивации:** — это протокол, который ограничивает, сколько валидаторов или эффективного веса может прекратить участие за эпоху, сессию или другой интервал.
- **Ответственность или задержка разъединения:** освобожденная или неделегированная позиция остается заблокированной и может продолжать подвергаться штрафам за предыдущее поведение, за которое она ответственна.
- **Обработка вывода средств:** подходящий баланс продвигается протоколом sweep, забирается транзакцией claim, высвобождается со счета stake или переводится при обработке очереди maturity.
- **Выкуп поставщиком:** как хранитель, пул, токен с жидким стейкингом или контракт на повторный стейкинг применяет свои собственные методы пакетирования, ликвидность, комиссии, обменный курс, разрешения и задержки поверх базового протокола.

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

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

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

## Как анализировать время выхода и отзыва

### 1. Определите позицию и набор правил

Запишите `network`, `chain ID`, активную ветку или среду выполнения, блок или эпоху, версию клиента/спецификации, модуль стекинга или контракты и условия предоставления услуг. Определите, является ли объект идентификатором валидатора, собственным стейком, делегированными долями, стейк-аккаунтом, объединенным требованием, токеном ликвидного стекинга или повторно застейканным распределением. Не применяйте правило выхода валидатора к выкупу делегатора или внецепочной ответственности провайдера.

### 2. Проверьте полномочия и запросите подтверждение

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

### 3. Восстановите конечный автомат

Записывайте каждое состояние и переход, а не одну предполагаемую дату. Иллюстративный путь валидатора — `active -> exit_requested -> exit_scheduled -> exited -> withdrawable -> withdrawal_processed -> wallet_credited`. Делегатор может вместо этого пройти через `bonded -> unbonding -> matured -> transferred`, в то время как аккаунт с ставкой может быть `active -> deactivating -> inactive -> withdrawn`. Запишите, какие переходы автоматические, а какие требуют другой транзакции или действия сервиса.

### 4. Количественно оцените каждое узкое место

Разделите лимиты запроса-входа, выход валидатора, фиксированные задержки, пропускную способность вывода-сме́тки, очереди контрактов, пакетную обработку поставщиков и финальность или подтверждение. Определите, измеряется ли пропускная способность по записям валидатора, эффективной ставке, балансу, запросам, газу или прошедшему времени. Запросите `queue_ahead`, `capacity_per_interval`, размер активного набора или баланс, а также любые ограничения в той же точке окончательного наблюдения. Простая оценка `ceil((work_ahead + own_work) / capacity)` действительна только тогда, когда предполагаются порядок и пропускная способность.

### 5. Определите обязанности, награды и возможность штрафов

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

### 6. Отслеживайте актив и слои претензий

Отслеживайте местные единицы от заблокированных или активных на учете через ожидающие, разблокируемые, доступные для снятия, эскроу по контракту, хранение у провайдера и конечный счет. Отдельно оценивайте доли, токены-талончики или токены ликвидного стекинга, используя их обменный курс и рыночную цену. Сверяйте вознаграждения протокола, штрафы, срезы (slashing), комиссионные, сборы за выкуп, газ, расходы на мост и округления. Продажа претензии передает риск ликвидности покупателю; это не ускоряет базовый переход протокола.

### 7. Проверьте завершение и план ликвидности

Используйте окончательное состояние, события протокола, записи очереди, объекты вывода, остатки на счетах назначения и обязательства поставщика, чтобы доказать каждое изменение. Сохраняйте идентификаторы запросов и снимок параметров, использованных для оценки. Стройте денежные планы с диапазоном и резервом на случай непредвиденных обстоятельств, а не с одной датой, и определяйте порядок эскалации в случае пропущенных свипов, приостановленных контрактов, неверных учетных данных, неплатежеспособности поставщика или остатка, который отличается от ожидаемой сверки.

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

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

### Многоступенчатый расчет времени

Рассмотрим иллюстративный протокол с `block_time = 12 seconds` и `epoch = 30 blocks = 6 minutes`. Запрос занимает `4 blocks`, чтобы достичь выбранной точки подтверждения, ожидает `72 epochs` наличия пропускной способности на выходе, затем имеет задержку ответственности `8 epochs` и ожидаемое время `12 blocks` до обработки передачи:

`4 * 12 = 48 seconds`.

`72 * 6 = 432 minutes`.

`8 * 6 = 48 minutes`.

`12 * 12 = 144 seconds = 2.4 minutes`.

Общее иллюстративное время составляет `48 seconds + 432 minutes + 48 minutes + 2.4 minutes = 483.2 minutes = 8.0533 hours`. Этапы суммируются, потому что они последовательны. Это не прогноз Ethereum: реальные правила могут использовать разные интервалы, зависимый от состояния отток, минимальные задержки, алгоритмы обхода и предположения о финальности.

### Очередь с весом с изменяющейся ёмкостью

Предположим, что эффективные единицы `work_ahead = 50,000`, этот выход представляет `own_work = 320`, а начальный `capacity_per_epoch = 640`. При постоянной мощности:

`ceil((50,000 + 320) / 640) = ceil(78.625) = 79 epochs`.

На `6 minutes` за эпоху, это `79 * 6 = 474 minutes = 7.9 hours`. Но предположим, что ёмкость падает до `512` после эпохи 30. Первые 30 эпох обрабатывают `30 * 640 = 19,200`, оставляя `50,320 - 19,200 = 31,120`. Остальное занимает `ceil(31,120 / 512) = 61 epochs`, так что пересчитанный итог составляет `30 + 61 = 91 epochs = 9.1 hours`. Живую оценку необходимо пересчитывать с учётом ёмкости и порядка, а не фиксировать одну скорость на панели.

### Сверка баланса при выходе

Иллюстративный валидатор начинается с единиц `32`, зарабатывает `0.40` до окончания обязанностей, несет `0.05` обычных штрафов и позже получает `1.20` сокращения, связанного с окном воздействия протокола. Сумма, доступная до любых сборов провайдера или налога, составляет:

`32 + 0.40 - 0.05 - 1.20 = 31.15 units`.

Запрос не зафиксировал выплату в единицах 32. Изменения баланса протокола, учет провайдера и изменения рыночной цены ведутся в отдельных учетных книгах. Если пункт назначения получает `31.15`, это согласует путь в нативных единицах, но не говорит ничего о фиатной стоимости или правах на возмещение.

### Заявка на ликвидность против очередного выкупа

Предположим, что токены liquid-staking `100` могут быть проданы сейчас по `0.965` единиц каждой, что принесет:

`100 * 0.965 = 96.5 units`.

Поставщик вместо этого указывает выкуп по одной нативной единице за токен после очереди с комиссией `0.2%`, или `100 * (1 - 0.002) = 99.8 units`. Разница составляет `99.8 - 96.5 = 3.3 units`, а скидка при немедленной продаже относительно указанных доходов в очереди составляет `3.3 / 99.8 = 3.3066%`. Спред в 3.3 единиц компенсирует только время, неопределённость и ликвидность в этом снимке; снижение, изменения обменного курса, потеря контракта или приостановка очереди могут изменить последующие доходы.

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

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

- **Неверная очередь:** Очереди выхода валидаторов, приема запросов на вывод, анбондинга, обхода, контрактов и погашения у провайдера имеют разные состояния и пропускную способность.
- **Неверный набор правил:** Другая сеть, форк, среда выполнения, версия модуля, тестовая сеть или развертывание контракта может использовать иные переходы.
- **Устаревшие параметры:** Скорость выхода, фиксированные задержки, лимиты обхода, комиссии, блокировки и условия провайдера могут измениться после расчета.
- **Запрос не принят:** Подписание, отправка, симуляция или открытие тикета не доказывает окончательное принятие запроса протоколом.
- **Путаница с полномочиями:** Ключи валидатора, вывода, стейка, владельца, хранителя и администратора контракта могут разрешать разные действия.
- **Ошибка учетных данных или адреса:** Необратимое преобразование учетных данных или неверный адрес вывода может навсегда передать контроль.
- **Преждевременное отключение:** Прекращение обязанностей до зафиксированного состояния выхода может привести к потере наград или штрафам.
- **Ошибка момента прекращения наград:** Запрос, запланированный и фактический выход, доступность вывода и перевод могут подчиняться разным правилам начисления.
- **Сохраняющийся риск слэшинга:** Вышедшие, находящиеся в анбондинге или очереди средства могут оставаться уязвимыми из-за ранее совершенных нарушений.
- **Несоответствие количества и веса:** Очередь в количестве валидаторов может не отражать пропускную способность, ограниченную эффективным балансом или долями.
- **Ошибка динамической очереди:** Последующие изменения параметров или активного набора могут изменить пропускную способность, даже если новые запросы не могут обойти старые.
- **Путаница между обходом и заявкой:** После достижения права средства могут отправиться автоматически, потребовать заявки или продолжить ждать циклического обхода.
- **Путаница частичного и полного вывода:** Вывод избыточного баланса, частичная отмена делегирования и полный выход валидатора не равнозначны.
- **Блокировки и удержания:** Блокировки счета, меры управления, паузы безопасности или удержания внешнего модуля могут продолжаться после номинального срока.
- **Несоответствие провайдера:** Сервис может задержать, объединить, ограничить, зачесть или отклонить погашение даже после завершения базового протокола.
- **Пересечение с рестейкингом:** Выход из базовой сети может не освободить стейк, выделенный другому сервису, и не завершить его штрафной период.
- **Базисный риск ликвидного требования:** Токен ликвидного стейкинга может торговаться ниже стоимости требования или потерять конвертируемость при стрессе.
- **Комиссии и потери округления:** Газ, динамические комиссии, вознаграждение провайдера, пересчет долей, комиссии моста и изменение десятичных разрядов влияют на полученную сумму.
- **Сбой хранения или контракта:** Компрометация ключей, неплатежеспособность, права обновления, ошибки или сбой моста могут заблокировать или перенаправить активы.
- **Ошибка наблюдаемости и окончательности:** Панели могут отставать, пропускать удерживаемые записи, путать оценочный и окончательный статус или показывать событие, позже удаленное реорганизацией.

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

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

### Означает ли подача заявления на выход, что обязанности валидатора прекращаются немедленно?

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

### Означает ли «выводимый» то, что целевой кошелек был зачислен?

Нет. `withdrawable` обычно описывает право на участие. Протокол все еще может нуждаться в проверке валидатора, пользователю может потребоваться запросить средства, с аккаунта может потребоваться явное снятие, или провайдеру может потребоваться снять свою ответственность. Проверьте баланс назначения.

### Может ли длина очереди, делённая на сегодняшний темп, дать точную дату?

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

### Продает ли токен с жидким стекингом обход очереди выхода?

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

### Является ли рекламируемый период разблокировки или вывода средств гарантированным максимумом?

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

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

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

- [Валидатор](/ru/crypto/validator/)
- [Рубящий](/ru/crypto/slashing/)
- [Стейкинг](/ru/crypto/staking/)
- [Жидкий стекинг](/ru/crypto/liquid-staking/)
- [Повторная ставка](/ru/crypto/restaking/)

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

## Источники

- [Вывод средств из стекинга](https://ethereum.org/staking/withdrawals/) - Ethereum.org (доступ: 2026-08-19)
- [Спецификации консенсуса Ethereum: Цепочка маяков](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (доступ: 2026-08-19)
- [Спецификации консенсуса Ethereum: Capella](https://github.com/ethereum/consensus-specs/blob/master/specs/capella/beacon-chain.md) - Ethereum Foundation (доступ: 2026-08-19)
- [Спецификации консенсуса Ethereum: Electra](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md) - Ethereum Foundation (доступ: 2026-08-19)
- [EIP-7002: Выплаты с исполнительного уровня с возможностью инициирования](https://eips.ethereum.org/EIPS/eip-7002) - Ethereum Improvement Proposals (доступ: 2026-08-19)
- [Cosmos SDK модуль x/staking](https://docs.cosmos.network/sdk/v0.50/build/modules/staking/README) - Cosmos SDK (доступ: 2026-08-19)
- [Stake Accounts](https://solana.com/docs/references/staking/stake-accounts) - Solana Foundation (доступ: 2026-08-19)
- [EigenLayer МенеджерДелегации](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/DelegationManager.md) - Eigen Labs (доступ: 2026-08-19)

Source: https://wiki.fcontext.com/ru/crypto/validator-exit-withdrawal-queue/index.mdx