> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plasma.org/llms.txt
> Use this file to discover all available pages before exploring further.

# 개요

> Plasma의 모듈식 노드 아키텍처 및 운영자 역할 이해하기

## 요약

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는 [점진적 탈중앙화 모델](https://a16zcrypto.com/posts/article/progressive-decentralization-crypto-product-management/)을 따르고 있습니다. 첫날부터 검증자 세트를 개방하기보다, 초기 초점은 안정성, 성능 및 개발자 사용성에 있습니다. 이 접근 방식은 핵심 프로토콜 구성 요소가 아직 진화하는 동안 네트워크 신뢰성을 우선시합니다.

탈중앙화는 장기 목표로 남아 있지만 점진적으로 단계별로 도입될 것입니다. 검증자 세트는 세 단계를 통해 확장됩니다:

<Steps>
  <Step title="중앙화된 운영">
    테스트넷 동안 모든 합의 노드는 빠른 반복을 가능하게 하고 운영 위험을 최소화하기 위해 Plasma 팀에서 운영합니다.
  </Step>

  <Step title="신뢰할 수 있는 검증자 세트">
    메인넷 출시 후 신뢰성, 운영 준비성 및 지리적 분산을 기준으로 선택된 소규모 외부 검증자 그룹이 합류합니다.
  </Step>

  <Step title="무허가 참여">
    시간이 지남에 따라 검증자 접근은 안전성, 활성 및 경제적 정렬을 위한 프로토콜 수준 보호 장치에 의해 지원되어 대중에게 개방됩니다.
  </Step>
</Steps>

이 단계적 출시는 탈중앙화와 네트워크 무결성의 균형을 맞춥니다. 이를 통해 광범위한 검증자 세트에 중요한 인프라 책임을 넘기기 전에 프로토콜을 강화할 수 있습니다.

## 피어 디스커버리

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

### 실행 계층 (Reth)

실행 클라이언트는 피어 디스커버리를 위해 Ethereum의 표준 [devp2p](https://github.com/ethereum/devp2p) 프로토콜을 사용합니다. 시작 시 Reth 노드는 `enodes.txt`에 정의된 신뢰할 수 있는 실행 피어 세트에 연결합니다. 이는 각 피어의 공개 키, IP 주소 및 포트를 인코딩하는 [enode URL](https://ethereum.org/en/developers/docs/networking-layer/#enode)입니다.

각 네트워크의 `enodes.txt`는 [non-validator-templates](https://github.com/PlasmaLaboratories/non-validator-templates) 저장소에 미리 구성되어 있습니다. 초기 세트에 연결한 후 Reth의 내장 디스커버리 프로토콜(discv4/discv5)이 자동으로 추가 피어를 찾습니다.

실행 P2P 계층은 포트 `30303`(TCP/UDP)에서 작동합니다.

### 합의 계층 (PlasmaBFT)

합의 옵저버 클라이언트는 `non-validator.toml`에 정의된 부트스트랩 노드를 통해 피어를 발견합니다. 각 부트스트랩 노드 항목에는 API 호스트, P2P 포트 및 [libp2p 피어 ID](https://docs.libp2p.io/concepts/fundamentals/peers/)가 포함됩니다:

```toml theme={null}
[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 게이트웨이나 방화벽 뒤에 있는 경우 다른 피어가 내부 주소를 사용하여 도달할 수 없을 수 있습니다. 피어가 노드를 발견하고 연결할 수 있도록 외부 주소를 구성할 수 있습니다:

<CodeGroup>
  ```toml non-validator.toml theme={null}
  [network]
  external_address = "node.example.com:34070"
  ```

  ```bash CLI theme={null}
  --p2p.external-address node.example.com:34070
  ```
</CodeGroup>

포트가 생략되면 `p2p_port`의 값으로 기본 설정됩니다. 외부 주소가 도달 가능하고 관련 포트가 방화벽을 통해 포워딩되는지 확인하세요.

### 요약

| 계층 | 프로토콜   | 포트      | 디스커버리 방법                       |
| :- | :----- | :------ | :----------------------------- |
| 실행 | devp2p | `30303` | 신뢰할 수 있는 enode + 자동 디스커버리      |
| 합의 | libp2p | `34070` | `non-validator.toml`의 부트스트랩 노드 |

포트 및 방화벽 세부 사항은 [비검증 노드 설정](./non-validator-node-setup#port-configuration) 가이드를 참조하세요.

## 빠른 시작

<CardGroup cols={2}>
  <Card title="노드 유형" icon="chart-network" iconType="light" color="#307F61" href="/docs/node-operators/setup-and-configuration/node-types">
    검증자, 비검증 및 RPC 공급자 역할 이해
  </Card>

  <Card title="비검증 노드 설정" icon="gears" iconType="light" color="#307F61" href="../setup-and-configuration/non-validator-node-setup">
    Docker Compose로 노드 배포
  </Card>

  <Card title="하드웨어 요구 사항" icon="microchip" iconType="light" color="#307F61" href="/docs/node-operators/setup-and-configuration/hardware-requirements">
    노드를 위한 최소 및 권장 사양
  </Card>

  <Card title="운영자 온보딩" icon="rocket" iconType="light" color="#307F61" href="../setup-and-configuration/operator-onboarding">
    무허가 노드 운영 시작하기
  </Card>
</CardGroup>