Road to Web3 (1) 블록체인 용어 최소 사전: 블록/노드/밸리데이터/멤풀

이 글은 Ethereum 및 EVM 계열(e.g. Ethereum, Base, Arbitrum 등)에서 가장 자주 쓰이는 개념과 관점을 기준으로 정리합니다. Bitcoin(UTXO)·Solana(SVM) 등은 용어는 비슷해도 동작 방식/역할 분담이 달라 같은 단어가 다른 의미를 가질 수 있습니다.

 

Road to Web3 (1) 블록체인 용어 최소 사전: 블록/노드/밸리데이터/멤풀

Road to Web3 (2) 블록체인 네트워크가 하는 일: 전 세계가 공유하는 DB 커밋 로그

Road to Web3 (3) 트랜잭션 생애주기 전파 → 멤풀 → 블록 포함

Road to Web3 (4) Confirm vs Finality: 블록 포함은 끝이 아니다

 

 

 

Web2 개발자의 시야에서 생겼던 Ethereum 에 대한 오해들은 다음과 같습니다.

• 내가 트랜잭션을 보냈다 = 온체인에 확정됐다
  • 전파(broadcast)와 블록 포함(inclusion), 최종성(finality)은 단계가 다릅니다.
  • 따라서 트랜잭션을 보낸(broadcast) 이후 inclusion / finality 가 필요합니다.
• 노드 = 채굴기(=밸리데이터) = 서버 한 대
  • 노드는 큰 범주이고, 밸리데이터는 합의 참여 역할입니다. 채굴은 PoW 용어입니다.
• 멤풀은 블록체인 DB 테이블 같은 것
  • 멤풀은 영구 저장소가 아니라 임시 대기실이며, 노드마다 내용이 달라질 수 있습니다.

이 글은 딱 네 단어(블록/노드/밸리데이터/멤풀)를 같은 언어로 맞춰서, 이후 글에서 헷갈림을 줄이는 게 목표입니다.

용어	정의	오해
블록(Block)	트랜잭션을 묶어서 이 순서로 실행했다를 기록한 단위	블록 = 트랜잭션 1개
노드(Node)	블록/트랜잭션을 받고 검증하고 전파하는 네트워크 참여자(컴퓨터)	노드 = 밸리데이터(검증자)
밸리데이터(Validator)	합의 규칙에 따라 블록을 제안/검증해 체인 상태를 굳히는 참여자	밸리데이터가 모든 트랜잭션을 처리한다
멤풀(Mempool)	아직 블록에 들어가기 전 트랜잭션의 대기실	멤풀 = 영구 저장소(DB)

 

---

웹2 개발자용 비유

이 비유는 정확한 동작을 대체하려는 게 아니라, 단순한 비유입니다.

 

블록체인	웹2에 비유하면	요약
트랜잭션(Transaction)	POST /payments 같은 상태 변경 요청	상태를 바꾸는 커맨드
멤풀(Mempool)	Kafka/SQS 같은 대기 큐(ingress buffer)	아직 커밋 전인 줄
블록(Block)	DB의 커밋 로그 batch(또는 WAL segment)	여러 요청을 묶어 순서대로 커밋
노드(Node)	읽기/검증을 수행하는 레플리카 + 게이트웨이	검증하고 퍼뜨리는 서버들
밸리데이터(Validator)	커밋 권한을 가진 컨센서스 멤버	어느 커밋이 정답인지 결정
Finality(최종성)	COMMIT이 여러 복제본에 안정적으로 반영된 상태	되돌리기 거의 불가
Reorg	분산 로그에서의 리더 교체/롤백에 가까운 사건	잠깐 맞다고 했던 커밋이 바뀜

 

---

1) 블록(Block): 커밋 로그 한 덩어리

정의

블록은 트랜잭션 묶음 + 그 묶음의 메타데이터(누가/언제/이전 블록과 어떻게 이어지는지)로 구성된 기록 단위입니다.

EVM 관점에서 가장 중요한 건 이거예요:

• 블록은 이 트랜잭션들을 이 순서대로 실행했다라는 순서의 증거다.
• 블록이 쌓이면 상태(state)가 이렇게 바뀌었다가 공유된다.

웹2 비유: 블록은 DB 커밋 로그를 일정량 모아 배치로 커밋한 덩어리에 가깝습니다.

왜 필요한가

• 전 세계 노드가 같은 순서로 실행해야 같은 결과(상태)를 얻습니다.
• 블록은 그 순서를 공식으로 확정하는 그릇입니다.

포인트

• 블록 = 트랜잭션 1개가 아니라 트랜잭션 여러 개의 묶음입니다.
• 블록에 포함됐다는 말은 처리 완료(확정)와 같지 않을 수 있습니다.

 

---

2) 노드(Node): 검증하고 퍼뜨리는 참여자

정의

노드는 블록체인 네트워크에 참여하는 컴퓨터(프로그램)입니다.

• 새로운 트랜잭션을 받는다(사용자/지갑/RPC를 통해)
• 트랜잭션이 규칙에 맞는지 기본 검증한다
• 다른 노드들에게 트랜잭션/블록을 전파(gossip)한다
• 블록을 내려받아 검증하고, 체인 상태를 갱신한다

중요한 구분: 노드는 역할의 집합이고, 밸리데이터는 그중 하나의 역할

• 대부분의 노드는 풀노드(full node)처럼 검증/전파를 수행합니다.
• 그중 일부가 밸리데이터(검증자) 역할까지 수행합니다.
• 즉, 노드 ⊃ 밸리데이터 관계로 생각할 수 있습니다.

왜 필요한가

중앙 서버가 없기 때문입니다. 누군가의 서버가 아니라, 여러 노드가 같은 규칙으로 검증해 같은 장부를 유지합니다.

참고.
우리가 알고 있는 Cassandra도 클러스터 내부에서 노드 상태(멤버십/헬스)를 퍼뜨리기 위해 gossip 프로토콜을 사용합니다. 블록체인의 P2P gossip도 기본 아이디어는 비슷하게, 어떤 노드가 받은 정보를 이웃 노드들에게 조금씩 전달하고 그게 연쇄적으로 퍼지면서 네트워크 전체가 같은 정보를 알게 만드는 방식이에요. 다만 Cassandra의 gossip이 주로 클러스터 운영 정보(누가 살아있고, 어떤 상태인지) 를 공유하는 데 초점이 있다면, 블록체인의 gossip은 트랜잭션과 블록(합의의 재료)을 최대한 빨리 넓게 전파하는 데 초점이 있습니다. 또 Cassandra는 보통 우리가 운영하는 신뢰된 노드들을 전제로 하는 반면, 퍼블릭 블록체인은 악성 노드/스팸이 상수라서 레이트리밋, 무효 데이터 필터링, 피어 스코어링 같은 방어 로직이 훨씬 중요해집니다. 그리고 가장 큰 차이는 정합성 책임인데요, Cassandra에서 데이터 정합성은 커밋과 복제/일관성 설정이 책임지는 반면, 블록체인에서는 gossip은 어디까지나 전파 수단일 뿐이고 최종 정합성은 합의와 최종성(finality)이 확정합니다.

 

 

---

3) 밸리데이터(Validator): 블록을 확정 방향으로 밀어주는 합의 주체

정의(Ethereum PoS 기준)

밸리데이터는 합의(Consensus)에 참여하는 역할입니다. 아주 단순화하면

• 어떤 밸리데이터(또는 밸리데이터 집합)가 블록 제안(propose)을 하고,
• 다른 밸리데이터들이 검증/투표(attest) 해서,
• 규칙에 맞는 블록이 체인으로 이어지도록 합니다.

채굴(Mining)은 PoW(작업증명) 용어고, Ethereum은 PoS(지분증명)로 전환했습니다.
그래서 Ethereum/EVM 계열을 말할 때는 채굴기 대신 밸리데이터가 더 정확한 단어입니다.

왜 필요한가

• 누가 다음 블록을 만들지 정해야 하고,
• 서로 못 믿는 환경에서 어느 블록이 정답인지를 결정해야 합니다.

포인트

• 밸리데이터가 모든 트랜잭션을 처리하는 게 아니라, 블록 단위로 선택/검증/합의를 수행합니다.
• 트랜잭션 실행 자체는 EVM 규칙에 따라 결정되며, 노드들이 동일하게 재실행해서 검증합니다.

---

4) 멤풀(Mempool): 블록에 들어가기 전 트랜잭션 대기실

정의

멤풀은 아직 블록에 포함되지 않은 트랜잭션을 노드가 임시로 보관하는 대기 공간입니다.

• 트랜잭션이 네트워크로 전파되면 여러 노드의 멤풀에 잠시 담깁니다.
• 밸리데이터/블록 제안자는 멤풀에서 트랜잭션을 골라 블록을 구성합니다.

왜 필요한가

모든 요청이 즉시 블록에 들어갈 수 없기 때문입니다.

• 네트워크 처리량은 제한돼 있고
• 동시에 많은 트랜잭션이 들어오면 줄을 서야 합니다.
• 이 줄 서기가 멤풀에서 벌어집니다.

포인트

• 멤풀은 영구 저장소가 아닙니다.
  • 노드가 재시작하면 날아갈 수 있고
  • 노드마다 멤풀 상태는 조금씩 다를 수 있습니다(전파 지연, 정책 차이).
• 멤풀에 있다는 건 확정이 아니라 대기 중입니다.

---

5) Lifecycle

서명된 트랜잭션이 만들어지면…

1. 지갑/클라이언트가 어떤 노드(RPC)에 트랜잭션을 보냄
2. 노드가 기본 검증 후 네트워크에 전파 → 여러 노드의 멤풀에 쌓임
3. 밸리데이터가 멤풀에서 트랜잭션을 골라 블록을 제안
4. 네트워크가 합의 규칙으로 블록을 채택 → 체인 상태 업데이트
5. 시간이 더 지나 되돌리기 어려운 수준이 되면 우리는 그걸 확정(final)로 취급

 

---

 

비유의 한계

• 블록체인은 중앙 DB가 없어서 락을 걸 주체가 없고, 대신 순서 결정 + 조건부 실패(revert)로 문제를 풉니다.
• 노드/밸리데이터는 클라우드 서버처럼 마음대로 스케일링하는 컴포넌트가 아니라, 규칙(프로토콜)이 먼저이고 구현은 그 규칙을 따르는 형태입니다.
• 따라서 비유는 감을 잡는 용도이고, 이후 편에서는 실제 프로토콜 동작(전파/합의/최종성)을 기준으로 더 정확히 설명합니다.

---