EIP-7708 ETH 전송 로그: 이더리움 인덱서가 알아야 할 것

토큰 전송은 보통 로그를 조회하면 찾을 수 있어요. 하지만 모든 네이티브 ETH 이동은 그렇지 않습니다. 최상위 송금은 트랜잭션에서 보이지만 컨트랙트 호출 안쪽에서 이동한 ETH는 지금까지 트레이스(Trace) 같은 별도 수단이 필요했어요. EIP-7708 ETH 전송 로그는 네이티브 가치 이동을 트랜잭션 영수증(Transaction Receipt)에 기록해 이 빈틈을 메우려는 제안입니다. 먼저 블록체인 기초와 연결해 원리를 살펴보고, 인덱서가 무엇을 가정해도 되는지 구분해 볼게요.

2026년 9월 8일 기준 EIP-7708은 글램스테르담(Glamsterdam) 업그레이드에 포함 예정입니다. 다만 EIP 자체는 Review 상태이고 하드포크 메타 EIP에도 메인넷 활성화 시점이 적혀 있지 않아요. 현재 메인넷에서 이미 쓸 수 있는 기능으로 다루면 안 됩니다.

EIP-7708은 어떤 문제를 해결하나요?

이더리움을 두 가지 전표 체계를 쓰는 물류창고라고 생각해 보세요. ERC-20 토큰 상자는 컨트랙트가 Transfer 이벤트를 내보내므로 표준 배송 전표가 붙습니다. 네이티브 ETH는 창구의 일반 트랜잭션으로도, 창고 안쪽의 컨트랙트 간 호출로도 이동할 수 있지만 내부 이동에는 같은 검색용 전표가 자동으로 붙지 않았어요.

그래서 지갑, 거래소, 브릿지, 회계 시스템은 여러 도구를 조합합니다. 최상위 트랜잭션을 읽고, 내부 호출은 실행 트레이스를 조회하거나, 이미 전송을 재구성한 인덱싱 제공자에게 의존하죠. 트레이스 인터페이스는 클라이언트와 제공자마다 다를 수 있고 영수증만 읽는 파이프라인은 현재 모든 내부 ETH 이동을 볼 수 없습니다.

EIP-7708은 이 기록을 이더리움 실행 규칙에 넣습니다. 조건을 충족하는 네이티브 ETH 이동이 발생하면 프로토콜이 트랜잭션 영수증에 로그를 만들어요. 오프체인 소프트웨어는 ETH만 별도의 트레이스 전용 자산처럼 다루지 않고 익숙한 영수증과 eth_getLogs 흐름을 활용할 수 있습니다.

ETH 전송 로그는 어떻게 구성되나요?

제안된 로그는 ERC-20의 Transfer(address,address,uint256) 이벤트와 의도적으로 같은 형태를 사용해요.

발생 주소: 0xfffffffffffffffffffffffffffffffffffffffe
topics[0]: keccak256("Transfer(address,address,uint256)")
topics[1]: 32바이트로 왼쪽 패딩한 발신 주소
topics[2]: 32바이트로 왼쪽 패딩한 수신 주소
data:      wei 단위 금액을 big-endian uint256으로 표현

로그 발생 주소(Emitter)는 발신자, 수신자, 토큰 컨트랙트가 아니라 이더리움의 예약된 SYSTEM_ADDRESS입니다. 이 필드가 가장 중요한 구분자예요. 익숙한 Transfer 시그니처만 필터링하면 활성화 이후 네이티브 ETH 로그와 ERC-20 로그가 섞입니다. EIP-7708 기록이 필요하다면 시스템 주소와 시그니처를 함께 조건으로 사용하세요.

이 로그는 LOG3와 같은 형태로 설명됩니다. 시그니처 토픽 하나, 인덱싱된 주소 토픽 두 개, 데이터 필드의 금액으로 구성돼요. 영수증 안에 있으므로 블록 정보, 트랜잭션 해시, 트랜잭션 인덱스, 로그 인덱스로 실행 순서를 찾을 수 있습니다. 계층이 헷갈린다면 이더리움 트랜잭션 영수증 가이드를 함께 보세요.

어떤 이동에 로그가 생기나요?

현재 명세에서는 다음 경로로 0보다 큰 가치가 다른 계정으로 이동할 때 로그를 만듭니다.

• 최상위 트랜잭션
• 가치가 이동하는 CALL
• ETH를 담은 CREATE 또는 CREATE2
• 다른 수익자에게 가치가 이동하는 SELFDESTRUCT

로그 발생 시점은 실행 순서를 따라요. 최상위 전송 로그는 EVM 실행이 만든 다른 로그보다 먼저 오고, 중첩 호출의 로그는 실제 전송이 실행될 때 나타납니다. 로그를 만든 실행이 나중에 되돌려지면(Revert) 상태 변경과 로그도 함께 취소됩니다.

의도적으로 기록하지 않는 것은 무엇인가요?

“모든 ETH 전송이 로그를 만든다”는 훌륭한 요약이지만 운영 소프트웨어에는 제외 항목이 더 중요해요.

정산할 때 이 경계를 놓치면 안 됩니다. “EIP-7708 로그가 없다”를 “ETH 잔액에 영향을 준 활동이 없다”로 해석하면 수수료와 출금을 놓쳐요. 이 제안은 트랜잭션에 연결된 가치 이동을 표준화하지, 모든 프로토콜 잔액 변화를 담는 범용 장부를 만들지는 않습니다.

지갑·거래소·브릿지에 왜 중요한가요?

네이티브 ETH와 토큰에 비슷한 조회 모델을 써요

ERC-20은 성공한 토큰 전송에 Transfer 이벤트를 요구합니다. EIP-7708은 네이티브 ETH에 같은 이벤트 형태를 재사용하되 시스템 발생 주소로 구분해요. 인덱서는 ETH를 ERC-20 컨트랙트라고 오해하지 않으면서 디코딩과 필터링 기반을 공유할 수 있습니다.

스마트 컨트랙트 지갑의 입금을 더 쉽게 찾아요

스마트 컨트랙트 지갑은 중첩 실행 중 ETH를 받을 수 있습니다. 현재는 이런 지급을 찾기 위해 트레이스를 살펴보는 경우가 많아요. 영수증 로그는 일반 로그 API가 제공할 수 있는 합의 규칙 기반 기록을 만들어 제공자별 트레이스 동작에 대한 의존을 줄입니다.

영수증 기반 회계와 증명이 단순해져요

영수증과 로그는 이더리움 블록 구조를 통해 커밋됩니다. 표준 로그는 별도 트레이싱 서비스가 만든 해석보다 결정론적 백필(Backfill)과 영수증 기반 증명에 쓰기 쉬워요. 그렇다고 최신 블록이 최종 확정되거나 수신 주소가 신뢰할 만해지는 것은 아닙니다.

안전한 인덱서 전환 순서

1. 체인과 활성화 블록으로 기능을 나눠요

모든 EVM 네트워크가 같은 시점에 EIP-7708을 도입하거나 반드시 도입한다고 가정하지 마세요. 체인 ID와 해당 네트워크의 확정된 포크 경계를 기록해야 합니다. 활성화 전 영수증에는 애초에 존재하지 않았던 로그를 소급해 만들 수 없어요.

2. 발생 주소와 시그니처를 함께 비교해요

정확한 시스템 주소와 Transfer(address,address,uint256) 토픽을 함께 사용하세요. 토큰 전송 처리는 각 토큰 컨트랙트 주소로 한정합니다. 그래야 이중 집계를 막고 익숙한 이벤트를 내보낸 임의의 컨트랙트를 네이티브 ETH로 오인하지 않아요.

3. 순서와 멱등성을 보존해요

블록 해시, 트랜잭션 해시, 로그 인덱스를 이벤트 식별 정보로 저장합니다. 트랜잭션 하나에 여러 전송이 있을 수 있고 체인 재구성(Reorg)이 블록을 교체할 수 있어요. 신뢰할 수 있는 소비자는 재시도를 중복 제거하고 정식 체인에서 빠진 블록의 파생 데이터를 되돌려야 합니다.

4. 도입 초기에는 트레이스와 대조해요

활성화 뒤 일정 기간은 EIP-7708 로그와 기존 트랜잭션·트레이스 파이프라인을 비교하세요. 차이가 보이면 임의의 예외 규칙을 붙이지 말고 명세의 제외 항목으로 분류해야 합니다. 이더리움 실행 명세 테스트는 일반 전송, 호출, 컨트랙트 생성, 되돌림, 자기 전송, 0 가치, 포크 전환 동작을 다룹니다.

5. 탐지와 입금 확정을 분리해요

로그는 실행 과정에서 가치 이동이 기록됐다는 뜻입니다. 블록이 필요한 확신 수준에 도달했거나 수신 주소가 주장한 사용자의 것이라는 뜻은 아니에요. 중요한 지급이나 출고 전에는 컨펌 또는 최종성 정책을 적용하고 잔액과 다시 대조하세요.

리스크와 한계

• 아직 활성화되지 않음: 포함 예정과 메인넷 활성화는 다릅니다. 포크 전에는 EIP 문구, 클라이언트 동작, 일정이 바뀔 수 있어요.
• 영수증 데이터 증가: 평균 로그 수는 늘어납니다. 다만 보안 분석은 ETH 전송의 기존 가스 비용이 로그 발생 비용보다 커서 최악 조건의 로그 수를 늘리지는 않는다고 설명해요.
• 잘못된 분류: 시그니처는 ERC-20 Transfer와 같습니다. 발생 주소를 무시하면 자산 종류가 섞이거나 이중 집계할 수 있어요.
• 불완전한 회계: 수수료, 기본 수수료 소각, 합의 레이어 출금은 이 로그 흐름 밖에 남습니다.
• 체인 재구성: 최근 블록의 로그는 정식 체인이 바뀌면 사라질 수 있어요. ‘관찰됨’은 ‘최종 확정됨’이 아닙니다.
• 애플리케이션 위험: 데이터가 깔끔해져도 스마트 컨트랙트 버그, 운영 실수, 자산 변동성이 사라지지는 않습니다.

자주 묻는 질문

EIP-7708은 이더리움 메인넷에서 활성화됐나요?

2026년 9월 8일 기준 아니요. 현재 글램스테르담 범위에는 포함 예정이지만 제안과 하드포크 메타 EIP는 Review 상태이며, 메타 EIP에는 메인넷 활성화 시점이 없습니다.

ETH가 ERC-20 토큰으로 바뀌나요?

아니요. ETH는 이더리움의 네이티브 자산으로 남습니다. 프로토콜이 만든 로그만 ERC-20 이벤트 형태를 빌려 기존 인덱싱 패턴을 재사용해요.

활성화 후 eth_getLogs로 네이티브 ETH 전송을 찾을 수 있나요?

그것이 실무적인 목표입니다. 시스템 발생 주소와 전송 시그니처로 로그를 조회하고 일반적인 블록 범위·최종성 처리를 적용하세요. 제공자의 조회 제한은 운영 정책이지 합의 규칙은 아닙니다.

과거 내부 ETH 전송에도 로그가 생기나요?

아니요. 프로토콜 로그는 각 네트워크의 활성화 경계부터 생깁니다. 그 이전 기록은 계속 트랜잭션, 트레이스 또는 기존 인덱스를 이용해 재구성해야 해요.

모든 ETH 잔액 변화가 전송 로그를 만드나요?

아니요. 현재 명세는 수수료 지급, 기본 수수료 소각, 합의 레이어 출금 등을 제외합니다. 이런 흐름에는 알맞은 블록과 영수증 필드를 사용하세요.

1차 출처

• EIP-7708: ETH transfers emit a log
• EIP-7773: 글램스테르담 하드포크 메타
• Ethereum.org: 글램스테르담 로드맵
• Ethereum Execution Specs: EIP-7708 전송 로그 테스트
• ERC-20 토큰 표준
• Ethereum.org: JSON-RPC API

실무 핵심 정리

EIP-7708은 트랜잭션 안에서 일어난 네이티브 ETH 이동을 구조화된 영수증 증거로 바꿉니다. 인덱서에는 새로운 자산 종류보다 일관된 조회 경로가 핵심이에요. 시스템 발생 주소, 익숙한 전송 시그니처, 발신자, 수신자, wei 금액을 같은 방식으로 읽을 수 있습니다. 그래도 안전한 전환에는 활성화 경계, 발생 주소 기반 디코딩, 재구성 처리, 트레이스 대조, 제외된 잔액 변화의 명시적 처리가 필요해요.

이 글은 교육 목적이며 투자 조언이 아닙니다. 프로토콜 명세는 활성화 전에 바뀔 수 있고 크립토 애플리케이션과 자산에는 기술·시장 리스크가 있어요. 최신 1차 문서를 직접 확인하고 운영 반영 전 테스트하며 스스로 조사하세요(DYOR).