---
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.
# 검증자 종료 및 출금 대기열
> 교육 목적으로만 사용됩니다; 투자 조언이 아닙니다. 투자는 손실을 초래할 수 있습니다.
## 직접적인 답변
검증자 종료 대기열은 합의 가중치가 활성 검증자 세트에서 얼마나 빨리 나갈 수 있는지를 제한합니다. 이것은 반드시 출금 요청 대기열, 언본딩 또는 책임 지연, 사용 가능한 잔액의 자동 청산, 사용자가 시작한 청구, 또는 스테이킹 제공자의 상환 대기열과 동일한 메커니즘은 아닙니다. 중요한 질문은 '대기열이 얼마나 긴가?'가 아니라 '이 위치가 어느 상태에 있는가, 다음 전환은 무엇인가, 그리고 어떤 조건에서 자산을 소유자가 사용할 수 있는가?'입니다.
이 단계와 청구를 분리하세요:
- **요청 수락:** 서명된 메시지, 거래, 계약 호출 또는 제공자 지침이 올바르게 포함되고 올바른 검증자, 계정 또는 위치에 귀속됩니다.
- **종료 또는 비활성화 용량:** 는 프로토콜이 각 에포크, 세션 또는 다른 구간마다 검증자 수나 유효 가중치가 참여를 중단할 수 있는 양을 제한하는 방법입니다.
- **책임 또는 언본딩 지연:** 종료되었거나 위임되지 않은 위치는 잠긴 상태로 남아 있으며, 이전 행동에 대한 책임으로 인한 처벌에 계속 노출될 수 있습니다.
- **출금 처리:** 적격 잔액은 프로토콜 스윕에 의해 밀리거나, 청구 거래에 의해 끌어당겨지거나, 스테이크 계정에서 해제되거나, 만기 큐가 처리될 때 이체됩니다.
- **제공자 상환:** 관리인, 풀, 유동성 스테이킹 토큰 또는 재스테이킹 계약은 기본 프로토콜을 중심으로 자체적인 배치, 유동성, 수수료, 환율, 권한 및 지연을 적용합니다.
Ethereum는 왜 이러한 구분이 중요한지를 보여줍니다. 전체 밸리데이터 종료는 밸리데이터 서명 키로 시작할 수 있으며, 현재 규칙 하에서는 출금 권한에 의해 실행 계층에서 시작할 수도 있습니다. 종료 예약과 이후 출금 가능한 상태 후에는, 실행 출금 자격 증명을 가진 적합한 전체 출금이 자동으로 처리됩니다. 레거시 Type 1 밸리데이터와 복리 Type 2 밸리데이터는 부분 출금 동작이 다릅니다. 따라서 요청 트랜잭션, 합의 종료, 출금 가능한 에포크, 그리고 스윕은 별도의 관찰로 나뉩니다.
그 Ethereum 라벨은 보편적이지 않습니다. Cosmos SDK 체인에서는 위임자의 위임 해지가 체인 설정 완료 시간과 함께 언본딩 항목을 생성하며, 외부 모듈은 언본딩을 보류할 수 있습니다. Solana에서는 스테이크 계정 권한이 위임을 비활성화하고, 스테이크는 에포크 경계를 넘어 냉각되며, 출금 권한자는 잠금 조건에 따라 비활성 스테이크를 출금할 수 있습니다. 재스테이킹 계약은 또 다른 대기 중인 출금과 벌칙 가능 창을 추가할 수 있습니다. 항상 정확한 네트워크, 버전, 모듈, 계약 및 서비스 조건을 확인하십시오.
## 퇴출 및 철수 시점 분석 방법
### 1. 위치와 규칙을 정의하세요
`network`, `chain ID`, 활성 포크 또는 런타임, 블록 또는 에포크, 클라이언트/사양 버전, 스테이킹 모듈 또는 계약, 그리고 서비스 약관을 기록하십시오. 객체가 검증자 신원, 자기 스테이크, 위임된 지분, 스테이크 계정, 풀링 클레임, 유동 스테이킹 토큰, 또는 재스테이킹 할당인지 확인하십시오. 위임자 상환이나 제공자의 오프체인 책임에 검증자 종료 규칙을 적용하지 마십시오.
### 2. 권한을 확인하고 수락을 요청하십시오
검증자 서명 키, 인출 자격 증명 또는 권한, 스테이크 권한, 계정 소유자, 계약 호출자, 수혜자 및 수수료 지급자를 매핑하십시오. 필요한 메시지 필드, 서명 도메인, 검증자 인덱스 또는 공개 키, 금액, 논스, 목적지 및 수수료를 재현하십시오. 완료된 포함과 결과 상태를 확인하십시오; 로컬에서 서명된 파일, 제출된 거래, 제공자 티켓 또는 성공적인 시뮬레이션은 프로토콜이 요청을 수락했다는 증거가 아닙니다.
### 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. 자산 및 청구 계층을 추적하세요
결합되거나 활성 회계에서 보류, 언본딩, 인출 가능, 계약 에스크로, 제공자 수탁, 최종 계정까지 네이티브 단위를 추적합니다. 교환 비율과 시장 가격을 사용하여 주식, 영수증 토큰 또는 유동 스테이킹 토큰을 개별적으로 평가합니다. 프로토콜 보상, 벌금, 슬래싱, 수수료, 상환 수수료, 가스, 브리지 비용 및 반올림을 조정합니다. 청구권을 판매하면 유동성 위험이 구매자에게 이전되며, 기본 프로토콜 전환을 가속화하지는 않습니다.
### 7. 완료 여부를 확인하고 유동성을 계획하십시오
최종 상태, 프로토콜 이벤트, 대기열 기록, 출금 객체, 목적지 계좌 잔액 및 제공자 부채를 사용하여 각 전환을 증명하십시오. 요청 식별자와 추정에 사용된 매개변수 스냅샷을 저장하십시오. 단일 날짜 대신 범위와 긴급 대비 버퍼를 사용하여 현금 계획을 수립하고, 누락된 스윕, 일시 중단된 계약, 잘못된 인증 정보, 제공자 지급 불능 또는 예상 조정과 다른 잔액에 대한 에스컬레이션을 정의하십시오.
## 작동된 예제
### 다단계 타이밍 계산
`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`마다 한 epoch당, 그것은 `79 * 6 = 474 minutes = 7.9 hours`입니다. 그러나 capacity가 epoch 30 이후에는 `512`로 감소한다고 가정합니다. 처음 30개의 epoch는 `30 * 640 = 19,200`를 처리하여 `50,320 - 19,200 = 31,120`가 남습니다. 나머지는 `ceil(31,120 / 512) = 61 epochs`가 걸리므로, 수정된 총량은 `30 + 61 = 91 epochs = 9.1 hours`입니다. 실시간 추정치는 하나의 대시보드 속도를 고정하기보다는 capacity와 순서를 다시 계산해야 합니다.
### 퇴출을 통한 잔액 조정
예시 검증자는 `32` 단위로 시작하여, 의무가 끝나기 전에 `0.40`를 벌고, 일반 벌금으로 `0.05`를 부담하며, 나중에 프로토콜의 노출 창에 따라 `1.20`의 슬래싱을 받습니다. 공급자 수수료나 세금 전 사용 가능한 금액은:
`32 + 0.40 - 0.05 - 1.20 = 31.15 units`.
이 요청은 32-단위 지급을 확정하지 않았습니다. 프로토콜 잔액 변경, 제공자 회계, 시장 가격 변화는 별도의 장부입니다. 목적지가 `31.15`를 받으면 해당 원화 단위 경로는 조정되지만, 법정화폐 가치나 환급 권리에 대해서는 아무것도 말해주지 않습니다.
### 유동 청구 대 대기 중 환매
`100` 리퀴드 스테이킹 토큰을 지금 단위당 `0.965` 네이티브 단위로 판매할 수 있다고 가정하면, 수익은 다음과 같습니다:
`100 * 0.965 = 96.5 units`.
한 공급자는 대신 `0.2%` 수수료가 있는 대기열 후 토큰당 1개의 기본 단위로 상환을 인용하거나 `100 * (1 - 0.002) = 99.8 units`로 인용합니다. 차이는 `99.8 - 96.5 = 3.3 units`이며, 인용된 대기열 수익에 대한 즉시 매도 할인은 `3.3 / 99.8 = 3.3066%`입니다. 3.3 단위 스프레드는 이 스냅샷에서만 시간, 불확실성 및 유동성에 대한 보상이며, 감액, 환율 변동, 계약 손실 또는 대기열 일시 중단으로 인해 이후 수익은 달라질 수 있습니다.
## 위험과 검토 실패
- **잘못된 대기열 선택:** 검증자 종료, 출금 요청 접수, 언본딩, 스윕, 계약 및 사업자 상환 대기열은 상태와 처리 용량이 서로 다릅니다.
- **잘못된 규칙 집합:** 다른 체인, 포크, 런타임, 모듈 버전, 테스트넷 또는 계약 배포에는 다른 상태 전이가 적용될 수 있습니다.
- **오래된 매개변수:** 이탈률, 고정 지연, 스윕 한도, 수수료, 잠금 및 사업자 약관은 추정 후 바뀔 수 있습니다.
- **수락되지 않은 요청:** 서명, 전파, 시뮬레이션 또는 티켓 생성만으로는 프로토콜의 최종 수락이 입증되지 않습니다.
- **권한 혼동:** 검증자, 출금, 스테이크, 소유자, 수탁자 및 계약 관리자 키는 서로 다른 작업을 승인할 수 있습니다.
- **자격 증명 또는 목적지 오류:** 되돌릴 수 없는 자격 증명 변환이나 잘못된 출금 주소는 자산 통제권을 영구적으로 이전할 수 있습니다.
- **조기 종료:** 기록된 종료 상태가 되기 전에 검증 업무를 중단하면 보상을 잃거나 페널티를 받을 수 있습니다.
- **보상 종료 시점 오류:** 요청, 예약된 종료, 실제 종료, 출금 가능 및 전송 시점에는 서로 다른 적립 규칙이 적용될 수 있습니다.
- **잔여 슬래싱 위험:** 종료되었거나 언본딩 또는 대기 중인 자금도 과거의 귀책 위반으로 슬래싱될 수 있습니다.
- **개수와 가중치 불일치:** 검증자 수로 표시된 대기열은 유효 잔액이나 지분으로 제한되는 처리 용량을 정확히 나타내지 못할 수 있습니다.
- **동적 대기열 오류:** 뒤의 요청이 앞지르지 못하더라도 이후 매개변수나 활성 집합 변화로 처리량은 달라질 수 있습니다.
- **스윕과 청구 혼동:** 자격을 갖춘 뒤 자동 전송될 수도, 청구가 필요할 수도, 순환 스윕을 더 기다려야 할 수도 있습니다.
- **부분과 전체의 혼동:** 초과 잔액 출금, 부분 위임 해제, 검증자의 완전한 종료는 동일하지 않습니다.
- **잠금과 보류:** 계정 잠금, 거버넌스 통제, 보안 일시 중지 또는 외부 모듈 보류는 명목 만기 이후까지 지속될 수 있습니다.
- **사업자 불일치:** 기본 프로토콜이 완료되어도 사업자는 상환을 지연하거나 일괄 처리, 제한, 상계 또는 거부할 수 있습니다.
- **리스테이킹 중첩:** 기본 체인에서 종료해도 다른 서비스에 할당된 스테이크가 해제되거나 해당 페널티 기간이 끝난다고 볼 수 없습니다.
- **유동성 청구권 베이시스 위험:** 리퀴드 스테이킹 토큰은 스트레스 상황에서 청구 가치보다 낮게 거래되거나 전환 가능성을 잃을 수 있습니다.
- **수수료와 반올림 손실:** 가스, 동적 요청 수수료, 커미션, 지분 변환, 브리지 수수료와 소수 자릿수 변경은 실제 수령액에 영향을 줍니다.
- **수탁 및 계약 실패:** 키 탈취, 지급 불능, 업그레이드 권한, 버그 또는 브리지 실패는 자산을 차단하거나 유출시킬 수 있습니다.
- **관찰 가능성과 최종성 오류:** 대시보드는 지연되거나 보류 항목을 누락하고, 추정 상태와 최종 상태를 혼동하거나 리오그된 이벤트를 표시할 수 있습니다.
## 일반적인 오해
### 출구를 제출하면 검증자 의무가 즉시 중단되는 것인가요?
아니요. 요청 포함, 종료 일정, 그리고 업무가 종료되는 상태는 별개입니다. 최종 상태가 검증자가 더 이상 참여할 필요가 없음을 확인할 때까지 프로토콜에 따라 계속 운영하십시오.
### '출금 가능'이라는 것은 목적지 지갑에 입금되었음을 의미합니까?
아니요. `withdrawable`는 일반적으로 적격성을 설명합니다. 프로토콜은 여전히 검증자를 확인해야 할 수 있고, 사용자가 청구해야 할 수 있으며, 계정이 명시적인 출금을 필요로 하거나 공급자가 그 책임을 해제해야 할 수 있습니다. 목적지 잔액을 확인하십시오.
### 대기열 길이를 오늘 속도로 나누면 정확한 날짜를 알 수 있나요?
아니요. 디스플레이가 잘못된 단위를 표시할 수 있고, 용량은 상태에 따라 달라질 수 있으며, 고정 지연과 스윕 시간이 따를 수 있고, 공급 단계가 생략될 수 있습니다. 모든 가정을 명시하고 범위를 계산하세요.
### 리퀴드 스테이킹 토큰을 판매하면 출구 대기열을 우회할 수 있나요?
구매자가 존재하는 경우 판매자에게 즉각적인 시장 유동성을 제공합니다. 기초 지분이나 다른 보유자의 상환 청구는 여전히 프로토콜과 제공자 규칙을 따르며, 판매자는 시장 가격과 거래 비용을 수락합니다.
### 광고된 언본딩 또는 출금 기간이 보장된 최대치인가요?
아니요. 요청 포함, 혼잡, 최종성, 스윕, 보류, 계약 일시 중지, 제공자 배치 또는 사고 대응을 제외한 최소 또는 예상 지연일 수 있습니다. 완료는 오직 활성 규칙과 관찰된 상태에 의해서만 정의됩니다.
## 관련 주제
- [검증자](/ko/crypto/validator/)
- [베기](/ko/crypto/slashing/)
- [스테이킹](/ko/crypto/staking/)
- [리퀴드 스테이킹](/ko/crypto/liquid-staking/)
- [재스테이킹](/ko/crypto/restaking/)
## 출처
- [스테이킹 인출](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 컨센서스 사양: 카펠라](https://github.com/ethereum/consensus-specs/blob/master/specs/capella/beacon-chain.md) - Ethereum Foundation (접근일: 2026-08-19)
- [Ethereum 컨센서스 사양: 일렉트라](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/스테이킹 모듈](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/ko/crypto/validator-exit-withdrawal-queue/index.mdx