전파와 EIP-4844

오늘은 두 부로 나뉜다. A부는 tx 전파: 노드끼리 주고받는 네트워크 메시지를 본다. B부는 EIP-4844 구현: 스펙 문서 한 장이 geth의 어느 파일을 어떻게 바꿨는지 여섯 군데를 따라간다.

• 단계가 나뉘어 있는 이유: 아래 두 단계는 무슨 대화를 하든 상관없이 동작한다. 그래서 eth 말고 snap 같은 다른 프로토콜도 같은 연결 위에서 돈다.

• 부트노드란: 소스에 IP가 적혀 있는 시작점 노드다. 처음 켠 노드는 아는 주소가 0개라 여기서만 하드코딩으로 출발한다(params/bootnodes.go, 메인넷 4개).
• Target에는 보통 난수를 넣는다: 값을 바꿔가며 반복 요청해 네트워크의 여러 구역에서 주소를 모은다.
• 이 고리는 계속 돈다: 노드가 켜져 있는 동안 멈추지 않는다. 결과물은 IP 주소 목록이다.

• 왜 절반 넘게 남의 몫으로 비워두나: 전부 내가 걸면 방화벽 뒤에 있어 연결을 못 거는 노드가 네트워크에 참여할 수 없다.
• 연결하지 않은 나머지 200여 개를 계속 들고 있는 이유: ① 피어는 계속 끊기므로 빈자리를 메운다 ② 다른 노드가 나에게 Findnode를 보내면 내 목록에서 골라 응답한다 ③ 후보가 많아야 느리거나 응답 없는 노드를 걸러내고 쓸 수 있다.

• ForkID가 하는 일: 지금까지 적용한 하드포크의 요약과 다음 포크 블록 번호다. 지금은 같은 체인이어도 업그레이드가 밀린 노드는 포크 시점에 갈라지므로 미리 거른다.
• 다른 체인은: 그 앞의 NetworkID에서 이미 걸러진다.
• 이 검사를 통과한 상대만 피어가 된다: 아래부터는 이 피어들과 tx를 주고받는 이야기다.

피어 n개가 같은 tx를 나에게 알릴 때 오가는 바이트를 두 방식으로 세어 보면 이렇다.

• 실제 중복 횟수는 미리 알 수 없다: 피어마다 그 피어가 이미 아는 해시 장부를 최대 32,768개까지 들고 있어(knownTxs) 한 번 주고받은 tx는 다시 보내지 않는다. 다만 이 장부는 내가 보낼 때만 거른다. 상대가 나에게 보내는 것은 못 막으므로, 중복이 몇 번일지는 보내는 시점에 알 수 없다.

• 해시를 받은 42개도 결국 원문을 받는다: 그 tx를 모르면 나에게 요청해 오고, 그때 원문을 보낸다. 즉 42개 쪽은 조건부 전송이다.
• 7개를 고르는 계산에 tx 발신 계정 주소가 들어간다: 같은 계정의 tx는 항상 같은 피어로 간다.
• 발신 계정을 계산에 넣는 이유: 한 계정의 tx에는 0, 1, 2 순번(nonce)이 붙고 순서를 건너뛰어 실행되지 않는다. 5번과 6번이 다른 경로로 퍼져 6번만 먼저 도착하면 그 노드는 5번이 올 때까지 6번을 블록에 넣지 못한다.

• 도착한 tx는 지갑이 직접 보낸 tx와 같은 함수로 들어간다: 같은 검증을 받는다. 단, RPC 입구에만 있는 이 노드 자체의 정책 검사는 거치지 않는다.
• 정책 검사가 다른 이유: 수수료 상한 같은 검사는 합의 규칙이 아니라 이 노드가 자기 사용자에게 거는 안전장치다. 다른 노드 사용자의 tx에까지 적용할 근거가 없다.

• 3번이 가능하려면 앞의 두 단계가 끝나 있어야 한다: 주소를 모아뒀고(1단계), 그중 일부와 연결해 신원과 체인을 확인해뒀어야(2단계) 한다.

• 블록 전파 메시지를 받으면: 처리하지 않고 에러를 내며 연결을 끊는다.
• 실행 클라이언트(EL)와 합의 클라이언트(CL): 2022년 머지 이후 이더리움 노드는 프로그램 두 개가 짝을 이룬다. CL은 누가 다음 블록을 만들지 순서를 정하고, EL은 tx를 실행하고 상태를 보관한다. geth가 EL이고 6주 동안 읽은 코드가 이것이다.

• 롤업이란 (아비트럼, 베이스 등): 시퀀서 한 대가 tx를 밖에서 실행하고, 처리한 원본 데이터를 이더리움에 올려 공개한다. 이더리움이 그 결과를 검증해 주는 게 아니라, 누구든 원본을 받아 재실행해 시퀀서의 거짓말을 잡을 수 있게 하는 것이 목적이다.
• 이의 제기 기간이란: 시퀀서가 결과를 올린 뒤 누구든 반박할 수 있는 기간이다. 아비트럼과 베이스는 7일이다. 지나면 확정되어 다툴 일이 없으므로 원본도 그때까지만 필요하다. blob의 18일은 이 기간을 덮는 값이다.

해법은 별도 데이터 영역(blob)을 만드는 것이다.

• `rlp:"-"` 태그가 핵심이다: 이 필드는 직렬화에서 제외하라는 표시이고, 그래서 서명 대상에도 tx 해시 계산에도 들어가지 않는다.
• BlobHashes는: blob의 요약값을 해시해 만들고 첫 바이트를 버전 번호로 덮은 값이다.
• 직렬화란: 구조체를 전송하거나 저장할 수 있는 바이트 배열로 바꾸는 것이다. 이더리움은 RLP라는 자체 형식을 쓴다.

• 누적치가 가격을 만든다: 목표보다 많이 쓰는 블록이 이어지면 누적치가 커지고 가격이 빠르게 오른다. 한산해지면 줄어들며 내려간다.
• blob 비용은 선불이고 환불이 없다: 실행 가스는 덜 쓰면 돌려받지만 blob은 실은 만큼 낸다.
• 하드포크가 필요했던 이유: 이 계산을 하려면 블록 헤더에 필드 두 개(ExcessBlobGas, BlobGasUsed)가 추가돼야 한다. 헤더 변경은 모든 노드가 동의해야 하므로 하드포크로만 가능하다.

• blob 내용 검증 창구는 프리컴파일 0x0a다: 프리컴파일은 옵코드로 만들기에 무거운 연산을 특정 주소에 미리 구현해 둔 것이다. 그 주소를 호출하면 EVM이 해석하지 않고 Go 코드가 처리한다. 0x0a는 blob을 열지 않고도 특정 지점의 값이 맞는지 증명으로 확인해 주며, 롤업의 사기 증명이 사용한다.

• A부에서 남겨둔 질문의 답이 2번이다: blob tx 원문을 아무에게도 보내지 않는 이유는 사이드카가 크기 때문이다.