---
title: "Ethereum 트랜잭션은 어떻게 전파(브로드캐스트)되는가?"
description: "Ethereum 네트워크 전체에 트랜잭션이 전파되는 과정 알아보기"
---

# Ethereum 트랜잭션은 어떻게 전파(브로드캐스트)되는가?

트랜잭션은 블록체인에서 정보와 가치를 교환하는 기본 단위이며, 개발자, 트레이더, 취미로 다루는 사람 모두에게 이해가 필요한 개념이다. 트랜잭션은 **RLPx**와 **Wire Protocol** 같은 다양한 네트워킹 프로토콜을 사용해 Ethereum의 탈중앙화된 Peer-to-Peer\(P2P\) 네트워크 전역에 전파되며, 이를 통해 블록 생산자와 검증자가 mempool에서 대기 중인 트랜잭션을 찾을 수 있다.

이 글에서는 Ethereum 트랜잭션의 유형과, 트랜잭션이 Ethereum 노드 네트워크 전역에 어떻게 브로드캐스트되는지 다룬다.

## **Ethereum 트랜잭션이란 무엇인가?**

**Ethereum 트랜잭션**은 한 주소가 Ethereum 네트워크상의 다른 주소로 토큰이나 자산을 전송하는 계약적 절차다. Ethereum 트랜잭션의 간단한 예로, Alice라는 사람이 Ethereum의 네이티브 토큰인 ETH 1개를 친구 Bob에게 보내는 경우를 들 수 있다.

트랜잭션은 블록체인 애플리케이션 구축의 기초가 되므로, Ethereum 트랜잭션에 포함되는 정보를 살펴보자.

### **Ethereum 트랜잭션에는 어떤 정보가 포함되는가?**

프로그래밍 언어 수준에서 보면, 발신자 Alice는 **msg.sender** 전역 변수를 가지고, 수신자 Bob은 **address\(this\)** 변수를 가지며, 양측 간에 전송되는 토큰의 양인 ETH 1개는 **msg.value**가 된다.

위 데이터 외에도, 일반적인 Ethereum 트랜잭션에는 항상 다음 정보가 포함된다:

- **Signature** - 트랜잭션을 시작하겠다는 발신자의 승인 서명
- **gasLimit** - 트랜잭션에 사용할 수 있는 최대 gas 양
- **Nonce** - 특정 트랜잭션의 고유 식별자
- **Data** - 트랜잭션에 대한 설명이나 메시지를 담는 선택적 항목

## **Ethereum 트랜잭션에는 어떤 종류가 있는가?**

스마트 컨트랙트를 배포하는 트랜잭션, 개체 간\(즉, 사람 간\) 트랜잭션, 스마트 컨트랙트 간\(internal transaction\) 트랜잭션, 또는 DeFi 프로토콜 사용처럼 사람과 스마트 컨트랙트가 혼합된 트랜잭션 등 다양한 유형의 Ethereum 트랜잭션이 존재한다.

이 섹션에서는 Ethereum 네트워크 전역에서의 트랜잭션 전파와 관련된, 개체 간\(Entity-to-Entity\) 트랜잭션 상태의 여러 유형을 다룬다.

### **1. Pooled\(대기 중\) 트랜잭션**

Pooled 트랜잭션은 아직 채굴되지 않은 [mempool 내 대기 중인 트랜잭션](http://www.alchemy.com/overviews/what-is-a-mempool)이다\(즉, 단일 노드의 로컬 저장소 내에 있는 대기 중인 트랜잭션\).

두 노드가 연결을 맺으면, 각 노드의 로컬 트랜잭션 풀에 있는 내용이 공유되어 각 노드가 대기 중인 트랜잭션의 전체 목록을 갖게 된다.

노드들이 Ethereum P2P 네트워크에서 더 많은 연결을 맺을수록, 하나 또는 여러 노드에 동시에 전송된 트랜잭션은 네트워크 전역으로 더 광범위하게 전파된다.

### **2. Mined 트랜잭션**

Mined 트랜잭션은 대기 중인 트랜잭션의 전역 풀\(즉, mempool\)에서 선택되어 블록체인에 추가된 새로운 블록에 포함된, 완료된 트랜잭션이다.

[체인 재구성\(reorg\)](https://www.alchemy.com/overviews/what-is-a-reorg) 때문에, mined 트랜잭션은 여러 커밋 수준 중 하나를 가질 수 있다. The Merge 이전에는 트랜잭션 블록이 매 블록\(~12초\)마다 증가하는 _latest_ 커밋 수준을 가졌으며, The Merge 이후에는 트랜잭션에 32블록\(~6분\)마다 증가하는 _safe_\(_justified_라고도 함\) 또는 finalized 라벨이 추가로 붙을 수 있다.

_Safe_ 블록은 재구성될 가능성이 낮은 블록이며, _finalized_ 블록은 재구성될 가능성이 극히 낮은 블록이다.

### **3. Dropped 및 Replaced 트랜잭션**

[Dropped 트랜잭션](https://www.alchemy.com/docs/ethereum-transactions-pending-mined-dropped-replaced)은 전역 mempool에서 제거된 대기 중인 트랜잭션이다. Dropped 트랜잭션은 발신자의 gas 수수료가 너무 낮거나, 트랜잭션의 nonce에 오류가 있을 때 발생할 수 있다.

Replaced 트랜잭션은 mempool에 있는 기존 트랜잭션과 동일한 nonce를 가진 트랜잭션이다. Replaced 트랜잭션은 사용자가 원래 트랜잭션이 다음 블록에 포함되도록 gas 가격을 인상하려 할 때 가장 흔히 사용된다. Replaced 트랜잭션이 확정되면 원래 트랜잭션은 dropped 된다.

### **4. Reinforced 트랜잭션**

Reinforced 트랜잭션은 트랜잭션을 Ethereum 노드에 재전파함으로써, 특히 네트워크 활동이 많고 gas 가격 변동성이 큰 시기에 트랜잭션이 검증될 가능성을 높이는 새로운 Ethereum 트랜잭션 유형이다.

Reinforced 트랜잭션은 실패하거나 dropped된 트랜잭션에 대한 해결책이다.

### **추가 트랜잭션 유형**

pooled, mined, dropped 및 replaced, reinforced 트랜잭션 외에도 다음과 같은 트랜잭션 상태들이 있다:

- **Canceled Transactions** - 원래 트랜잭션을 취소하는 replacement 트랜잭션의 한 유형
- **Confirmed Transactions** - 채굴되어 블록체인에 포함된 트랜잭션
- **EOA Transactions** - 하나 이상의 Externally Owned Account\(EOA\), 일반적으로 사람 간의 트랜잭션
- **Failed Transactions** - 시도했지만 성공하지 못한 트랜잭션
- Internal Transactions - 두 스마트 컨트랙트 간의 트랜잭션
- **Private Transactions** - 공개 mempool을 거치지 않고 마이너에게 직접 전송되는 트랜잭션
- **Stuck Transactions** - 채굴될 수 없는 트랜잭션
- **Type 0 Transactions** - EIP-1559 도입 이전의 트랜잭션
- **Type 2 Transactions** - EIP-1559 업데이트를 따르는 트랜잭션

## **Ethereum의 P2P 네트워크는 어떻게 작동하는가?**

peer-to-peer 네트워크에서 사용자는 네트워크 자원의 소비자이자 공급자다. 그러나 모든 P2P 프레임워크가 동일한 것은 아니며, 정보가 공유되고 검증되고 브로드캐스트되는 메커니즘을 이해하는 것이 Ethereum 네트워크 전체를 이해하는 데 중요하다.

P2P 네트워크에서는 정보가 노드를 통해 공유되고 저장된다. 이 글을 쓰는 시점 기준으로 Ethereum에는 30만 개 이상의 full node가 있다. 다음은 새로운 full node가 추가되는 방식, 관련 프로토콜, 그리고 각 노드가 Ethereum 체인에서 새로운 블록을 처리, 검증, validate하기 위해 수행하는 구체적인 기능에 대한 개요다.

### **1. 노드가 서로를 발견한다**

Ethereum은 네트워크상의 새로운 노드를 감지하고 발견하기 위해 **bootnode**를 사용한다. 새로운 노드가 연결하고자 하면, bootnode에 PING이라 불리는 초기화 요청을 보낸다. 그러면 bootnode는 bonding PONG 메시지로 응답한다.

이 과정이 완료되면, 노드는 bootnode에게 근처에 있는 다른 노드들의 목록을 요청한다. Ethereum은 노드를 이진 트리의 leaf로 구성하기 때문에, 여기서 말하는 거리는 임의의 두 노드의 160비트 ID 간의 수치적 근접성을 의미한다.

노드가 근처의 사용 가능한 노드들과 연결할 수 있게 되면 bootnode의 역할은 끝난다. 이후 동기화 작업은 RPLx 프로토콜이 담당한다.

### **2. 노드가 보안 연결을 수립한다**

RPLx 프로토콜은 패킷\(즉, 작은 데이터 조각\)을 주고받을 수 있도록 함으로써 두 노드의 동기화를 지원한다. 패킷은 RLP 인코딩을 사용해 동적으로 프레임화되며, 암호화 및 인증된다.

RPLx를 사용해 노드는 보안 연결을 수립하고 서로를 검증한다. 검증을 위해서는 두 노드 모두 인증 메시지를 보낸 뒤, 포트, 클라이언트와 노드 양쪽의 ID, 프로토콜 및 하위 프로토콜 정보를 포함한 메시지를 보내야 한다.

노드들이 서로 인증을 마치면 Wire protocol을 사용해 통신을 시작할 수 있다. 이 두 노드는 이제 peer로 간주되며, peer는 노드가 Ethereum 네트워크 전체와 통신하는 방식이다.

### **3. 노드가 상태, 블록을 동기화하고 pooled 트랜잭션을 교환한다**

이 단계에서, Ethereum P2P 네트워크상의 새로운 full node는 프로토콜 전체의 상태와 조화를 이루고 데이터 교환을 시작한다. 여기서 노드와 클라이언트를 구분하는 것이 중요하다. 두 용어가 종종 혼용되긴 하지만, 클라이언트는 노드가 Ethereum 블록체인의 블록과 스마트 컨트랙트를 읽을 수 있게 해주는 소프트웨어다.

Ethereum의 모든 full node는 [Wire protocol](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)과 관련해 세 가지 기본 작업을 수행한다:

1. Synchronization
1. Block Propagation
1. Pending Transaction Propagation

#### **3A. 체인 및 상태 동기화**

Synchronization은 체인과의 동기화, 상태와의 동기화로 나뉜다.

체인 동기화 과정에서 peer들은 자신이 가진 블록의 난이도와 해시를 제시한다. 난이도가 가장 높은 클라이언트가 블록의 헤더를 다운로드한다. 반면 상태 동기화 과정에서는, peer들이 데이터의 원본성을 인증하고 블록 상태를 다운로드한다.

#### **3B. Block Propagation**

Block propagation 과정에서, Ethereum P2P 네트워크상의 블록이 처리되고 브로드캐스트된다. 새로운 블록이 생기면, 클라이언트는 이를 peer에게 전송하고 블록 안의 트랜잭션을 승인함으로써 검증한다.

클라이언트가 블록을 validate하고 처리한 뒤, 노드는 이를 네트워크의 모든 full node 또는 peer에게 브로드캐스트해, 이들이 그 유효성을 검토할 기회를 갖도록 해야 한다.

#### **3C. Pending\(Pooled\) 트랜잭션 교환**

새로운 블록을 체인에 추가하는 책임은 마이너에게 있다. 따라서 검증에 참여한 모든 노드는 마이너에게 처리된 대기 중인 트랜잭션을 제공해야 한다.

이 교환을 시작하기 위해, 각 peer는 자신이 가진 대기 중인 트랜잭션의 해시를 서로에게 보내야 한다. [Private 트랜잭션](http://www.alchemy.com/overviews/ethereum-private-transactions)은 마이너나 블록 생산자에게 직접 전송되기 때문에, 노드들은 이러한 유형의 트랜잭션을 발견하거나 전파할 수 없다.

이 모든 작업이 완료되면, 마이너는 새로운 블록을 Ethereum 체인에 추가할 수 있게 되고, Wire protocol이 다시 시작된다.

## **Ethereum 트랜잭션은 어떻게 전파되는가?**

Ethereum 트랜잭션은 노드가 자신의 pooled 트랜잭션 컬렉션에 새로운 트랜잭션이 있음을 알리고, peer들이 이 트랜잭션을 가져오기 위해 조회할 때 네트워크 전체에 전파된다.

과정은 다음과 같다:

1. 전파하는 노드는 `NewPooledTransactionHashes` 메시지를 게시해 새로운 트랜잭션이 있음을 네트워크에 알린다.
1. 또는 peer들이 `GetPooledTransactions` 메시지를 게시해 이러한 트랜잭션을 조회할 수 있다

## **The Merge 이후 트랜잭션은 어떻게 브로드캐스트되는가?**

The Merge 이후, Ethereum 노드는 트랜잭션 처리에 대해 각각 별도의 역할을 담당하는 두 개의 노드 클라이언트, 즉 [execution layer client와 consensus layer client](https://www.alchemy.com/overviews/execution-layer-and-consensus-layer-node-clients)를 갖는다. 요약하면, execution layer client는 트랜잭션을 실행하고 상태를 validate하는 역할을 하며, consensus layer client는 새로운 블록을 수신하고 전파하는 역할을 한다.

**Merge 이후 환경에서 트랜잭션이 어떻게 작동하는지 좀 더 자세히 살펴보자:**

각 노드의 consensus layer client는 블록을 수신하고, 사전 검증하며, execution layer client에 블록을 전달하고, EL client가 작업을 완료하면 블록체인 head에 블록을 추가하고, 네트워크에 브로드캐스트하는 역할을 담당한다.

execution client가 노드의 consensus layer client로부터 사전 검증된 블록을 받으면, 트랜잭션을 실행하고 블록의 상태를 validate한 뒤, validate된 블록을 consensus layer client로 다시 전송하는 역할을 담당한다.

이러한 변경 사항을 제외하면, Ethereum P2P 네트워크의 다른 모든 동작 방식은 [The Merge](https://www.alchemy.com/the-merge) 이후에도 동일하게 유지된다.

### **CL client가 블록 생산자이기도 할 때 트랜잭션은 어떻게 브로드캐스트되는가?**

Merge 이후의 Ethereum에는 [block producer와 block proposer](https://www.alchemy.com/overviews/proposer-builder-separation)가 존재하며, consensus layer client가 block producer를 겸할 경우 The Merge 이후 트랜잭션과 블록이 전파되는 방식은 약간 다르게 작동한다. 이 세부적인 사용 사례에 대한 정보는 [Ethereum Foundation의 네트워킹 계층 문서](https://ethereum.org/en/developers/docs/networking-layer/#connecting-clients:~:text=When%20consensus%20client%20is%20block%20producer%3A)를 참고하기 바란다.

## **Ethereum 트랜잭션 전파 요약**

Ethereum의 글로벌 peer-to-peer 네트워크는 노드들이 서로를 발견하고, 검증하고, 안전하게 통신함으로써 대기 중인\(pooled\) 트랜잭션과 새로 채굴된 블록을 브로드캐스트할 것을 요구한다. RLPx와 Wire Protocol 같은 일련의 저수준 네트워킹 프로토콜을 사용해 peer를 맺고 정보를 전파하는 이 과정이, Ethereum이라는 전 세계적인 컴퓨터 전역에서 블록체인 트랜잭션을 가능하게 만든다.