저자: gangzhu 함께하기: X, @bangzhu_x
제한 조항 제안으로서의 OP_CAT의 이해
op. _cat을 제한 조항 제안으로 이해하며, 최근 BIP 번호 347을 받았습니다. 먼저 '제한 조항(규약)'이 무엇인지 이해해 보겠습니다.
1. 현재 존재하는 비트코인 스크립트의 근본적인 한계를 이해하는 것부터 시작하겠습니다. 표면적으로 비트코인은 자금 잠금 및 잠금 해제 규칙을 정의하는 코드인 기본적인 스마트 컨트랙트를 생성할 수 있습니다. 그러나 프로그래밍 언어인 비트코인 스크립트는 매우 제한적이며 트랜잭션이 자금을 이동할 때만 작동합니다.
2. 현재 비트코인에서는 코인의 전송 경로를 미리 구성하거나 지정할 방법이 없으며, 잠글 때 금액을 인출할 수 있는 속도를 제한할 수도 없습니다(PSBT(서명된 비트코인 거래 대기 중)를 기반으로 하는 비 전통적인 워크플로우를 사용하지 않는 한, 이는 잘 처리되지 않습니다). 거래 수수료가 발생하거나 더 이상 사용하지 않기로 결정했을 때 생방송을 안정적으로 제거 및 차단할 수 없습니다). 이러한 단순성은 비트코인 보안 모델의 핵심이지만, 스크립트와 같은 스크립팅 언어가 (심지어 기본적인) 스마트 컨트랙트를 지원하는 데에는 여전히 상당한 제약이 있습니다. 선형 실행 모델.
선형 실행 모드
1. 비트코인 스크립트의 한계 중 하나는 작동 모드에 있습니다: 연산자는 순차적으로 실행되고 루프가 없습니다.
이 P2PKH 거래를 예로 들면, 공개 키를 복사하고, 공개 키를 주소에 해시하고, 해시가 잠금 스크립트와 일치하는지 확인한 다음, 마지막으로 해당 공개 키와 거래 서명을 확인하는 등 스크립트가 선형적으로 실행되는 것을 볼 수 있습니다. 루프가 없다는 것은 스크립트가 튜링 완전하지 않고 종료가 보장되지 않는다는 것을 의미하며, 노드를 다운시키거나 전체 네트워크 속도를 크게 저하시킬 수 있는 무한 반복 연산을 방지할 수 있습니다. 이러한 설계 선택으로 리소스 소비를 정적으로 제한할 수 있지만, 복잡한 워크플로를 관리하는 스크립트의 기능도 제한됩니다.
2. 기본 연산 부족 비트코인 스크립트에는 100개 미만의 중요한 연산 코드가 있는데, 이는 스택의 객체를 곱하기, 나누기, 결합할 수 없다는 점에서 의외로 놀랍습니다. OP_CAT에 관심이 있는 많은 사용자가 알다시피, 사토시 나카모토는 2010년에 OP_OR, OP_MUL(곱하기), OP_DIV(나누기), OP_CAT(문자열 연결)을 포함한 비트코인의 여러 연산 코드를 비활성화했습니다. 이러한 비활성화된 옵코드는 원래 구현에 악용될 수 있는 취약점이 있어 네트워크의 보안을 위협할 수 있기 때문에 제거되었습니다. 그러나 이러한 옵코드가 없으면 스크립트에서 기본적인 수학 연산을 수행하기 어렵기 때문에 컨트랙트의 거래 수수료 계산과 같은 간단한 시나리오에서는 유용할 수 있습니다.
3. 트랜잭션 데이터를 볼 수 없음대부분의 사람들은 비트코인의 스마트 콘트랙트는 블록체인에 정보가 공개되어 있기 때문에 거래 금액과 데이터의 다른 부분도 볼 수 있을 것이라고 생각하곤 합니다. 하지만 비트코인 스크립트의 거래 데이터 이해 능력은 매우 제한적이기 때문에 비트코인의 컨트랙트는 거래 데이터를 기반으로 지출 조건을 설정할 수 없습니다. 스크립트가 거래 데이터에서 더 많은 세부 사항을 파악할 수 있다면, 특정 지출 조건 적용, 단계적으로 실행되는 거래 생성, 고급 안전 보관 기능(예: "안전 보관 계약(볼트)") 활성화 등 흥미로운 현실을 모두 수행할 수 있는 훨씬 더 강력한 스마트 콘트랙트를 개발할 수 있을 것입니다. ").
4. 어떻게 할 것인가심플리시티 언어 등 비트코인 스크립트에 대한 보다 전위적인 실험은 스택 형태의 제약에 대한 대안을 제공하기 위해 노력합니다. OP_MULTISHA256, OP_LESS, OP_LE32TOLE64와 같은 연산 코드는 비트코인의 연산 능력을 업그레이드하는 것을 목표로 하며, OP_CTV, OP_CAT과 같은 내성적인 연산 코드를 다루는 제안은 "제약"으로 분류됩니다. 그렇다면 "스마트 콘트랙트"와 "제한 조항"의 차이점은 무엇일까요?
5. 스마트 콘트랙트와 제한 조항스마트 콘트랙트는 중개자 없이 자금을 이체하는 자체 실행형 거래입니다. 오늘날의 비트코인에서 스마트 콘트랙트는 비트코인 스크립트를 사용해 비트코인을 잠그고 잠금 해제하는 것으로 제한됩니다. 이러한 제한은 사용자가 향후 거래에서 자금이 어떻게 사용되는지 제어할 수 있도록 함으로써 비트코인의 스마트 콘트랙트 기능을 강화하기 위한 것입니다. 스크립트가 트랜잭션 데이터를 인트로스펙트할 수 있도록 허용함으로써 본질적으로 해당 데이터를 계약 로직에 사용할 수 있도록 허용하는 것입니다. 다음은 약관의 기능을 제한하기 위해 제안된 몇 가지 흥미로운 인트로스펙션 코드 목록입니다.
OP_TXHASH: 트랜잭션 입력(또는 출력)의 해시를 제공하고 스크립트가 트랜잭션 데이터를 기반으로 조건을 검증하고 시행할 수 있는 기능을 제공합니다.
OP_CSFS + OP_CAT: 이 두 개의 옵코드를 사용하면 스크립트가 트랜잭션 자체뿐만 아니라 임의의 데이터에 대한 서명을 확인할 수 있습니다. 즉, 스크립트가 트랜잭션 데이터와 외부 정보를 기반으로 조건을 확인할 수 있으며, 이는 비트코인 스크립트 내에서 확인 작업의 가능성을 확장합니다.
이 두 가지 옵코드는 의도적으로 광범위하게 설계되었기 때문에 복잡한 검증 프로세스와 내성 검사 기능을 지원할 수 있습니다. 다른 코드는 의도적으로 좁고 더 제한적인 제약 조건으로 설계되었습니다.
OP_CHECKTEMPLATEVERIFY(CTV): 거래의 출력을 후속 지출 거래의 템플릿에 포함할 수 있어 보다 제한적인 제약 조건을 적용할 수 있습니다.
OP_VAULT: 사용자가 트랜잭션의 목적지를 지정할 수 있지만 시간 지연이 끝날 때까지 실제로 자금을 이동할 수 없도록 하는 안전 계약에 특정한 제한을 활성화합니다.
인트로스펙션 기능을 활성화하기 위해 직접적인 옵코드가 아닌 OP_CAT도 있습니다 ......OP_CAT: 스크립트에서 스택의 두 요소를 앞뒤로 연결할 수 있으며, 스크립트의 정보 조각을 결합하는 데 사용할 수 있습니다.
OP_CAT: 모든 가능성을 열어줍니다 비트코인 스크립트에서 트랜잭션 데이터를 인트로스펙트할 수 있는 주요 옵코드는 크게 세 가지뿐입니다: CHECKLOCKTIMEVERIFY,
OP_CAT: 모든 가능성을 열어줍니다 비트코인 스크립트에서 트랜잭션 데이터를 인트로스펙트할 수 있는 주요 옵코드는 크게 세 가지뿐입니다. 왼쪽;">CHECKSEQUENCEVERIFY(상대 시간 잠금), CHECKSIG(확인 서명)입니다.
또한 CHECKSIG의 미니 변형인 CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG 및 CHECKMULTISIGVERIFY와 같은 변형이 있습니다. 는 수표가 통과하는지 여부를 확인할 수 있고 매우 좁은 기능만 제공하며, CHECKSIG는 비슷하지만 스택에서 서명과 공개 키를 가져올 수 있다는 차이점이 있습니다.
이전에는 연결이 두 요소를 분할하는 함수라고 이해했지만, 서명을 (r, s) 쌍으로 분할하는 등 요소를 분할하는 데에도 사용할 수 있습니다.
OP_CAT(연결)에서 OP_SPLIT 함수를 어떻게 파생할 수 있을까요? "부피가 큰 객체가 있는 경우 사용자에게 두 조각을 모두 비용으로 제공하도록 요청하여 객체를 반으로 나눌 수 있습니다. 이 두 조각을 CAT한 다음 동일성을 확인할 수 있습니다. 모든 작업은 이런 식으로 되돌릴 수 있습니다. CAT를 사용하면 서명을 반으로 나눌 수 있습니다."
어떻게 진행되나요? 사용자가 먼저 서명, 공개 키, 서명할 트랜잭션을 제공하면 서명을 반으로 분할한 다음 트랜잭션 데이터로 각 부분을 개별적으로 확인할 수 있습니다. 이 기술은 서명과 공개 키가 유효한 트랜잭션의 일부인지 확인하기 때문에 분할 또는 스플라이스로 볼 수 있습니다. (번역자 주: 여기서 "데이터를 반으로 나눌 수 있다"는 말은 스크립트 실행 시 데이터를 두 조각으로 나눌 수 있다는 뜻이 아니라, 두 개의 데이터를 감시 데이터로 별도로 전달한 다음 CAT를 사용하여 함께 연결한 다음 전체 데이터에서 실행할 수 있는 검사를 실행할 수 있다는 뜻입니다. 이 접근 방식을 사용하면 두 데이터 세그먼트를 전달하기 전에 추가 검사를 실행할 수 있습니다.) 이것이 인트로스펙션과 어떤 관련이 있을까요? "탭루트에는 이미 슈노르 서명이 있습니다. OP_CAT과 슈노르 서명을 사용해 옵코드를 검증하면 비재귀적 제한 조항, 즉 트랜잭션의 해시를 실제로 얻을 수 있다는 것이 입증되었습니다. 우연히 덧칠한 거래의 해시가 아니라 스택에 있는 모든 거래 데이터의 SHA2 해시입니다."
스택에 있는 나머지 트랜잭션 입력 또는 출력의 SHA2 해시를 구하는 방법. 마법의 수학은 생략하겠지만, 여기서는 OP_CAT을 사용하여 트랜잭션의 특정 부분에 대한 제약 조건을 잠금 해제 스크립트의 요구 사항으로 만들었습니다. 송금인의 주소나 송금할 금액을 제한할 수 있으며, 트랜잭션의 해시가 자금 잠금을 해제하는 열쇠 역할을 하게 됩니다.
세이프
같은 트릭을 사용하면 거래 내사를 통해 기본적인 종류의 안전한 계약을 즉시 얻을 수 있습니다. 포엘스트라가 기사에서 설명한 추론의 연장선상에서 Rijndael이라는 개발자는 OP_CAT만으로 퍼펙트 볼트("완벽한 금고")를 구현할 수 있음을 보여주었습니다.
사용자는 자금이 다음에 이동할 주소를 지정할 수 있으며, 이는 키가 손상된 경우 자금을 복구하는 메커니즘을 제공하여 개인 키를 훔치려는 유인을 줄여줍니다.
스크립트 내 메르켈 트리
현재 비트코인에서는 데이터 구조인 "메르켈 트리"가 데이터 검증, 동기화, 그리고 다음과 같은 용도로 사용됩니다. 트랜잭션과 블록을 특정 의미에서 "바인딩"하는 데 사용됩니다. 반면 OP_CAT은 스택에서 두 개의 변수를 연결할 수 있으며, 공개 키의 SHA256 해시와 함께 사용하면 간단한 메르켈 트리 검증 절차를 스크립트에서 구현할 수 있습니다. 이 접근 방식은 2015년에 Pieter Wuille이 처음 제안한 것으로, Liquid에서 구현되었습니다.
트리 서명
공개 키의 수에 따라 대수적으로 크기가 정해지고, n 대 m 이상의 지출 조건을 인코딩할 수 있는 멀티서명 스크립트를 제공합니다. 예를 들어, 1KB보다 작은 트랜잭션은 1000개의 공개 키로 트리 서명을 지원할 수 있습니다. 또한 지출 조건의 논리적 일반화도 가능합니다.
재귀적 제한지출 조건
재귀적 제한
거래를 디코딩하고 특정 부분에 제약을 가할 수 있다면 여러 조건에 걸쳐 연속되는 조건, 즉 연속된 제약의 체인을 만들 수 있습니다. 이 개념을 "재귀적 제약 조건"이라고 합니다.
OP_CAT은 단 10줄의 코드만으로 강력한 기능을 제공하기 때문에 독특한 프로토콜입니다. 트랜잭션 데이터 가시성, 더 나은 수학 기능, 선형 실행 모델 등 앞서 언급한 모든 한계를 해결할 수 있습니다. OP_CAT은 언뜻 평범해 보일 수 있지만, 창의적으로 활용할 수 있는 엄청난 잠재력을 가지고 있습니다. 또한 양자 컴퓨팅에 강한 램포트 서명과 같이 이 글의 범위를 벗어난 더 많은 기능을 위한 브리콜라주로도 사용할 수 있습니다.
안전한가요?
OP_CAT이 처음 제거되기 전에 OP_DUP(스택 복사)과 함께 스택에서 처음 조작된 객체가 1바이트에 불과하더라도 이 옵코드 쌍을 반복적으로 적용하면 스택 객체의 크기가 메모리가 터질 때까지 급속히 확장될 수 있습니다. 이는 DoS 공격으로 사용될 수 있습니다. 새로운 제안은 스택 요소에 520바이트 제한을 부과하여 이 공격을 쉽게 방지합니다.
무기한으로 실행되는 컨트랙트를 생성할 위험이 있나요?
이 질문이 스크립트의 선형 실행 모델로 변경되면 스크립트가 더 이상 리소스 사용량을 정적으로 제한할 수 없는지(스크립트 볼륨의 선형 함수가 되는지)를 의미한다면, 대답은 '아니요'입니다.
제한 조항으로 인해 비트코인에서 다른 코인을 발행할 수 있는 시장이 생길까요?
재귀형 제한 조항이 있다면 기술적으로는 NFT, 탈중앙화 거래소, 전자 고양이 등을 포함한 복잡한 레이어 2 앱을 개발할 수 있습니다. 하지만 만들기는 쉽지 않습니다. 이것이 어떻게 상당한 규모의 시장을 창출할지 알기 어렵습니다.
캣으로 재산을 영구적으로 '오염'시킬 수 있을까요?
다이드 코인과 NFT의 경우, 자산을 발행하면 실제로 사토시를 "소각"하여 "레이어 2" 자산의 소유권을 상징하는 표시를 하게 됩니다. 이 과정을 "테인팅"이라고 합니다. 그러나 화폐의 소유자만이 자신의 화폐를 표시할 수 있으며, 비트코인의 지갑은 이를 이해할 수 없습니다(개발자가 이를 활성화하기 위해 추가 코드를 추가하지 않는 한). 결국 비트코인 지갑에서도 코인을 받을 수 없습니다. 전자 고양이 지갑 같은 곳에서는 허용될 수도 있지만, 대다수의 비트코인 사용자와는 무관한 일입니다.
비트코인에 MEV 문제를 일으킬까요?
비트코인과 이더리움의 주요 차이점 중 하나는 거래의 가시성입니다. 이더와 달리 비트코인에서는 계약의 모든 측면이 반드시 투명하지는 않기 때문에 비트코인 채굴자는 이더 채굴자와 마찬가지로 계약의 내부 상태를 확인하고 특정 작업을 선제적으로 수행할 수 없습니다.
OP_CAT의 주요 관심사는 경제적 인센티브에 영향을 미쳐 "채굴자 추출 가능 가치(MEV)"를 초래할 수 있다는 점입니다. 지난 포스팅에서 이 주제에 대해 자세히 설명했습니다. 많은 사용자들이 우려하는 것은 레이어 2 콘트랙트를 기술적으로 가능하게 만들면 필연적으로 MEV가 발생한다는 것입니다.
그렇지만 정말 그럴까요? 구체적으로 비트코인에서 레이어 2 코인을 발행할 수 있다면, 이는 레이어 2 코인이 반드시 채택될 것이라는 의미일까요? 간단한 스왑 계약이나 상대적으로 비효율적인 NFT를 개발할 수는 있지만, 자동화된 시장 조성자가 있는 탈중앙화 거래소를 개발하는 것만큼 복잡한 일은 거의 불가능에 가깝고, "기술적으로 실현 가능"함에도 불구하고 Liquid에서 이와 같은 개발 사례를 본 적이 없습니다.
OP_CAT은 비교적 완벽한가요?
"치료론자"라고 할 수 있는 비트코인 사용자 중 일부는 비트코인을 현재 상태로 유지하는 것을 지지하며 프로토콜 업그레이드에 회의적인 입장을 취하고 있습니다. 이들은 특히 제한 조항의 도입과 같은 중대한 변화가 네트워크의 탈중앙화를 약화시킬 수 있다고 우려합니다. 이들은 비트코인의 원래 비전을 고수하는 것이 최선이라는 신념을 바탕으로 지지하고 있습니다.
아이러니한 점은 OP_CAT이 오리지널 비트코인의 일부였기 때문에 완전히 정반대의 의견이 나온다는 것입니다. 어떤 이들은 OP_CAT을 되살리는 것이 사토시 나카모토의 원래 비전에 더 부합한다고 생각합니다.
재귀적 제한 조항과 함께 제공되는 일부 안전 기능을 원한다면 OP_CAT도 좋지만, 본격적인 Lisp 스타일의 스크립팅 언어만큼은 아닙니다. 문제는 그런 것을 도입하는 것은 큰 변화이며, 조만간 인기를 얻기는 어려울 것이라는 점입니다. 아니면 반대편에 있는 사람이라면 OP_CTV나 OP_VAULT와 같은 비재귀적 제한 절의 단순함을 선호할 수도 있습니다.
비재귀 제한 절은 제어되지 않는 제한 사슬을 만들 위험 없이 더 간단하고 분석하기 쉽습니다. 하지만 어떤 형태의 재귀 제한 절이 나타날 수밖에 없다면 어떻게 해야 할까요? 지난 몇 년 동안 개발자들은 트랜잭션 유효성 검사 로직의 거의 모든 확장을 사용해 OP_CAT의 기능을 에뮬레이션할 수 있다는 사실을 알게 되었습니다. 스크립트 세계에는 스택 요소의 크기에 따라 나눌 수 있는 두 가지 세계가 있습니다. 4바이트보다 큰 요소의 경우, 동일성을 검사하고 공개 키 또는 서명으로 디코딩한 후 해싱할 수 있습니다. 4바이트보다 작거나 같은 요소의 경우 연산을 수행할 수 있습니다. BitVM에서 실행되는 RISC-V 프로세서를 사용하면 무엇이든 할 수 있습니다. 스택 요소를 분할하거나 스티칭하는 등 OP_CAT 기능을 에뮬레이트할 수 있는 모든 것이 이 두 세계를 병합하여 스크립트에서 "무엇이든 할 수 있게" 해줍니다.
앤드류 포엘스트라 같은 일부 연구자들은 아주 적은 수의 새로운 옵코드로 재귀형 제한을 만들 수 있을 것으로 예상합니다. 이것이 사실이라면, 이를 위한 최선의 방법을 찾아내야 할 필요가 있습니다. OP_CAT이 통과될 가능성이 가장 높은 제한 조항 제안인가요?
OP_CAT은 여전히 제한 조항 논쟁에서 강력한 경쟁자입니다. OP_CAT은 가장 우아한 도구는 아니지만, 기능 대비 복잡성 비율이 가장 높기 때문에 개발자들이 놀라운 새로운 기능을 만들 수 있게 해줄 것입니다. BTC의 미래를 위한 더 많은 가능성.