ACDT #96 · 누가 무슨 말을 했나

ACDT 96 · 누가 무슨 말을 했나 다음 하드포크가 첫 공개 테스트넷 적용 단계에 들어간다 데브넷 8 복구와 레이어 간 조율 일주일간의 공격 테스트가 끝난 데브넷 8의 복구가 더디자 누가 문제를 추적하고 조율할 것인지가 도마에 올랐다. · Saulius Grigaitis (Grandine): 데브넷 8이 다소 방치된 느낌이고 여러 클라이언트가 어려움을 겪는데 진전이 안 보인다며, 누군가 어려움을 겪는 클라이언트에 연락해 문제가 EL 쪽인지 CL 쪽인지 가려내는 조율을 해 달라고 요청했다. · pk910 (EF DevOps): 이미 이날 아침 문제가 있는 클라이언트들에 통지했다고 답했다. 한 클라이언트는 완전히 초기화 후 재동기화 중이고 다른 클라이언트도 최신 상태로 따라잡는 중이라 전반적으로 진전이 있다고 했다. · Saulius Grigaitis (Grandine): CL 쪽에서는 노드가 블록을 제안하지 못하는 것만 보이는데 대부분 원인이 EL 쪽이었다며, EL 팀에 직접 연락해 계속 챙기는 조율이 있으면 CL 개발자들이 진짜 문제를 훨씬 쉽게 볼 수 있다고 재차 강조했다. · pk910 (EF DevOps): 타당한 지적이라고 인정하면서도, 지난주에 무거운 공격 트랜잭션을 돌렸기 때문에 많은 EL이 어려움을 겪은 측면이 있다고 덧붙였다. 이어 다수 EL이 풀 싱크(full sync)로 설정돼 지난 2주의 공격 트랜잭션을 전부 재실행하느라 느리며 일부를 스냅 싱크(snap sync)로 바꿀 수 있다고 설명했다. "대부분의 경우 문제는 EL 쪽에 있으니, 누군가 EL 쪽 사람들에게 연락해서 계속 챙겨 주면 정말 좋겠다." (Saulius Grigaitis, 00:13:40) 컨센서스 스펙 테스트 추가 제한 · 확정 결정 00:19:11 누구나 제안할 수 있는 EIP의 테스트가 스펙 저장소 곳곳을 건드려 유지보수 부담이 커지자, 트렁크에 테스트를 넣을 수 있는 EIP를 제한하자는 제안이 나왔다. · Justin Traglia (EF, 보안): 테스트 추가는 자기완결적인 스펙 디렉터리 추가보다 침습적이므로 컨센서스 스펙 저장소의 테스트 추가를 CFI·SFI EIP로 제한하자고 제안했다. · Jochem Brouwer (EF, EthereumJS · EIP-8037 공동 저자): 트렁크 브랜치 제한 자체에는 동의하되, 테스트 작업을 미루라는 신호가 돼서는 안 된다고 선을 그었다. PFI 단계에서 PR이나 포크 저장소에 테스트를 준비해 두면 CFI로 승격되는 즉시 병합할 수 있다고 했다. · Jihoon: 제안 취지는 테스트가 여러 파일과 테스트 인프라를 건드려 기존 하드포크의 테스트 유지보수가 어려워지는 것을 막으려는 것이지, 테스트 개발을 억제하려는 게 아니라며 Justin의 설명에 동의했다. · Enrico Del Fante (Consensys, Teku): 제한에 동의하면서도 클라이언트에게 이른 테스트가 중요하다는 점을 강조했다. (채팅) "EIP가 CFI에 도달한 뒤에야 테스트 작업을 시작한다면 프로세스 면에서 효율적이지 않을 것이다." (Jochem Brouwer, 00:19:32) 세폴리아 섀도 포크 시작 시점 · 일정 결정 00:18:24 세폴리아 업그레이드 전 예행연습인 섀도 포크를 언제 띄울지가 논의됐고, 클라이언트 준비 상태가 관건이었다. · pk910 (EF DevOps): 클라이언트들의 unstable·master 브랜치가 테스트 준비만 됐다면, 반대가 없으면 이번 주 중 세폴리아 섀도 포크를 시작하자고 제안했다. 실패하면 반복해야 하는 큰 작업이라 한 번에 성공시키고 싶다고 했다. · Pawan Dhananjay: 프로그레시브 컨테이너(progressive container) 관련 의존성 감사가 아직 끝나지 않았다며, 수정 버전을 확보한 뒤 시작하도록 한 ACDT 주기를 더 기다리자고 요청했다. · pk910 (EF DevOps): Pawan의 요청을 받아들여 다음 테스팅 콜에서 모두 준비됐는지 다시 이야기하자며 좋은 계획이라고 동의했다. · Dragan Rakita (Tempo, revm 저자): 팀들이 대비할 수 있도록 디스코드에 미리 공지를 남겨 두자고 제안했다. (채팅) "프로그레시브 컨테이너 관련 의존성을 아직 완전히 감사하지 못했으니, 그 전에 수정된 버전을 확보하고 싶다." (Pawan Dhananjay, 00:18:42) EIP-7610 롤백과 BAL 충돌 처리 · 확정 결정 00:35:09 컨트랙트 생성 충돌 처리를 정의하지 않은 EIP-7610 탓에 레거시 테스트가 무더기로 깨지자, 옛 동작으로 되돌릴지와 새로 도입되는 BAL이 이 경우를 어떻게 다뤄야 할지가 논의됐다. · FLCL (Nethermind): 충돌 시 스토리지를 다시 쓰는 옛 EIP 동작으로 롤백하고 테스트와 클라이언트를 그에 맞춰 정렬하자고 제안하면서, 충돌 상황에서 BAL을 어떻게 처리할지 의견을 구했다. · Milen (Erigon): EIP-7610 이전 상태(옐로페이퍼와 EIP-684, 충돌 시 스토리지 슬롯 무효화)로 레거시 테스트를 복원하는 PR 18을 열었고, 복원 과정에서 자기 클라이언트의 실제 회귀를 잡아냈으니 테스트를 유지할 가치가 있다고 했다. BAL은 미정의로 두기, 충돌 시 BAL 항목 제외 명시, EIP-8253 도입의 세 가지 선택지를 제시했다. · Jochem Brouwer (EF, EthereumJS · EIP-8037 공동 저자): BAL을 블록의 상태 디프로 쓰려면 충돌 시 삭제되는 스토리지 슬롯까지 담아야 하는데, 해시된 키만 저장하는 클라이언트는 프리이미지(pre-image)를 복원할 수 없어 복잡한 문제라고 설명했다. 메인넷에서 가능한 계정이 28개뿐인 만큼 이 동작을 명시적으로 테스트하지 말고 헤고타에 PFI 상태인 EIP-8253으로 근본 해결하자는 의견을 냈다. · FLCL (Nethermind): jochem의 제안에 맞서, 미정의 동작은 클라이언트마다 구현이 갈려 검증과 버그 헌팅을 어렵게 하므로 적을수록 좋다고 반박했다. 모두가 합의한 가장 단순한 방식과 테스트 하나면 충분하다고 했다. · Spencer Taylor-Brown (EF, 테스팅): milen의 PR을 병합해 헤고타의 EIP-8253까지 가는 징검다리로 삼겠다는 계획을 밝혔고, 레거시 테스트는 연말까지 보관 처리할 예정이라고 했다. BAL 케이스는 비동기로 논의를 이어가자고 했다. · Karim Taam (Consensys, Besu): BAL을 스냅 싱크 힐링(healing)에 쓰려 하고 있어 BAL에서 상태 수정이 빠지면 최종 상태가 잘못될 수 있다며, 삭제까지 모두 포함하는 쪽을 선호한다고 했다. "미정의 동작은 검증과 버그 헌팅 쪽에서 문제를 일으킨다. 미정의 동작은 적을수록 좋다." (FLCL, 00:38:04) 남은 것 · EL 전 팀: devp2p PR 281(스파스 블롭풀 길이 인코딩) 리뷰 · spencer(EF 테스팅): 클라이언트 간 동작 비교용 BAL 충돌 단일 픽스처 제작 콜 페이지에서 전체 보기 → https://ethcollective.xyz/calls/acdt-96