솔라나 네트워크 프로토콜

1. 이더리움과 솔라나의 네트워크 비교

통신 목적	Ethereum	Solana
노드 발견(Discovery)	discv4/discv5	Gossip + CRDS
트랜잭션 전달	EL의 devp2p/eth 프로토콜	TPU, Gulf Stream 방식의 Leader 전달
블록 전파	CL의 GossipSub	Turbine
합의 투표 전파	CL GossipSub	Vote Transaction, TPU 및 Gossip
누락된 블록 데이터 복구	EL/CL의 동기화 프로토콜	Repair Protocol
실행과 합의의 연결	Engine API	일반적으로 Validator 내부 처리

여기서 가장 중요한 차이는 솔라나는 이더리움처럼 모든 검증자에게 미확인 트랜잭션을 Gossip으로 전파하는 구조가 아니라는 점입니다.

이더리움은 EL 노드들이 Tx Pool의 트랜잭션을 서로 전파합니다. 반면 솔라나는 향후 블록을 생성할 Leader가 누구인지 미리 알 수 있어, 트랜잭션을 해당 Leader 쪽으로 전달합니다. 이 접근 방식을 Gulf Stream이라고 부릅니다.

2. Gossip Protocol — 노드 발견과 네트워크 정보 교환

솔라나에서 새로운 Validator가 네트워크에 참여하려면 다른 Validator들의 IP 주소, 포트, 노드 식별자 등의 정보가 필요합니다. 이러한 정보를 공유하는 것이 Gossip Protocol입니다.

이더리움의 Discovery Protocol과 가장 유사한 역할입니다.

Gossip과 CRDS의 관계

솔라나는 CRDS(Cluster Replicated Data Store)라는 분산 데이터 저장 구조를 사용합니다. 각 노드는 자신이 알고 있는 네트워크 정보를 CRDS에 보유하고, Gossip을 통해 다른 노드들과 정보를 교환합니다.

Validator의 공개키(= Identity Public Key(Node ID))와 네트워크 주소
TPU, TVU, Gossip 등 통신 엔드포인트
노드 소프트웨어 버전
일부 투표 및 Slot 관련 정보
Snapshot 및 네트워크 상태 정보

예를 들어 새로운 Validator A가 네트워크에 참여하는 과정을 생각해 보겠습니다.

Validator A
    │
    │ ① 알려진 Entrypoint로 접속
    ▼
Validator B
    │
    │ ② Gossip / CRDS 정보 교환
    ▼
Validator A
    │
    │ ③ 다른 Validator의 IP 및 Port 학습
    ▼
Validator C, D, E ... 와 통신

이때 중요한 개념이 Entrypoint입니다.

Entrypoint는 새로운 노드가 네트워크에 처음 참여할 때 접촉하는 알려진 Gossip 노드입니다. 이더리움의 Bootnode와 비슷한 역할을 합니다. 하지만 Entrypoint가 모든 통신을 중계하는 중앙 서버는 아닙니다. 노드가 다른 Peer의 정보를 학습하면 그 Peer들과 직접 통신할 수 있습니다.

Gossip의 Push / Pull

Gossip은 대표적으로 Push와 Pull 방식으로 정보를 동기화합니다.

Push — 새로 알게된 CRDS 데이터를 다른 Peer에게 전파
Pull — 자신에게 없는 정보를 다른 Peer에게 요청
Prune — 중복 전파 경로를 줄이기 위한 조정
Ping/Pong — Peer의 도달 가능성 확인(검증)

특히 Pull 과정에서는 Bloom Filter를 사용해 자신이 이미 보유한 데이터와 다른 Peer가 가진 데이터를 효율적으로 비교할 수 있습니다.

따라서 솔라나의 ⁠Gossip은 단순한 Peer Discovery 이상의 역할을 수행합니다. 네트워크 구성원들이 클러스터의 동적인 정보를 공유하도록 지원합니다.

3. TPU와 Gulf Stream — 트랜잭션 전달

이더리움에서는 일반적으로 트랜잭션이 EL의 Tx Pool에 들어가고, 다른 EL Peer들에게 전파됩니다. 솔라나는 접근 방식이 다릅니다.

솔라나에서는 Slot마다 블록을 생성하는 Leader가 정해져 있으며, 앞으로 어떤 Validator가 Leader가 될지도 사전에 결정된 Leader Schedule을 통해 알 수 있습니다. 이 특성을 활용해 트랜잭션을 현재 또는 향후 Leader에게 전달하는 방식을 Gulf Stream이라고 합니다.

트랜잭션 처리 흐름

사용자
  │
  │ ① Transaction 생성 및 서명
  ▼
RPC Node
  │
  │ ② Transaction을 Leader의 TPU로 전달
  ▼
Leader Validator
  │
  └── TPU
       ├── Transaction 수신
       ├── 역직렬화 (Deserialize)
       ├── 서명 검증
       ├── 유효성 검사
       ├── 계정 로딩
       ├── Instruction 실행
       └── 상태 변경 및 블록 생성 과정에 반영

Transaction Processing Unit(TPU)

여기서 TPU는 Transaction Processing Unit의 약자로, Validator 내부에서 트랜잭션을 수신하고 검증·처리하는 시스템입니다.

실제 트랜잭션 전달에서는 QUIC 기반 통신이 중요하며, 해당 Validator 구현과 엔드포인트에 따라 UDP 경로도 존재합니다.

QUIC는 UDP 위에 구현되는 전송 프로토콜로, 연결 관리, 흐름 제어, 혼잡 제어 등의 기능을 제공합니다. — https://solana.com/ja/developers/cookbook/transactions/retry

솔라나에는 Tx Pool이 없는가?

흔히 솔라나를 Mempool-less Blockchain이라고 설명합니다.

이 표현은 이더리움처럼 네트워크 전체에 미확인 트랜잭션을 Gossip으로 복제하는 공개 Mempool 구조를 사용하지 않는다는 의미입니다.

그러나 Validator 내부에 트랜잭션을 임시로 보관하는 버퍼나 큐가 전혀 없다는 뜻은 아닙니다. 예를 들어 Leader가 많은 트랜잭션을 받아 즉시 처리하지 못하면 일부 트랜잭션을 임시 보관하거나 다음 Leader에게 전달할 수 있습니다. 이때 tpu_forwards라는 엔드포인트가 사용됩니다.

tpu: 일반 트랜잭션 수신

tpu_forwards: 처리되지 않은 트랜잭션을 다음 Leader 쪽으로 전달

tpu_vote: 검증자의 Vote Transaction 수신

이처럼 솔라나는 트랜잭션 유형과 전달 목적에 따라 엔드포인트를 구분합니다.

4. Turbine — 블록 전파 프로토콜

솔라나에서 이더리움 CL의 블록 Gossip과 가장 유사한 역할을 하는 것이 Turbine입니다. 다만 전파 방식은 크게 다릅니다.

이더리움의 CL에서는 블록을 GossipSub 토픽으로 전파하지만, 솔라나에서는 Leader가 블록 데이터를 Shred라는 작은 조각으로 나누어 전파합니다.

Shred란?

Shred는 블록 데이터를 네트워크에 효율적으로 전파하기 위해 분할한 패킷 단위입니다. 크게 두 종류가 있습니다.

Data Shred: 실제 블록 데이터를 포함한 조각
Coding Shred: 일부 Data Shred가 유실되었을 때 복원하기 위한 오류 정정 데이터

Coding Shred는 Reed-Solomon Erasure Coding을 이용해 생성됩니다. 검증자는 충분한 Shred를 수신하면 일부 패킷이 유실되었더라도 데이터를 복구할 수 있습니다.

Turbine의 전파 과정

모든 Validator에게 Leader가 직접 블록 전체를 전송한다면 네트워크 대역폭 부담이 커집니다. Turbine은 이를 방지하기 위해 Tree 형태의 계층적 전파 구조를 사용합니다.

TVU(Transaction Validation Unit)

Leader는 Shred들을 선택된 Peer에게 전송하고, 수신한 Validator는 다시 하위 Peer에게 전달합니다. 여기서 사용되는 수신 측 구성 요소가 TVU(Transaction Validation Unit)입니다.

TVU는 Shred를 수신하고, 블록을 재구성하며, 해당 블록을 검증·재실행하는 역할을 합니다. Turbine의 장점은 Leader가 모든 Validator에게 동일한 블록 데이터를 직접 전송할 필요가 없다는 점입니다.

— https://beta.docs.solanalabs.com/de/consensus/turbine-block-propagation

5. Repair Protocol — 누락된 블록 데이터 복구

Turbine으로 Shred를 전파하더라도 모든 패킷이 정상적으로 전달된다는 보장은 없습니다. 네트워크 패킷이 유실되거나, 노드가 잠시 중단되었거나, 새로운 노드가 뒤늦게 참여한 경우 일부 Shred가 누락될 수 있습니다. 이때 사용하는 것이 Repair Protocol입니다.

Validator A
    │
    ├── Slot 100 Shred 수신 완료
    ├── Slot 101 일부 Shred 누락
    └── Slot 102 Shred 수신 완료
              │
              ▼
      누락된 Shred 식별
              │
              ▼
      다른 Validator에 Repair 요청
              │
              ▼
      누락된 Shred 수신
              │
              ▼
      블록 재구성 및 검증

따라서 Turbine과 Repair는 서로 보완적인 관계입니다.

Turbine: 새로운 블록 데이터를 빠르게 전파하는 기본 경로
Repair: 전파 과정에서 놓친 데이터를 요청해 복구하는 경로

Repair는 이더리움에서 Peer에게 누락된 블록이나 체인 데이터를 요청하는 동기화 과정과 유사한 역할을 합니다.

6. 그렇다면 합의 투표는 어떻게 전파할까?

이 부분도 이더리움과 다릅니다. 이더리움의 Consensus Layer에서는 Attestation이 GossipSub를 통해 네트워크에 전파되지만, 솔라나에서는 검증자 투표가 Vote Transaction으로 표현됩니다.

Validator는 블록을 검증한 후 Vote Program에 대한 투표 트랜잭션을 생성합니다. 해당 트랜잭션은 일반 트랜잭션과 마찬가지로 Leader에게 전달되어 블록에 포함될 수 있습니다. 동시에 투표 정보는 Gossip 경로를 통해 공유될 수도 있습니다.

따라서 솔라나의 Gossip은 단순한 Peer Discovery에만 사용되는 것은 아닙니다. 투표를 비롯한 여러 네트워크 상태 정보를 전파하는 데에도 사용됩니다. — https://beta.docs.solanalabs.com/implemented-proposals/reliable-vote-transmission

다만 Gossip을 통해 투표 정보를 알게 되는 것과, 투표 트랜잭션이 블록에 포함되어 온체인에 기록되는 것은 별개의 과정입니다.

정리

이더리움은 EL과 CL의 P2P 네트워크를 분리하여 실행 트랜잭션과 합의 정보를 각각 전파합니다. 솔라나는 하나의 Validator에 실행과 합의 기능을 통합하면서도, 네트워크 통신은 역할에 따라 구분합니다.

Gossip / CRDS — 누구와 통신할 것인가?
Gulf Stream / TPU — 트랜잭션을 누구에게 보낼 것인가?
Turbine / TVU — 생성된 블록을 어떻게 전파하고 검증할 것인가?
Repair — 누락된 블록 데이터를 어떻게 복구할 것인가?

참고할 만한 기술 문서

⁠Solana Foundation — Protocol Specifications: Gossip, P2P, Shred 규격
Solana — Gulf Stream: 트랜잭션 전달 구조
⁠Solana — Shred Specification: Shred 포맷과 전파 데이터 구조
Solana — Turbine Block Propagation: Turbine의 계층적 전파
Solana — Transaction Pipeline: Agave의 트랜잭션 검증 및 실행 과정
Solana — Exchange Node Operations: 실제 Validator 네트워크 운영