과거에 Arbitrum에서 실제로 실행된 거래를 Foundry로 다시 돌려 볼 때, 그 거래가 일어난 당시의 Arbitrum 규칙을 적용하도록 고쳤다. 다만 이 예외는 과거 재현에만 쓰고, 새 거래를 받는 일반 검증 규칙은 그대로 엄격하게 유지한다.
Foundry는 Solidity 스마트컨트랙트를 테스트하고, 로컬 컴퓨터에서 이더리움 노드를 흉내 낼 수 있게 해주는 개발 도구다. 개발자는 실제 체인의 과거 거래를 가져와 “왜 이 거래가 실패했지?”, “이 해킹은 어떤 순서로 일어났지?”를 재현해 본다. 이를 replay, 즉 거래 재현이라고 한다.
문제는 블록체인 규칙이 모든 체인에서 완전히 같지 않고, 시간에 따라서도 달라질 수 있다는 점이다. 특히 Arbitrum은 이더리움 위에서 동작하지만 자신만의 실행·수수료 환경을 가진 L2다. 과거 Arbitrum 거래를 현재의 일반 규칙으로만 검사하면, 실제 체인에서는 통과한 거래가 개발 도구 안에서는 거절될 수 있다.
Foundry는 거래가 “과거를 재현하는 용도”인지 구분하고, 그 경우에만 Arbitrum의 재현 환경을 사용한다. 테스트에는 과거 거래가 재현 경로에서는 통과하지만, 똑같은 형태의 새 raw transaction은 일반 검증에서 여전히 실패하는 경우가 들어 있다.
버그 조사·보안 감사·사고 분석은 과거를 정확하게 되돌려 볼 수 있어야 한다. 재현 결과가 실제 체인과 다르면 개발자는 존재하지 않는 버그를 쫓거나, 반대로 실제 문제를 놓칠 수 있다.
그렇다고 재현을 위해 일반 규칙까지 느슨하게 만들면 더 위험하다. 예외 규칙이 새 거래를 받는 경로까지 퍼지면, 노드나 개발 도구가 원래 거절해야 할 거래를 받아들이는 문제가 생길 수 있다.
비유하면
2023년의 세금 신고서를 검토할 때는 2023년 세법을 적용해야 한다. 그렇다고 2026년에 새로 접수되는 신고까지 옛 세법으로 처리하면 안 된다. 이번 수정은 “과거 문서 검토”와 “새 문서 접수”를 분리한 것이다.
블록체인은 계약 코드만 중요한 산업이 아니다. 실제 체인의 상태를 읽고, 과거를 재현하고, 문제를 분석하는 노드·RPC·테스트 인프라도 함께 성숙해야 한다. L2가 늘어날수록 체인별 차이를 정확히 다루는 개발 도구의 가치도 커진다.
원문: https://github.com/foundry-rs/foundry/commit/44f64f5ae61c989ed93d5405dc4ed04c5a13b55b
NFT가 매우 큰 금액에 팔리는 상황에서도 로열티 계산의 중간 곱셈이 넘치지 않도록, OpenZeppelin이 ERC-2981 구현에 Math.mulDiv를 적용했다.
OpenZeppelin은 토큰, 권한 관리, 업그레이드 같은 기능을 구현할 때 많은 프로젝트가 가져다 쓰는 Solidity 표준 라이브러리다. ERC-2981은 NFT 판매 때 창작자 로열티를 얼마로 계산할지 알려주는 표준이다.
계산은 보통 다음처럼 보인다.