이더리움 RLP 인코딩: 접두부 규칙·리스트·트랜잭션 이해하기

이더리움 탐색기는 트랜잭션을 깔끔한 표로 보여주지만, 노드가 실제로 받는 것은 바이트예요. 모든 구현체가 바이트 경계를 똑같이 나누지 못하면 네트워크는 무엇이 전송됐는지 합의할 수 없습니다. 이 실행 레이어 구조의 바탕에 있는 간결한 규칙이 재귀 길이 접두부(RLP, Recursive-Length Prefix) 인코딩이에요.

이 글은 RLP를 블록체인 기초 안에서 살펴보고 접두부, 중첩 리스트, 트랜잭션 봉투, 실패 사례를 차례로 설명합니다. RLP는 기술 인프라이지 투자 신호가 아니며, 이를 이해한다고 ETH 가격을 예측할 수는 없어요.

이더리움 RLP 인코딩이란?

RLP는 바이트 문자열(Byte String)과 바이트 문자열이 재귀적으로 중첩된 리스트를 직렬화(Serialization)하는 방식입니다. 직렬화는 구조화된 데이터를 저장·전송·해시하고 나중에 다시 해석할 수 있는 하나의 결정론적 바이트열로 바꾸는 과정이에요.

공항에서 큰 여행 가방 안에 작은 가방을 넣는 장면을 떠올려 보세요. 각 가방에는 뒤에 내용물이 얼마나 이어지는지 알려주는 짧은 표가 붙습니다. 큰 가방 안의 작은 가방에도 같은 방식의 표가 붙어요. 다만 표에는 내용물이 여권인지 옷인지, 트랜잭션 논스(Nonce)인지는 적혀 있지 않습니다. 바이트와 리스트의 경계만 표시하고, 의미와 필드 순서는 상위 이더리움 규칙이 정해요.

이 제한된 역할은 의도된 설계입니다. 이더리움 공식 문서에 따르면 RLP는 주로 구조를 인코딩하며 대부분의 데이터 타입 해석은 상위 프로토콜에 맡겨요. 문자열, 주소, 불리언, 부호 있는 정수, 필드명, 스키마를 자체적으로 알지 못합니다. RLP 정의에서 ‘문자열’은 단순한 바이트 배열이에요.

다섯 가지 RLP 접두부 범위

첫 바이트를 보면 디코더는 대상이 바이트 문자열인지 리스트인지, 페이로드 길이를 어디서 찾아야 하는지 알 수 있어요.

긴 문자열과 리스트에서는 접두부가 먼저 ‘길이 필드 자체의 바이트 수’를 알려줘요. 이어지는 길이 필드가 실제 페이로드 길이를 나타냅니다. 작은 객체를 위해 큰 고정 길이 필드를 항상 예약하지 않아도 되는 구조예요.

경계는 리스트 항목 수가 아니라 인코딩된 페이로드 바이트 수를 기준으로 합니다. 자식이 두 개뿐이어도 각각 크다면 55바이트 경계를 넘을 수 있어요.

작은 값을 단계별로 인코딩하기

먼저 dog의 ASCII 바이트는 0x64 0x6f 0x67이에요. 페이로드가 3바이트이므로 짧은 문자열 접두부는 0x80 + 3 = 0x83입니다.

dog -> 83 64 6f 67

0x00부터 0x7f까지의 단일 바이트는 값 그대로 인코딩해요. 따라서 한 바이트 0x0f는 그대로 0x0f이며, 0x81 0x0f로 감싸면 불필요하게 길어진 비표준(Non-canonical) 표현입니다.

빈 값은 중요한 차이를 보여줘요.

빈 바이트 문자열 -> 80
빈 리스트        -> c0
정수 0           -> 80  (표준 정수-바이트 변환 뒤)
바이트 0x00      -> 00

RLP 자체는 바이트 문자열이 정수라고 선언하지 않아요. 상위 이더리움 프로토콜이 양의 정수로 해석할 때는 선행 0이 없는 가장 짧은 빅엔디언(Big-endian) 표현을 사용해야 합니다. 정수 0은 RLP 인코딩 전에 빈 바이트 배열로 바뀌어요.

이제 cat과 dog를 리스트에 넣어 볼게요. 세 글자 단어는 접두부까지 각각 4바이트예요. 두 인코딩을 합친 페이로드가 8바이트이므로 리스트는 0xc0 + 8 = 0xc8로 시작합니다.

[cat, dog] -> c8 83 63 61 74 83 64 6f 67

각 자식을 먼저 인코딩하고, 결과를 이어 붙인 뒤 전체 리스트 페이로드에 다시 접두부를 붙여요. 이것이 이름에 ‘재귀(Recursive)’가 들어가는 이유입니다.

이더리움은 RLP를 어디에 사용할까?

RLP는 이더리움 실행 레이어(Execution Layer) 여러 곳에 등장하지만, 객체를 특정하지 않은 채 “이더리움은 RLP를 쓴다”고만 말하면 너무 넓은 설명이에요.

레거시·타입 트랜잭션

EIP-2718은 두 트랜잭션 계열을 정의합니다. 레거시 트랜잭션(Legacy Transaction)은 논스, 가스 가격, 가스 한도, 목적지, 가치, 데이터, 서명 값 등을 담은 RLP 리스트예요. 타입 트랜잭션(Typed Transaction)은 트랜잭션 타입 바이트로 시작하고, 그 뒤에 해당 타입이 정의한 페이로드가 붙습니다.

현재 여러 타입 트랜잭션의 페이로드도 RLP 리스트지만 EIP-2718은 의도적으로 페이로드를 불투명한 바이트 배열로 취급해요. 미래 트랜잭션 타입이 다른 인코딩을 정의할 여지를 남긴 것입니다. 타입 트랜잭션 전체에 일반 RLP 디코더를 바로 적용하고 첫 바이트까지 RLP 리스트의 일부라고 가정하면 안 돼요.

계정·트라이·영수증

이더리움 수정 머클 패트리샤 트라이(Modified Merkle Patricia Trie)는 키와 노드 값 주위에 RLP를 사용합니다. 계정 상태는 논스, 잔액, 스토리지 루트, 코드 해시를 정해진 순서로 담아요. 트라이 노드는 직접 포함되거나 해시로 참조되기 전에 인코딩됩니다. 인증 구조는 머클 패트리샤 트라이 가이드에서 더 자세히 설명해요.

트랜잭션 영수증(Transaction Receipt)도 레거시 또는 타입 봉투를 사용하고 영수증 트라이에 커밋됩니다. 각 필드와 영수증이 증명하는 범위는 이더리움 트랜잭션 영수증을 참고하세요.

네트워크 메시지

이더리움 실행 네트워킹 스택은 구조화된 프로토콜 메시지에 RLP를 사용해 왔습니다. 정확한 메시지 스키마는 RLP 자체가 아니라 해당 네트워킹 프로토콜이 정해요.

RLP·ABI 인코딩·SSZ 차이

세 형식은 서로 다른 문제를 해결해요.

RLP 트랜잭션의 data 필드 안에 ABI로 인코딩된 컨트랙트 입력이 들어갈 수 있습니다. 두 레이어를 같은 방식으로 디코딩하면 안 돼요. 먼저 트랜잭션 봉투와 필드를 식별한 뒤, 대상 컨트랙트 ABI를 사용해 data를 해석해야 합니다. 안쪽 레이어는 콜데이터 가이드에서 다뤄요.

SSZ도 ‘모든 곳에서 RLP를 대체한 새 형식’은 아닙니다. SSZ는 합의 레이어 객체와 증명의 중심이고, RLP는 실행 레이어 구조에 계속 남아 있어요. 제안이 있다는 이유만으로 배포됐다고 추정하지 말고 정확한 객체의 활성 사양을 확인해야 합니다.

안전한 디코딩 순서

1. 먼저 컨테이너를 식별하세요. 레거시 트랜잭션, 타입 트랜잭션, 트라이 노드, 영수증, 네트워크 메시지 중 무엇인지 확인합니다.
2. 맞는 프로토콜 스키마를 고르세요. RLP 결과는 바이트 문자열과 리스트일 뿐, 필드명과 타입은 알려주지 않아요.
3. 접두부를 읽고 경계를 검사하세요. 선언된 길이가 남은 입력을 넘어가면 즉시 거부해야 합니다.
4. 비표준 표현을 거부하세요. 짧은 값은 불필요하게 긴 형식을 쓰면 안 되고, 프로토콜 정수에는 선행 0이 없어야 해요.
5. 입력이 완전히 소비됐는지 확인하세요. 예상하지 못한 후행 바이트는 잘못된 스키마나 손상된 입력의 신호일 수 있습니다.
6. 공식 테스트 벡터와 경곗값을 시험하세요. 빈 바이트, 빈 리스트, 55/56바이트 경계, 중첩 리스트, 과도한 길이 선언을 포함합니다.

운영 시스템에서는 유지 관리되는 라이브러리를 쓰세요. 학습용 디코더는 원리를 이해하는 데 유용하지만, 악의적인 재귀 입력, 메모리 할당 제한, 포크별 트랜잭션 규칙까지 안전하게 처리하기는 어렵습니다.

리스크·한계·흔한 실수

• RLP는 자기 설명형이 아니에요. 올바른 바이트도 잘못된 스키마로 해석하면 엉뚱한 의미가 붙을 수 있습니다.
• 표준 인코딩이 중요해요. 하나의 논리 값에 여러 표현을 허용하면 결정론적 해시가 흔들리므로 디코더는 상위 프로토콜이 요구하는 최소 표현을 강제해야 합니다.
• 재귀에는 한도가 필요해요. 깊게 중첩되거나 길이가 조작된 입력은 경계 검사가 없는 파서의 메모리와 스택을 소모할 수 있어요.
• 타입 봉투는 먼저 분기해야 해요. 트랜잭션 타입을 읽고 해당 타입의 페이로드 규칙을 적용해야 합니다.
• RLP는 ABI가 아니에요. 트랜잭션 봉투를 풀어도 컨트랙트 호출 인자가 자동으로 설명되지는 않습니다.
• RLP는 암호화가 아니에요. 구조를 제공할 뿐 기밀성, 인증, 권한을 제공하지 않아요.
• 디코딩 성공은 유효한 거래를 뜻하지 않아요. 서명, 논스, 가스, 포크 규칙, 상태 전이 검증이 별도로 필요합니다.

서명이나 브로드캐스트가 가능한 도구라면 디코딩한 필드가 사용자의 의도와 일치하는지 비교하고 안전한 환경에서 먼저 시험하세요. 직렬화가 정확해도 스마트 컨트랙트와 자산 상호작용은 실패하거나 손실을 낼 수 있습니다. 잃어도 되는 금액만 사용하고 스스로 조사하세요(DYOR).

자주 묻는 질문

왜 재귀 길이 접두부라고 부르나요?

각 바이트 문자열과 리스트 앞에 페이로드 길이를 식별하는 정보가 붙고, 리스트의 각 항목도 RLP로 인코딩된 항목이기 때문이에요. 따라서 리스트를 재귀적으로 중첩할 수 있습니다.

RLP에 필드명이나 데이터 타입이 들어가나요?

아니요. 바이트 문자열과 리스트를 구분하고 경계를 보존할 뿐입니다. 별도의 이더리움 사양이 필드 순서, 정수 해석, 주소 길이 같은 의미를 정의해요.

모든 이더리움 트랜잭션이 단순 RLP 리스트인가요?

아니요. 레거시 트랜잭션은 RLP 리스트입니다. EIP-2718 타입 트랜잭션은 타입 바이트와 타입별 불투명 페이로드로 구성돼요. 현재 배포된 여러 타입은 페이로드에 RLP를 정의하지만, 봉투는 모든 미래 타입이 RLP를 쓰도록 강제하지 않습니다.

이더리움 합의 레이어도 RLP를 사용하나요?

현대 합의 레이어는 타입이 있는 합의 객체에 주로 SSZ를 사용합니다. RLP는 주로 실행 레이어 구조와 네트워킹 일부에 남아 있어요. 항상 정확한 프로토콜 경계를 확인하세요.

주요 출처

출처 확인일: 2026년 9월 1일

• Ethereum.org: 재귀 길이 접두부 직렬화
• 이더리움 옐로 페이퍼 부록 B: Recursive Length Prefix
• EIP-2718: Typed Transaction Envelope
• Ethereum.org: 트랜잭션과 타입 봉투
• Ethereum.org: Merkle Patricia Trie

RLP는 의도적으로 단순합니다. 표준 바이트 문자열, 표준 리스트, 둘을 나눌 만큼의 길이 정보만 제공해요. 그 의미는 주변 이더리움 사양이 채웁니다. 이 글은 교육 목적이며 투자 조언이 아닙니다(NFA).