이더리움 SSZ 완벽 정리: 직렬화·머클화·증명 원리

이더리움 합의 클라이언트는 어느 블록이 선택됐는지만 같게 판단하면 끝나지 않아요. 블록, 검증자 기록, 상태 필드를 나타내는 바이트와 루트 해시도 정확히 같아야 합니다. 인코딩 규칙 하나가 모호하면 정직한 클라이언트끼리 다른 결과를 계산할 수 있어요.

이 문제를 해결하는 규칙이 블록체인 기초의 핵심 요소인 **SSZ(Simple Serialize)**입니다. SSZ는 이더리움 합의 레이어(Consensus Layer)에 공통 타입 체계, 결정적인 바이트 인코딩, 구조화된 데이터를 머클 루트로 바꾸는 방법을 제공해요. 다만 이는 기술 인프라이지 투자 신호가 아니며, SSZ를 이해한다고 ETH 가격을 예측할 수 있는 것은 아닙니다.

이더리움 SSZ란 무엇인가요?

SSZ는 이더리움 합의 사양이 정의한 직렬화(Serialization) 및 머클화(Merkleization) 방식이에요. 직렬화는 타입이 정해진 객체를 표준 바이트열로 바꿉니다. 머클화는 같은 타입 데이터를 해시 트리로 배열해 hash_tree_root를 만들어요.

국제 배송 서류를 떠올려 보세요. 직렬화는 포장 봉투 안에서 각 항목이 놓일 자리를 정확히 정하는 규칙입니다. 머클화는 전체 화물의 마스터 봉인과 비교해 특정 항목만 검증하게 해 주는 위변조 방지 색인에 가까워요. 둘 다 같은 스키마에서 출발하지만 역할은 다릅니다.

Ethereum.org는 SSZ를 합의 레이어의 인코딩 방식으로 설명해요. 피어 검색 프로토콜을 제외한 합의 레이어에서 실행 레이어(Execution Layer)의 RLP(Recursive-Length Prefix)를 대신합니다. 이 경계가 중요해요. SSZ는 비콘 체인 데이터의 중심이지만, 현재 이더리움의 모든 거래와 실행 레이어 객체가 SSZ를 쓴다고 말하면 부정확합니다.

SSZ에 스키마가 필요한 이유

SSZ는 자기 설명적(Self-describing) 형식이 아니에요. 바이트열 자체에 필드 이름과 모든 타입 정보가 들어 있지 않습니다. 디코더는 해당 위치가 Uint64인지, 불리언(Boolean)인지, 고정 벡터인지, 가변 리스트인지, 컨테이너인지 미리 알아야 해요.

불편해 보이지만 합의 프로토콜에는 엄격함이 장점입니다. 모두가 같은 스키마를 쓰면 클라이언트는 잘못된 데이터를 거부하고, 유효한 바이트를 해당 타입의 객체 하나로만 해석할 수 있어요. 공식 사양은 직렬화가 단사 함수(Injective Function)라고 설명합니다. 같은 타입의 서로 다른 두 객체가 같은 바이트열로 직렬화되지 않는다는 뜻이에요.

주요 타입은 다음과 같습니다.

• 기본 타입(Basic Type): 부호 없는 정수, 불리언, 불투명 바이트
• 벡터(Vector): 길이가 타입에 포함되는 고정 길이 시퀀스
• 리스트(List): 길이가 달라질 수 있는 시퀀스
• 비트벡터·비트리스트: 불리언 시퀀스를 압축한 표현
• 컨테이너(Container): 서로 다른 타입의 필드를 정해진 순서로 묶은 구조

따라서 Vector[Byte, 32]와 List[Byte, 32]는 서로 바꿔 쓸 수 없어요. 앞의 타입은 정확히 32개 요소를 가지지만 뒤의 타입은 한도 안에서 더 짧을 수 있습니다. 타입 정보는 인코딩뿐 아니라 머클 트리 모양에도 영향을 줘요.

SSZ 직렬화는 어떻게 작동하나요?

고정 크기 기본값은 비교적 단순합니다. 부호 없는 정수는 리틀 엔디언(Little-endian) 순서로 인코딩하고, 불리언은 거짓이면 0x00, 참이면 0x01 한 바이트가 돼요.

고정 크기 복합값은 스키마 순서대로 인코딩한 필드를 배치할 수 있습니다. 가변 크기 필드에는 한 단계가 더 필요해요. SSZ는 고정 영역에 4바이트 오프셋(Offset)을 넣고, 뒤의 가변 영역에 실제 데이터를 붙입니다. 오프셋은 디코더에게 해당 필드가 시작되는 위치를 알려 줘요.

단순화한 컨테이너를 보겠습니다.

Record {
  slot: Uint64
  active: Boolean
  note: List[Byte, 64]
}
 
고정 영역: [slot 바이트][active 바이트][note 위치 오프셋]
가변 영역:                                  [note 바이트]

옷 보관소와 비슷해요. 고정 영역에는 바로 들어가는 물건과 번호표를 두고, 부피가 큰 물건은 별도 공간에 보관합니다. 번호표가 그 위치를 가리켜요. 디코더는 스키마를 통해 어떤 바이트가 일반 데이터가 아니라 번호표인지 구분합니다.

오프셋, 크기, 한도, 필드 순서는 모두 프로토콜 규칙이에요. 익스플로러 화면만 보고 직접 만든 디코더가 이를 추측해서는 안 됩니다. 클라이언트와 애플리케이션 개발자는 보통 관리되는 SSZ 라이브러리를 쓰고 공식 참조 테스트 벡터와 결과를 비교해요.

SSZ 머클화는 어떻게 작동하나요?

직렬화는 전송하거나 저장할 바이트를 만들고, 머클화는 타입 데이터에 대한 작은 커밋먼트(Commitment)를 만듭니다. SSZ는 값을 32바이트 청크(Chunk)로 묶고, 타입 규칙에 맞게 패딩한 뒤, 이진 트리에서 두 개씩 해시해 하나의 hash_tree_root에 도달해요.

리스트는 실제 길이에도 커밋합니다. 패딩된 청크가 우연히 같아 보이더라도 논리적으로 다른 두 리스트가 같은 루트를 갖지 않도록 하기 위해서예요. 컨테이너는 선언된 필드 순서대로 머클화하며, 중첩된 복합값의 루트도 포함합니다.

이 구조는 일부 값만 검증할 때 유용해요. 큰 상태 안에서 검증자 잔액 하나가 바뀌면 관련 경로의 해시만 다시 계산할 수 있습니다. 모든 관계없는 가지를 처음부터 해시할 필요가 없어요. 기본 원리는 머클 트리와 머클 증명 가이드에서 더 자세히 설명합니다.

SSZ 직렬화와 hash_tree_root를 같은 해시의 다른 표현으로 보면 안 돼요. 직렬화된 바이트열을 단순히 해시한다고 일반적으로 SSZ 루트가 나오지 않습니다. 타입을 반영하는 머클화 규칙을 적용해야 해요.

일반화 인덱스와 머클 증명

SSZ는 이진 머클 트리의 노드를 가리키기 위해 **일반화 인덱스(Generalized Index)**를 사용해요. 루트는 1, 왼쪽과 오른쪽 자식은 2와 3, 다음 줄은 4부터 7입니다. 인덱스를 이진수로 보면 루트에서 해당 노드까지의 경로도 표현돼요.

알려진 스키마 아래에서 필드나 하위 트리에 안정적인 주소가 생기는 셈입니다. 증명자는 대상 값과 필요한 이웃 해시를 제공하고, 검증자는 전체 객체 없이 예상 루트를 재구성할 수 있어요.

이 기능은 이더리움 라이트 클라이언트와 트러스트리스 RPC에서 특히 중요합니다. 가벼운 검증자는 합의 헤더를 인증한 뒤 지원되는 가지를 SSZ 루트와 대조할 수 있어요. 그래도 진짜 루트와 정확한 스키마가 필요합니다. 공격자가 제공한 루트에 연결되는 수학적으로 올바른 증명은 실질적으로 아무것도 보장하지 않아요.

SSZ와 RLP·ABI 인코딩의 차이

세 인코딩은 서로 다른 경계에서 쓰입니다.

지갑과 익스플로러가 컨트랙트 호출을 해석할 때 보는 것은 ABI로 인코딩된 콜데이터(Calldata)예요. 셀렉터와 인자 워드의 원리는 이더리움 콜데이터 가이드에서 확인할 수 있습니다. SSZ는 비콘 블록과 상태 같은 합의 구조를 나타낼 때 등장해요.

SSZ를 실행 레이어 구조로 넓히려는 제안도 있습니다. 제안이 존재한다는 사실만으로 배포가 완료된 것은 아니에요. 제안된 SSZ 거래 형식을 메인넷 기능이라고 설명하기 전에 현재 EIP 상태와 활성 네트워크 사양을 확인해야 합니다.

개발자는 어디서 SSZ를 만나나요?

다음과 같은 작업에서 SSZ를 접할 수 있어요.

1. 합의 클라이언트를 개발하거나 운영할 때
2. 비콘 API 객체를 합의 스키마와 비교할 때
3. 라이트 클라이언트를 구현하거나 합의 상태 증명을 검증할 때
4. 프로토콜 구현용 테스트 벡터를 만들 때
5. 브릿지나 증명 시스템이 이더리움 합의 데이터에 커밋하는 방식을 감사할 때

관련 포크(Fork)에 맞는 정확한 스키마를 사용하세요. 이더리움 합의 사양은 이름이 붙은 업그레이드를 거치며 발전하고, 이후 포크에서 구조에 필드가 추가되거나 새로운 타입이 채택될 수 있습니다. 모든 페이로드를 가장 최신 스키마로 조용히 디코딩하지 말고 프로토콜 버전에 따라 스키마를 선택해야 해요.

리스크·한계와 흔한 실수

• 잘못된 스키마: 겉보기에 유효한 바이트도 다른 타입이나 포크 스키마로 해석하면 거부되거나 잘못 읽힐 수 있어요.
• 바이트와 루트 혼동: 직렬화된 바이트를 해시하는 것으로 SSZ 머클화를 대신할 수 없습니다.
• 한도 무시: 리스트 한도와 벡터 길이는 유효성과 트리 모양에 영향을 줘요.
• 인증되지 않은 루트 신뢰: 머클 가지는 주어진 루트와의 관계만 증명합니다.
• 오래된 라이브러리 사용: 새 합의 포크와 SSZ 확장은 타입과 참조 테스트 업데이트가 필요할 수 있어요.
• 합의 증명과 최종성 혼동: 증명 유효성, 정식 체인 선택, 블록체인 최종성은 별도 확인 사항입니다.
• 배포 상태 과장: 초안 EIP나 실험 타입이 자동으로 이더리움 메인넷에서 활성화되는 것은 아니에요.

SSZ는 모호함을 줄이지만 구현 버그, 탈취된 엔드포인트, 브릿지 신뢰 가정, 스마트 컨트랙트 실패, 자산 변동성을 없애지는 못합니다. 프로토콜 버전과 소스 코드를 직접 검증하세요. 자금이 움직이는 기술 연동이라면 잃어도 감당할 수 있는 소액으로 먼저 시험하고 스스로 조사해야 합니다(DYOR).

FAQ

이더리움의 모든 거래가 SSZ를 사용하나요?

아니요. SSZ는 합의 레이어 데이터의 핵심 인코딩 및 머클화 방식입니다. 실행 레이어 거래와 컨트랙트 호출에는 여전히 RLP, ABI 같은 다른 형식이 관여해요. 마이그레이션 제안은 현재 사양 상태와 배포 여부를 따로 확인해야 합니다.

SSZ는 압축 형식인가요?

단순한 압축 형식이 아니에요. SSZ는 타입, 표준 직렬화, 타입을 반영한 머클화를 정의합니다. 결정적인 루트와 증명에 적합한 구조가 중요한 설계 목표예요.

타입을 몰라도 SSZ를 디코딩할 수 있나요?

신뢰성 있게 디코딩할 수 없습니다. SSZ는 자기 설명적 형식이 아니므로 필드 순서, 고정·가변 크기, 컬렉션 한도가 포함된 스키마가 필요해요.

SSZ 루트와 블록 해시는 무엇이 다른가요?

SSZ의 hash_tree_root는 특정 타입의 SSZ 객체에 커밋합니다. 프로토콜은 이 루트를 더 큰 인증 구조 안에 넣거나 다른 식별자를 만들 때 활용할 수 있어요. 반면 ‘블록 해시’는 다른 프로토콜별 식별자를 뜻할 수 있으므로 API가 어느 객체와 해시 규칙을 노출하는지 확인해야 합니다.

공식 자료

자료 확인일: 2026년 8월 22일

• Ethereum Consensus Specs: SimpleSerialize
• Ethereum.org: Simple Serialize
• Ethereum Proof-of-Stake Consensus Specifications
• EIP-2982: Serenity Phase 0 — SSZ 설계 근거

SSZ는 이더리움 합의 데이터를 객체에서 표준 바이트와 검증 가능한 루트로 바꾸는 하나의 타입 경로를 제공합니다. 정확한 스키마, 정확한 포크, 인증된 루트라는 세 조건을 항상 확인하세요. 이 글은 교육 목적이며 투자 조언이 아닙니다(NFA).