https://secureum.substack.com/p/audit-findings-201

151. 계정 생성 스팸 가능성

• 내용
  • Hermez 네트워크는 계정 수가 2MAX_NLEVELS로 제한됨
  • 계정 생성 시 수수료가 없어, 공격자가 대량 계정 생성을 통해 트리를 가득 채울 수 있음
  • MAX_NLEVELS가 32 미만이면 단기간에 계정 한도 도달 가능
  • 32 이상이면 초당 처리량에 따라 최소 수개월 소요되지만, 여전히 가능성 존재
  • 이더리움 채굴자는 L1 계정 생성 시 가스를 지불할 필요가 없어, L1 사용자 트랜잭션을 통해 네트워크를 스팸할 수 있음
• 영향
  • 신규 계정 생성 불가 → 서비스 거부(DoS) 상태 발생
  • 네트워크 자원 고갈로 운영 중단 위험
  • 악의적인 코디네이터(coordinator)가 장기간 네트워크를 마비시킬 가능성
• 권장 조치
  1. 단기: 계정 생성 시 수수료 부과 또는 MAX_NLEVELS를 32 이상으로 설정
  2. 단기: 계정 생성 모니터링 및 스팸 발생 시 커뮤니티 알림 시스템 구축
  3. 장기: L1 가스 비용 회피 가능성을 고려한 스팸 방지 설계 적용
  4. 장기: 계정 생성 요청에 대한 속도 제한(rate limiting) 또는 화이트리스트 적용
• 심각도: 높음(High)
• 출처: ToB’s Audit of Hermez Network

152. 인터페이스 대신 빈 함수 사용으로 인한 오류 가능성

• 내용
  • WithdrawalDelayerInterface는 인터페이스 용도로 설계되었으나, 함수 시그니처 대신 빈 본문을 가진 함수로 구현됨
  • 이 경우 상속받는 계약에서 해당 함수를 반드시 오버라이드할 필요가 없어, 컴파일러의 올바른 인터페이스 구현 여부 검증을 받지 못함
  • 결과적으로 구현 누락이나 잘못된 시그니처 사용 시도 시 오류가 발견되지 않고 배포될 위험 존재
• 영향
  • 인터페이스 불일치로 인한 런타임 오류 발생 가능
  • 함수 구현 누락으로 예상치 못한 동작 유발
  • 유지보수성 및 코드 안전성 저하
• 권장 조치
  1. 단기: WithdrawalDelayerInterface를 contract가 아닌 interface로 정의
  2. 단기: 모든 파생 계약이 컴파일 시 인터페이스 구현 검증을 거치도록 강제
  3. 장기: 계약 상속 구조를 문서화하고, Slither의 inheritance-graph 기능으로 정기 점검
  4. 장기: 주요 인터페이스 변경 시 파생 계약 일괄 리뷰
• 심각도: 중간(Medium)
• 출처: ToB’s Audit of Hermez Network