MSTR Cat

블록체인/레벨 IV · 프로토콜 심화/4.1 Script/수업 4

타임락: CLTV와 CSV

다시 돌릴 수 없는 시계, 그리고 그것을 정직하게 유지하는 중앙값

준비물거래 상세 정보를 확인할 수 있는 블록 탐색기(예: mempool.space 또는 blockchain.com)유닉스 타임스탬프를 처리할 수 있는 계산기BIP65, BIP68, BIP113 사양 문서들

호기심

  1. 새 트랜잭션으로 언제든 우회할 수 있다면, 지출을 지연시키는 트랜잭션 필드는 왜 존재할까요?
  2. 한 명의 채굴자는 어떻게 다른 모든 이들의 합의를 깨뜨리지 않고 시간에 대해 거짓말을 할 수 있을까요?
  3. 특정 연도까지 기다리는 것과 지금부터 2년을 기다리는 것은 어떻게 다를까요?

탐구

  1. 모든 비트코인 거래에는 nLockTime 필드가 있으며, 이는 특정 시점 이전에 해당 거래가 채굴되는 것을 방지하는 4바이트 값입니다. 이 값이 500,000,000 미만이면 블록 높이를 나타내고, 그 임계값 이상이면 유닉스 타임스탬프를 의미합니다. 하지만 이 메커니즘은 해당 거래에만 적용됩니다. 사용자는 동일한 입력 값과 0인 락타임을 가진 새로운 거래를 만들어 즉시 코인을 지출할 수 있습니다. nLockTime은 출력 자체를 구속하지 않기 때문에, 그것만으로는 미래 조건에 대한 보안을 제공하지 못합니다.
  2. 피터 토드가 BIP65에서 제안하고 2015년 12월에 활성화된 OP_CHECKLOCKTIMEVERIFY(CLTV)는 이 구도를 바꾸었습니다. CLTV는 트랜잭션의 nLockTime을 스택의 값과 비교하는 스크립트 옵코드입니다. 락타임이 요구값보다 작으면 실행이 실패합니다. 이 검사는 출력의 잠금 스크립트 안에서 이루어지므로, 그 특정 미사용 트랜잭션 출력(UTXO)을 지출하려는 모든 시도는 이 조건을 충족해야 합니다. 이렇게 절대 타임락이 만들어집니다. 전역적인 합의 기준의 특정 시각이나 블록 높이에 도달할 때까지 코인은 지출할 수 없습니다.
  3. 상대 타임락은 절대 시점이 아니라 경과 기간을 측정한다는 점에서 다르게 작동합니다. BIP68은 이전에는 이 목적으로 쓰이지 않던 트랜잭션 입력의 nSequence 필드를 재해석해 상대적 지연을 인코딩합니다. BIP112에 정의되고 2016년 7월 BIP68과 함께 활성화된 OP_CHECKSEQUENCEVERIFY(CSV)는 입력의 시퀀스 값을 요구되는 기간과 비교합니다. 이를 통해 스크립트는 ‘이 출력은 컨펌된 후 144블록이 지날 때까지 지출할 수 없다’와 같은 조건을 강제할 수 있습니다. 이 지연은 해당 UTXO가 컨펌된 시점을 기준으로 하므로, 시간 기반 복구 경로나 결제 채널 만료에 이상적입니다.
  4. 시간 기반 잠금은 채굴자에게 타임스탬프를 조작할 유인도 주었습니다. 채굴자는 타임락이 걸린 트랜잭션을 의도보다 일찍 더 많이 포함하기 위해 블록 타임스탬프를 최대 2시간 미래로 설정할 수 있었습니다. 2016년 7월 상대 타임락과 동시에 활성화된 BIP113은 MTP(Median Time Past, 과거 시간 중앙값)를 도입했습니다. 이제 타임락 검사는 블록 자체의 타임스탬프가 아니라 직전 11개 블록 타임스탬프의 중앙값과 비교합니다. 이로써 어느 한 채굴자도 시계에 크게 영향을 줄 수 없습니다. MTP는 보통 실제 시각보다 약 1시간 늦으며, 모든 타임락 계산에 안정적이고 검증 가능한 기준을 제공합니다.
  5. 이러한 메커니즘은 결제 채널이나 상속 프로토콜 같은 복잡한 애플리케이션의 기반이 됩니다. 라이트닝 채널에서 진행 중인 결제에는 절대 타임락(CLTV)이 쓰여, 청구되지 않은 결제는 기한이 지나면 환불될 수 있습니다. 한편 각 당사자 자신의 출력에 걸린 상대 지연(CSV)은 상대방이 오래된 채널 상태를 처벌할 시간을 줍니다. 상속의 경우 스크립트로 멀티시그니처 요건과 타임락을 결합할 수 있습니다. 예를 들어 평소 사용에는 키 두 개가 필요하지만, 1년 동안 활동이 없으면 세 번째 키(상속인)가 CSV 조건을 통해 정족수에 합류하는 식입니다. 이러한 매개변수는 지갑 생성 시 고정되며, 일단 자금이 잠기면 변경할 수 없습니다.
  6. 타임락은 영구적인 제약입니다. 정해진 시점에 해제되지만, 활성화된 뒤에는 다시 잠그거나 지연을 연장할 방법이 없습니다. 스크립트에 100블록의 시퀀스 값이 인코딩되어 있다면, 코인은 컨펌 이후 그 상대 높이에 도달하는 바로 그 시점에 지출 가능해집니다. 인코딩을 잘못하면 의도보다 오래 자금에 접근하지 못하거나, 반대로 너무 일찍 해제될 수 있습니다. 직접 확인하려면 블록 탐색기에서 아무 최근 트랜잭션이나 열어 nLockTime 필드를 살펴보세요. 대부분의 지갑은 이 값을 현재 블록 높이로 설정하므로, 그 트랜잭션은 더 낮은 높이의 블록에 들어갈 수 없습니다. 이는 채굴자가 최신 블록의 수수료를 차지하려고 그 블록을 다시 쓰려는 유인(‘수수료 스나이핑’)을 하나 없애 줍니다.

핵심 사실

  • nLockTime 값이 500,000,000 미만인 경우는 블록 높이로 해석되며, 그 이상인 경우는 유닉스 타임스탬프로 간주됩니다.
  • OP_CHECKLOCKTIMEVERIFY(BIP65)는 2015년 12월에 활성화되었으며, 스크립트 수준에서 절대 타임락을 강제합니다.
  • OP_CHECKSEQUENCEVERIFY(BIP112)와 BIP68은 2016년 7월에 활성화되었으며, nSequence 필드를 통해 상대 타임락을 가능하게 합니다.
  • BIP113에 도입된 Median Time Past(MTP)는 채굴자의 시간 조작을 방지하기 위해 과거 11개 블록의 중앙값을 사용합니다.
  • CSV 지연은 사용되는 특정 UTXO의 확인 높이나 시간을 기준으로 측정됩니다.
  • 지갑들은 수수료 스니핑 위험을 줄이기 위해 일반적으로 nLockTime을 현재 블록 높이로 설정합니다.

연습 아홉, 여섯, 셋, 하나

9모으기설명된 타임락 활용 사례 9가지(라이트닝, 볼트, 상속, 에스크로, 아토믹 스왑 등)를 찾아 나열하고, 각각 절대 락인지 상대 락인지 표시하세요.
6묶기9개를 목적에 따라 6개 그룹으로 묶으세요: 환불, 페널티 기간, 상속, 저축 잠금, 계약 기한, 기타.
3추리기6개를 타임락이 지출 트랜잭션에만 있어서는 안 되고 출력 스크립트 안에 있어야 하는 이유 3가지로 줄이세요.
1결정화MTP가 어떻게 타임락을 채굴자를 신뢰하는 모델에서 결정론적 합의 규칙으로 바꾸는지 한 문장으로 설명하세요.

팩트 체크

날짜, 수치 및 주장은 아래에 명시된 출처들을 통해 확인되었습니다.

인터랙티브 아카데미에서 열기 →

EN PT ES ZH JA RU DE FR MS