EIP-778 이더리움 노드 레코드(ENR) (Ethereum Node Records (ENR))
최종 확정 · 네트워크·노드 · 원문 상태 Final · 2017-11-23 작성
노드의 접속 정보를 서명된 키/값 쌍으로 담는 개방형 형식인 노드 레코드(Ethereum Node Records, ENR)를 정의합니다. 시퀀스 번호로 어느 정보가 최신인지 가리고, 새 정보도 자유롭게 추가할 수 있습니다.
왜 필요한가
이더리움 노드는 노드 디스커버리(node discovery) 프로토콜로 서로를 찾습니다. 그런데 기존 디스커버리 v4는 노드의 공개키(secp256k1 곡선), IP 주소, 포트 번호 두 개만 전달할 수 있고 그 밖의 정보는 실어 보낼 수 없습니다. 새 전송 프로토콜이나 그와 연결된 공개키 자료를 알릴 방법이 없는 것입니다. 또 노드가 접속 지점을 바꾸고 새 정보를 올려도, 다른 노드가 어느 쪽이 더 새 정보인지 판별할 기준이 없습니다. 이 EIP는 연결 관련 정보를 자유로운 키/값 쌍으로 담는 노드 레코드 형식을 정의해 이 제약을 풉니다. 레코드는 미래 버전의 디스커버리 프로토콜뿐 아니라 DNS, ENS, devp2p 서브프로토콜 같은 다른 경로로도 전달할 수 있습니다. 레코드에는 서명과 시퀀스 번호가 있어 노드가 접속 지점을 바꿔 새 레코드를 올리면 다른 노드가 어느 레코드가 더 새것인지 알 수 있습니다.
무엇이 바뀌나
지금
- 디스커버리 v4는 공개키, IP 주소, 포트 두 개만 전달하고 다른 정보는 실을 수 없습니다
- 새 전송 프로토콜이나 그에 딸린 공개키 자료를 알릴 방법이 없습니다
- 노드가 접속 지점을 바꾸면 어느 정보가 최신인지 가릴 기준이 없습니다
EIP-778 이후
- 서명된 키/값 쌍 형식인 노드 레코드에 임의의 연결 정보를 담습니다
- 새 키/값 쌍은 구현 합의 없이 추가할 수 있고, 새 신원 스킴은 EIP로 추가합니다
- 시퀀스 번호를 비교해 더 새로운 레코드를 판별합니다
누구에게 영향이 있나
- 클라이언트 팀: 레코드의 서명 생성과 검증, 300바이트 크기 제한, enr: 텍스트 인코딩을 구현해야 합니다.
- 노드 운영자: 자기 노드의 접속 정보를 enr:로 시작하는 한 줄 텍스트로 공유할 수 있습니다.
- 프로토콜 설계자: 새 전송 프로토콜 정보나 새 암호 체계(신원 스킴)를 레코드에 실어 네트워크에 퍼뜨릴 수 있습니다.
심층 설명
레코드의 세 가지 구성 요소
노드 레코드는 signature(레코드 내용에 대한 암호학적 서명), seq(64비트 부호 없는 정수인 시퀀스 번호), 그리고 나머지 임의의 키/값 쌍으로 이뤄집니다. 노드는 레코드가 바뀔 때마다 seq를 올리고 레코드를 다시 게시해야 합니다. 키/값 쌍은 키 기준으로 정렬돼야 하고 같은 키가 두 번 나올 수 없습니다. 키는 기술적으로 어떤 바이트 시퀀스도 가능하지만 ASCII 텍스트가 선호됩니다. 서명의 생성과 검증, 그리고 DHT에서 노드 주소를 유도하는 일은 신원 스킴(identity scheme)이 담당합니다.
사전 정의 키와 IPv4/IPv6 이중 선언
사전 정의된 키는 id(신원 스킴 이름, 예: "v4"), secp256k1(압축 공개키 33바이트), ip(IPv4 주소 4바이트), tcp·udp(빅 엔디언 정수 포트), ip6(IPv6 주소 16바이트), tcp6·udp6(IPv6 전용 포트)입니다. id를 뺀 모든 키는 선택 사항이라, IP와 포트가 없어도 서명만 유효하면 레코드는 유효합니다. tcp6/udp6 포트가 없으면 tcp/udp 포트가 두 주소 모두에 적용됩니다. 같은 포트를 tcp와 tcp6, udp와 udp6에 중복 선언하는 일은 피해야 하지만 레코드가 무효가 되지는 않습니다. IP 관련 키가 많은 이유는 가정·모바일 환경에서 IPv4는 NAT 뒤에 있고 IPv6는 같은 호스트로 직접 라우팅되는 경우가 많아서입니다. 두 주소를 모두 선언하면 IPv4만 되는 곳과 둘 다 되는 곳 어디서든 접근할 수 있습니다.
RLP 인코딩과 300바이트 제한
레코드의 표준 인코딩은 [signature, seq, k, v, ...] 형태의 RLP 리스트입니다. 서명은 content = [seq, k, v, ...]에 대해 만들고(signature = sign(content)), 최종 레코드는 record = [signature, seq, k, v, ...]입니다. 인코딩된 레코드의 최대 크기는 300바이트이고 구현은 이보다 큰 레코드를 거부해야 합니다. 크기를 제한한 이유는 레코드가 자주 중계되고 DNS처럼 크기 제약이 있는 프로토콜에 담길 수 있어서입니다. IPv4 주소를 담고 v4 스킴으로 서명한 레코드는 대략 120바이트를 차지해 추가 메타데이터를 넣을 여유가 충분합니다.
텍스트 인코딩: enr: 접두사
레코드의 텍스트 형태는 RLP 표현을 base64로 인코딩하고 앞에 enr:을 붙인 것입니다. 구현은 URL-safe base64 알파벳을 쓰고 패딩 문자를 생략해야 합니다. 원문의 테스트 벡터는 IPv4 주소 127.0.0.1과 UDP 포트 30303을 담은 레코드로, 시퀀스 번호 1과 명시된 개인키로 v4 스킴 서명을 했을 때의 enr: 문자열과 RLP 구조를 보여 줍니다.
기본 신원 스킴 "v4"
다른 스킴이 별도 EIP로 정의되기 전까지 기본으로 쓰는 스킴입니다. 디스커버리 v4가 쓰는 암호 체계와 하위 호환됩니다. 서명할 때는 content에 keccak256 해시 함수(EVM에서 쓰는 것과 같은 함수)를 적용한 뒤 그 해시에 서명합니다. 결과인 64바이트 서명은 r과 s 값을 이어 붙여 인코딩하고 복구 ID v는 생략합니다. 검증할 때는 레코드의 "secp256k1" 키/값 쌍에 담긴 공개키로 서명이 만들어졌는지 확인합니다. 노드 주소는 비압축 공개키의 keccak256 해시로 유도합니다.
두 갈래 확장 경로
형식은 두 방식으로 미래 수요에 대응하도록 설계됐습니다. 첫째, 새 키/값 쌍 추가는 언제나 가능하고 구현 합의가 필요 없습니다. 기존 클라이언트는 내용을 해석할 수 있든 없든 어떤 키/값 쌍이든 받아들입니다. 둘째, 새 신원 스킴 추가는 구현 합의가 필요합니다. 네트워크가 서명을 받아들이지 않으면 쓸 수 없기 때문입니다. 새 스킴을 도입하려면 EIP를 제안하고 구현시켜야 하며 대부분의 클라이언트가 받아들이는 시점부터 쓸 수 있습니다. 이 EIP 자체는 상태가 Final로 확정된 표준입니다.