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

ACDT 98 · 누가 무슨 말을 했나 2억 가스 블록도 안전, 느린 블록은 디버그 기록 탓이었다 2억 가스 한도는 정말 안전한가 · 확정 00:19:34 지난 실행 계층 콜(ACDE)에서 데브넷 8의 느린 블록을 근거로 2억 가스 한도의 안전성에 의문이 제기됐고, 이번 콜에서 심층 분석 결과가 공유됐다. · Maria Silva (EIP-8037 제1저자): Potuz가 서로 다른 시점의 두 공격을 혼동했다고 해명했다. Paweł의 공격은 최악 2.5초 실행으로 느린 블록을 만들지 않았고, Jochem의 공격에서 느렸던 블록은 메모리 집약 공격과 디버그 트레이싱을 동시에 돌린 탓이라며 2억 가스는 실행 시간 관점에서 안전하다고 결론지었다. · Justin Florentine (Besu): 트레이싱을 끈 상태로 재시뮬레이션을 했는지 물어 재검증 논의의 물꼬를 텄다. (채팅) · Stefan Starflinger (EF DevOps): 데브넷에서는 아직 트레이싱을 끈 적이 없다고 확인했고, 이후 데브넷 8과 메인넷 섀도 포크 중 하나만 고를 필요 없이 양쪽 모두에서 테스트하자고 제안했다. · Łukasz Rozmej (Nethermind, EIP-8037 공동 저자): 가정에 어긋난 것이 없는지 항상 재검증해야 한다며 트레이싱을 끈 재실험에 동의했다. (채팅) · Csaba: 네트워크 전파 효과는 실행 차이가 아니어서 벤치마크에는 잡히지 않고 실제 네트워크에서만 드러난다는 점을 상기시켰다. "지금 우리의 결론은, 벤치마크와 데브넷에서 관찰한 것 모두에 근거해, 적어도 실행 시간 관점에서는 2억 가스가 안전하다는 것이다." (Maria Silva, 00:17:06) 패스트 컨펌 룰을 위한 새 블록 태그 · 확정 00:33:25 체인링크가 이날 FCR을 가동하는 등 채택이 시작됐지만 RPC 제공자들이 기존 safe 태그와의 하위 호환 문제에 막혀 있어, safe를 재활용하는 대신 새 태그를 만들자는 제안이 나왔다. · Julian Ma: safe 태그를 재활용하는 대신 빠르게 확정된 블록용 새 태그를 만들자고 제안했다. RPC 제공자들이 기존 고객을 위해 justified 블록과 FCR을 동시에 서비스해야 해서 하위 호환 문제가 도입을 막고 있으며, 체인링크가 이날 FCR을 가동했고 다른 브리지와 L2도 원한다고 밝혔다. · Dustin Brody (Sigma Prime, Lighthouse): justification과 safe의 정의는 CL 스펙 역사 중간에 이미 바뀌었으므로 다시 바꿔도 오래된 호환성을 깨는 것이 아니라고 반론했다. · Jihoon: 'fast' 블록이 있으면 느린 블록은 무엇이냐며 'confirmed'에 투표했고, 이 이름이 채팅에서 다수의 지지를 얻어 결정 3으로 이어졌다. (채팅) · Mikhail Kalinin: 원칙적으로 하드포크는 필요 없지만 CL과 EL 간 조율이 필요하며, 엔진 API의 capabilities 엔드포인트를 활용할 수 있다고 설명했다. · Potuz (Offchain Labs, Prysm): FCR은 소수 노드만 쓸 선택 기능인데 왜 기본 노드 동작을 바꾸느냐며, 필요한 운영자만 호환 조합을 돌리게 하고 대다수 노드의 FCU는 건드리지 말자고 Mikhail에게 반박했다. · Enrico Del Fante (Consensys, Teku): 기본값에서는 새 필드를 아예 넣지 않고 CL에서 FCR을 켤 때만 추가하면 일반 사용자에게 완전히 투명한 수동 선택 기능이 된다며 Potuz와 같은 취지로 정리했다. "이 하위 호환성 우려가, 그 외에는 꽤 잘 진행되고 있는 도입을 정말로 가로막고 있다." (Julian Ma, 00:24:18) JUMPDEST 공격, 데브넷과 벤치마크의 격차 같은 JUMPDEST 분석 공격이 벤치마크 코어(Benchmark Core)에서는 최악 2.5초인데 데브넷 8에서는 1억 가스 블록에 약 5초가 걸려, 격차의 원인과 가스 리프라이싱 필요성이 논의됐다. · Daniel Lehrner: Paweł의 공격은 약 4.4GB의 컨트랙트를 디스크에서 로드해야 했고 Besu에서는 코드 캐시가 전부 축출됐다며, 컨트랙트 로딩이 분명한 요인이라고 짚었다. · Dragan Rakita (Tempo, revm 저자): 문제 블록의 실행 시간이 일관되게 5초 안팎이라고 확인하고, JUMPDEST 가스를 올리거나 모든 클라이언트가 Nethermind처럼 최적화하는 두 갈래 길을 제시했다. reth는 며칠에서 1주 안에 크게 최적화할 계획이라고 밝혔다. · Maria Silva (EIP-8037 제1저자): 벤치마크 코어에서는 2억 가스 블록도 최악 2.5초라며, 디버그 트레이서를 끄고 측정하기 전에는 리프라이싱 결정을 해서는 안 된다고 Dragan이 제기한 리프라이싱 안에 반대했다. · Parithosh Jayanthi (EF DevOps): 데브넷은 네트워크 연결 디스크를 쓰는 클라우드 드로플렛에서 돌아 전용 하드웨어인 벤치마커와 지연이 다르므로, 데브넷 결과가 위양성일 수 있다고 지적했다. · Ben Adams (Nethermind): 최적화 전 벤치마크에서 한 코어로 2초 걸리던 것이 지금은 0.3초라며, 디스크 로딩만이 아니라 분석 자체가 문제라고 Daniel의 진단을 보완했다. "디버그 트레이서를 끄고 실제로 측정하기 전까지는 어떤 리프라이싱 결정도 내려서는 안 된다고 생각한다." (Maria Silva, 00:53:41) 남은 것 · EthPandaOps(Stefan)와 Paweł: 데브넷 8에서 디버그 트레이싱을 끄고 Paweł과 Jochem의 JUMPDEST 공격을 다시 실행해 트레이싱 오버헤드를 분리한다. 이때 Besu와 Nethermind는 세폴리아 릴리스 대신 trunk 브랜치를 쓴다. · Julian Ma: 'confirmed' 블록 태그 PR(execution-apis 908)에 대한 비동기 논의 스레드를 EF R&D 디스코드나 EF Magicians에 연다. 콜 페이지에서 전체 보기 → https://ethcollective.xyz/calls/acdt-98