용어집 / 프로토콜과 업그레이드
OP_CHECKSEQUENCEVERIFY
별칭은 CSV, BIP112입니다.
- OP_CHECKSEQUENCEVERIFY란 무엇입니까?
- OP_CHECKSEQUENCEVERIFY는 코인의 자체 확정 시점부터 측정한 일정 기간 동안 코인을 잠그며, 입력이 충분히 기다리지 않은 지출은 실패시킵니다.
BIP-112에 명시되어 있습니다.
이 옵코드는 스택에서 숫자를 읽어 지출되는 입력의 시퀀스 필드와 비교합니다. 따라서 시계는 달력상의 날짜가 아니라 코인이 블록에 들어온 시점에 시작됩니다. BIP-112가 이를 정의했고, 네트워크는 2016년 7월 4일 블록 419,328에서부터 이를 시행하기 시작했습니다. 열게 되는 모든 라이트닝 채널이 이에 의존합니다.
작동 방식
옵코드 178은 예전에 OP_NOP3이었고 아무 일도 하지 않았습니다. 그래서 이 규칙은 체인 분열이 아니라 소프트 포크로 네트워크에 도달했습니다.
검사는 세 가지 입력을 기준으로 실행됩니다. 스택의 숫자, 지출되는 입력의 시퀀스 필드, 그리고 트랜잭션의 버전입니다. 버전 2 이상이 필요합니다. BIP-68의 상대적 타임락 규칙은 그 버전부터만 적용되기 때문입니다. 두 값 중 어느 하나의 최상위 비트가 설정되어 있으면 타임락은 해제되고 옵코드는 그냥 포기합니다. 그렇지 않으면 두 값은 단위에서 일치해야 하고 스택 값은 시퀀스 필드를 넘지 않아야 합니다.
단위는 두 가지 형태이고 한 번의 비교에서 섞을 수 없습니다. 특정 플래그를 해제하면 숫자는 블록을 세고, 설정하면 숫자는 512초 간격을 셉니다. 어느 쪽이든 16비트를 쓸 수 있으므로 상한은 65,535 블록, 대략 455일이거나, 같은 수의 512초 간격으로 389일을 조금 밑도는 값입니다. 그보다 긴 기간에는 대신 절대적 타임락이 필요합니다.
실패는 지연이 아니라 거부입니다. 대기 기간이 끝나기 전에는 그 지출이 대기열에 남아 있는 대기 트랜잭션이 아니라, 어떤 노드도 중계하지 않고 어떤 채굴업자도 포함하지 않을 무효 트랜잭션입니다. 코인이 충분히 오래될 때까지 다시 시도할 필요가 없으며, 그 시점에 동일한 트랜잭션이 유효해집니다.
볼 수 있는 곳
라이트닝은 거래량 기준 최대 사용처이며, 이 옵코드는 모든 채널에서 자신의 측 잔액을 보호하는 스크립트에 들어 있습니다.
채널이 일방적으로 닫히면, 닫는 측의 잔액은 지연이 지나기 전에는 옮길 수 없는 출력으로 들어갑니다. 이는 BOLT 3의 to_self_delay이며, 보통 수백 블록입니다. 지연이 있는 이유는 상대 피어가 철회를 게시하고, 닫기가 오래된 상태를 사용했다면 자금을 가져갈 수 있는 창을 주기 위해서입니다. 어느 경우든 자금은 안전하지만, 이런 이유로 강제 종료는 하루 이상 기다리게 하는 반면 협력적 종료는 즉시 지급됩니다.
같은 구조는 잠수함 스왑과 원자적 스왑에도 나타납니다. 여기서는 상대방이 청구할 공정한 기회를 가진 뒤에만 환불 경로가 열려야 합니다. 또한 복구 지갑에서도 나타나며, 이때는 오랜 침묵 뒤에 백업 키가 사용 가능해집니다.
한 가지 함정은 경고할 만합니다. 상대적 타임락은 지출되는 특정 코인의 확정 시점부터 측정되므로, 그 코인이 움직일 때마다 다시 시작됩니다. 더스트 출력을 통합하거나 잔돈을 쓸어 담거나 지갑이 출력을 재배치하게 하면 설정해 둔 모든 복구 분기의 카운트다운이 초기화되며, 다음 달에 백업 키가 작동하리라 기대한 상속인은 시계가 다시 0으로 돌아간 것을 발견할 수 있습니다.
OP_CHECKSEQUENCEVERIFY vs OP_CHECKLOCKTIMEVERIFY
CSV는 코인이 얼마나 오래 존재했는지를 묻고, CLTV는 지금이 몇 시인지를 묻습니다. 두 옵코드는 번호상 나란히 있으며 178과 177이고, 아주 다른 작업에 선택됩니다.
기한이 실제 날짜일 때는 절대적 형태를 사용합니다. 2030년에 잠금이 해제되는 신탁, 알려진 높이에서 만료되는 환불 같은 경우입니다. 대기가 계약이 시작될 때마다 시작되어야 할 때는 상대적 형태를 사용하며, 한 번 작성해 여러 번 재사용하는 스크립트라면 이것이 필요합니다. 라이트닝은 채널 지연에 절대적 타임락을 쓸 수 없었습니다. 오늘 연 채널과 내년에 연 채널은 서로 다른 스크립트가 필요하기 때문입니다. 두 옵코드는 몇 달 간격으로 도착했습니다. CLTV는 2015년 12월 14일 블록 388,381에, CSV는 그다음 해 7월에 왔으며, 두 번째가 존재한 큰 이유는 첫 번째만으로는 결제 채널을 만들기에 충분하지 않았기 때문입니다.