메인 콘텐츠로 건너뛰기

​
요약

Plasma는 검증자 노드(블록 제안 및 확정)와 비검증 노드(합의에 영향을 미치지 않고 RPC를 제공하고 체인을 따라감)를 분리합니다. 이를 통해 Plasma는 검증자 세트를 작고 안전하게 유지하고, RPC 공급자가 독립적으로 확장할 수 있게 하며, 합의나 네트워킹 위험을 추가하지 않습니다.

​
고수준 아키텍처

계층역할신뢰 모델
합의 계층 (CL)블록 제안 및 확정PlasmaBFT
실행 계층 (EL)트랜잭션 처리, 상태 관리, RPC 제공페어링된 CL을 완전히 신뢰
각 검증자는 하나의 합의 노드와 하나의 실행 노드를 운영하며 직접 연결되어 있습니다. 파트너 외에는 노드가 계층 피어 밖에서 통신하지 않습니다(CL-to-CL, EL-to-EL). 이러한 분리는 시스템을 예측 가능하고 안전하며 추론하기 쉽게 유지합니다.

​
확장 과제

사용량이 증가함에 따라 더 많은 앱과 사용자가 체인 데이터를 조회하거나 트랜잭션을 전송하기 위해 RPC 접근이 필요합니다. 하지만 각 새 실행 노드가 반드시 새 합의 노드와 페어링되어야 한다면 확장이 비효율적이 되고 검증자 세트가 비대해질 위험이 있습니다. 읽기 수요를 충족하기 위해 RPC 공급자가 추가 검증자를 운영하도록 하는 것은 실용적이지 않으며 Plasma의 성능 목표와 일치하지 않습니다.

​
해결책: 비검증 노드

비검증 노드는 합의 노드처럼 작동하지만 합의에 참여하지 않습니다. 대신 확정된 블록과 fork-choice 업데이트를 위해 신뢰할 수 있는 검증자를 ‘따라’갑니다. 주요 동작:
  • 검증자의 합의 노드를 구독하여 동기화 상태를 유지합니다.
  • 실제 검증자가 가질 수 있는 동일한 fork-choice 뷰를 노출합니다.
  • 읽기만 수행하므로 부하를 추가하거나 보안 위험을 도입하지 않습니다.
애플리케이션에 대해 비검증 노드는 풀 노드와 정확히 동일하게 보입니다: RPC 요청에 응답하고 현재 상태를 반영할 수 있지만 블록을 제안하거나 투표할 수는 없습니다.

​
이 설계의 이점

목표비검증 노드가 도움이 되는 방법
검증자 세트를 작게 유지비검증 노드는 투표하지 않고 검증자만 투표합니다.
무제한 수평 확장RPC 공급자는 새 검증자 자리를 요구하지 않고도 각각 자체 비검증 노드와 함께 수백 개의 읽기/쓰기 RPC 노드를 실행할 수 있습니다.
합의 정확성 유지각 실행 노드는 여전히 정확히 하나의 CL을 따릅니다. 상태 분기의 위험이 없습니다.
위험 감소비검증 노드는 읽기 전용이며 합의 메시지에 영향을 미칠 수 없습니다.
페일오버 단순화여러 검증자를 따름으로써 하나가 오프라인이 되면 자동으로 새 검증자로 전환할 수 있습니다.

​
요약 비교

기능검증자비검증 노드
합의 참여전체 (제안, 투표, 확정)없음 (수신만)
메시지 유형모든 합의 메시지블록 메시지만
네트워크 역할적극적 참여자수동적 추적자
리소스 요구 사항더 높음 (전체 합의)더 낮음 (메시징만)

​
점진적 탈중앙화

Plasma는 점진적 탈중앙화 모델을 따르고 있습니다. 첫날부터 검증자 세트를 개방하기보다, 초기 초점은 안정성, 성능 및 개발자 사용성에 있습니다. 이 접근 방식은 핵심 프로토콜 구성 요소가 아직 진화하는 동안 네트워크 신뢰성을 우선시합니다. 탈중앙화는 장기 목표로 남아 있지만 점진적으로 단계별로 도입될 것입니다. 검증자 세트는 세 단계를 통해 확장됩니다:
1

중앙화된 운영

테스트넷 동안 모든 합의 노드는 빠른 반복을 가능하게 하고 운영 위험을 최소화하기 위해 Plasma 팀에서 운영합니다.
2

신뢰할 수 있는 검증자 세트

메인넷 출시 후 신뢰성, 운영 준비성 및 지리적 분산을 기준으로 선택된 소규모 외부 검증자 그룹이 합류합니다.
3

무허가 참여

시간이 지남에 따라 검증자 접근은 안전성, 활성 및 경제적 정렬을 위한 프로토콜 수준 보호 장치에 의해 지원되어 대중에게 개방됩니다.
이 단계적 출시는 탈중앙화와 네트워크 무결성의 균형을 맞춥니다. 이를 통해 광범위한 검증자 세트에 중요한 인프라 책임을 넘기기 전에 프로토콜을 강화할 수 있습니다.

​
피어 디스커버리

Plasma 노드는 스택의 각 계층에 대해 하나씩 두 가지 독립적인 메커니즘을 통해 피어를 발견하고 연결합니다.

​
실행 계층 (Reth)

실행 클라이언트는 피어 디스커버리를 위해 Ethereum의 표준 devp2p 프로토콜을 사용합니다. 시작 시 Reth 노드는 enodes.txt에 정의된 신뢰할 수 있는 실행 피어 세트에 연결합니다. 이는 각 피어의 공개 키, IP 주소 및 포트를 인코딩하는 enode URL입니다. 각 네트워크의 enodes.txt는 non-validator-templates 저장소에 미리 구성되어 있습니다. 초기 세트에 연결한 후 Reth의 내장 디스커버리 프로토콜(discv4/discv5)이 자동으로 추가 피어를 찾습니다. 실행 P2P 계층은 포트 30303(TCP/UDP)에서 작동합니다.

​
합의 계층 (PlasmaBFT)

합의 옵저버 클라이언트는 non-validator.toml에 정의된 부트스트랩 노드를 통해 피어를 발견합니다. 각 부트스트랩 노드 항목에는 API 호스트, P2P 포트 및 libp2p 피어 ID가 포함됩니다: 
[network.bootstrap_nodes.0]
api_host = "plasma-mainnet-observer-cs-1.plasmalabs.tech"
p2p_port = 34070
peer_id = "16Uiu2HAm4WdZmik6PVsRvcbCzc1eHuNfQHgj52CxUAjmdC7W5dXi"
각 네트워크는 3개의 부트스트랩 노드와 함께 제공됩니다. 옵저버 클라이언트는 시작 시 이러한 노드에 연결되며 피어 디스커버리가 활성화되면(discovery.enabled = true) 네트워크에서 추가 피어를 자동으로 찾습니다. 합의 P2P 계층은 포트 34070(TCP)에서 작동합니다.

​
NAT 뒤의 노드

노드가 NAT 게이트웨이나 방화벽 뒤에 있는 경우 다른 피어가 내부 주소를 사용하여 도달할 수 없을 수 있습니다. 피어가 노드를 발견하고 연결할 수 있도록 외부 주소를 구성할 수 있습니다: 
[network]
external_address = "node.example.com:34070"
포트가 생략되면 p2p_port의 값으로 기본 설정됩니다. 외부 주소가 도달 가능하고 관련 포트가 방화벽을 통해 포워딩되는지 확인하세요.

​
요약

계층프로토콜포트디스커버리 방법
실행devp2p30303신뢰할 수 있는 enode + 자동 디스커버리
합의libp2p34070non-validator.toml의 부트스트랩 노드
포트 및 방화벽 세부 사항은 비검증 노드 설정 가이드를 참조하세요.

​
빠른 시작

노드 유형

검증자, 비검증 및 RPC 공급자 역할 이해

비검증 노드 설정

Docker Compose로 노드 배포

하드웨어 요구 사항

노드를 위한 최소 및 권장 사양

운영자 온보딩

무허가 노드 운영 시작하기