EIP-2718은 거래를 TransactionType 한 바이트와 페이로드를 이어 붙인 봉투로 정의해 새 거래 종류를 추가하기 쉽게 합니다. 첫 바이트가 0~0x7f이면 새 유형, 0xc0~0xfe이면 기존 거래입니다. 이 글은 2026-10-27에 연 EIP-2718 원문(상태 Final)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
봉투는 어떻게 만들어질까?
TransactionType은 0부터 0x7f 사이의 부호 없는 8비트 값이고, TransactionPayload는 유형에 따라 해석이 달라지는 불투명한 바이트 배열입니다. 영수증도 TransactionType과 ReceiptPayload를 이은 형태입니다.
| 첫 바이트 | 의미(원문) |
|---|---|
| 0 ~ 0x7f | 새 거래 유형, 봉투 형식 |
| 0xc0 ~ 0xfe | RLP로 인코딩된 기존 거래 |
| 0xff | 확장 표지로 예약 |
기존 거래와는 어떻게 구분될까?
원문 Backwards Compatibility는 첫 바이트로 구분합니다. RLP로 인코딩된 기존 거래는 0xc0~0xfe로 시작하고, 0xff는 확장용 표지로 예약되어 있습니다. 접근 목록 거래는 접근 목록이란? 이더리움 거래의 계정·저장소 지정 글에, 기본 수수료 거래는 EIP-1559 기본 수수료는 왜 오르고 내려갈까 글에서 각각 다룹니다.
탐색기에서는 무엇이 달라 보일까?
거래 유형 번호가 보이면 봉투의 첫 바이트를 해석한 값입니다. 유형별 필드는 이 EIP가 아니라 각 EIP가 정합니다.
봉투 방식은 어떤 문제를 풀까?
봉투는 맨 앞 한 바이트로 유형을 알리고 나머지는 유형별 규칙에 맡겨, 서로 다른 형식이 한 구조 안에 공존할 수 있게 합니다. 기존 거래는 첫 바이트가 0xc0 이상이라 겹치지 않으며, 원문은 0xff를 확장 표지로 남겨 둡니다. 새 필드가 필요한 기능은 새 유형 번호를 받아 정의되고, 이 EIP 자체는 어떤 유형도 구체적으로 도입하지 않습니다.
이 글에서 확인하지 못한 것은?
현재 쓰이는 거래 유형 번호별 필드와 의미, 각 유형이 도입된 시점은 개별 EIP의 내용이라 이번에 열지 않았습니다. 영수증 페이로드의 구체적 구성도 유형별 EIP가 정합니다. 탐색기에 표시되는 유형 이름이 서비스마다 다를 수 있다는 점은 이 문서에서 확인한 사실이 아닙니다. 정리하면 첫 바이트가 유형을 알려 주는 표지이므로, 같은 거래 데이터를 읽을 때도 먼저 맨 앞 바이트가 0x7f 이하인지 0xc0 이상인지를 보면 봉투형인지 기존형인지 나눌 수 있습니다. 원문의 작성일은 2020-06-13이며 상태는 Final입니다. 유형 값의 범위가 0부터 0x7f이므로 번호 공간은 모두 128개이고, 거래와 영수증 모두 유형 바이트를 앞에 붙인 하나의 바이트열로 다뤄집니다. 어떤 번호가 어떤 기능에 쓰이는지는 개별 문서에서 따로 확인해야 합니다.
자주 묻는 질문
거래 유형 번호는 누가 정하나요?
이 EIP는 봉투 형식만 정합니다. 각 번호의 필드와 의미는 유형을 도입하는 별도 EIP가 정합니다.
기존 거래는 지금도 쓰이나요?
원문은 첫 바이트가 0xc0~0xfe이면 기존 유형이라고 정의합니다. 현재 사용 비율은 이 글에서 확인하지 않았습니다.
영수증에도 유형이 붙나요?
원문 Abstract가 TransactionType과 ReceiptPayload를 이은 것이 유효한 영수증이라고 적습니다.
