EIP-8077 트랜잭션 알림에 발신자와 논스 추가 (eth/XX - announce transactions with nonce)

Hegota 포함 검토 (CFI) · 네트워크·노드 · 원문 상태 Draft · 2025-11-07 작성

노드끼리 새 트랜잭션을 알리는 메시지에 보낸 계정의 주소와 논스를 함께 담습니다. 받는 노드가 어떤 트랜잭션을 먼저 가져올지 더 똑똑하게 고를 수 있게 하는 멤풀 통신 개선입니다.

왜 필요한가

이더리움 노드는 아직 블록에 들어가지 않은 트랜잭션을 멤풀(mempool)이라는 대기 공간에 두고 서로 주고받습니다. 작은 트랜잭션은 몇몇 이웃 노드에 본문을 바로 밀어 넣지만 나머지 노드와 큰 트랜잭션, 블롭을 싣는 타입 3 트랜잭션은 '이런 트랜잭션이 있다'는 알림만 받습니다. 지금 이 알림에는 해시, 종류, 크기만 들어 있습니다. 받는 노드는 알림이 온 순서 말고는 판단할 근거가 없어서 여러 이웃에게 나눠 요청하다 보면 같은 계정의 논스(nonce, 계정별 순번)에 빈칸이 생겨 블록에 넣을 수 없는 트랜잭션을 받아 오기 쉽습니다. 빈칸을 메우려 해도 누구의 몇 번 트랜잭션이 빠졌는지 모르니 해시를 하나씩 더 요청해 보는 수밖에 없습니다. 이미 체인에 들어간 오래된 알림을 거르려면 체인 위 모든 트랜잭션 해시를 캐시로 들고 있어야 합니다. 특정 발신자의 트랜잭션만 골라 요청할 방법도 없습니다. 블록 처리량이 커질수록 노드가 모든 트랜잭션을 다 가져오지 못하는 상황이 늘어나므로, 골라서 가져오고 빈칸을 메울 수 있는 정보가 필요합니다.

무엇이 바뀌나

지금

EIP-8077 이후

누구에게 영향이 있나

심층 설명

NewPooledTransactionHashes 메시지 형식

devp2p eth 프로토콜의 NewPooledTransactionHashes(0x08) 메시지를 다음 버전(eth/XX)에서 확장합니다. eth/69 형식은 [txtypes: B, [txsize₁: P, txsize₂: P, ...], [txhash₁: B_32, txhash₂: B_32, ...]]로 종류, 크기, 해시 세 목록을 담습니다. eth/XX 형식은 여기에 [txsource₁: B_20, txsource₂: B_20, ...]와 [txnonce₁: P, txnonce₂: P, ...] 두 목록을 덧붙입니다. txsource는 20바이트 주소이고 txnonce는 가변 길이 정수입니다. 아래 첨자가 보여 주듯 각 목록은 같은 트랜잭션 순서로 나열됩니다. 메시지 번호와 기존 필드는 그대로 두고 뒤에 두 목록만 더하는 변경입니다.

txsource와 txnonce가 가리키는 값

txsource는 그 트랜잭션이 논스를 소비하는 계정이고 txnonce는 소비하는 논스 값입니다. 타입 0x00부터 0x04까지의 트랜잭션은 서명에서 복원한 주소가 txsource, 트랜잭션의 nonce 필드가 txnonce입니다. EIP-8141 프레임 트랜잭션은 서명 복원이 아니라 트랜잭션에 명시된 sender 필드를 txsource로, nonce 필드를 txnonce로 씁니다. EIP-8250이 적용되면 nonce 필드가 nonce_keys와 nonce_seq로 바뀌는데, 이때 txnonce는 nonce_seq입니다. 프레임 트랜잭션의 sender는 서명에서 복원한 값이 아니고 signatures 목록의 어떤 항목 주소와도 같지 않을 수 있으며 컨트랙트 계정일 수도 있습니다.

보내는 쪽과 받는 쪽의 처리

보내는 쪽 변경은 단순합니다. 전송하는 데이터만 바뀝니다. 다만 알림 크기가 커지므로 구현은 본문을 바로 밀어 넣는 즉시 전달(eager push)과 알림 중 무엇을 쓸지 가르는 조건(보통 트랜잭션 크기)을 다시 검토할 수 있습니다(MAY). 받는 쪽은 추가 정보를 요청 스케줄링 개선에 쓸 수 있지만 프로토콜이 특정 방식을 강제하지 않고 구현에 맡깁니다. Rationale은 해시, 크기, 종류만으로는 부족하고 발신자와 논스를 더하면 받는 쪽이 더 나은 가져오기 결정을 할 수 있다고 설명합니다.

프레임 트랜잭션의 논스는 계정 논스로 다루면 안 됩니다

알린 논스가 항상 계정 논스는 아닙니다. EIP-8250이 적용된 곳에서 프레임 트랜잭션은 발신자의 계정 논스 대신 키 지정 논스 시퀀스를 소비할 수 있고 이때 txnonce는 그 시퀀스 값이라 state[txsource].nonce와 무관합니다. 유효한 트랜잭션이 그보다 훨씬 낮거나 높은 값을 알릴 수 있고 둘 중 어느 쪽을 쓰는지는 알림만으로 알 수 없습니다. 따라서 받는 쪽은 프레임 트랜잭션의 txnonce를 state[txsource].nonce와 비교해 오래된 알림으로 버리거나 논스 빈칸을 추정해서는 안 되고(MUST NOT), <txsource, txnonce>를 프레임 트랜잭션의 식별자로 써서도 안 됩니다(MUST NOT). EIP-8250에서 대기 트랜잭션의 식별자는 <sender, nonce_keys, nonce_seq>입니다. 알림에 담긴 타입으로 계정 논스 검사가 유효한 트랜잭션과 구분합니다.

계정 추상화 트랜잭션에서 알림이 하는 역할

EIP-8141은 sender를 서명에서 복원하는 값이 아니라 명시적 필드로 두므로, 받는 쪽은 본문을 가져오기 전에는 발신자를 알 방법이 없습니다. 그 공개 멤풀은 발신자당 대기 프레임 트랜잭션을 최대 하나만 받고 그 논스가 발신자의 현재 논스와 같아야 하며 대기 트랜잭션을 <sender, nonce>로 식별합니다. 그래서 이 트랜잭션에는 메울 논스 빈칸이 없고 알림은 대신 그 발신자의 후보를 이미 갖고 있는지를 알려 줍니다. 프레임 트랜잭션 검증은 validation prefix를 시뮬레이션해야 하므로 가져왔다가 거부하면 대역폭만이 아니라 실행 비용까지 드는 만큼 이 답의 가치가 큽니다. EIP-8250은 논스를 <nonce_keys, nonce_seq>로 바꾸는데 알림에는 nonce_seq만 싣습니다. 키 집합은 최대 16워드이고 32바이트 정규 해시로 줄여도 모든 타입의 모든 알림이 그 비용을 치르기 때문입니다. 공개 멤풀이 여전히 발신자당 하나만 받으므로 스케줄링 결정은 발신자 주소가 담당하고 논스는 힌트로 남깁니다.

오버헤드와 검토한 대안

기존 B_32 해시, 크기, 타입에 B_20 주소와 가변 길이 논스를 더하므로 알림 크기가 눈에 띄게 늘어납니다. 원문은 그만한 효율 이득이 있다고 보지만 세부 수치는 TBD로 남겨 두었습니다. 대안도 검토했습니다. 작은 트랜잭션은 주로 즉시 전달로 퍼지니 알림 확장에서 빼는 안과 블롭 트랜잭션에만 적용하는 안은 논스 빈칸 메우기가 여전히 시행착오로 남아 택하지 않았습니다. 알림을 보낼 이웃 수는 프로토콜이 정하지 않으며 대역폭이 빠듯하면 더 적은 이웃에게 더 많은 메타데이터를 보내는 편이 낫다고 봅니다. 한 트랜잭션의 알림이 평균 이웃 절반에게서 중복해 오므로 단순 알림과 상세 알림을 확률적으로 섞는 안도 있지만 이득이 복잡도에 비해 작다고 봅니다. 해시 대신 발신자, 논스, RBF(replace-by-fee) 버전으로 트랜잭션을 식별하는 안은 버전에 서명이 필요해 더 깊은 변경이 됩니다. 대신 이미 서명된 수수료 값을 알림에 실으면 RBF 버전 대용으로 새 버전을 고를 수 있고 정렬 결과를 미리 내다봐 어차피 버릴 트랜잭션을 가져오지 않아 트래픽을 더 줄일 수 있습니다.

호환성과 보안

eth 프로토콜의 새 버전을 배포해야 하지만 여러 버전을 함께 지원하는 것은 통상적인 관행이라 옛 클라이언트는 이전 버전을 계속 쓰면 됩니다. EVM 합의 규칙은 바뀌지 않고 하드포크도 필요 없습니다. 보안 면에서 알림 속 주소와 논스는 본문을 가져오거나 즉시 전달로 받기 전까지 검증할 수 없으므로 믿을 수 있는 정보로 다루면 안 됩니다. 공격자는 발신자 주소를 마음대로 적은 알림을 비용 없이 보낼 수 있고 알림마다 state[txsource].nonce를 조회하는 노드는 공격자가 고른 주소에 대해 알림 하나당 상태를 한 번 읽게 됩니다. 이는 EIP-8141이 설명한 발신자 상태 읽기 증폭의 알림 수준 형태이며 알림 메타데이터로 상태에 접근하기 전에 피어 제한이나 속도 제한 같은 값싼 검사를 먼저 두어야 한다는 근거가 됩니다. 알림의 <txhash, type, size, address, nonce> 튜플과 실제 받은 트랜잭션이 다르면 프로토콜 위반으로 다룹니다. 해시를 확인하고 나면 알린 노드가 악의적이거나 내용을 검증하지 않고 알렸다는 것이 드러나기 때문입니다.

상태와 포크 논의

이 EIP는 Draft 상태라 형식과 세부가 아직 바뀔 수 있습니다. 특히 오버헤드 수치는 원문에 TBD로 남아 있습니다. 코어 개발자 콜에서는 08.13 ACDE #243에서 헤고타(Hegota) 후보(PFI)로 접수됐습니다. 트랜잭션 해시 알림에 발신자와 논스를 붙여 멤풀이 더 똑똑하게 고르게 하자는 제안으로 소개됐습니다. 10.08 ACDE #247에서는 프레임 트랜잭션과 수수료 필드까지 포함한 심층 분석을 조건으로 검토 대상(CFI)으로 올렸습니다. 가스 한도가 오를 때 멤풀이 버티게 하는 통신 개선이라는 평가입니다.

EIP 원문 · ← EIPs