이 글은 개별 계약 제안에 대한 심층 분석을 다루는 시리즈의 두 번째 기사입니다.
CHECKSIGFROMSTACK (CSFS)는 Brandon Black과 Jeremy Rubin이 BIP 348과 함께 제안한 것으로, 계약이 아닙니다. 이 시리즈의 소개 기사에서 언급했듯이, 제가 다룰 일부 제안은 계약이 아니지만 어떤 방식으로든 계약과 시너지 효과를 내거나 상호 연관됩니다. CSFS는 그 첫 번째 예입니다.
CSFS는 매우 간단한 연산 코드(opcode)지만, 어떻게 작동하는지 살펴보기 전에 비트코인 스크립트가 실제로 어떻게 작동하는지 기본 사항을 살펴보겠습니다.
스크립트는 스택 기반 언어입니다. 즉, 데이터가 서로 쌓여서 스택 위에 쌓이고, 연산 코드를 기반으로 스택의 맨 위에서 항목을 제거하여 데이터를 반환하거나 결과를 스택의 맨 위로 가져옵니다.
스크립트가 궁극적으로 실행되고 검증될 때 두 가지 부분이 있습니다. 스크립트를 잠금 해제하는 데 제공되는 “증인(witness)”과 지출되는 출력에 포함된 스크립트입니다. 증인/잠금 해제 스크립트는 잠금 스크립트의 왼쪽에 “추가”되고, 각 요소는 왼쪽에서 오른쪽으로 하나씩 스택에 추가되거나 작동합니다. 다음 예를 살펴보세요(“|”는 증인과 스크립트 사이의 경계를 표시합니다):
1 2 | OP_ADD 3 OP_EQUAL
이 예제 스크립트는 값 “1”을 스택에 추가한 다음 그 위에 값 “2”를 추가합니다. OP_ADD는 스택의 맨 위 두 요소를 가져와 더한 후 결과를 다시 스택에 넣습니다(따라서 현재 스택에는 “3”만 있습니다). 그런 다음 또 다른 “3”이 스택에 추가됩니다. 마지막 항목인 OP_EQUAL은 스택의 맨 위 두 항목을 가져와 “1”을 스택에 반환합니다(1과 0은 True 또는 False를 나타낼 수 있습니다).
스크립트는 스택의 맨 위에 마지막 항목이 True로 끝나야 하며, 그렇지 않으면 스크립트(및 이를 실행하는 트랜잭션)는 실패하고 합의가 무효로 간주됩니다.
다음은 pay-to-pubkey-hash (P2PKH) 스크립트의 기본 예입니다. 즉, “1”로 시작하는 레거시 주소입니다:
<signature> <pubkey> | DUP HASH160 <pubkey-hash> EQUALVERIFY CHECKSIG
먼저 서명과 공개 키가 스택에 추가됩니다. 그런 다음 DUP가 호출되어 스택의 맨 위 항목을 복제하고 이를 스택의 맨 위로 반환합니다. HASH160은 스택의 맨 위 항목(공개 키 복제본)을 가져와 해시한 후 이를 스택의 맨 위로 반환합니다. 스크립트의 공개 키 해시는 스택의 맨 위에 놓입니다. EQUALVERIFY는 EQUAL과 동일하게 작동하며, 두 개의 맨 위 스택 항목을 가져와 결과에 따라 1 또는 0을 반환합니다. 유일한 차이점은 EQUALVERIFY가 EQUAL 후에 VERIFY를 실행하여 맨 위 스택 항목이 1이 아닐 경우 트랜잭션이 실패하고 맨 위 스택 항목을 제거합니다. 마지막으로 CHECKSIG가 실행되어, 맨 위 두 스택 항목을 서명과 공개 키로 가정하고, 서명을 검증합니다. 유효하면 스택의 맨 위에 1을 놓습니다.
CSFS 작동 방식
CHECKSIG는 비트코인에서 가장 많이 사용되는 연산 코드 중 하나입니다. 거의 모든 트랜잭션은 그 스크립트 중 어느 시점에서 이 연산 코드를 사용합니다. 서명 검증은 비트코인 프로토콜의 기본 구성 요소입니다. 문제는, 서명을 검증하는 메시지에 대한 유연성이 거의 없다는 것입니다. CHECKSIG는 검증되는 트랜잭션에 대해서만 서명을 검증합니다. 약간의 유연성은 있지만, 서명이 적용되는 트랜잭션의 일부를 자유롭게 결정할 수 있을 뿐입니다.
CSFS는 서명을 트랜잭션 자체의 검증에 국한되지 않고 스택에 직접 푸시된 임의의 메시지에 대해 검증할 수 있도록 하여 이를 변경하는 것을 목표로 합니다. 이 연산 코드는 매우 기본적인 운영 구조를 따릅니다:
<signature> <message> | <pubkey> CSFS
서명과 메시지가 스택의 맨 위에 추가된 다음, 그 위에 공개 키가 추가되고, 마지막으로 CSFS는 스택에서 맨 위의 세 항목을 가져와 공개 키, 메시지 및 서명으로 가정하고 메시지에 대해 서명을 검증합니다. 서명이 유효하면 스택에 1이 놓입니다.
그게 전부입니다. 사용자가 지출 트랜잭션 대신 임의의 메시지를 지정할 수 있게 해주는 CHECKSIG의 간단한 변형입니다.
CSFS의 유용성
그렇다면 이것은 정확히 무엇에 좋을까요? 스택에서 임의의 메시지에 대해 서명을 검증하는 것이 지출 트랜잭션에 대해 검증하는 것보다 어떤 유용성이 있을까요?
첫째, CTV와 결합하면 라이트닝 개발자들이 처음부터 원했던 기능인 서로 다른 트랜잭션에 첨부할 수 있는 플로팅 서명을 제공할 수 있습니다. 이는 서명이 적용되는 트랜잭션의 일부를 결정하는 새로운 sighash 플래그로 제안되었습니다. 이는 트랜잭션 서명이 지출되는 출력의 트랜잭션 ID를 포함하기 때문에 필요했습니다. 즉, 서명은 그 정확한 출력을 지출하는 트랜잭션에 대해서만 유효합니다.
이것은 라이트닝에서 바라는 동작으로, 채널 벌칙을 없앨 수 있게 해줍니다. 모든 과거 라이트닝 상태는 채널 상대방이 소유하지 않은 자금을 주장하지 못하도록 보장하기 위해 벌칙 키와 트랜잭션이 필요합니다. 그들이 시도하면 당신은 그들의 모든 돈을 주장할 수 있습니다. 더 나은 기능은 현재 상태 트랜잭션을 이전의 트랜잭션에 단순히 “첨부”하여 자금을 압수하는 대신 올바르게 분배하여 도난 시도를 방지할 수 있는 것입니다.
이는 CTV 해시와 그에 대한 서명을 가져와 CSFS를 사용하여 검증하는 기본 스크립트를 통해 달성할 수 있습니다. 이렇게 하면 해당 CSFS 키로 서명된 모든 트랜잭션 해시가 이 스크립트로 생성된 출력을 지출할 수 있게 됩니다.
또 다른 유용한 기능은 UTXO의 제어 위임입니다. CSFS 키로 서명된 모든 CTV 해시가 특정 스크립트로 UTXO를 유효하게 지출할 수 있는 것처럼, 새로운 공개 키와 같은 다른 변수를 스크립트에 전달하여 검증할 수 있습니다. CSFS 키가 모든 공개 키에 서명할 수 있도록 하는 스크립트를 구성할 수 있으며, 이는 CSFS를 사용하여 검증되고 일반 CHECKSIG 검증에 사용될 수 있습니다. 이를 통해 UTXO를 온체인으로 이동하지 않고도 다른 누구에게든 지출할 수 있는 능력을 위임할 수 있습니다.
마지막으로, CAT와 결합하면 CSFS는 훨씬 더 복잡한 내재적 기능을 구성하는 데 사용될 수 있습니다. 그러나 시리즈 후반부에서 볼 수 있듯이, CSFS는 이러한 고급 동작을 에뮬레이트하는 데 실제로 필요하지 않으며, CAT만으로도 가능합니다.
마무리 생각
CSFS는 기본적인 연산 코드로, 그 자체로 간단하고 유용한 기능을 제공할 뿐만 아니라 가장 간단한 계약 연산 코드와도 잘 결합되어 매우 유용한 기능을 생성합니다. 플로팅 서명에 관한 위의 예는 라이트닝 네트워크를 특별히 언급하지만, 플로팅 서명은 비트코인 위에 구축된 모든 프로토콜에 적용 가능한 일반적으로 유용한 원시입니다.
플로팅 서명 외에도 스크립트 위임은 UTXO에 대한 제어를 새로운 공개 키로 위임하는 것 이상으로 일반화된 매우 유용한 원시입니다. 스크립트 검증 흐름에 후속적으로 변수를 “사이드로드”하는 동일한 기본 능력은 공개 키뿐만 아니라 모든 것에 적용될 수 있습니다. 타임락 값, 해시락 프리이미지 등. 이제 변수를 검증하기 위해 하드코딩한 모든 스크립트는 그 값이 동적으로 추가될 수 있습니다.
게다가, CSFS는 매우 성숙한 제안입니다. 2016년부터 Liquid Network와 Elements( Liquid가 사용하는 코드베이스)에서 실시간으로 구현되었습니다. 또한 비트코인 캐시는 2018년부터 그 버전을 가지고 있습니다.
CSFS는 제가 이 분야에 있는 거의 모든 기간 동안 개념적으로 존재해온 매우 성숙한 제안으로, 여러 성숙한 구현과 적용 가능한 매우 명확한 사용 사례가 있습니다.
