Tech/EIPs/#2718
EIP 2718카테고리 · 코어유형 · 표준 트랙상태 · 최종

Typed Transaction Envelope

쉬운 설명

새로운 트랜잭션 유형을 추가할 수 있는 확장 가능한 봉투(Envelope) 형식을 정의해요. 이 틀 위에 EIP-1559 수수료 방식, EIP-2930 접근 목록 등이 만들어졌어요.

EIP-2718은 이더리움 트랜잭션에 타입 시스템을 도입한 핵심 Core EIP입니다. TransactionType || TransactionPayload 형식의 봉투(Envelope) 구조를 정의해, 프로토콜 수준에서 새로운 트랜잭션 형식을 하위 호환성을 유지하며 안전하게 추가할 수 있는 확장 가능한 기반을 마련했습니다.

레거시 트랜잭션의 확장성 문제

기존 이더리움 트랜잭션(레거시, type 0)은 RLP 인코딩된 단일 고정 형식이었습니다. 새로운 필드나 의미론을 추가하려면 기존 필드를 재활용(예: EIP-155의 v 필드에 체인 ID 인코딩)하거나, 이미 배포된 클라이언트와의 호환 파싱이 불가능한 형식 변경이 필요했습니다. 이는 프로토콜 혁신의 심각한 병목이었습니다.

TransactionType || TransactionPayload 포맷

인코딩된 트랜잭션의 첫 바이트가 트랜잭션 타입을 나타냅니다. 0~0x7f 범위의 단일 바이트가 type이며, 나머지 바이트는 해당 타입에 맞는 페이로드(RLP 또는 다른 인코딩)입니다. 레거시 트랜잭션(0xc0~0xfe로 시작하는 RLP 리스트)과 첫 바이트로 구분할 수 있어 하위 호환성을 보장합니다.

EIP-1559와 EIP-2930 활성화

EIP-2718이 없었다면 EIP-1559(maxFeePerGas, maxPriorityFeePerGas 추가)나 EIP-2930(accessList 추가)을 레거시 형식에 깔끔하게 추가하는 것이 불가능했습니다. EIP-2718 덕분에 EIP-2930은 type 1, EIP-1559는 type 2 트랜잭션으로 독립적으로 정의됐으며, 향후 새로운 트랜잭션 타입(예: EIP-4844의 blob tx = type 3, EIP-7702 = type 4)도 동일 방식으로 추가됩니다.

영수증(Receipt)과 서명의 타입 확장

EIP-2718은 트랜잭션뿐만 아니라 TransactionReceipt에도 동일한 타입 봉투 개념을 적용합니다. 타입별 수신 영수증을 구분해 클라이언트가 적절히 파싱할 수 있도록 합니다. 서명 해시(sighash) 계산 시에도 타입 바이트를 포함해 서명 충돌을 방지합니다.

생태계 영향과 미래 확장성

EIP-2718은 이더리움 프로토콜의 "미래 대비(future-proof)" 설계를 가능하게 한 메타 EIP입니다. 지갑, 노드, 익스플로러가 미지의 트랜잭션 타입을 무시하거나 경고하면서도 알려진 타입은 정상 처리할 수 있습니다. EIP-4844 blob 트랜잭션(type 3)이나 EIP-7702(type 4)처럼 앞으로도 새로운 타입이 이 틀 위에서 계속 정의될 것입니다.

공식 EIP 문서open_in_new