EOF (EVM Object Format) 논쟁 요약

[EOF (EVM Object Format) 논쟁 요약] (링크) 최근 Fusaka 업그레이드에 들어갈 EIP들을 논의하면서, EOF를 넣어야 하는지에 대한 논쟁이 발생하고 있습니다. - EOF란? EVM 바이트코드를 구조화해, 분석성과 검증성을 높이는 포맷입니다. 배포 시 코드 유효성 검사를 진행하고, 컨트랙트 크기(24KB → 64KB) 확대하며, Stack too deep 에러를 제거합니다. 지난 4년 간 개발되어, 현재 대부분의 클라이언트 구현에 적용되었고, 거의 테스팅 단계에 와 있습니다. - EOF 도입 시 장점 1. 배포 시점 코드 검증 → 버그 감소 2. 클라이언트 부하 감소 → 컨트랙트 크기 제한 두 배 이상 상향 가능 3. 스택 연산 확장 (DUPN, SWAPN) → Stack too deep 문제 해결 4. 정적 분석 및 formal verification 용이 - 반대 이유 요약 1. 너무 큰 복잡성: 11개 EIP + 19개 새 opcode으로 테스팅 난이도가 증가하고, 컨트랙트 배포 과정에서 검증 로직에 버그가 생길 시 이더리움 합의에 리스크가 생김. 2. 이득 대비 무거운 비용: 주는 혜택이 제한적 (Stack too deep 해결, 컨트랙트 크기 제한 상향) 이며, 대체안 (EIP-7912, EIP-7907) 존재 3. 기존 라이브러리 대규모 수정 필요: OpenZeppelin 등 거의 모든 프로토콜이 사용하는 라이브러리들을 재작성해야 하는 부담 존재 - 총평 무엇보다도 EOF에 대한 논의가 지난 4년 동안보다 근 한 달 간 더 많이 이뤄지고 있다는 점이 좋지 못한 것 같습니다. 진작에 앱 개발자 및 리서처들과의 논의를 충분히 거쳤더라면, 코어 개발 리소스를 보다 효율적으로 쓸 수 있지 않았을까 싶네요. EF도 이전보다 실사용자에 집중하고 있는 만큼, 이더리움 프로토콜 거버넌스도 사용자에 집중하여 이뤄지는 것이 좋지 않을까 싶습니다. 이런 저런 이야기를 보면서 생각한 것은, EOF가 안 좋은 업그레이드는 아닐지라도 '사용자'에 집중한 것 같지는 않았다는 점입니다. Pectra 다음 업그레이드인 Fusaka에서는, L2 확장성 업그레이드인 PeerDAS / L1 확장성을 위한 가스 리밋 증가 두 가지 주제를 중점으로 다루는 것이 바람직하다고 생각되네요.