Ethereum Transaction Lifecycle

· 11분 읽기

이더리움에서 트랜잭션을 전송하면 실제로 어떤 일이 일어나는가?

Defi 프로토콜처럼 실제 자금을 다루는 시스템을 개발하는 경우, 트랜잭션 라이프사이클을 정확하게 이해하는 것은 필수이다.

사용자가 Confirm 하는 순간부터, 그 트랜잭션이 블록체인에 영구적으로 기록되어 되돌릴 수 없는 상태(Finality)에 도달하기 까지, 이더리움 네트워크에서는 복잡한 과정이 진행된다.

트랜잭션 구조

이더리움 트랜잭션 형식은 예전부터 점차 진화해왔다. 따라서 트랜잭션 타입이 여러 개다.

트랜잭션 타입

Type 0(Legacy): 레거시, 말 그대로 기본 트랜잭션 형식

Type 1(EIP-2903): Access List 트랜잭션, Berlin 하드포크

Type 2(EIP-1559): 새로운 Gas 메커니즘이 적용된 트랜잭션, London 하드포크

Type 3(EIP-4844): Blob 트랜잭션 (Dencun 하드포크)

Type 4(EIP-7702): Account Abstraction 트랜잭션 (Pectra 하드포크)

필요에 따라 사용하는게 다르지만, 아직 대부분 usecase 에서는 Type2 를 사용하는듯 하다.

L2 롤업에서는 Type3 를 적극적으로 활용한다.

각 하드포크에 대해서는 별도 아티클에서 다루도록 하고 본 글에서는 다루지 않는다.

이제 각 트랜잭션별 사용되는 필드를 알아보자.

Type 0, Legacy Transaction

  • nonce: 발신자 계정의 트랜잭션 순차 번호 (0부터 시작, 매 트랜잭션마다 +1)

  • gasPrice: Gas당 지불할 가격 (예: 30 gwei)

  • gasLimit: 이 트랜잭션이 소비할 수 있는 최대 Gas 양 (단순 전송: 21,000)

  • to: 수신자 주소 (20 bytes). null이면 컨트랙트 배포

  • value: 전송할 ETH 양 (wei 단위. 1 ETH = 10^18 wei)

  • data: 스마트 컨트랙트 호출 데이터 (ABI 인코딩). 단순 전송 시 빈 값 (0x)

  • v: ECDSA Recovery ID. EIP-155 이전: 27 또는 28. EIP-155 이후: chainId * 2 + 35 또는 chainId * 2 + 36

  • r: ECDSA 서명의 R 값 (32 bytes). 서명 시 생성되는 타원곡선 포인트의 X 좌표

  • s: ECDSA 서명의 S 값 (32 bytes). 서명의 증거 값

chainId에 대해: Legacy 트랜잭션에는 별도의 chainId 필드가 없다. EIP-155(2016) 이전에는 replay protection이 아예 없어서, 같은 트랜잭션을 다른 체인(예: mainnet ↔ testnet)에서 재사용할 수 있었다. EIP-155 이후 v 값에 chainId를 인코딩하여 이를 방지한다. Type 1(EIP-2930)부터 chainId가 독립 필드로 분리되었다.

Type 1, EIP-2930 Transaction

2021년 4월 Berlin 하드포크에서 도입. EIP-2929로 인해 특정 opcode(SLOAD, CALL 등)의 Gas 비용이 인상되었는데, 이에 대한 보완책으로 Access List를 통해 미리 접근할 주소/슬롯을 선언하면 Gas를 절약할 수 있게 했다.

  • chainId: 체인 식별자. 최초로 독립 필드로 분리됨 (Legacy의 v 인코딩 방식에서 벗어남)

  • nonce: 발신자 계정의 트랜잭션 순차 번호

  • gasPrice: Gas당 지불할 가격 (Legacy와 동일한 단일 가격 방식)

  • gasLimit: 이 트랜잭션이 소비할 수 있는 최대 Gas 양

  • to: 수신자 주소 (20 bytes). null이면 컨트랙트 배포

  • value: 전송할 ETH 양 (wei 단위)

  • data: 스마트 컨트랙트 호출 데이터

  • accessList: 트랜잭션이 접근할 주소와 스토리지 슬롯의 목록. 각 항목:

    • address: 접근할 컨트랙트 주소

    • storageKeys: 접근할 스토리지 슬롯 해시 목록

  • v: ECDSA Recovery ID (0 또는 1. chainId가 별도 필드이므로 단순화)

  • r: ECDSA 서명의 R 값 (32 bytes)

  • s: ECDSA 서명의 S 값 (32 bytes)

Access List의 Gas 절약 원리: EIP-2929에서 “cold” 스토리지 접근은 2,100 Gas, “warm” 접근은 100 Gas로 차등 책정되었다. Access List에 미리 선언하면 해당 슬롯이 “warm” 상태로 시작되어 cold 접근 비용(2,100)을 지불하지 않는다. 단, Access List 자체에도 Gas 비용이 있으므로 (주소당 2,400 Gas, 슬롯당 1,900 Gas) 실제로 접근하는 경우에만 이득이다.

Type 2, EIP-1559 Transaction

  • chainId: 체인 식별자 (예: 1 = Ethereum Mainnet, 11155111 = Sepolia). Type 2부터 독립 필드

  • nonce: 발신자 계정의 트랜잭션 순차 번호

  • maxPriorityFeePerGas: Validator에게 지불하는 팁 (예: 2 gwei)

  • maxFeePerGas: Gas당 지불할 최대 가격 (예: 100 gwei). 실제 지불 = min(maxFeePerGas, baseFee + maxPriorityFeePerGas)

  • gasLimit: 이 트랜잭션이 소비할 수 있는 최대 Gas 양

  • to: 수신자 주소 (20 bytes)

  • value: 전송할 ETH 양 (wei 단위)

  • data: 스마트 컨트랙트 호출 데이터

  • accessList: 미리 접근할 주소와 스토리지 슬롯을 선언하여 Gas 절약 (EIP-2930에서 도입)

  • v: ECDSA Recovery ID (0 또는 1. chainId가 별도 필드이므로 v가 단순화됨)

  • r: ECDSA 서명의 R 값 (32 bytes)

  • s: ECDSA 서명의 S 값 (32 bytes)

Type 3, EIP-4844 Transaction

2024년 3월 13일 Dencun 업그레이드로 도입된 Blob Transaction은 L2 롤업의 데이터 가용성 비용을 대폭 절감했다.

트랜잭션 본체:

  • chainId: 체인 식별자

  • nonce: 발신자 계정의 트랜잭션 순차 번호

  • maxPriorityFeePerGas: Validator에게 지불하는 팁

  • maxFeePerGas: 일반 Gas당 지불할 최대 가격

  • maxFeePerBlobGas: Blob 전용 Gas 최대 가격. 일반 Gas와 별도의 수수료 시장에서 결정됨

  • gasLimit: 이 트랜잭션이 소비할 수 있는 최대 Gas 양

  • to: 수신자 주소 (20 bytes). Blob 트랜잭션은 null이 될 수 없음 (컨트랙트 배포 불가)

  • value: 전송할 ETH 양 (wei 단위)

  • data: 스마트 컨트랙트 호출 데이터

  • accessList: 접근 목록

  • blobVersionedHashes: Blob 데이터의 KZG commitment 해시 목록. 온체인에 기록되어 Blob 참조에 사용

  • v, r, s: ECDSA 서명 값

Blob Sidecar (트랜잭션 본체와 별도로 전파):

  • blobs: 실제 Blob 데이터 (최대 6개, 각 128 KiB)

  • commitments: KZG commitment 값들. Blob 데이터의 다항식 커밋먼트

  • proofs: KZG proof 값들. commitment의 유효성을 증명

Blob의 특징:

  • 각 Blob = 4,096 field elements × 32 bytes = 128 KiB

  • 블록당 목표: 3개 Blob (Pectra 이후 6개로 증가)

  • 블록당 최대: 6개 Blob (Pectra 이후 9개로 증가)

  • Blob당 Gas: 131,072 (고정)

Blob 의 정의, L2 에서 Blob 을 활용하는 방식도 별도 아티클로 다룬다.

Type 4, EIP-7702 Transaction

2025년 5월 7일 Pectra 업그레이드로 도입된 EIP-7702는 EOA(Externally Owned Account)가 임시로 스마트 컨트랙트 코드를 실행할 수 있게 한다.

  • chainId: 체인 식별자

  • nonce: 발신자 계정의 트랜잭션 순차 번호

  • maxPriorityFeePerGas: Validator에게 지불하는 팁

  • maxFeePerGas: Gas당 지불할 최대 가격

  • gasLimit: 이 트랜잭션이 소비할 수 있는 최대 Gas 양

  • to: 수신자 주소 (20 bytes)

  • value: 전송할 ETH 양 (wei 단위)

  • data: 스마트 컨트랙트 호출 데이터

  • accessList: 접근 목록

  • authorizationList: EOA가 위임할 컨트랙트 코드 목록. 각 항목은:

    • chainId: 위임이 유효한 체인 (0이면 모든 체인에서 유효)

    • address: 위임할 컨트랙트 주소 (Delegation Designator: 0xef0100 || address)

    • nonce: 위임자의 현재 nonce

    • v, r, s: 위임자(EOA)의 ECDSA 서명

  • v, r, s: 트랜잭션 발신자의 ECDSA 서명 값

Authorization List:

  • EOA가 트랜잭션 실행 중에만 특정 컨트랙트 코드를 사용하도록 승인

  • Delegation Designator: 0xef0100 || address

  • 트랜잭션 종료 후 EOA는 원래 상태로 복귀

주요 사용 사례:

  1. 트랜잭션 배칭: 여러 작업을 하나의 트랜잭션으로 묶기

  2. Gas 스폰서십: 다른 사람이 Gas 비용 대납

  3. 소셜 복구: 친구/가족의 서명으로 계정 복구

  4. 커스텀 검증 로직: 멀티시그, 지출 한도 등

EIP-3074와의 비교:

  • EIP-3074는 폐기되고 EIP-7702로 대체됨

  • EIP-7702는 더 안전하고 ERC-4337과 호환 가능

  • 트랜잭션별 임시 위임으로 보안 강화

주소의 도출

이더리움의 보안은 타원곡선 암호화(ECDSA)에 기반한다.

Private Key → Public Key → Address 의 순서로 주소를 도출해내는 방식이다.

아래 그림을 참조하면 편하다.

What Is the Elliptic Curve Digital Signature Algorithm (ECDSA ...

트랜잭션 서명 과정

  1. 트랜잭션 데이터를 준비한다.

  2. RLP 인코딩(이더리움의 표준 직렬화 형식이다)

  3. 해시 생성(txHash = keccak256(rlpEncoded))

  4. Private Key 로 서명

(v, r, s) = sign(txHash, privateKey)
v: Recover ID
r: 서명의 X 좌표
s: 서명의 증거값

서명 검증 과정

노드가 트랜잭션을 받으면 다음을 검증한다.

  1. v, r, s 값에서 Public Key 복구

  2. Public Key 에서 Address 도출 (이 주소가 곧 sender 가 됨)

  3. 도출된 Address 기반으로 상태 검증(nonce 일치여부, balance >= value + gas?, gasLimit?)

모두 통과하면 Mempool 에 추가한다.

트랜잭션 전파 후 블록 포함

서명된 트랜잭션은 이제 네트워크를 통해 전파되어야 한다.

RPC 를 통해 노드로 전송되고 나면, 검증 이후 Mempool 에 추가되고, GasPrice 가 높은 트랜잭션이 우선순위가 된다.

만약 Nonce 가 미래 값이라면 대기 상태에 들어간다.

노드는 연결된 Peer 들에게 전파하고, 각 노드가 검증 후 자신의 Mempool 에 추가한다.

그리고 다시 연결된 Peer 들에게 전파한다.

여기서부터는 빠르게 진행된다. Gossip protocol 등에 대해서 공부해보면 좋지만 이 글에서는 다루지 않는다.

Validator 가 선택하는 경우 블록에 트랜잭션이 포함되는데, 포함되었다고 해서 Finality 보장이 되는 것은 아니다.

The Merge 이후의 이더리움에서는 절대적 Finality 가 보장되는데,

Finalized된 블록을 되돌리려면 전체 검증자 예치금의 1/3 이상이 소각되어야 하므로, 경제적으로 사실상 불가능하다.

이것은 확률적 보장이 아니라 경제적/수학적 보장이다.

이더리움에서는 Slot / Epoch 라는 단위를 사용한다.

  • Slot: 12초, 각 Slot 마다 한 명의 Validator 가 Block 을 제안한다

  • Epoch: 32 Slots = 약 6.4분, Finality 판단의 기본 단위

Finality 는 두 단계를 거친다.

  1. Justified: 한 Epoch 가 끝나면, 해당 Epoch 에 속한 검증자들이 Checkpoint 에 대해서 투표한다. 여기서 말하는 체크포인트는 Epoch 의 첫 번째 Slot 의 블록을 말한다. 전체 스테이킹 ETH 의 2/3 이상이 투표하면, Justied 상태가 된다.

  2. Finalized: 다음 Epoch 의 Checkpoint 도 Justified 가 되면, 이전 Epoch 의 Justified Checkpoint 가 Finalized 된다. 즉, 연속으로 2개의 Epoch 이 justified 되어야 첫 번째 Epoch 이 finalized 된다.

Finalized 된 블록은 프로토콜 규칙 상 절대 되돌릴 수 없다. 만약 누군가가 Finalized 된 블록을 포함하지 않는 대안 체인을 만드려면, 기존 Finalized 에 투표했던 검증자들 중 1/3 이상이 모순된 투표를 해야한다.

이 경우 해당 (모순된 투표를 한) 검증자들의 예치금이 전액 소각된다. (Slashing 이라고 함)