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

ACDT 95 · 누가 무슨 말을 했나 블록 접근 목록의 예외 계정 수정이 다음 포크로 밀렸다 EIP-8253을 글램스터담에 넣을 것인가 · 보류 결정 00:42:15 글램스터담의 블록 접근 목록(BAL) 사양이 논스 0인데 저장소가 남아 있는 28개 옛 계정과 충돌한다는 사실이 막판에 제기돼, 이번 포크에 넣을지 헤고타로 미룰지가 논의됐다. · Jochem Brouwer (EF, EthereumJS · EIP-8037 공동 저자): 옐로페이퍼는 컨트랙트를 생성하면 저장소 트리가 비어 있다고 가정하는데, BAL로 재실행 없이 상태 디프만 적용하면 기존 저장소 키를 지우지 못해 상태 루트가 어긋난다고 설명했다. 늦었지만 지금 글램스터담에서 처리하는 것이 가장 깔끔하다고 제안했다. · Toni Wahrstätter (EF, 리서처): BAL은 사후 상태 디프만 담고 이전 저장소 내용은 상관하지 않으므로 당장 깨지는 것은 없다고 요헴에게 반박했다. EIP 자체는 타당하고 더 일찍 했어야 하지만 지금은 너무 늦어 헤고타행이 당연하다고 했다. · FLCL (Nethermind): 남은 포크 전환 횟수로는 제대로 테스트할 수 없어 글램스터담엔 너무 늦었고 최소 헤고타로 가야 한다고 했다. · Marius van der Wijden (EF, geth): 글램스터담과 헤고타의 BAL 메커니즘이 둘로 갈리는 기술 부채만 남지 않는다면 헤고타로 미루는 데 찬성한다고 했다. · Ben Adams (Nethermind): 포크 전에 전환용 블록을 두는 아이디어도 검토했지만 너무 늦었다고 인정했고, 해당 계정들은 최대 40개 저장소 슬롯 수준으로 작아 BAL에 넣어도 부담이 없으니 기다려도 된다고 했다. · Milen (Erigon): 이 문제를 다시 꺼내지 않도록 글램스터담에서 끝내는 쪽을 약간 선호하지만 어느 쪽이든 좋다고 했다. (채팅) "이 EIP는 충분히 타당하고 더 일찍 했어야 하지만, 이렇게 늦은 시점에 넣지는 않겠다. 내게는 헤고타행이 고민할 것도 없는 선택으로 느껴진다." (Toni Wahrstätter, 00:33:22) JUMPDEST 스팸 공격과 Besu 노드 다운 데브넷 8에서 64KB JUMPDEST 컨트랙트 수만 개를 반복 호출하는 스팸 공격이 Besu 노드 13대 중 12대를 마비시켜, 원인과 각 클라이언트의 대응이 논의됐다. · Stefan Starflinger (EF DevOps): 요헴의 스팸으로 Besu 노드 대부분이 다운됐고 다른 노드들도 버거워했다고 보고했다. 최종성은 유지됐지만 Besu는 주말 동안 블록 제안의 약 65%를 놓쳤고 Nethermind는 5%, Geth는 0.1%였다며 클라이언트들이 이 엣지 케이스를 최적화해야 한다고 했다. · Jochem Brouwer (EF, EthereumJS · EIP-8037 공동 저자): 공격은 고유 코드 해시를 가진 66,667개 계정을 돌아가며 호출해 매번 64KB의 JUMPDEST 분석을 강제한다고 설명했다. 벤치마커에서는 문제가 없었는데 지속 공격에서 노드가 떨어진다며 Geth와 Nethermind를 뺀 모든 클라이언트가 살펴봐야 한다고 했다. · Ameziane Hamlat (Consensys, Besu): Besu에서 한 번에 치솟는 큰 메모리 스파이크를 확인했으며, 아직 최적화되지 않은 디버그 트레이스 코드 경로가 원인일 수 있다고 봤다. 이를 고치는 PR은 있지만 머지 전이라고 했다. · Carlos Pérez (CPerezz) (EF, EIP-8037 공동 저자): 노드 하드웨어(8코어 16GB)가 EIP-7870 권장 사양보다 낮아 보인다며 문제의 실제 심각도를 가늠해야 한다고 지적했다. (채팅) · Marius van der Wijden (EF, geth): 노드에 트레이싱이 켜져 있는지 물으며 트레이싱이 켜져 있으면 상황이 훨씬 어려워진다고 했다. (채팅) "그가 Besu 노드 대부분을 다운시켰고, 다른 많은 노드도 따라가는 데 애를 먹고 있다." (Stefan Starflinger, 00:05:42) EL 공용 리오그 테스트 스위트 · 확정 00:52:05 클라이언트마다 따로 하고 있는 리오그(reorg) 테스트를 모두가 공유하는 하나의 스위트로 만들자는 제안이 나와, 어떤 프레임워크에 만들지가 논의됐다. · Carlos Pérez (CPerezz) (EF, EIP-8037 공동 저자): 각 클라이언트가 내부적으로만 리오그를 테스트하고 공용 스위트가 없다며, 최근 메인넷 포크의 MPT 관련 버그 같은 문제를 미리 잡을 일반 테스트를 만들자고 제안했다. 클라이언트 팀에는 작업 부담이 없다고 했다. · Marius van der Wijden (EF, geth): 유지 보수할 도구를 또 만들고 싶지 않다며, 이미 동기화 테스트와 과거 리오그 테스트가 있던 Hive를 약간 선호한다고 했다. · Ben Adams (Nethermind): Hive가 좋겠다며 마리우스의 의견에 동의했다. · Luis Pinto (Besu): 성능 테스트도 계획에 있는지 물었다. · Karim Taam (Consensys, Besu): Hive가 말이 되는 선택이라고 했다. (채팅) · danceratopz (EF, 테스팅): EEST와 비슷한 테스트 형식에 FCU 지시문을 더하면 복잡한 리오그 시나리오는 물론 같은 형식의 벤치마크 전용 테스트까지 만들 수 있다고 답했고, CPerezz도 큰 리오그 윈도의 성능 측정이 유용하다며 동의했다. "나는 Hive를 약간 선호한다. 같은 기능을 갖고 우리가 유지 보수하고 들여다봐야 할 도구를 하나 더 만드는 일을 피하고 싶기 때문이다." (Marius van der Wijden, 00:51:07) 남은 것 · danceratopz / pk910: JUMPDEST 스팸 공격을 EEST 테스트로 표현하는 문제를 내일 벤치마킹 콜에 올린다. · 모든 EL 팀: EIP-8253의 글램스터담 대 헤고타 결정은 목요일 ACDE로 미뤘고, 클라이언트 팀들은 그 전에 비동기로 검토한다. 콜 페이지에서 전체 보기 → https://ethcollective.xyz/calls/acdt-95