컨트랙트 배포 거래가 블록에 한 번 포함된 즉시 “끝났다”고 판단하지 않고, 개발자가 정한 확인 깊이까지 기다리게 해 짧은 체인 재구성에 배포 자동화가 덜 흔들리게 했다.
Foundry의 forge script --broadcast는 Solidity 스크립트로 컨트랙트를 배포하거나
온체인 설정을 바꾸는 도구다. 거래를 전송한 뒤에는 영수증(receipt)을 조회해 성공
여부를 판단한다. 다만 “영수증이 생겼다”는 것은 거래가 현재 정식 체인으로 보이는
블록에 들어갔다는 뜻이지, 그 블록이 절대로 바뀌지 않는다는 뜻은 아니다.
네트워크에서 잠깐 서로 다른 블록이 경쟁하면 더 무거운 체인으로 정리되는 과정에서 최근 블록이 교체될 수 있다. 이를 재구성(reorg)이라 한다. 후속 배포가 앞선 거래의 주소나 상태를 전제로 한다면, 첫 영수증만 보고 다음 단계로 넘어가는 것은 위험하다. 확인 수(confirmations)는 거래가 포함된 블록을 포함해 그 위에 얼마나 많은 블록이 쌓였는지를 기준으로 기다리는 값이다.
Foundry 커밋 d49ac1a는 forge script에 --confirmations 옵션을 추가했다. 기본값은
1이고 0은 허용하지 않는다. 일반 거래 영수증 감시와 Tempo 배치 거래 대기 로직에
같은 값을 전달한다. Tempo 경로에서는 거래가 mempool에서 사라졌는데 영수증도 없을
경우 “드롭됨”으로 처리한다. 커밋은 2026-08-03에 반영됐다.
출처: https://github.com/foundry-rs/foundry/commit/d49ac1add5003d969a7c5319427b8f94a46aecd1
코드/구조에서는 어떤 차이인가
아래는 실제 diff의 조건을 단순화한 의사코드다.
이전:
receipt = wait_until_receipt_exists(tx_hash)
return receipt
변경:
confirmations = CLI값(기본 1, 최소 1)
receipt = get_receipt(tx_hash)
required_tip = receipt.block + confirmations - 1
if latest_block >= required_tip: return receipt
if tx도 없고 receipt도 없음: return “mempool에서 드롭됨”
아니면 500ms 뒤 다시 확인
예를 들어 거래가 100번 블록에 들어갔고 --confirmations 3이면 102번 블록까지
관찰한 뒤 완료로 판단한다. 이것은 “추가로 세 블록”이 아니라 포함 블록까지 합쳐
세 번의 확인이라는 점이 중요하다.
개발자는 메인넷·L2·사설 체인의 특성에 맞춰 배포 파이프라인의 신뢰도와 대기 시간을 조절할 수 있다. CI/CD가 첫 영수증 직후 검증·권한 이전·프런트엔드 설정 변경을 실행하는 경우, 최근 블록이 교체되어 앞 단계가 사라졌는데 뒤 단계만 진행되는 오류를 줄인다. 다만 확인 수를 늘려도 확정성을 수학적으로 보장하는 것은 아니다. 네트워크의 합의 방식과 finality 규칙은 별도로 이해해야 한다.
블록체인 개발 도구가 “거래 전송 성공”을 넘어 실제 운영의 확정성 정책을 자동화 인터페이스에 담는 흐름이다. 개발자 경험 개선이 단순 속도 향상이 아니라, 분산 합의의 불확실성을 배포 도구가 명시적으로 다루는 방향으로 발전하고 있음을 보여준다.
1차 출처: https://github.com/foundry-rs/foundry/commit/d49ac1add5003d969a7c5319427b8f94a46aecd1
노드가 꺼져 있던 동안 블록은 저장됐지만 증명 처리기가 놓친 구간이 생길 수 있어, 재시작 직후 저장된 최신 블록까지 증명 이력을 먼저 따라잡도록 했다.