비트코인에서 토큰, NFT, DeFi를 개발하는 과정은 실제로 보이는 것보다 훨씬 복잡합니다. 예를 들어, Ethereum Virtual Machine(EVM) 및 기타 스마트 계약 플랫폼에서 스마트 계약은 튜링 완전합니다. 즉, 사용자 정의 계약을 배포하기만 하면 새로운 기능이나 옵션을 추가할 수 있습니다. 하지만 비트코인에서 개발자는 하드 포크를 일으키지 않고 혁신하기 위해 주의해야 하며, 기존 프로토콜 기능의 한계 내에서만 운영할 수 있습니다. 앞서 언급했듯이 비트코인을 독특하고 중요하며 가치 있게 만드는 핵심 요소 중 하나는 "독창성"을 고수한다는 것입니다. 메인 체인은 시간이 지남에 따라 거의 변경되지 않았습니다.

그럼에도 불구하고 비트코인은 널리 채택된 최초의 블록체인이었으며, 이후 더욱 유연한 블록체인에 구현된 많은 기술은 실제로 비트코인에서 가장 먼저 시작되었습니다. 사실, NFT는 비트코인에서 "컬러드 코인" 형태로 처음 등장했습니다. State Channel의 개념은 오늘날의 L1-L2 아키텍처와 설계상 매우 유사합니다. 그리고 원자 스왑은 현대의 크로스체인 브리지의 기초를 마련했습니다. 이러한 개발 내용에 대해서는 이전 기사 "비트코인에서 시작해서: DeFi의 진정한 기원"에서 부분적으로 소개했습니다. 하지만 Botanix와 다른 비트코인 ​​체인을 위한 인프라로서 비트코인의 비교할 수 없는 가치를 진정으로 이해하려면 이러한 초기 혁신이 오늘날의 생태계로 가는 길을 어떻게 마련했는지 더 깊이 이해해야 합니다. 비트코인 자체는 비교적 단순하지만, 실제로는 Web3 공간에서 가장 복잡하고 매혹적인 생태계 중 하나이며 가장 풍부한 역사를 가지고 있습니다.

비트코인 기능 이론 탐구: 비트코인은 복잡한 생태계를 지원할 만큼 강력할까요?

비트코인이 2009년에 출시되었을 당시에는 간단한 결제를 가능하게 할 뿐만 아니라 멀티시그와 타임락과 같은 더 복잡한 작업도 처음부터 지원하는 내장 스크립팅 언어가 있었습니다. 사토시 나카모토는 nLockTime과 시퀀스 번호를 사용하는 확인되지 않은 거래가 고빈도 거래를 위해 두 당사자 사이에서 여러 번 업데이트될 수 있으며, 최종 상태만 체인에 기록된다고 설명했습니다.

비트코인 스크립트는 매우 흥미로운 메커니즘입니다. 한편으로는 튜링 불완전성이 있어 기능이 제한됩니다. 반면에 간단하고 안전합니다. 따라서 비트코인에서 복잡한 기능을 구축할 때 개발자는 Script에서 제공하는 프레임워크 내에서 해당 기능을 설계해야 합니다. 여기에는 다양한 동작을 프로그래밍하는 데 사용되는 많은 수의 명령(Opcode)이 포함되어 있으며, 이는 결국 거래 데이터에 기록됩니다.

비트코인 스크립트는 비트코인이 코인의 지출 조건을 정의하는 데 사용하는 스크립팅 언어입니다. 스크립트는 케이크를 굽는 일련의 단계인 요리법이라고 생각할 수 있습니다. 명령어는 이 언어의 기본 구성 요소입니다. 명령어는 프로그래머가 스크립트를 작성할 때 사용하는 "젓다", "가열하다" 등의 기본 명령어입니다. 스크립트의 기능을 더 명확하게 이해하기 위해 가장 일반적인 스크립트 유형을 간략하게 살펴보겠습니다.

  • P2PK(Pay To Public Key) - 이것은 원래의 BTC 전송 방법으로, 나중에 P2PKH로 대체되었습니다. 여기에는 다음과 같은 여러 가지 Opcode가 포함됩니다. OP_DATA_65 OP_CHECKSIG OP_DATA_33 OP_CHECKSIG.

  • P2PKH(공개 키 해시에 지불) - 스크립트 형식은 다음과 같습니다: OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG. 이 스크립트는 거래 크기를 최적화하기 위해 32바이트 공개 키 해시를 사용하므로 64바이트 P2PK보다 공간 효율성이 높아 빠르게 대중화되었습니다. 거래 규모가 작을수록 수수료는 낮아집니다. 특히 비트코인 ​​사용량과 수수료가 증가함에 따라 이는 매우 중요합니다.

  • 임의의 데이터 저장 - 이러한 스크립트는 일반적으로 매우 적은 양의 사토시를 잠그고 주로 ASCII 텍스트, 링크 또는 스크립트를 저장하는 데 사용됩니다. 예: OP_0 OP_DATA_20 # 20바이트의 사용자 정의 데이터. OP_RETURN을 사용하여 데이터를 저장하는 표준화된 방법도 있습니다. 예를 들어, Bitcoin Colored Coins 프로토콜(NFT의 전신)은 OP_RETURN을 통해 토큰 메타데이터를 내장합니다.

NCC 그룹의 연구에서는 156개의 다양한 스크립트 패턴을 요약하고 이러한 스크립트 구조에 대한 자세한 분석을 실시했습니다.

그렇다면 스크립트를 사용해서 비트코인에서 DeFi와 같은 메커니즘을 구성할 수 있을까요? 다음 단계를 계속해서 살펴보겠습니다.

대출 메커니즘:

앞서 언급했듯이, 명령어를 결합하여 일련의 작은 명령어 체인을 구축하면 더 복잡한 동작을 달성할 수 있습니다. 예를 들어, 개발자는 명령어를 결합하여 대출 계약 기능이 있는 복잡한 스크립트를 구성할 수 있습니다. 이는 타임락과 다중 서명을 조합하여 달성할 수 있습니다.

  • OP_CHECKSEQUENCEVERIFY(CSV): 상대적 시간 잠금(예: 특정 거래 후 X 블록의 자금을 잠금)

  • OP_CHECKLOCKTIMEVERIFY(CLTV): 절대 시간 잠금(예: 대출은 특정 블록 높이 또는 타임스탬프에서 만료됨)을 위한 것입니다.

  • OP_CHECKMULTISIG(또는 OP_ADD를 포함한 여러 OP_CHECKSIG): 여러 당사자가 서명해야 함

  • 조건 논리 명령어 OP_IF / OP_ELSE: 다양한 지출 경로(예: 상환 대 불이행)를 정의합니다.

이러한 도구를 사용하면 "시간 제한이 있는 양자 에스크로 계약"이 가능해질 수 있습니다. 예를 들어, 앨리스가 BTC를 담보로 제공하고 밥이 그녀에게 오프라인으로 스테이블코인을 빌려준다고 가정해 보겠습니다. 그들은 계약을 통해 다음과 같은 규칙을 정하고자 합니다. 앨리스가 제때 대출금을 갚지 못하면 밥이 그녀의 BTC를 받습니다. 앨리스가 대출금을 제때 갚으면 BTC가 잠금 해제되어 앨리스에게 반환됩니다. 이를 위해 2-2 다중 서명 출력을 사용할 수 있습니다(앨리스와 밥이 자금을 사용하려면 둘 다 서명해야 함). 그런 다음 스크립트 로직을 설정할 수 있습니다. 특정 블록 높이에 도달한 후에도 대출이 상환되지 않으면 Bob만 자금을 사용할 수 있습니다.

하지만 여기에는 여전히 큰 어려움이 있습니다. 비트코인 ​​자체는 자동으로 이자를 계산하거나, 담보 비율을 모니터링하거나, 청산을 강제할 수 없습니다. 모든 이자 지급은 체인 밖에서 또는 사전 서명된 거래를 통해 이루어져야 합니다(실제로는 매우 복잡합니다). 대출 기간 동안 BTC 가격이 하락하면 비트코인 ​​스크립트 자체는 이를 알 수 없으며 자동으로 청산을 실행할 수 없습니다. 이 기능을 구현하려면 오라클이나 오프체인 프로토콜을 사용해야 합니다. 오라클이 없으면 계약은 최종 만료일을 기준으로만 결정을 내릴 수 있습니다.

따라서 비트코인 ​​계층에서 신뢰가 필요 없는 BTC 담보 스테이블코인 대출을 직접 구현하는 것은 매우 어렵습니다. 현재의 관행은 일반적으로 신뢰할 수 있는 제3자에 의존하거나 다른 체인의 원자 스왑 메커니즘을 통해 간접적으로 구현됩니다.

AMM 기능:

위에서 언급했듯이, 대출 및 스테이킹 메커니즘은 이론적으로는 비트코인 ​​스크립트를 통해 구현할 수 있지만, 실제로는 효율성이 떨어집니다. 그러나 우리는 비트코인에서 자동화된 시장 조작자(AMM)와 같은 보다 복잡한 메커니즘을 구축하는 것이 가능한지 여부를 여전히 알아볼 수 있습니다. Bitcoin Script에는 OP_ADD, OP_SUB, OP_MUL(일부는 비활성화됨)과 같은 수학 명령어 코드와 OP_LESSTHAN과 같은 비교 명령어 코드가 포함되어 있습니다. 이론상 이러한 함수는 가격 계산 논리를 구현하는 데 사용될 수 있습니다.

이론상 개발자는 고정 가격이나 미리 정의된 수용 가능한 가격대를 포함하는 스크립트를 작성할 수 있지만, 각 거래 후에 가격을 동적으로 조정하는 것은 불가능할 것입니다. 그 이유는 비트코인이 UTXO 모델을 사용하고 각 거래가 새로운 UTXO와 스크립트를 생성하기 때문에 가능한 모든 상태를 미리 계산하거나 각 거래 후에 계약을 다시 배포해야 하기 때문입니다.

AMM 구현의 또 다른 핵심 요소는 자산을 교환할 수 있는 능력입니다. 이론상 비트코인은 원자 스왑을 지원하는데, 이는 유동성 풀이 아닌 주문장 형태로 구성될 수 있습니다. AMM과 유사한 동작은 일련의 HTLC(해시 타임 잠금 계약)를 구성하거나 다양한 가격대에서 주문을 발행하여 정적 자동 시장 조성 시스템(수익률 곡선과 유사)을 형성함으로써 시뮬레이션할 수도 있습니다. 하지만 이런 시스템을 유지하는 것은 매우 번거롭습니다. 각 거래 후 스크립트를 수동으로 업데이트하고 UTXO를 재발행해야 하며, 체인상 비용이 엄청나게 높습니다.

따라서 AMM은 이론상으로는 구축할 수 있지만 실제로는 더 큰 문제가 있습니다. 비트코인 ​​메인넷에는 기본 자산이 BTC 하나뿐이라는 것입니다. Omni 프로토콜과 같은 프로토콜은 토큰 메커니즘을 제공하지만, 이러한 자산은 거래의 메타데이터에 존재하며 스크립트로 식별 및 처리할 수 없습니다. 따라서 비트코인 ​​스크립트를 통해서는 진정한 자산 간 교환이나 유동성 풀 유지가 이루어질 수 없습니다. 또한 비트코인의 UTXO 모델은 여러 당사자의 자금을 동시에 보유하고 부분적인 잔액을 업데이트하는 단일 계약을 지원하지 않습니다. 각 상태 변경에는 새로운 거래와 여러 서명이 필요합니다.

확장된 스크립트 기능:

위에서 언급한 사항들은 비트코인이 기능을 개선하기 위해 정기적으로 주요 업데이트를 실시하는 이유를 설명합니다. 중요한 업데이트 중 하나는 소프트 포크를 통해 도입된 Taproot인데, 스크립트가 디자인되는 방식을 크게 바꾸었습니다.

Taproot의 OP_SUCCESS 메커니즘:

Taproot 업그레이드(BIP 342)가 도입되면서 이전에 비활성화되었거나 예약된 많은 명령어가 Tapscript(예: SegWit v1 스크립트)에서 OP_SUCCESS 명령어로 변환되었습니다. OP_SUCCESS는 명령어 코드가 실행되자마자 스크립트가 성공적으로 종료됨을 의미합니다. 이 디자인을 사용하면 소프트 포크를 통해 새로운 명령어를 더 쉽고 안전하게 추가할 수 있습니다. 구체적으로, Tapscript에서 명령어 코드의 값이 특정 범위(예: 0x50, 0x62, 0x7E–0x81, 0x83–0x86, 0x89–0x8a, 0x8d–0x8e, 0x95–0x99, 0xbb–0xfe) 내에 있는 경우 OP_SUCCESSx로 간주됩니다. 이러한 명령어를 만나면 스크립트는 무조건 성공으로 판단하고 다른 논리를 무시합니다.

이 메커니즘은 기존의 OP_NOP(작업 코드 없음) 업그레이드 방식을 대체하여 더 높은 보안성과 유연성을 제공합니다. 향후 소프트 포크에서는 특정 OP_SUCCESS 명령어의 동작을 재정의할 수 있으며, 이전 버전 노드는 여전히 이를 "스크립트 성공"으로 간주하여 버전 불일치로 인해 발생하는 잘못된 트랜잭션을 방지합니다. 요약하자면, "사용 가능"으로 나열되지 않은 모든 명령어는 사용을 위해 예약되어 있거나 Taproot에서 항상 OP_SUCCESS를 반환하도록 변환되었습니다.

또 다른 중요한 측면은 BIP(비트코인 개선 제안) 프로세스를 통해 명령어를 제안할 수 있다는 점이며, 이미 고려 중인 강력한 제안이 있거나 거부된 제안이 있습니다. 이러한 제안 중 일부가 채택된다면 비트코인의 기능이 크게 확장되어 더 복잡한 작업을 수행할 수 있게 될 것입니다.

  • OP_CAT(연결 연산자): 비트코인 ​​스크립트에서 데이터를 결합하고 처리하는 기능을 강화하여 표현력을 크게 향상시키는 데 사용됩니다. OP_CAT은 원래 비트코인 ​​초기부터 존재했습니다(2010년에 비활성화됨). 이 함수의 기능은 스택에서 두 바이트 문자열을 가져와 연결한 다음 다시 스택에 푸시하는 것입니다. 이 간단하면서도 강력한 연산은 메시지를 동적으로 구성하고, 스크립트에서 머클 트리 해시를 계산하고, 기타 복잡한 논리를 실행하는 데 사용할 수 있습니다. 제안에서는 연결된 결과를 최대 520바이트(최대 스택 요소 제한)로 제한할 것을 제안합니다.

  • OP_CHECKSIGFROMSTACK / OP_CHECKSIGFROMSTACKVERIFY(약칭 OP_CSFS): 이 명령어는 Oracle 기반 스크립트 검증을 활성화합니다. 예를 들어, 스크립트는 외부 조건(가격이나 이벤트 결과 등)에 대한 서명된 메시지가 특정 오라클에서 왔는지 확인할 수 있습니다. 간단한 실행 논리에도 불구하고 OP_CSFS는 비트코인에 완전히 새로운 기능을 제공할 수 있습니다. 예를 들어, 오라클은 "X 시점에서 BTC가 20,000달러 아래로 떨어진다"는 메시지에 서명하고, 대출 스크립트는 OP_CSFS를 통해 이 서명을 검증하여 대출자가 담보를 청산할 수 있도록 합니다. 이 프로세스에서는 제3자가 개인 키를 보관할 필요가 없습니다. 또한, 대출인이 대출금을 상환한 후 오라클이나 대출 기관은 "상환 수령"에 서명하고 스크립트 검증 후 담보가 반환됩니다. OP_CSFS가 없다면 외부 조건에 따른 이러한 자동 계약은 구현이 불가능하거나 공동 서명자인 오라클을 통해서만 완료될 수 있으며, 이는 더 높은 신뢰 위험을 수반합니다.

  • OP_CHECKTEMPLATEVERIFY(약칭 OP_CTV): 이 명령어를 사용하면 사용자는 비트코인이 미래에 어떻게 사용될지 미리 정의할 수 있습니다. 예를 들어, 특정 주소 집합으로만 전송하거나 특정 수수료 조건을 충족하는 경우에만 사용할 수 있습니다. OP_CTV는 특정 사전 정의된 규칙이 시행되도록 하는 "계약" 메커니즘을 기반으로 일괄 거래, 채널 팩토리 및 기타 고급 사용 사례를 구축하는 데 사용할 수 있습니다.

하지만 왜 이러한 명령어가 아직 승인되지 않았을까요?

가장 큰 이유는 비트코인 ​​개발자 커뮤니티가 비트코인의 원래 형태를 유지하는 데 매우 신중하기 때문일 수 있습니다.

한편, 새로운 기능을 도입하면 실제로 비트코인의 유용성과 확장성이 향상될 수 있습니다. 하지만 반면에 비트코인 ​​자체는 "느리게" 설계된 네트워크이고, 이 "느림"은 어느 정도 "원래" 특징으로 여겨지기도 합니다. 예를 들어, 청산 메커니즘에 OP_CSFS를 적용하는 경우 속도가 핵심 요소입니다. 시장이 폭락하고 BTC 가격이 급격히 하락하면 역설이 발생할 수 있습니다.

첫째, 블록체인 부하가 급증했고 네트워크 속도가 더욱 떨어졌습니다.

둘째, 비트코인 ​​네트워크의 거래 처리 속도가 상당히 뒤떨어지고, 가격이 현재 시장 수준을 한참 벗어난 반면, 중앙화 거래소와 탈중앙화 거래소(CEX, DEX)는 이미 신속하게 대응했습니다.

온체인 클리어링 거래가 완료되기 전에 가격이 반등할 가능성이 매우 높습니다.

따라서 비트코인 ​​자체는 느리게 실행되고, 부하가 높을 때 거래 수수료가 엄청나게 높아서 메인넷에 DeFi 관련 메커니즘을 기본적으로 구현하려는 시도는 기본적으로 의미가 없습니다.

이로 인해 개발자들은 점차 더 합리적인 결론에 도달했습니다. 즉, 비트코인 ​​위에 확장 계층을 구축해야 한다는 것입니다. 이는 실제로 Rollup 아이디어의 전신인 "프로토 결제 채널" 개념입니다. 즉, 오프체인에서 여러 소액 거래를 지원하여 최종적으로 온체인 결제 거래로 압축하는 것입니다.

2011년 4월 초, 비트코인의 첫 번째 코드 브랜치인 네임코인이 출시되었는데, 이는 비트코인 ​​기술을 통해 분산형 도메인 이름 등록(DNS ".bit")을 실현했습니다.

네임코인의 사례는 이름-값 쌍을 체인상에 저장하는 방식으로, 비트코인 ​​디자인이 화폐 거래뿐만 아니라 다른 자산에도 사용될 수 있다는 것을 처음으로 보여준 사례입니다. 물론 별도의 블록체인 구조가 필요할 수도 있습니다. 이러한 개념은 이후 자산 토큰화, 분산 거래, 비트코인의 오프체인 확장 혁신의 기반을 마련했습니다.

스테이블코인: 비트코인 ​​생태계에서 얼마나 효과적일까요?

스테이블코인은 DeFi와 직접 관련이 없더라도 모든 Web3 생태계에서 핵심 구성 요소가 되었습니다. 이를 통해 사용자는 변동성 위험을 헤지하고 자산 가격 변동에 대한 걱정 없이 자금을 이체할 수 있습니다. 앞서 언급했듯이, 비트코인 ​​네트워크는 기능의 단순성과 기록할 수 있는 데이터 양 간의 균형을 항상 찾으려고 노력합니다. 흥미롭게도, 비트코인에서 자산을 발행하려는 최초의 시도는 "컬러드 코인"의 개발을 통해 이루어졌는데, 이는 어떤 면에서 NFT와 비슷합니다.

2012년 초, JR 윌렛은 비트코인을 기반으로 새로운 자산을 발행한다는 아이디어를 제안했고, "컬러드 코인"이라는 개념을 제시했습니다. 이후 그는 마스터코인 프로토콜(나중에 옴니로 이름 변경)을 만드는 데 기여하여 비트코인 ​​자산(법정 통화에 고정된 토큰 포함)을 토큰화할 수 있는 기반을 마련했습니다.

표준 Bitcoin Script 스크립트에는 직접적인 "토큰" 명령어가 없으므로 개발자는 OP_RETURN의 도움으로만 토큰 메타데이터를 거래 출력에 내장할 수 있습니다(OP_RETURN은 출력을 사용할 수 없게 만들고 데이터와 함께 제공합니다). OP_RETURN이 표준화되기 전에는 다중 서명 스크립트가 데이터 인코딩을 위한 해결책으로 사용되었습니다.

비트코인 스크립트 자체는 토큰 규칙을 강제할 수 없습니다. 규칙은 비트코인 ​​거래를 분석하는 오프체인 소프트웨어에 의해 유지됩니다.

Colored Coins, Omni Layer(이전 Mastercoin), Counterparty, Open Assets와 같은 프로토콜은 모두 "특정 사토시 또는 UTXO에 색상을 입혀" 토큰을 나타냅니다. 예를 들어, Open Assets 프로토콜은 토큰 금액과 자산 ID를 나타내는 메타데이터가 포함된 OP_RETURN 출력을 사용합니다.

기본적으로 비트코인 ​​블록체인 자체는 "토큰"의 존재를 인식하지 못합니다. 단순히 데이터를 처리할 뿐입니다. 토큰의 유효성(예: 공급, 소유권)은 OP_RETURN 데이터를 구문 분석한 후 외부 지갑 자체에서 추적됩니다.

OP_RETURN에는 데이터 크기 제한이 있다는 점에 유의하세요. Bitcoin Core 클라이언트의 표준 정책은 각 OP_RETURN 출력에 최대 80바이트의 임의 데이터가 포함될 수 있다고 명시합니다. 80바이트를 초과하는 데이터는 "비표준 거래"로 간주되어 기본적으로 전달되지 않습니다. 이론상으로는 거래에 여러 개의 OP_RETURN 출력이 포함되어 수반되는 데이터 양을 늘릴 수 있습니다(각각 최대 80바이트). 하지만 스팸 거래를 방지하기 위해 비트코인의 현재 표준 릴레이 전략은 일반적으로 각 거래에 OP_RETURN 출력을 하나만 포함하도록 허용합니다.

비트코인 거래에 메타데이터를 내장할 수 있는 기능 덕분에 2012년에 마스터코인 프로토콜이 만들어졌고, 이후 옴니로 이름이 바뀌었습니다. 옴니 레이어는 테더의 초기 운영에서 핵심적인 역할을 했으며, 첫 번째 USDT 전송을 위한 기반 전송 프로토콜이 되었습니다.

2010년대 중반에는 비트코인(옴니) 기반의 USDT가 시장에서 가장 지배적인 스테이블코인이었으며, 비트파이넥스 등의 거래소에서 널리 사용되었습니다. 옴니 거래는 기본적으로 추가 메타데이터가 포함된 표준 비트코인 ​​거래입니다. 이후 옴니는 여러 가지 구현 범주를 개발하고 자체적인 기술 진화 경로를 형성했습니다.