용어집 / 프로토콜과 업그레이드
OP_CHECKLOCKTIMEVERIFY
별칭은 CLTV, BIP65입니다.
- OP_CHECKLOCKTIMEVERIFY란 무엇입니까?
- OP_CHECKLOCKTIMEVERIFY는 키를 누가 가지고 있든 관계없이 명시된 블록 높이나 달력 날짜 전에는 코인이 지출되지 않도록 막는 스크립트 연산 코드입니다.
BIP-65에 명시되어 있습니다.
트랜잭션이 아니라 코인 자체에 기록되는 시간 잠금입니다. Peter Todd가 BIP65에서 이를 명세했으며, 그때 이 연산 코드는 기존의 아무 동작도 하지 않던 연산 코드 NOP2의 자리를 대신 차지했고, 이 규칙은 2015년 12월의 블록 388,381부터 적용되어 왔습니다. 상속 계획이나 복구 경로를 설정해 본 적이 있다면, 문을 닫아 잠그고 있는 것이 바로 이 연산 코드입니다.
작동 방식
OP_CHECKLOCKTIMEVERIFY는 스크립트 스택에서 숫자 하나를 읽고, 코인을 지출하려는 트랜잭션의 locktime 필드와 비교한 뒤, 지출이 너무 이르면 전체 스크립트를 중단합니다.
BIP65에는 이 검사가 실패하는 다섯 가지 경우가 나열되어 있습니다. 스택이 비어 있는 경우, 최상위 항목이 음수인 경우, 해당 항목과 트랜잭션의 locktime이 블록을 세는지 초를 세는지에 대해 서로 어긋나는 경우, 해당 항목이 트랜잭션의 locktime보다 큰 경우, 입력의 시퀀스 번호가 0xffffffff로 설정된 경우입니다. 마지막 조건은 뻔한 허점을 막습니다. 모든 입력이 최종으로 표시되면 locktime은 완전히 무시되므로, 이 조건이 없다면 지출하는 쪽은 기한을 그냥 꺼 버리고 돈을 가져갈 수 있습니다.
이런 스크립트를 처음 읽는 사람을 놀라게 하는 세부 사항이 두 가지 있습니다. 이 연산 코드는 검사하는 숫자를 소비하지 않으므로, 실제 스크립트는 스택을 정리하기 위해 뒤에 OP_DROP를 붙입니다. 그리고 보통의 4바이트가 아니라 5바이트 피연산자를 받아들이는데, 비교해야 할 수 있는 가장 큰 값이 검사하는 필드의 전체 범위인 2**32-1이기 때문입니다.
소프트 포크 방식은 평범한 종류였습니다. 아무 동작도 하지 않던 연산을 재정의하는 것은 업그레이드되지 않은 소프트웨어에는 보이지 않습니다. 구형 노드는 연산 코드를 실행하고, 아무것도 하지 않은 채, 블록을 그대로 받아들입니다. 활성화에는 당시의 채굴업자 신호 임계값이 사용되었는데, 규칙 적용을 시작하려면 1,000블록 중 750블록이, 의무화하려면 1,000블록 중 950블록이 필요했습니다.
사용되는 곳
OP_CHECKLOCKTIMEVERIFY는 돈이 날짜가 도래할 때까지 그대로 머물러야 하는 모든 곳에 나타납니다.
상속 및 복구 지갑이 가장 분명한 사례입니다. 디스크립터는 자신의 키는 언제든지 지출할 수 있지만 백업 키는 명시된 높이 이후에만 지출한다고 지정할 수 있으며, 이는 상속인에게 누구의 협조도, 봉인된 봉투를 든 변호사도 필요 없는 경로를 제공합니다. Miniscript는 이를 after() 조각으로 작성하며, 이를 지원하는 지갑은 원시 스크립트 대신 높이를 쉬운 말로 보여 줍니다.
라이트닝 네트워크는 라우팅된 결제의 절대 기한에 이를 사용합니다. BOLT11 인보이스에는 최종 만료 델타가 담겨 있으며 기본값은 18블록이고, 경로를 따라 있는 해시 계약들은 그 수치 위에 쌓여서, 결제가 끝내 완료되지 않으면 각 홉이 정해진 순서대로 자금을 되찾을 수 있습니다.
에스크로와 신뢰가 필요 없는 환불도 같은 형태를 따릅니다. 지금 스크립트에 지불하고, 상대방이 끝내 서명하지 않으면 기한이 지난 뒤 돈을 되찾습니다. 이 연산 코드는 “시간 잠금 금고”를 제품으로 파는 사람에게 정직한 답이기도 한데, 그런 제품이 할 수 있는 일이 이것이 전부이기 때문입니다.
OP_CHECKLOCKTIMEVERIFY vs OP_CHECKSEQUENCEVERIFY
OP_CHECKLOCKTIMEVERIFY는 시점을 지정하고, OP_CHECKSEQUENCEVERIFY는 기간을 지정합니다. 하나는 “12월 이전에는 안 됨”이라고 말하고, 다른 하나는 “이 특정 코인이 확정된 뒤 144블록이 지나기 전에는 안 됨”이라고 말하며, 시계가 코인이 도착할 때 시작되는 것은 두 번째뿐입니다. BIP112에서 상대적 형태가 정의되었고 2016년 7월의 블록 419,328에서 활성화되었으며, 이는 절대적 형태의 자매 규격보다 대략 7개월 뒤였습니다. 계약 프로토콜은 둘 다 사용하며, 흔히 하나의 스크립트 안에서 씁니다. 전체 합의의 범위를 정하는 절대 기한과, 한쪽 당사자에게 대응할 시간을 보장하는 상대적 지연입니다.