EIP-7642 eth/69: 히스토리 만료와 간단한 영수증 (eth/69 - history expiry and simpler receipts)

최종 확정 · 네트워크·노드 · 원문 상태 Final · 2024-02-29 작성

노드끼리 블록을 주고받는 통신 규약(eth 프로토콜)을 eth/69로 올립니다. 각 노드가 보관 중인 블록 범위를 서로 알리게 하고 영수증에서 불필요한 블룸 필터를 빼서 동기화 데이터량을 크게 줄입니다.

왜 필요한가

이더리움 노드들은 'eth'라는 통신 규약으로 블록과 거래 데이터를 주고받습니다. 히스토리 만료 워킹그룹은 2025년 5월 1일 이후 클라이언트가 합병(머지) 이전의 오래된 블록 기록을 지워도 된다고 결정했습니다. 그런데 기존 규약에는 상대 노드가 옛 기록을 아직 갖고 있는지 물어볼 방법이 없어서 과거 데이터를 받으려는 노드는 일단 요청해 보고 실패하면 없다고 짐작할 수밖에 없습니다. 또 영수증(receipt, 거래 처리 결과 기록)에 들어가는 블룸 필터(Bloom filter, 로그 검색용 요약 데이터)는 어느 클라이언트도 저장하지 않고 필요할 때 다시 계산하는데, 규약상 전송은 의무였습니다. 그래서 새로 동기화하는 노드 하나마다 서버 노드가 약 530GB 분량의 블룸 필터를 다시 만들어 보내고, 받은 쪽은 검증만 하고 버리는 낭비가 반복됐습니다. 마지막으로 합병 이후 의미가 없어진 총난이도(TD) 값이 여전히 인사(핸드셰이크) 메시지에 남아 있었습니다.

무엇이 바뀌나

지금

EIP-7642 이후

누구에게 영향이 있나

심층 설명

Status (0x00) 메시지 변경

eth/68의 Status는 [version, networkid, td, blockhash, genesis, forkid]였습니다. eth/69에서는 [version, networkid, genesis, forkid, earliestBlock, latestBlock, latestBlockHash]로 바뀝니다. td가 빠지고 보관 블록 범위 세 필드가 추가되며 blockhash는 BlockRangeUpdate와 형식을 맞추기 위해 뒤로 이동해 latestBlockHash가 됩니다. td는 합병 이후 블록의 난이도가 0이라 의미를 잃었고 동기화 여부 구분은 forkid로 가능하다는 것이 제거 근거입니다.

Receipts (0x10) 인코딩 변경

eth/68에서는 legacy-receipt와 typed-receipt를 구분했고 typed-receipt는 tx-type || rlp(legacy-receipt) 형태로 감쌌으며 내부에 bloom: B_256 필드가 있었습니다. eth/69에서는 receipt = [tx-type, post-state-or-status, cumulative-gas, logs]라는 평탄한 리스트 하나로 통일합니다. 합의 계층에서는 타입 거래 영수증이 바이트 배열로 감싸진 불투명(opaque) 인코딩을 쓰지만, 모든 영수증 타입이 결국 같은 네 필드를 담으므로 네트워크 계층에서 그 비싼 인코딩을 따라 할 이유가 없다는 판단입니다.

블룸 필터 제거의 효과

어떤 클라이언트도 영수증의 Bloom 필드를 저장하지 않고 필요할 때 재계산하는데, 기존 규약은 전송을 요구했습니다. 그래서 서빙 노드는 약 23억 건의 거래에 각 256바이트, 합계 약 530GB의 블룸 필터를 재생성해 보내고 받는 노드는 검증 후 버렸습니다. 제거하면 동기화 노드당 약 530GiB, snappy 압축 기준 최소 95GiB의 대역폭과 서빙 노드의 CPU 부하를 아낍니다. 대신 받는 노드가 영수증 해시를 완전히 검증하려면 블룸 필터를 재계산해야 하는데, 이 계산은 CPU 부담이 크지 않습니다.

BlockRangeUpdate (0x11) 신설

[earliestBlock: P, latestBlock: P, latestBlockHash: B_32] 인코딩의 새 메시지입니다. 클라이언트가 제공 가능한 블록 범위가 바뀔 때마다 보내되, 트래픽을 줄이기 위해 블록마다 보낼 필요는 없고 에폭(32블록)당 최대 한 번만 보내야 합니다. 피어의 동기화 상태를 감지하고 데이터 요청 전략을 조정하는 데 쓰입니다.

earliestBlock을 넣은 이유

히스토리 만료 자체에 꼭 필요한 필드는 아니지만 세 가지 이점이 있습니다. 첫째, 합의된 합병 이전 기록 삭제가 시행된 뒤에도 p2p로 과거 기록을 받으려는 클라이언트의 피어 탐색이 좋아집니다. 이 필드가 없으면 요청을 보내 보고 실패하면 없다고 가정해야 합니다. 둘째, 전용 크롤러가 몇 개의 노드가 어떤 구현에서 히스토리를 켜 두었는지 조사할 수 있습니다. 셋째, 히스토리 만료 기간이 동적으로 바뀌는 미래에 대비합니다. 비슷한 아이디어가 EIP-7542로 제안됐지만 당시에는 히스토리 만료에 대한 정치적 결정이 없어 철회됐습니다.

하위 호환성과 상태

이 EIP는 와이어 프로토콜의 새 버전 eth/69를 도입합니다. 여러 버전을 동시에 지원할 수 있으므로 기존 클라이언트는 eth/68을 계속 쓰면 되고 즉시 깨지지 않습니다. EVM 합의 규칙은 바뀌지 않으며 하드포크도 필요 없습니다. 프로토콜 버전 협상은 EIP-5793(requires)을 전제로 합니다. 이 EIP의 상태는 Final로 확정됐습니다.

EIP 원문 · ← EIPs