타임락 계약은 관리자 변경이나 업그레이드 호출을 예약한 뒤 최소 지연 시간이 지나야 실행되게 하는 장치입니다. 제안 내용을 온체인에 미리 공개해 사용자와 감시자가 영향을 검토하고 대응할 시간을 줍니다. 다만 우회 관리자, 짧은 지연, 감시 부재, 즉시 업그레이드 경로가 있으면 타임락 이름만으로 안전이 보장되지 않습니다.
타임락은 호출 내용을 먼저 예약한다
OpenZeppelin TimelockController에서 operation은 하나 또는 여러 계약 호출입니다. target, 보낼 value, 함수와 매개변수를 담은 data, 선행 작업 predecessor, 동일 내용을 구분하는 salt로 해시를 만듭니다. proposer가 schedule을 호출하면 최소 지연보다 짧지 않은 대기 시간이 시작됩니다.
대기 전에는 Unset, 예약 뒤에는 Pending이며 시간이 지나면 Ready가 됩니다. executor가 execute를 호출해 실제 대상 계약 함수를 성공시키면 Done 상태가 됩니다. 시간이 지났다고 자동 실행되는 것은 아니며 실행 거래를 낼 주체와 수수료가 필요합니다.
| 역할 | 주요 권한 | 점검할 위험 |
|---|---|---|
| Admin | proposer·executor 역할 관리 | 외부 admin이 즉시 우회 가능한가 |
| Proposer | 작업 예약·대기 중 취소 | 누가 악성 작업을 올릴 수 있나 |
| Executor | Ready 작업 실행 | 누구나 실행인지 제한 주소인지 |
| Target admin | 대상 계약 설정 변경 | 타임락 외 권한이 남았나 |
지연 시간은 공개 검토 창을 만든다
예약 이벤트와 calldata가 공개되면 사용자는 어떤 구현 주소로 업그레이드하는지, 수수료나 담보 비율이 어떻게 바뀌는지 미리 분석할 수 있습니다. 위험한 변경이면 예치금을 인출하거나 포지션을 줄이고, 거버넌스 참여자는 취소 절차를 검토할 수 있습니다.
그러나 24시간 지연이 곧 24시간 탈출 기회를 뜻하지는 않습니다. 자산이 이미 잠겨 있거나 인출 큐가 더 길고, 시장 유동성이 부족하거나 체인이 멈추면 대응하지 못할 수 있습니다. 최소 지연을 사용자의 실제 대응 시간과 비교해야 합니다.
시간 지연은 경고를 행동으로 바꿀 수 있을 때 보호가 된다.
JOBCOIN 해설
예약된 작업의 calldata를 직접 읽는다
작업 제목이나 거버넌스 설명은 온체인 실행 내용과 다를 수 있습니다. operation의 target과 value, 함수 selector, 디코딩된 매개변수를 검증합니다. 프록시 업그레이드라면 새 implementation 코드와 초기화 호출이 함께 배치됐는지 확인합니다.
batch 작업은 여러 호출을 원자적으로 실행할 수 있습니다. 겉으로는 정상 파라미터 변경이지만 뒤 호출에서 역할을 부여하거나 자산을 이동할 수 있으므로 배열 전체를 봅니다. predecessor가 있으면 선행 operation이 Done인지와 의도한 실행 순서도 확인합니다.
- operation ID의 target·value·data·salt를 원문과 대조한다.
- batch의 모든 호출과 초기화 데이터를 디코딩한다.
- 예약 시각과 Ready 시각, 실제 최소 지연을 계산한다.
- 대상 계약의 다른 admin·guardian·upgrade 경로를 찾는다.
역할 설정이 타임락의 경계를 결정한다
OpenZeppelin 문서는 proposer가 예약과 Pending 작업 취소를 담당하고 executor가 Ready 작업을 실행한다고 설명합니다. executor 역할을 zero address에 열면 누구나 준비된 작업을 실행할 수 있지만 예약되지 않은 호출을 새로 만들 수는 없습니다. 실행 검열 위험과 가스 부담 구조가 달라집니다.
초기 설정용 외부 admin이 남아 있으면 proposer나 executor를 즉시 바꿀 수 있습니다. self-governed 구성을 원한다면 테스트 뒤 외부 admin이 권한을 포기했는지 온체인 역할 이벤트로 확인합니다. proposer와 canceller가 같은지, 비상 guardian이 무엇을 취소하거나 즉시 실행할 수 있는지도 봅니다.
최소 지연 변경도 타임락을 거쳐야 한다
공격자가 minDelay를 즉시 0으로 낮춘 뒤 위험한 작업을 실행할 수 있다면 지연 장치가 무력화됩니다. OpenZeppelin 구현은 updateDelay가 타임락 계약 자신에 의해서만 호출되도록 설계해 지연 변경 자체도 예약·대기 과정을 거치게 합니다.
커스텀 구현이나 프록시 업그레이드는 다른 규칙을 가질 수 있습니다. 현재 getMinDelay 값뿐 아니라 이를 변경할 수 있는 함수와 caller 조건을 읽습니다. 타임락 계약 자체를 업그레이드할 수 있다면 그 업그레이드 admin과 지연도 같은 분석 범위에 포함합니다.
모니터링과 대응 절차가 있어야 완성된다
Scheduled·Cancelled·Executed 이벤트를 감시해 새 operation의 디코딩 결과와 Ready 시각을 알림으로 보냅니다. 단순히 제안 생성만 감시하면 같은 제안의 취소·재예약이나 salt 변경을 놓칠 수 있습니다. 체인 재조직과 인덱서 지연을 고려해 확정 블록에서 다시 확인합니다.
사용자는 비상 때 인출에 필요한 승인, 가스, 대기 시간을 미리 알아야 합니다. 프로토콜 팀은 악성 예약을 누가 취소할지와 키가 침해됐을 때 역할 교체가 가능한지 연습합니다. 타임락은 취약한 코드를 고치지 않으며 알려진 변경에 대응할 시간을 배분하는 운영 장치입니다.
자주 묻는 질문
타임락 시간이 끝나면 변경이 자동 실행되나요?
일반적으로 아닙니다. Ready 상태가 된 뒤 executor가 실행 거래를 제출해야 대상 호출이 수행됩니다.
지연 시간이 길면 무조건 안전한가요?
아닙니다. 우회 관리자와 즉시 경로가 없어야 하고, 사용자가 그 시간 안에 인출·취소 등 실제 대응을 할 수 있어야 합니다.
누구나 executor면 위험한가요?
공개 executor는 이미 예약돼 Ready가 된 작업만 실행할 수 있습니다. 핵심은 proposer·operation 내용·역할 구성과 우회 권한입니다.
