프레임 등 헤고타 후보 EIP 4종이 데브넷 검증에 들어간다
프로포저 선택 버그, 지금 고칠 것인가 · 보류 결정 00:16:50
슬롯 31의 프로포저가 자기 슬래싱으로 셔플 인덱스를 조작해 다음 두 에포크의 프로포저 선정에 끼어들 수 있다는 스펙 버그가 콜 직전 보고돼, 금요일 후디 릴리스 마감 전에 글램스터담 수정 여부를 정해야 했다.
· Justin Traglia (EF, 보안): 합의를 깨는 변경이라 지금 넣으면 세폴리아가 깨지고 구현을 두 벌 관리해야 하는데, 공격은 자기 슬래싱이 필요해 실익이 적다며 헤고타에서 고치자고 했다.
· Barnabas Busa (EF DevOps): 버그를 보고하면서도 실제로 일어날 일이 거의 없다며 헤고타에서조차 고칠 필요가 있는지 의문이라고 했고, 글램스터담 포함에는 분명히 반대했다.
· Dustin Brody (Nimbus): 메인넷만 고치는 방안은 성립하지 않는다고 반박했다. 님버스는 네트워크별로 릴리스를 쪼개지 않고 단일 릴리스만 내기 때문이라는 근거다.
· Toni Wahrstätter (EF, 리서처): 공격자 입장에서 매우 비매력적인 공격이라 사실상 문제가 아니라고 봤고, 같은 조작이 RANDAO로도 가능하다는 점을 짚었다. (채팅)
· Pawan Dhananjay: 수정을 다음 포크로 미루는 데 동의한다고 밝혔다. (채팅)
"이건 실행하기 어렵고 이득은 거의 없으며, 하려면 스스로를 슬래싱까지 해야 한다." (Justin Traglia, 00:12:29)
EIP-7870 하드웨어 사양, 얼마나 올리고 어떻게 관리하나 · 리빙 문서 유지 확정 00:19:09
글램스터담에서 컨트랙트 크기(24에서 64KB), 가스 한도(60에서 200M)가 크게 오르면서 EIP-7870의 디스크 속도 기준 500MB/s가 현실과 맞지 않게 돼, 수치 상향 폭과 문서 관리 방식이 논의됐다.
· Jochem Brouwer (EF, EthereumJS · EIP-8037 공동 저자): 현 사양으로는 글램스터담 최악 블록 처리에 8초가 걸려 너무 느리다며 순차 읽기·쓰기를 최소 1000MB/s, 가급적 2000MB/s로 올리자고 했고, 소통의 명확성을 위해 포크마다 별도 사양 EIP를 두자고 제안했다.
· Maria Silva (EIP-8037 제1저자): 이번 포크의 병목 때문만이 아니라 현 수치 자체가 실제 노드가 쓰는 장비 대비 이상하게 낮아서 고치는 것이라고 논점을 보탰다.
· Ben Adams (Nethermind): Maria에 동조하며 스펙에 적힌 낮은 속도의 NVMe 드라이브는 해당 용량에서 애초에 존재한 적이 없다고 지적했다.
· Dustin Brody (Nimbus): 사양이 전반적으로 낮다는 서사에는 반박했다. RAM과 CPU 같은 다른 항목은 오히려 지나치게 높으며 님버스 사용자들은 16GB ARM 보드에서도 잘 돌린다는 근거를 들었다.
· Łukasz Rozmej (Nethermind, EIP-8037 공동 저자): 평소 블록은 낮은 장비로도 돌지만 권장 사양은 최악의 공격 블록을 감당해야 한다며 둘을 구분했고, 사양 EIP는 여러 개로 쪼개면 더 혼란스러우니 하나로 유지하며 포크별 이력을 담자고 jochem에 반대했다.
· Barnabas Busa (EF DevOps): EVM 작업에는 순차 처리량보다 랜덤 4K IOPS가 훨씬 중요하므로 그 수치에 집중해야 한다고 했다. (채팅)
"EIP에 요구사항으로 넣는 하드웨어는 최악의 블록을 처리할 수 있어야 하고, 그게 바로 차이점이다." (Łukasz Rozmej, 00:23:34)
퀵 슬롯과 heze-devnet-2의 슬롯 길이 · 12초 유지 결정 00:38:01
FOCIL 중심의 heze-devnet-2에 퀵 슬롯(EIP-8198)을 넣되 슬롯을 12초로 둘지 10초로 줄일지를 두고 클라이언트별 준비 상황이 갈렸다.
· Justin Traglia (EF, 보안): 클라이언트들이 시간 내 구현을 못 하면 슬롯을 12초로 두어 퀵 슬롯을 사실상 선택 사항으로 하고, 3개 이상 클라이언트가 준비되면 그때 10초로 바꾸자고 제안했다.
· Barnabas Busa (EF DevOps): 선택 사항이라면 아예 한 주 일찍 띄우자고 했고, 2주를 미룰 거라면 그때는 참여자 모두가 10초 전환 능력을 갖춰야 한다고 봤다. 채팅에서는 10월 21일 12초안 또는 10월 28일 10초안을 선호한다고 밝혔다.
· Dustin Brody (Nimbus): 님버스는 이 기간 안에 퀵 슬롯을 구현하지 못할 것이며, 10초가 필수가 되면 님버스는 참여하지 않을 가능성이 크다고 했다.
· Jihoon: 테쿠도 12초 퀵 슬롯은 지원한다고 채팅에 밝혔다며 12초 유지안에 힘을 실었다.
· Matthew Keil (ChainSafe, Lodestar): 슬롯을 12초로 유지해야 한다고 했다. (채팅)
· Pawan Dhananjay: 라이트하우스는 28일까지 준비할 수 있다고 했다. (채팅)
"어느 쪽이든 괜찮지만, 후자라면 님버스는 참여하지 않을 가능성이 매우 크다." (Dustin Brody, 00:37:51)
데브넷 계획을 얼마나 앞서 짤 것인가
데브넷에 넣을 EIP를 몇 단계 앞서 계획해 클라이언트 팀의 번아웃을 줄이자는 제안을 두고 속도와 검증 순서 사이의 긴장이 드러났고, 차기 데브넷 후보 EIP들이 거론됐다.
· Spencer Taylor-Brown (EF, 테스팅): 데브넷 두 단계 앞까지 EIP를 미리 정하면 팀들이 앞서 일할 수 있고 번아웃도 줄일 수 있다며, 이번 포크가 아니라 다음 포크부터라도 프로세스를 바꿔보자고 제안했다.
· Dustin Brody (Nimbus): CFI의 목적은 EIP가 실제로 작동하는지 확인하는 것인데, 파이프라인식 계획은 아직 모르는 앞선 데브넷의 결과를 미리 가정하게 된다며 신중론을 폈다.
· Justin Florentine (Besu): 제안의 취지는 인정하면서도 FOCIL과 프레임처럼 상호작용이 용량에까지 영향을 줄 수 있으므로, CFI 전부를 구현해놓고 나중에 고르는 방식으로 가기 전에 이 순환 문제부터 풀어야 한다고 했다.
· Maria Silva (EIP-8037 제1저자): 셀프디스트럭트 비활성화를 일찍 넣으면 테스트에서 엣지 케이스가 줄어드는지 물었고, 그렇다는 답을 듣자 복잡하지 않은 EIP이니 조기 포함이 합리적이라고 했다.
· Jochem Brouwer (EF, EthereumJS · EIP-8037 공동 저자): 셀프디스트럭트를 비활성화하면 기존 패턴이 경제적으로 비싸지므로 EIP-8360(TCREATE)도 함께 우선해야 한다고 했다가, 테스트 관점에서는 별개 문제라는 Justin Florentine의 반박에 좋은 지적이라고 수긍했다.
· Carlos Pérez (CPerezz) (EF, EIP-8037 공동 저자): SETCODEFROM은 포스트퀀텀 마이그레이션의 사실상 유일한 경로이고 네서민드와 게스가 이미 구현해 테스트를 통과했으며 프레임과의 통합 검증에도 도움이 된다며 조기 포함을 주장했다.
"이런 식의 계획 파이프라인의 위험 하나는, 앞선 데브넷에서 아직 알지 못하는 결과를 미리 가정하기 시작한다는 것이다." (Dustin Brody, 00:43:31)
남은 것
· 전체 클라이언트 팀: 후디 릴리스가 준비되면 블로그 작성 담당인 Alex Stokes에게 알린다.
· jochem: EIP-8253 테스트 계정을 데브넷 제네시스 템플릿에 추가하는 PR을 연다.
· EL 팀 / spencer: 다음 콜에서 bogota-devnet-2의 EIP 범위(SETCODEFROM, 데이터 리프라이싱, 논스 범프, 셀프디스트럭트 비활성화)를 확정한다.
콜 페이지에서 전체 보기 → https://ethcollective.xyz/calls/acdt-100