---
title: "라이트 클라이언트"
description: "포크를 인식하는 합의 라이트 클라이언트의 부트스트랩, 동기화 위원회, 약한 주관성 체크포인트, 낙관적 및 최종화 헤더, 실행 상태 증명, RPC 제공자, 데이터 가용성과 개인정보 보호를 설명합니다."
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.
# 라이트 클라이언트
> 교육 목적으로만 제공되며 보안 또는 거래 조언이 아닙니다. 라이트 클라이언트는 설정된 프로토콜과 증명이 다루는 객체만 검증합니다. 정확한 체인, 포크, 체크포인트, 헤더 상태, 제공자와 검증되지 않은 데이터 범위를 확인하십시오.
## 핵심 답변
라이트 클라이언트는 풀 노드보다 적은 로컬 실행, 상태와 이력으로 블록체인을 추적하는 검증 소프트웨어입니다. 라이트 노드는 이 소프트웨어를 실행하는 장치 또는 프로세스입니다. 지분증명 이더리움에서 합의 라이트 클라이언트는 신뢰할 수 있는 최근의 최종화 체크포인트에서 부트스트랩하고 포크를 인식하는 동기화 위원회 업데이트를 검증하여 낙관적 헤더와 최종화 헤더를 유지합니다. 모든 EVM 거래를 다시 실행하지는 않습니다.
검증된 합의 관점은 첫 번째 신뢰 앵커일 뿐입니다. 계정 또는 계약 스토리지 값을 검증하려면 인증된 비콘 헤더를 실행 페이로드 헤더에 연결하고 그 `stateRoot`를 선택한 뒤 해당 루트에 대해 계정 또는 스토리지 증명을 검증해야 합니다. 필요한 증명이 없는 일반 RPC 응답은 여전히 제공자의 주장입니다. 합의 서명은 거래 이력, 영수증, 추적, 데이터 가용성, 애플리케이션 동작 또는 장기 검색 가능성을 자동으로 증명하지 않습니다.
## 작동 방식
1. 네트워크와 신뢰 루트를 고정합니다. 체인 식별 정보, 제네시스 검증자 루트와 시각, 포크 일정과 프리셋, 현재 시계, 클라이언트 버전, 신뢰할 수 있는 최근의 최종화된 약한 주관성 체크포인트를 기록합니다. 서로 독립된 인증 출처로 체크포인트를 교차 확인합니다. 악의적인 시작 루트는 피어 간 합의로 바로잡을 수 없습니다.
2. 신뢰 블록 루트에 해당하는 `LightClientBootstrap`을 가져옵니다. 부트스트랩 헤더, 현재 동기화 위원회와 그 Merkle 브랜치를 검증한 뒤 `LightClientStore`를 초기화합니다. 설정한 포크와 일치하지 않는 체인, 포크 다이제스트, 일반화 인덱스 또는 직렬화 스키마는 거부합니다.
3. 동기화 위원회 기간별로 `LightClientUpdate` 객체를 처리합니다. 위원회를 교체하기 전에 슬롯, 참여 비트, BLS 집계 서명과 도메인, 현재 및 다음 위원회 브랜치, 최종성 브랜치와 단조성을 검증합니다. 포크 업그레이드는 객체 필드와 일반화 인덱스를 바꿀 수 있으므로 Altair 상수는 영구적인 공통값이 아닙니다.
4. `optimistic_header`와 `finalized_header` 정책을 분리하여 유지합니다. 낙관적 업데이트는 더 새로운 정보를 제공하지만 재구성이나 데이터 은폐 위험이 더 큽니다. 최종화 업데이트는 합의 상태가 더 강하지만 뒤처질 수 있습니다. 애플리케이션은 용도에 맞는 헤더를 명시적으로 선택해야 하며 최신 응답을 최종으로 다시 표시해서는 안 됩니다.
5. 실행 데이터를 앵커링합니다. 인증된 라이트 클라이언트 헤더에 포함된 실행 페이로드 헤더와 브랜치를 검증한 뒤 각 계정 또는 스토리지 질의를 해당 실행 `stateRoot`, 블록 해시와 최종성 상태에 연결합니다. 이더리움에서는 `eth_getProof`가 계정 증명과 요청한 스토리지 증명을 반환할 수 있습니다. 노드, 경로, 값과 부재를 로컬에서 검증합니다.
6. 검증되지 않은 모든 범위를 목록화합니다. 잔액 증명은 거래 영수증, 로그 질의, 추적, 호출 시뮬레이션, 멤풀, 토큰 레이블, 오라클, blob, 이력 범위 또는 제공자가 결과를 누락하지 않았다는 주장을 인증하지 않습니다. 필요한 각 객체에 대해 증명, 독립 재구성, 풀 노드 대체 경로 또는 명시적인 신뢰 가정을 정의합니다.
7. 검증 실패 시 닫히도록 운영합니다. 체크포인트, 포크, 낙관적 및 최종화 루트, 실행 블록과 상태 루트, 증명 노드, 제공자와 타임스탬프를 기록합니다. 최대 허용 지연을 강제하고 제공자와 네트워크 경로를 분산하며 질의 개인정보를 보호하고 Eclipse 공격과 중단 복구를 시험합니다. 라이트 클라이언트의 증명 범위가 부족하면 풀 노드나 다른 검증 시스템을 사용합니다.
## 계산 예시
- **동기화 위원회 정수 경계.** `512`명 위원회의 규격상 초다수 판정식은 `participants * 3 >= 512 * 2`입니다. 참여자가 `341`명이면 `341 / 512 = 66.6015625%`이고 `1,023 < 1,024`이므로 실패합니다. `342`명이면 `342 / 512 = 66.796875%`이고 `1,026 >= 1,024`이므로 통과합니다. 이는 설정된 업데이트 규칙을 검증할 뿐 모든 위원이나 구현이 정직하다는 증명은 아닙니다.
- **헤더 시계.** 교육용 체크포인트가 슬롯 `10,000`, 인증된 헤더가 `10,064`, 그 최종화 헤더가 `10,032`에 있다고 합시다. `12 seconds/slot`이면 인증된 헤더는 체크포인트보다 `64 * 12 = 768 seconds = 12 minutes 48 seconds` 뒤에 있고, 최종화 헤더는 인증된 헤더보다 `32 * 12 = 384 seconds = 6 minutes 24 seconds` 뒤처집니다. 슬롯 시간은 네트워크 전달이나 고정된 실제 시간 안의 최종성을 보장하지 않습니다.
- **작은 브랜치, 제한된 주장.** `2^20`개의 리프를 가진 이상적인 균형 트리에서 단일 리프 브랜치는 `20`개의 형제 해시를 갖습니다. `32 bytes/hash`이면 `640 bytes`입니다. `8 MiB = 8,388,608 bytes` 객체와 비교하면 브랜치는 `0.00762939453125%`이고 `99.99237060546875%`가 줄어듭니다. 이 브랜치는 리프와 루트의 관계만 증명하며 나머지 바이트의 가용성은 증명하지 않습니다.
- **증명과 증명 없는 RPC.** 최종화된 실행 `stateRoot`에서 검증된 계정 증명이 `3.25 ETH`를 산출하지만 증명 없는 RPC 응답은 `3.30 ETH`라고 합시다. 차이는 `0.05 ETH`이고 증명 없는 응답은 `0.05 / 3.30 = 1.5151515152%` 더 높습니다. 선택한 루트 아래에서 증명된 값을 받아들이되, 그 증명으로 이후 잔액, 영수증, 이력 결과 또는 토큰 정체성을 추론해서는 안 됩니다.
## 위험
- 잘못된 체인, 제네시스 검증자 루트, 제네시스 시각 또는 프리셋을 설정한다.
- 악의적이거나 오래됐거나 최종화되지 않은 체크포인트에서 부트스트랩한다.
- 인증되지 않은 단일 체크포인트 출처를 사용하거나 장거리 포크를 수용한다.
- 로컬 시계 오차로 슬롯, 기간, 도메인 또는 지연 판단을 잘못한다.
- 오래된 포크 일정, 객체 스키마 또는 일반화 인덱스를 사용한다.
- 동기화 위원회 참여도, BLS 서명 또는 도메인을 검증하지 않는다.
- 위원회 교체를 놓치거나 유효하지 않은 현재 또는 다음 위원회를 받아들인다.
- 낙관적 헤더를 최종화 헤더로 취급한다.
- 잘못된 비콘 헤더, 실행 페이로드 또는 실행 블록 해시를 연결한다.
- 잘못된 `stateRoot`에 대해 계정 또는 스토리지 증명을 검증한다.
- 형식이 잘못된 trie 노드, 경로, 인코딩 또는 부재 증명을 받아들인다.
- 지원되지 않거나 증명 없는 RPC 메서드를 검증된 것으로 취급한다.
- 오래됐거나 검열됐거나 불완전하거나 조작된 제공자 응답을 받는다.
- 겉보기에는 다른 제공자가 공동 지배되거나 Eclipse 또는 Sybil 공격을 받는다.
- 증명을 제공하는 풀 노드가 프루닝하거나 서비스를 중단해 라이브니스를 잃는다.
- 합의 유효성을 실행 재현 또는 애플리케이션 정확성과 혼동한다.
- 유효한 증명을 데이터 가용성 또는 영구 검색 가능성과 혼동한다.
- 애플리케이션에 필요한 영수증, 로그, 추적, 블록 본문 또는 이력이 없다.
- 클라이언트 구현, 의존성, 바이너리 또는 포크 업그레이드가 실패한다.
- 제공자나 피어에 질의, IP, 계정과 거래 개인정보가 유출된다.
## 흔한 오해
- 라이트 클라이언트는 작은 풀 노드이거나 원격 RPC의 다른 이름일 뿐이다.
- 동기화 위원회 헤더를 검증하면 모든 RPC 응답을 신뢰할 수 있다.
- 가장 최신인 낙관적 헤더는 최종화 헤더와 같다.
- Merkle 증명이나 합의 서명은 데이터 가용성과 완전한 이력을 증명한다.
- 라이트 클라이언트를 사용하면 풀 노드 수준의 개인정보 보호, 라이브니스와 검열 저항성을 자동으로 얻는다.
## 관련 주제
- [풀 노드](/ko/crypto/full-node/)
- [약한 주관성](/ko/crypto/weak-subjectivity/)
- [상태 루트](/ko/crypto/state-root/)
## 출처
- [Light clients](https://ethereum.org/developers/docs/nodes-and-clients/light-clients/) - Ethereum.org (열람일: 2026-08-13)
- [Altair Light Client -- Sync Protocol](https://ethereum.github.io/consensus-specs/specs/altair/light-client/sync-protocol/) - Ethereum Consensus Specs (열람일: 2026-08-13)
- [Altair Light Client -- Light Client](https://ethereum.github.io/consensus-specs/altair/light-client/light-client/) - Ethereum Consensus Specs (열람일: 2026-08-13)
- [Electra Light Client -- Sync Protocol](https://ethereum.github.io/consensus-specs/electra/light-client/sync-protocol/) - Ethereum Consensus Specs (열람일: 2026-08-13)
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (열람일: 2026-08-13)
- [eth_getProof](https://ethereum.github.io/execution-apis/api/methods/eth_getProof/) - Ethereum Execution APIs (열람일: 2026-08-13)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum.org (열람일: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (열람일: 2026-08-13)
Source: https://wiki.fcontext.com/ko/crypto/light-client/index.mdx