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

## 직접적인 답변

검증자는 블록 제안, 투표, 증명 또는 최종화와 같은 합의 업무를 수행할 자격이 있는 것으로 프로토콜이 인식하는 신원입니다. 프로토콜은 해당 신원을 키, 상태 및 투표 또는 선택 가중치와 연결합니다. 정확한 가입 규칙, 업무 집합 및 책임 메커니즘은 네트워크마다 다릅니다. 지분 증명 시스템은 일반적으로 담보 지분이나 유효 지분에 따라 검증자에 가중치를 부여하는 반면, 일부 비잔틴 장애 허용 또는 허가형 시스템은 고정되거나 관리되는 검증자 집합을 사용합니다.

검증자는 자동으로 노드, 기계, 운영자, 스테이커, 위임자, 풀 또는 법인과 같은 것이 아니다. 하나의 운영자가 여러 검증자 아이덴티티를 운영할 수 있으며, 하나의 검증자는 여러 클라이언트나 기계를 사용할 수 있다. 전체 노드는 투표 권한 없이 체인을 검증할 수 있으며, 위임된 스테이크는 합의 키를 통제하지 않는 사람들에게 경제적으로 속할 수 있다. 이러한 구분은 결함의 귀속, 집중도, 그리고 누가 보상과 손실을 받거나 부담하는지를 결정한다.

이 물건들을 따로 보관하세요:

- **노드 또는 클라이언트:** 프로토콜 데이터를 수신, 검증, 실행 및 전달하는 소프트웨어와 인프라; 많은 노드가 검증자가 아니다.
- **검증자 신원:** 상태, 의무, 가중치, 보상 및 벌칙이 부여되는 프로토콜 기록 또는 공개 키.
- **검증자 운영자:** 서명 및 운영 시스템을 제어하는 개인 또는 조직, 아마도 여러 신원을 위해.
- **스테이커 또는 대리인:** 지분의 경제적 소유자 또는 기여자; 위임은 일반적으로 검증자의 서명 권한을 이전하지 않고 가중치를 할당합니다.
- **활성 검증자 세트 및 유효 가중치:** 현재 의무를 수행할 수 있는 자격이 있는 신원과 선택 또는 정족수 계산에 사용되는 프로토콜 측정 무게로, 이는 원래 지갑 잔액과 다를 수 있습니다.

이 단어는 또한 검증자가 임의의 거래가 법적 또는 경제적으로 바람직한지를 결정한다는 의미도 아닙니다. 노드는 결정론적 유효성 규칙을 적용합니다. 합의 참가자는 유효한 후보 중에서 순서가 정해진 기록을 선택하거나 확정하는 데 도움을 줍니다. 유효한 블록도 포크 선택 경쟁에서 패할 수 있으며, 유효하지 않은 블록이 강력한 검증자가 서명했다고 해서 유효해지는 것은 아닙니다.

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

## 검증자를 분석하는 방법

### 1. 프로토콜과 규칙 집합을 수정하세요

`network`, `chain ID`, 활성 포크 또는 런타임, 블록 또는 에폭, 클라이언트/사양 릴리스, 관련 스테이킹 계약 또는 모듈을 기록하세요. `validator`, `nominator`, `delegator`, `vote account`, `operator` 용어는 Ethereum, Cosmos SDK 체인, Polkadot 및 Solana 전반에서 상호 교환될 수 없습니다. 다른 네트워크의 규칙을 옮기지 말고 실시간 매개변수와 최종 상태를 확인하세요.

### 2. 신원, 키 및 제어를 해결합니다

검증자 인덱스, 주소, 투표 또는 합의 공개 키, 출금 또는 소유자 권한, 수수료 수령인, 운영자 및 수혜자를 매핑합니다. 어떤 키가 합의 메시지에 서명할 수 있는지, 어떤 자격 증명이 자금을 재배치하거나 인출할 수 있는지, 원격 서명자, 다중 서명 정책, 관리인 또는 스마트 계약이 그들 사이에 존재하는지 여부를 확인합니다. 예를 들어 Ethereum는 검증자 서명 키를 출금 자격 증명과 분리합니다; 해당 키 모델은 보편적이지 않습니다.

### 3. 입장, 활성화 및 종료 추적

최소 스테이크 또는 지명 요건, 등록 트랜잭션, 보증 및 활성화 대기열, 활성 세트 선택, 세션 또는 에폭 경계, 교체 한도, 보증 해제, 강제 종료 및 출금 완료를 식별합니다. `Deposited`, `bonded`, `eligible`, `active`, `exiting`, `withdrawable` 및 `withdrawn`는 서로 다른 상태입니다. 대기열에 있는 검증자는 아무 것도 벌지 못할 수 있으며, 종료 중인 검증자도 여전히 의무나 벌칙 노출이 있을 수 있습니다.

### 4. 업무와 서명 제약 사항을 열거하세요

제안자, 증명, 사전투표, 사전커밋, 가용성, 집계, 동기화 또는 기타 임무와 그 기한을 나열하십시오. 각 서명된 메시지에 대해 도메인, 높이 또는 슬롯, 관련된 경우 출처와 대상, 포크 컨텍스트, 그리고 이중서명 방지 규칙을 기록하십시오. 결정론적 블록 유효성을 포크 선택 및 최종성과 구분하십시오. 임무를 놓치거나, 늦게 서명하거나, 잘못된 메시지에 서명하거나, 상충되는 메시지에 서명하는 경우 각각 다른 결과를 초래할 수 있습니다.

### 5. 효과적인 가중치와 쿼럼 수학을 재현하다

프로토콜이 원시 스테이크, 상한이 있는 `effective stake`, 위임 지분, 지명 노출, 평판, 검증자당 한 표 또는 다른 가중치를 사용하는지 판단하십시오. 현재 지갑 잔액이 아니라 관련 스냅샷의 스테이크를 조정하십시오. 그런 다음 단순히 검증자 기록 수만 세지 말고 공통 운영자, 서명자, 클라우드, 클라이언트 또는 거버넌스 통제별 선택 확률, 정족수 임계값 및 집중도를 계산하십시오.

### 6. 경제학과 손실 배분 조정

유입을 발행, 우선 수수료, MEV 또는 제안자 지급, 위임 수수료, 서비스 수익으로 나누십시오. 누락된 보상, 일반 벌금, 슬래싱, 강제 퇴출 영향, 수탁 수수료, 인프라 비용, 세금 및 보험을 구분하십시오. 보상이 자동으로 복리되는지, 그리고 각 손실을 운영자, 셀프 스테이커, 위임자, 지명자, 풀 소유자 또는 재스테이커가 부담하는지 명시하십시오.

### 7. 운영을 검토하고 체인 상 상태를 확인하세요

키 보관, 서명자 독점성, 슬래싱 보호, 시계 동기화, 피어 연결, 디스크 및 메모리 여유, 클라이언트 및 위치 다양성, 장애 조치 펜싱, 백업 복원, 모니터링 및 사고 대응을 확인하세요. 대시보드와 제공자 명세서를 최종 블록, 검증자 상태, 서명된 메시지, 보상 기록, 페널티 및 출금 상태와 조정하세요. 익스플로러 라벨은 유용한 단서일 수 있지만 권위 있는 프로토콜 정의는 아닙니다.

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

## 실제 사례

### 과제 확률과 분산

프로토콜이 유효 가중치에 비례하여 검증자를 샘플링한다고 가정합니다. 검증자 `V`는 `64` 단위를 보유하고 총 유효 가중치는 `3,200,000`이므로, 한 번의 기회에 선택될 확률은 다음과 같습니다:

`64 / 3,200,000 = 0.00002 = 0.002%`.

`100,000`개의 독립적인 설명 기회에서 예상 과제는 `lambda = 100,000 * 0.00002 = 2`입니다. Poisson 근사 하에서, 과제가 0일 확률은:

`P(0) = exp(-2) = 13.5335%`.

따라서 해당 시간 창에서 할당을 받지 못했다고 해서 자체적으로 다운타임을 증명하는 것은 아닙니다. 실제 프로토콜은 독립적이지 않게 샘플링하거나, 위원회를 지정하거나, 유효 잔액을 제한하거나, 임무를 다르게 계획할 수 있으므로 실제 선택 알고리즘을 사용하세요.

### 가중 생존성은 검증자 수가 아닙니다

최종성이 총 투표 가중치의 3분의 2를 초과해야 한다고 가정하고, 스냅샷에 `1,000,000` 단위가 있다고 하자. 가장 작은 정수 임계값은 `666,667`이다. 온라인 검증자가 `655,000`를 대표하면, 부족분은:

`666,667 - 655,000 = 11,667`.

검증자 기록 `65`개가 온라인이고 전체 기록 수가 `100`개이더라도, 개수만으로는 임계값 충족 여부를 판단할 수 없습니다. 반대로, 소수의 고가중치 검증자가 임계값을 충족하면서 운영자와 인프라 집중을 초래할 수 있습니다.

### 보상 및 커미션 계단식 구조

한 기간 동안 검증자가 `1,800` 단위의 프로토콜 보상과 `300` 단위의 수수료를 얻고, `60` 단위의 프로토콜 벌금을 부담하며, `15%`의 커미션을 부과한다고 가정합니다. 벌금 차감 후 기준 금액은 `2,040`입니다:

`1,800 + 300 - 60 = 2,040`.

`operator_commission = 2,040 * 0.15 = 306`.

`delegator_distribution = 2,040 - 306 = 1,734`.

인프라와 인력 비용이 운영자 `240`에게 발생한다면, 세전 가상의 순이익은 `306 - 240 = 66`입니다. 이는 계약이 두 수익 범주 모두에 대해 벌금 이후 수수료를 적용한다고 가정한 것이며, 다른 체인이나 제공자는 다른 기준, 시점, 반올림 또는 손실 배분을 사용할 수 있습니다.

### 기록 대 일반 통제

블록 익스플로러에는 검증자 기록 `120`개가 표시되며 각 기록의 유효 가중치는 `32`단위입니다:

`120 * 32 = 3,840`.

조사에서는 `60` 기록을 운영자 A에, `40`를 B에, `20`를 C에 매핑합니다. 이들의 유효 가중치는 `1,920`, `1,280`, `640` 또는 `50%`, `33.3333%`, `16.6667%`입니다. 인터페이스는 120 검증자 신원을 보고하지만, 알려진 운영자는 세 명뿐입니다. 추가 분석에서는 공유 서명자, 클라이언트, 클라우드 및 실질 소유자를 그룹화해야 하며, 기록 수는 탈중앙화 척도가 아닙니다.

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

## 위험과 검토 실패

- **잘못된 프로토콜 모델:** 다른 체인, 포크, 런타임 또는 스테이킹 계약의 규칙은 잘못된 상태, 의무 또는 임계값을 생성할 수 있습니다.
- **노드와 검증자 혼동:** 접근 가능한 노드를 활성 검증자로 계산하거나 모든 검증자 ID를 별도 장비로 취급하면 토폴로지가 왜곡됩니다.
- **항등 연산자 혼동:** 한 명의 운영자가 여러 키를 제어할 수 있으므로, 기록 수는 거버넌스와 실패 집중을 숨길 수 있습니다.
- **스테이커-운영자 혼동:** 위임된 경제적 소유권은 반드시 서명 권한이나 운영 통제를 포함하지는 않습니다.
- **정체 상태:** 의 현재 스테이크와 상태는 할당, 정족수, 보상 또는 페널티에 사용된 스냅샷과 다를 수 있습니다.
- **원시-실효 잔액 불일치:** 캡, 플로어, 반올림 단위, 주식 및 지명 규칙은 지갑 잔액을 합의 가중치와 무관하게 만들 수 있습니다.
- **핵심 역할 혼란:** 합의 키, 철회 자격 증명, 계정 소유자, 수수료 수령자 및 거버넌스 키는 서로 다른 권한을 가질 수 있습니다.
- **중복된 서명 키:** 두 개의 살아있는 인스턴스는 각 기계가 정상으로 보일 때도 동일한 말을 할 수 있습니다.
- **안전하지 않은 장애 조치:** 의 애매한 주요 소유권, 오래된 잠금 또는 복원된 백업은 충돌하는 서명을 만들 수 있습니다.
- **클라이언트 결함:** 합의, 실행, 서명자, 또는 미들웨어 버그는 의무를 놓치거나, 잘못된 데이터를 제안하거나, 실패를 연관시킬 수 있습니다.
- **네트워크 및 클록 오류:** 파티션, 지연, 일식 조건 또는 클록 드리프트로 인해 적시에 올바르게 참여하는 것이 불가능할 수 있습니다.
- **자원 고갈:** 디스크, 메모리, 대역폭, 파일 디스크립터 또는 상태 증가로 인해 대시보드에 장애가 표시되기 전에 검증자 성능이 저하될 수 있습니다.
- **연관된 인프라:** 가 공유하는 클라우드, 지역, 중계기, 서명자, 클라이언트 및 제어 평면은 공통 모드 위험을 생성합니다.
- **검열 및 정책 위험:** 중계기, 운영자 또는 법적 제약은 거래를 제외하거나 신뢰할 수 있는 중립성을 감소시킬 수 있습니다.
- **MEV 충돌:** 제안자의 수익, 건설자의 의존성, 그리고 재조직 인센티브는 일반적인 보상 가정과 달라질 수 있습니다.
- **위임 집중:** 스테이크는 위임자 수가 증가하더라도 투표권을 소수의 운영자에게 이동시킬 수 있습니다.
- **수수료 변경:** 변동 금리, 지연된 업데이트, 프로모션 금리 및 다양한 수수료 기준은 수익률 비교를 무효화할 수 있습니다.
- **슬래싱 및 페널티 전가:** 제공자 조건은 프로토콜 손실을 위임자, 지명자 또는 풀 보유자에게 할당할 수 있습니다.
- **유동성 부족 종료:** 활성화, 언본딩, 출금 또는 재스테이킹 대기열은 가격과 페널티 노출이 계속되는 동안 접근을 지연시킬 수 있습니다.
- **관측 가능성과 귀속 격차:** 탐색기 라벨, 운영자 공개 정보 및 소유 클러스터는 불완전하거나 잘못될 수 있습니다.

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

## 일반적인 오해

### 모든 풀 노드가 검증자인가요?

아니요. 전체 노드는 활성 합의 신분을 보유하지 않고도 체인을 검증하고 전달할 수 있습니다. 검증자는 일반적으로 노드 소프트웨어에 의존하지만, 프로토콜은 하나의 검증자를 키나 기록으로 나타낼 수 있으며 운영자는 그 뒤에서 여러 대의 기기와 클라이언트를 사용할 수 있습니다.

### 검증자가 개인적인 판단으로 거래를 검증합니까?

아니요. 소프트웨어는 거래와 블록이 프로토콜 규칙에 맞는지 확인합니다. 검증자의 합의 의무는 순서가 정해진 기록을 제안, 선택 또는 확정하는 데 도움을 줍니다. 검증자는 선호에 따라 잘못된 상태 전환을 유효하게 만들 수 없으며, 합의 승인은 법적, 투자 또는 사기 인증이 아닙니다.

### 검증자 기록이 더 많다고 해서 항상 탈중앙화가 더 되는 걸까?

아니요. 여러 기록이 하나의 운영자, 서명자, 실소유자, 클라이언트, 클라우드, 중계기 또는 거버넌스 정책을 공유할 수 있습니다. 장애 영역 전체에서 효과적인 투표 권한과 공통 제어를 측정하세요. 기록 수는 단지 하나의 관찰일 뿐입니다.

### 광고된 스테이킹 수익이 검증자 운영자의 수익인가요?

아니요. 인용된 수익률은 활성화 시간, 누락된 의무, 벌금, 수수료, MEV 배분, 복리, 인프라, 수탁, 세금, 토큰 가격 변동, 그리고 유휴 또는 언본딩 기간을 무시할 수 있습니다. 운영자 수익과 위임자 수익은 서로 다른 현금 흐름입니다.

### 위험이 증가할 때 운영자가 즉시 종료하고 철회할 수 있나요?

반드시 그런 것은 아니다. 프로토콜은 활성화 교체, 종료 대기열, 언바운딩 기간, 지연된 출금, 이전 위반에 대한 지속적인 책임을 부과할 수 있다. 재스테이킹 또는 유동 스테이킹 계약은 별도의 대기열과 상대방을 추가할 수 있다. 모든 상태 전환과 마지막으로 벌점이 적용될 수 있는 시간을 추적하라.

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

## 관련 주제

- [지분 증명](/ko/crypto/proof-of-stake/)
- [베기](/ko/crypto/slashing/)
- [스테이킹](/ko/crypto/staking/)
- [검증자 출구 및 철수 대기열](/ko/crypto/validator-exit-withdrawal-queue/)
- [약한 주관성](/ko/crypto/weak-subjectivity/)

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

## 출처

- [지분 증명 합의](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (접근일: 2026-08-19)
- [지분 증명 키](https://ethereum.org/developers/docs/consensus-mechanisms/pos/keys/) - Ethereum.org (접근일: 2026-08-19)
- [Ethereum 합의 사양: Honest Validator](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (접근일: 2026-08-19)
- [Cosmos SDK x/스테이킹 모듈](https://docs.cosmos.network/sdk/v0.53/build/modules/staking/README) - Cosmos SDK (접근일: 2026-08-19)
- [노드 실행](https://docs.cosmos.network/sdk/latest/node/run-node) - Cosmos SDK (접근일: 2026-08-19)
- [Validator Requirements](https://docs.polkadot.com/node-infrastructure/run-a-validator/requirements/) - Polkadot Developer Docs (접근일: 2026-08-19)
- [Stake Accounts](https://solana.com/docs/references/staking/stake-accounts) - Solana Foundation (접근일: 2026-08-19)
- [블록체인 기술 개요](https://doi.org/10.6028/NIST.IR.8202) - NIST (접근일: 2026-08-19)

Source: https://wiki.fcontext.com/ko/crypto/validator/index.mdx