언약 살펴보기: 비트코인에 네이티브 프로그래밍 기능을 도입하는 방법

제프리 후 & 하퍼 리, 해시키 캐피탈

최근 비트코인 커뮤니티에서 비트코인에 대한 논의의 물결이 일고 있습니다. OP_CAT과 같은 옵코드 재 활성화. 탭루트 마법사는 퀀텀 캣용 NFT를 출시하고, BIP-420 번호를 획득했다고 주장하는 등 많은 관심을 끌었습니다. 지지자들은 OP_CAT을 활성화하면 비트코인에 대한 '언약', 스마트 컨트랙트 또는 프로그래밍이 가능하다고 주장합니다.

'제한적 언약'이라는 용어를 발견하고 검색을 조금만 해보면 이것이 또 다른 큰 토끼굴이라는 것을 알 수 있습니다. 개발자들은 수년 동안 이에 대해 이야기해 왔으며, 제한 조항을 구현하는 데는 OP_CAT 외에도 OP_CTV, APO, OP_VAULT 및 기타 기술이 있습니다.

그렇다면 비트코인의 '제한 조항'이란 정확히 무엇일까요? 왜 수년 동안 많은 개발자들의 관심과 논의를 끌어온 것일까요? 비트코인은 어떤 프로그래밍이 가능한가요? 그 이면의 설계 원칙은 무엇일까요? 이 글은 이에 대한 개요와 논의를 제공하고자 합니다.

'제한'이란 무엇인가요

중국어로 '제한적 언약' 또는 때로는 '계약'으로 번역되는 언약은 향후 비트코인 거래에 조건을 설정할 수 있는 메커니즘입니다.

현재 비트코인 스크립트에도 지출 시 합법적인 서명 입력, 준수하는 스크립트 전송 등과 같은 제한 조건이 포함되어 있습니다. 하지만 사용자가 잠금을 해제할 수만 있다면 원하는 곳 어디에서든 UTXO를 사용할 수 있습니다.

제한은 UTXO를 잠금 해제하는 방법에 대한 제한이기도 하지만, UTXO를 사용한 후 사용할 수 있는 금액, 즉 '귀속' 효과와 같은 것을 얻기 위해 UTXO를 사용한 후 사용할 수 있는 금액 또는 단일 거래에 대해 전송할 수 있는 다른 입력을 제한하는 것과 같은 잠금 해제 방식에 대한 제한이기도 합니다. 트랜잭션에 공급되는 조건 등입니다. 궁극적으로 비트코인 스크립트에 제한을 직접 구현하여 트랜잭션의 추가 지출을 제한함으로써 스마트 콘트랙트의 효과와 유사한 트랜잭션 규칙을 구현할 수 있습니다.

더 엄밀히 말하면, 현재 비트코인 스크립트에는 트랜잭션의 nLock 또는 nSequence 필드를 내성적으로 검사하여 트랜잭션이 소비되기까지의 시간을 제한하는 옵코드 기반 시간 잠금과 같은 몇 가지 제한이 있지만 대부분 시간 제약에 한정되어 있습니다.

그렇다면 개발자와 연구자들은 왜 이러한 제한 검사를 설계할까요? 제한은 단순히 제한을 위한 제한이 아니라 트랜잭션이 실행되는 규칙을 설정하기 때문입니다. 이렇게 하면 사용자는 미리 설정된 규칙에 따라서만 트랜잭션을 실행할 수 있으므로 의도한 비즈니스 프로세스를 완료할 수 있습니다.

반직관적이지만 더 많은 애플리케이션 시나리오를 활용할 수 있습니다.

약정 적용 시나리오

스태킹 페널티 보장!

제한 조항의 가장 직관적인 예 중 하나는 비트코인 스테이킹 과정에서의 바빌론의 슬래시 트랜잭션입니다. align: left;">-행복한 결말: 일정 시간이 지나면 사용자가 서명을 통해 잠금을 해제할 수 있으며, 즉 스테이킹 해제 과정이 완료됩니다

-나쁜 결말: 사용자가 서명을 통해 잠금을 해제할 수 있습니다. 끝: 사용자가 바빌론에서 보안을 임대하는 지분증명 체인에 이중 서명하는 경우, 해당 자산의 일부는 EOTS(추출 가능한 일회용 서명)를 통해 잠금 해제될 수 있으며, 자산의 일부는 네트워크의 실행 역할에 의해 강제로 레코딩 주소(슬래시)로 전송될 수 있습니다. 소각 주소(슬래시)로 전송

(출처: 비트코인 스테이킹: 지분 증명 경제를 보호하기 위한 2100만 비트코인의 잠금 해제)

< 여기서 '강제 전송'에 주목하세요. 즉, 이 UTXO를 잠금 해제할 수는 있지만 자산을 임의로 다른 곳으로 보낼 수 없으며 소각할 수만 있다는 뜻입니다. 이를 통해 악의적인 사용자가 처벌을 피하기 위해 자신의 서명으로 자산을 미리 자신에게 전송할 수 없도록 합니다.

이 기능은 스테이킹 스크립트의 "나쁜 결말" 브랜치에 OP_CTV와 같은 옵코드를 추가하여 구현할 수 있습니다.

OP_CTV가 활성화되기 전에는 사용자 + 위원회가 함께 작동하여 제한을 적용하는 효과를 시뮬레이션할 수 있는 해결 방법이 필요했습니다.

혼잡 제어

일반적으로 혼잡이란 네트워크에 높은 수수료가 발생하고 많은 수의 트랜잭션이 풀에서 패키징되기를 기다리는 상황을 말합니다. 패킹하는 것을 의미하므로 사용자가 트랜잭션을 빠르게 확정하려면 수수료를 인상해야 합니다.

그러나 사용자가 여러 수취인에게 여러 트랜잭션을 보내야 하는 경우 수수료를 올려야 하고 비용이 더 많이 발생합니다. 이는 또한 전체 네트워크의 수수료율을 상승시킵니다.

한 가지 해결책은 제한이 있는 경우 발신자가 단일 대량 전송 트랜잭션에 커밋하는 것입니다. 이 커밋은 모든 수신자에게 최종 거래가 진행될 것이며, 특정 거래를 보내기 전에 수수료율이 낮아질 때까지 기다리면 된다는 확신을 줄 수 있습니다.

아래 그림과 같이 블록 공간에 대한 수요가 많으면 트랜잭션을 만드는 데 매우 많은 비용이 듭니다. 대량 결제 처리자는 OP_CHECKTEMPLATEVERIFY를 사용하여 모든 결제를 O(1)의 복잡도를 가진 단일 트랜잭션으로 통합하여 확인할 수 있습니다. 그런 다음 블록 공간에 대한 수요가 줄어든 일정 시간이 지나면 해당 UTXO에서 결제를 확장할 수 있습니다.

(출처: https )

이 시나리오는 OP_CTV 제한의 가장 일반적인 적용 사례 중 하나입니다. 더 많은 사용 사례는 https://utxos.org/uses/ 위에서 언급한 혼잡 제어 외에도 이 페이지에는 소프트 포크 베팅, 탈중앙화 옵션, 드라이브체인, 배치 채널, 비대화형 채널, 신뢰 없는 조정이 필요 없는 마이닝 풀, 볼트, 더 안전한 해시된 시간 고정 콘트랙트(HTLCS) 한도 등이 있습니다.

볼트

볼트는 특히 한도 영역에서 가장 널리 논의되는 비트코인 적용 시나리오 중 하나입니다. 일상적인 작업에는 필연적으로 자금을 안전하게 보관해야 할 필요성과 자금을 사용해야 할 필요성의 균형이 필요하기 때문에, 사람들은 자금을 안전하게 보관하고 계정이 해킹(개인 키 손상)되더라도 사용을 제한할 수 있는 애플리케이션인 일종의 볼트 애플리케이션을 원합니다.

사용 제한 조항을 구현하는 기술을 기반으로 비교적 쉽게 보관소 앱 클래스를 구축할 수 있습니다.

OP_VAULT 설계 솔루션을 예로 들면: 볼트에 자금을 사용하려면 먼저 트랜잭션을 체인 위로 전송해야 합니다. 이 트랜잭션은 볼트를 사용하겠다는 의사, 즉 '트리거'를 나타내며 조건이 설정되어 있습니다.

모든 것이 정상이라면 두 번째 트랜잭션이 결국 자금을 인출할 트랜잭션이 됩니다. N 블록을 기다린 후 자금은 어디에서나 더 사용할 수 있습니다

이 거래가 도난당한(또는 '스패너 공격' 중에 강제로 이루어진) 것으로 밝혀지면 N 블록의 인출 거래가 전송되기 전에 즉시 다른 보안 주소(사용자에게 더 안전한 보관)로 전송할 수 있습니다

(OP_VAULT의 프로세스, source. : BIP-345)

제한 조항 없이 볼트 애플리케이션을 구축할 수 있으며, 이를 위한 실행 가능한 방법은 개인 키를 사용하여 나중에 사용할 서명을 준비한 다음, 개인 키를 파기하는 것임을 유의해야 합니다. 개인 키를 파기하는 것입니다. <하지만 개인키가 파기되었는지 확인해야 하고(영지식 증명의 신뢰 설정 과정과 유사), 사전 서명으로 인해 금액과 수수료를 미리 결정할 수 있는 유연성이 부족하다는 등의 한계가 여전히 존재합니다.

(OP_VAULT) 대 사전 서명 볼팅 프로세스, 출처: BIP-345)

더 강력하고 유연한 상태 채널

일반적으로, 다음과 같이 주장할 수 있습니다. 라이트닝 네트워크를 포함한 상태 채널은 메인체인과 거의 동등한 보안을 가지고 있습니다(노드가 최신 상태를 관찰하고 최신 상태를 체인에 올바르게 게시할 수 있다는 의미에서). <하지만 제약 조건을 고려할 때 라이트닝 네트워크보다 더 강력하거나 유연할 수 있는 새로운 상태 채널 설계 아이디어가 몇 가지 있습니다. 잘 알려진 것들로는 Eltoo, Ark 등이 있습니다.

엘투(LN-Symmetry라고도 함)가 대표적인 예입니다. "L2"라는 단어에서 착안한 이 기술 솔루션은 라이트닝 네트워크에 페널티 메커니즘 없이도 이후 채널 상태가 이전 상태를 대체할 수 있도록 하는 시행 계층을 제안하며, 따라서 라이트닝 네트워크 노드가 적의 악의적인 행위를 방지하기 위해 여러 이전 상태를 저장할 필요도 없게 합니다. 위와 같은 효과를 달성하기 위해 엘투는 SIGHASH_NOINPUT 시그니처인 APO(BIP-118)를 제안합니다.

반면, 아크는 라이트닝 네트워크에서 인바운드 이동성 및 채널 관리의 어려움을 줄이는 것을 목표로 합니다. 여러 사용자가 일정 기간 동안 서비스 제공자를 거래 상대방으로 받아들이고, 오프체인에서는 가상 UTXO(vUTXO)를 거래하지만 온체인에서는 하나의 UTXO를 공유하여 비용을 절감할 수 있는 조인풀 형태의 프로토콜입니다. 아크는 볼팅과 유사하게 현재 비트코인 네트워크에서 구현할 수 있지만, 제한을 도입하면 트랜잭션 템플릿에 따라 필요한 상호작용의 양을 줄일 수 있어 보다 신뢰도가 낮은 일방적인 출구를 구현할 수 있습니다.

약정 기술 개요

위 적용 사례에서 보시다시피, 약정 제한은 기술이라기보다는 효과에 가깝습니다. 이를 구현하는 기술적인 방법은 여러 가지가 있습니다. 이를 분류하면 다음과 같습니다.

유형:일반, 특수

이행 방법 : 오코드 기반, 서명 기반

재귀:재귀적, 비재귀적

그리고 이 중 재귀: 몇 가지가 있습니다. 제한이 구현되어 있으며, 다음 출력을 제한하여 다음 출력의 출력을 제한함으로써 하나의 트랜잭션을 넘어 더 깊은 트랜잭션의 추가를 구현할 수 있습니다.

주류 제한 설계에는 다음이 포함됩니다.

약관의 제한 사항 조항 설계

이전 소개에서 볼 수 있듯이 현재 비트코인 스크립트는 주로 잠금 해제 조건을 제한하고 있으며, 해당 UTXO를 추가로 사용할 수 있는 방법을 제한하지 않습니다. 제한 조항을 구현하려면 다른 방식으로 생각해야 합니다. 왜 현재 비트코인 스크립트는 언약 제한 조항을 구현할 수 없는가?

주요 이유는 현재 비트코인 스크립트가 트랜잭션 자체의 내용, 즉 트랜잭션의 '인트로스펙션'을 읽을 수 없기 때문입니다.

트랜잭션에 대한 인트로스펙션을 구현할 수 있다면, 즉 트랜잭션(출력 포함)에 대한 모든 것을 검사할 수 있다면 제한 조항이 구현될 것입니다.

따라서 제한 조항에 대한 디자인 사고는 어떻게 인트로스펙션을 구현할 수 있는지를 중심으로 전개됩니다.

오퍼랜드 기반과 서명 기반

가장 간단하고 조잡한 아이디어는 하나 이상의 옵코드(즉, 하나의 옵코드 + 여러 개의 매개변수 또는 서로 다른 기능을 가진 여러 개의 옵코드)를 추가하여 트랜잭션을 직접 읽는 것입니다. 이것 역시 옵코드를 기반으로 한 아이디어입니다.

또 다른 방법은 스크립트에서 트랜잭션 자체의 내용을 직접 읽고 확인하는 대신 트랜잭션 내용의 해시를 사용할 수 있다는 것입니다 - 이 해시가 이미 서명되어 있다면 스크립트에 예를 들어 OP CHECKSIG 등으로 스크립트를 수정하여 이 서명을 확인할 수 있도록 하면 트랜잭션 인스펙션 및 제한 조항을 간접적으로 구현할 수 있습니다. 이 아이디어는 서명 설계 접근 방식을 기반으로 합니다. 주요한 것은 APO와 OP_CSFS입니다.

APO

SIGHASH_ANYPREVOUT(APO)는 비트코인 서명 방법 중 하나입니다. 가장 간단한 서명 방법은 트랜잭션의 입력과 출력을 모두 커밋하는 것이지만, 비트코인에는 트랜잭션의 입력 또는 출력 중 하나를 선택적으로 커밋하는 보다 유연한 방법인 SIGHASH도 있습니다.

SIGHASH의 현재 범위와 트랜잭션의 입력과 출력에 대한 서명 조합(출처: "비트코인 마스터하기, 2차"

위 그림에서 보듯이 모든 데이터에 적용되는 ALL을 제외한 NONE은 모든 입력에만 적용되고 출력에는 적용되지 않는 방식으로 서명되며, SINGLE은 입력 일련번호가 동일한 출력에만 적용되는 방식으로 서명됩니다. SINGLE은 이를 기반으로 하며 입력 일련 번호가 동일한 출력에만 적용됩니다. 또한 SIGHASH는 ANYONECANPAY 수정자를 겹쳐서 단일 입력에만 적용하도록 결합할 수 있습니다.

반면, APO의 SIGHASH는 입력이 아닌 출력에만 서명합니다. 즉, APO로 서명된 트랜잭션은 기준을 충족하는 모든 UTXO에 첨부할 수 있습니다.

이러한 유연성은 APO의 제한 조항 구현의 이론적 근거입니다. APO를 UTXO에 적용하는 것은 문제가 되지 않습니다. 제한 조항 구현의 이론적 근거:

하나 이상의 트랜잭션을 미리 생성할 수 있습니다

이 트랜잭션의 정보는 하나의 서명만 도출할 수 있는 공개키를 구성하는 데 사용됩니다

. style="text-align: left;">이 공개 키 주소로 전송된 모든 자산은 미리 생성된 트랜잭션을 통해서만 사용될 수 있습니다

이 공개 키에는 해당 개인 키가 없기 때문에 이러한 자산은 미리 생성된 트랜잭션을 통해서만 사용될 수 있다는 점에 유의할 필요가 있습니다. spent. 그런 다음 미리 생성된 트랜잭션에서 자산이 어디로 이동하는지 지정하여 제한 조항을 구현할 수 있습니다.

이를 이더리움의 스마트 콘트랙트와 비교하면 더 이해할 수 있습니다. 스마트 콘트랙트를 통해 달성할 수 있는 것은 EOA 서명을 통해 임의로 돈을 쓰는 것이 아니라 특정 조건이 충족되는 경우에만 계약된 주소에서 돈을 인출할 수 있다는 점입니다. 이러한 의미에서 비트코인은 서명 메커니즘의 개선을 통해 이러한 효과를 달성할 수 있습니다.

그러나 위 프로세스의 문제점은 트랜잭션에 미리 서명하고 생성하려면 입력값을 알아야 하기 때문에 계산에 순환 의존성이 있다는 것입니다.

이 서명을 구현하는 APO와 SIGHASH_NOINPUT의 중요성은 계산 시 (지정된) 트랜잭션의 전체 출력을 알면 이러한 순환 의존성을 해결할 수 있다는 것입니다.

OP_CTV

OP_CHECKTEMPLATEVERIFY(CTV), 또는 BIP-119. 는 Opcode의 세분화를 사용합니다. 커미션 해시를 인수로 받고, 옵코드를 실행하는 모든 트랜잭션에 해당 커미션과 일치하는 출력 집합을 포함하도록 요구합니다. CTV를 사용하면 비트코인 사용자가 비트코인 사용 방식을 제한할 수 있습니다.

원래 OP_CHECKOUTSHASHVERIFY(COSHV)로 소개되어 혼잡 제어 거래를 생성하는 기능에 초점이 맞춰진 이 제안에 대한 비판은 또한 충분히 충분히 일반적이지 않고 혼잡 제어 사용 사례에 너무 구체적이라는 비판도 있었습니다.

위에서 언급한 혼잡 제어 사용 사례에서 발신자인 앨리스는 10개의 출력을 생성하고 이 10개의 출력을 해시한 다음 결과 다이제스트를 사용하여 COSHV를 포함하는 탭리프 스크립트를 만들 수 있습니다.또한 앨리스는 참가자들의 공개 키를 사용하여 탭루트 내부 키를 생성하여 탭루트 스크립트의 경로를 공개하지 않고도 지출에 대해 공동 작업할 수 있습니다.

그런 다음 앨리스는 각 수신자가 앨리스의 설정 트랜잭션을 확인할 수 있도록 10개의 출력물 사본을 모두 제공합니다. 나중에 결제금을 사용하고자 할 때 누구든 약속된 출력물로 트랜잭션을 생성할 수 있습니다.

이 과정에서 앨리스가 설정 트랜잭션을 생성하여 전송하면 이메일이나 클라우드 드라이브와 같은 기존의 비동기 통신 방법을 통해 10개의 출력 사본을 전송할 수 있습니다. 즉, 수신자가 온라인 상태이거나 서로 상호 작용할 필요가 없습니다.

(출처: https ://bitcoinops.org/ko/newsletters/2019/05/29/#proposed-transaction-output-commitments)

APO와 유사합니다. 마찬가지로 지출 조건에 따라 주소를 구성할 수 있으며, 다른 키 추가, 시간 잠금, 구성 가능한 로직 등 다양한 방식으로 '잠금'을 설정할 수 있습니다.

(출처: https://twitter.com/OwenKemeys/status/) 1741575353716326835)

CTV는 이를 기반으로 해시 트랜잭션이 정의된 일치 항목과 일치하는지, 즉 트랜잭션 데이터를 '잠금'을 해제하는 키로 사용할 수 있는지 확인할 수 있다는 제안을 합니다.

위와 같은 수신자 10명의 예시를 확장하면, 수신자는 자신의 주소 키를 서명되었지만 브로드캐스트되지 않은 tx로 다음 수신자 주소 배치로 설정할 수 있으며, 아래 그림과 같이 트리 구조를 형성할 수 있습니다. 블록 공간을 체인에 추가하여 여러 사용자가 참여하는 계정 잔액 변경을 구성할 수 있습니다.

출처: https. //twitter.com/OwenKemeys/status/1741575353716326835

나뭇잎 중 하나가 라이트닝 채널, 콜드 스토리지, 다른 결제 경로인 경우 어떻게 될까요? 그러면 트리가 단일 차원 다층 비용 트리에서 다차원 다층 비용 트리로 확장되고 지원할 수 있는 시나리오가 훨씬 더 풍부하고 유연해질 것입니다.

출처: https. //twitter.com/OwenKemeys/status/1741575353716326835

제안 이후 CTV는 2019년에 COSHV에서 이름을 변경하고 2020년에 BIP를 배정받았습니다. -119를 부여받았으며, CTV 지원 계약을 만드는 데 사용된 프로그래밍 언어인 사피오의 등장으로 22년과 23년에 활성화 계획에 대한 많은 커뮤니티 토론, 업데이트, 논쟁이 있었으며, 여전히 커뮤니티에서 가장 많이 논의되는 소프트포크 업그레이드 제안 중 하나입니다.

OP_CAT

OP_CAT 역시 첫 단락에서 설명한 것처럼 현재 매우 인기 있는 업그레이드 제안으로, 스택의 두 요소를 연결하는 기능을 구현합니다. concatenante. 단순해 보이지만 OP_CAT은 스크립트에서 수행할 수 있는 작업 측면에서 많은 유연성을 제공합니다.

가장 직접적인 예는 머클 트리 조작으로, 두 요소를 먼저 연결한 다음 해시하는 것으로 해석할 수 있습니다. 현재 비트코인 스크립트에는 OP_SHA256과 같은 해시 연산자가 있기 때문에 OP_CAT을 사용해 두 요소를 연결할 수 있다면 OP_CAT을 사용해 동일한 작업을 수행할 수 있습니다. 두 요소의 연결을 달성하기 위해 CAT을 사용하면 스크립트에서 머클 트리의 검증 기능을 구현할 수 있으며, 어느 정도 라이트 클라이언트를 검증할 수 있는 기능을 가지고 있습니다.

또 다른 구현 기반에는 슈노르 서명에 대한 개선 사항이 포함됩니다. 스크립트는 사용자의 공개 키와 공개 논스의 스플라이스에 서명을 사용하도록 설정할 수 있으며, 서명자가 다른 거래에 서명하여 자금을 다른 곳에 사용하려는 경우 동일한 것을 사용해야 합니다. 서명자가 자금을 다른 곳에 사용하기 위해 다른 트랜잭션에 서명하려면 동일한 논스를 사용해야 하며, 이는 개인 키 공개로 이어집니다. 즉, OP_CAT은 서명된 트랜잭션의 유효성을 보장하기 위해 논스의 헌신을 가능하게 합니다.

OP_CAT의 다른 시나리오로는 비스트림, 트리 서명, 양자 내성 램포트 서명, 볼트 등이 있습니다.

OP_CAT 자체는 새로운 기능이 아니며, 비트코인 초기 버전에 존재했지만 악용 가능성으로 인해 2010년에 비활성화되었습니다. 예를 들어, 이 데모에서 볼 수 있듯이 OP_DUP과 OP_CAT을 재사용하면 이러한 스크립트를 처리할 때 스택에서 전체 노드가 쉽게 폭발할 수 있습니다.

그러나 OP_CAT이 다시 활성화되었으니 앞서 언급한 스택 폭발 문제가 발생하지 않나요? 현재 OP_CAT 제안은 스택 요소당 520바이트 이하로 제한되는 탭스크립트에서만 활성화하는 것이므로 이전의 스택 폭발 문제가 발생하지 않습니다. 사토시 나카모토가 OP_CAT을 완전히 비활성화하는 것은 너무 가혹하다고 생각하는 개발자들도 있습니다. 그러나 OP_CAT의 유연성 때문에 취약점을 유발할 수 있는 일부 애플리케이션 시나리오를 현재로서는 모두 처리할 수 없는 것이 사실일 수 있습니다.

이러한 적용 시나리오와 잠재적 위험을 고려할 때 OP_CAT은 최근 많은 관심을 받고 있으며, 자체 PR 검토를 거쳐 현재 가장 인기 있는 업그레이드 제안 중 하나가 되었습니다.

결론

"자율 규제가 자유를 가져온다"는 말처럼, 위의 소개에서 볼 수 있듯이 제한을 비트코인 스크립트에 직접 구현하여 거래 횟수를 제한할 수 있습니다. 추가 지출을 제한하여 스마트 콘트랙트의 효과와 유사한 거래 규칙을 구현할 수 있습니다. 이 프로그래밍 접근 방식은 BitVM과 같은 오프체인 접근 방식보다 비트코인에서 더 기본적으로 검증할 수 있으며, 메인 체인(혼잡 제어), 오프체인 애플리케이션(상태 채널) 및 기타 새로운 방향(스테이킹 페널티 등)의 애플리케이션도 개선할 수 있습니다.

제약 조건의 구현 기술은 일부 기본 업그레이드와 결합하면 프로그래밍 가능성의 잠재력을 더욱 끌어올릴 수 있습니다. 예를 들어, 최근 검토 중인 64비트 연산자를 위한 제안은 트랜잭션이 출력하는 사토시의 수를 기반으로 프로그래밍할 수 있는 OP_TLUV 또는 기타 제약 조건과 결합될 수 있습니다.

그러나 제한 조항은 의도치 않은 남용이나 취약점으로 이어질 수 있으므로 커뮤니티는 이를 경계하고 있습니다. 또한, 제한 조항을 확대하려면 합의 규칙의 소프트 포크 업그레이드도 수반되어야 합니다. 탭루트 업그레이드를 둘러싼 상황을 고려할 때 이용약관 관련 업그레이드를 완료하는 데는 다소 시간이 걸릴 수 있습니다.