이 기사는 개별 계약 제안에 대한 심층 분석 시리즈의 두 번째 기사입니다.
브랜든 블랙(Brandon Black)과 제레미 루빈(Jeremy Rubin)이 BIP 348로 제안한 CHECKSIGFROMSTACK(CSFS)은 계약이 아닙니다. 이 시리즈의 첫 번째 기사에서 언급했듯이 제가 다룰 제안 중 일부는 계약이 아니지만, 어떤 방식으로든 계약과 시너지 효과를 내거나 상호 연관됩니다. CSFS는 그 첫 번째 예입니다.
CSFS는 매우 간단한 연산자(opcode)지만, 그것이 어떻게 작동하는지 설명하기 전에 비트코인 스크립트가 실제로 어떻게 작동하는지 기본적인 사항을 살펴보겠습니다.
비트코인 스크립트의 기본 원리
스크립트는 스택 기반 언어입니다. 즉, 데이터가 스택 위에 차례대로 쌓이고, 연산자는 스택의 가장 위에서 항목을 하나씩 꺼내어 작업을 수행합니다. 연산자는 데이터를 반환하거나 결과를 스택의 가장 위에 올려놓습니다.
스크립트가 실행되고 검증될 때 두 가지 요소가 있습니다. 하나는 스크립트를 잠금 해제하는 데 필요한 ‘목격자'(witness)이고, 다른 하나는 소비되는 출력에 포함된 스크립트입니다. 목격자/해제 스크립트는 잠금 스크립트의 왼쪽에 추가되며, 각 요소는 왼쪽에서 오른쪽으로 하나씩 스택에 추가되거나 처리됩니다. 아래 예시를 보세요. (“|”는 목격자와 스크립트의 경계를 나타냅니다.)
1 2 |OP_ADD 3 OP_EQUAL
이 예시에서 스크립트는 값 “1”을 스택에 추가하고, 그 위에 값 “2”를 추가합니다. OP_ADD는 스택에서 가장 위의 두 항목을 더하고 그 결과를 다시 스택에 올려놓습니다 (그래서 스택에 남은 값은 “3”입니다). 그런 다음 또 다른 “3”이 스택에 추가됩니다. 마지막으로 OP_EQUAL은 스택의 가장 위 두 항목을 가져와서 “1” 또는 “0”을 스택에 반환합니다 (1과 0은 True 또는 False를 나타낼 수 있습니다).
스크립트는 마지막 항목이 True일 때 끝나야 하며, 그렇지 않으면 스크립트(및 이를 실행하는 거래)는 실패하고 합의에서 무효로 간주됩니다.
CSFS의 작동 원리
CHECKSIG는 비트코인에서 가장 많이 사용되는 연산자 중 하나입니다. 거의 모든 거래는 그 안의 스크립트 중 하나에서 CHECKSIG을 사용합니다. 서명 검증은 비트코인 프로토콜의 기본적인 구성 요소입니다. 문제는 서명을 확인하는 메시지가 거의 유연성이 없다는 것입니다. CHECKSIG는 검증 중인 거래와 관련된 서명만 확인할 수 있습니다. 어느 정도 자유도가 있기는 하지만, 서명이 검증하는 거래의 일부를 결정할 수 있을 뿐입니다. 그러나 그 외에는 유연성이 없습니다.
CSFS는 서명이 거래 자체에 대한 검증에 제한되지 않고 스택에 직접 푸시된 임의의 메시지에 대해 서명을 검증할 수 있도록 하여 이를 변경하는 것을 목표로 합니다. 이 연산자는 매우 기본적인 작업 구조를 따릅니다:
| CSFS
서명과 메시지가 스택에 추가되고, 그 위에 공개 키(pubkey)가 올려집니다. 그런 다음 CSFS는 스택에서 가장 위의 세 항목(공개 키, 메시지, 서명)을 가져와 서명을 메시지에 대해 검증합니다. 서명이 유효하면 1이 스택에 추가됩니다.
CSFS의 활용
그렇다면 CSFS는 무엇에 유용할까요? 서명을 거래가 아닌 스택 위의 임의의 메시지에 대해 검증하는 것의 장점은 무엇인가요?
우선, CTV와 결합하면 라이트닝 네트워크 개발자들이 처음부터 원했던 기능인, 여러 거래에 붙을 수 있는 플로팅 서명(floating signatures)을 제공할 수 있습니다. 이는 서명에 적용되는 거래의 일부를 결정하는 새로운 sighash 플래그로 제안되었습니다. 이는 거래 서명이 출력이 소비된 거래의 거래 ID를 포함하는데, 이로 인해 서명은 해당 출력이 소비되는 거래에 대해서만 유효합니다.
이것은 라이트닝 네트워크에서 바람직한 동작입니다. 이는 채널 처벌을 없애는 데 도움을 줄 수 있습니다. 모든 과거 라이트닝 상태는 채널 상대방이 소유하지 않은 자금을 주장하려 할 경우 이를 막기 위한 처벌 키와 거래가 필요합니다. 이들이 시도할 경우 모든 자금을 주장할 수 있습니다. 더 우수한 기능은 현재 상태의 거래를 이전 거래에 “붙여” 도난 시도를 막을 수 있는 것입니다.
이것은 CTV 해시와 이를 체크하는 서명을 CSFS를 사용하여 간단한 스크립트를 통해 달성할 수 있습니다. 이를 통해 CSFS 키로 서명된 거래 해시가 이 스크립트를 사용하여 생성된 출력을 소비할 수 있게 됩니다.
또 다른 유용한 기능은 UTXO의 제어 위임입니다. CSFS 키로 서명된 CTV 해시가 특정 스크립트와 함께 UTXO를 유효하게 소비할 수 있다면, 다른 변수들도 스크립트에 전달되어 체크될 수 있습니다. 예를 들어 새로운 공개 키를 전달할 수 있습니다. 스크립트는 CSFS 키가 모든 공개 키에 대해 서명하도록 허용할 수 있으며, 이는 CSFS를 사용하여 검증되고 정상적인 CHECKSIG 검증을 위해 사용될 수 있습니다. 이를 통해 UTXO를 온체인으로 이동하지 않고도 다른 사람에게 소비할 수 있는 권한을 위임할 수 있습니다.
마지막으로, CAT와 결합하여 CSFS는 훨씬 더 복잡한 내부 점검 기능을 만들 수 있습니다. 하지만 이 시리즈에서 나중에 알게 되겠지만, CSFS는 사실 이러한 고급 기능을 구현하기 위해 반드시 필요한 것은 아니며, CAT만으로도 이러한 동작을 에뮬레이트할 수 있습니다.
마지막 생각
CSFS는 매우 기본적인 연산자로, 그 자체로 유용한 기능을 제공할 뿐만 아니라, 가장 간단한 계약 연산자들과도 잘 결합되어 매우 유용한 기능을 만들어낼 수 있습니다. 위에서 언급한 플로팅 서명 예시는 라이트닝 네트워크에 구체적으로 언급되었지만, 플로팅 서명은 비트코인 위에서 구축된 어떤 프로토콜에서도 유용한 원시 기능입니다.
플로팅 서명 외에도 스크립트 위임은 UTXO의 제어를 새로운 공개 키로 위임하는 것 외에도 매우 유용한 원시 기능입니다. 스크립트 검증 흐름에 변수를 나중에 동적으로 추가할 수 있는 동일한 기본 기능은 공개 키에만 해당되지 않고, 타임락 값, 해시락 프리이미지 등 다른 모든 것에 적용될 수 있습니다. 즉, 스크립트가 검증해야 하는 변수를 하드코딩하는 대신, 그 값을 나중에 동적으로 추가할 수 있게 된 것입니다.
더욱이, CSFS는 매우 성숙한 제안입니다. Liquid Network와 그 코드베이스인 Elements에서는 2016년부터 이를 구현해왔으며, Bitcoin Cash는 2018년부터 해당 버전을 사용해왔습니다.
CSFS는 제가 이 공간에 들어온 이후로 거의 같은 시간 동안 존재한 개념적인 제안이며, 여러 개의 성숙한 구현이 있고, 명확한 사용 사례가 적용될 수 있는 제안입니다.