TAP의 발전을 목격하는 세 번째 분리 단계가 비트코인 2.0 단계를 예고할까요?

원저자: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio

1. 서론

"비트코인의 분리된 증인 기술과 세 가지 버전 업그레이드에 대한 철저한 이해"라는 기사를 쓰고 난 후, 저는 깊이 생각하게 되었습니다.

비트코인은 탄생 이래 확장성과 성능 향상을 모색해 왔습니다. TAP(Taproot Assets Protocol)의 등장은 비트코인의 확장성과 성능 향상을 위한 견고한 아키텍처 기반과 실현 가능한 방향을 제시했습니다. 현재 TAP는 무한한 데이터 공간으로의 확장을 허용합니다. 성능 향상 또한 튜링 완전성이라는 무한대에 도달할 수 있을까요? 몇 가지 이론적, 그리고 실질적으로 탐구 가능한 경로들을 분석해 보겠습니다. 비트코인이 완전한 확장성과 성능 향상을 달성할 수 있다면, 통합 블록체인 시나리오가 등장할 것입니다. 이 과정은 지속적이고, 길고, 도전적일 것이며, 집단 지성과 실질적인 적용이 필요합니다. 관심 있는 분들의 이 주제에 대한 토론과 개발 참여를 환영합니다.

2. 세 번째 격리는 새로운 문이 열리는 것을 목격했습니다.

간단한 결론부터 말씀드리자면, 세 번째 분리된 증인이 열어준 새로운 문은 무한한 데이터 공간을 제공한다는 것입니다. 이를 통해 튜링 완전 가상 머신(VM)을 개발할 수 있습니다.

먼저 세 번째 분리 증인 기술이 가져온 주요 변화를 살펴보고, 이어서 계층화된 프로토콜의 관점에서 비트코인의 추가 개발을 살펴보겠습니다.

2.1. TaprootAssets 프로토콜은 어떤 기반을 마련했나요?

이전 글 "비트코인의 분리 증인(Segregated Witness) 기술과 세 가지 버전 업그레이드에 대한 철저한 이해"에서 OP_RETURN의 초기 탐색 과정과 이후 분리 증인의 세 가지 버전 변경 과정을 살펴보실 수 있습니다. 아래 다이어그램을 참조하세요.

Segregated Witness(SegWit) 프로토콜의 세 번째 업그레이드에서는 두 가지 중요한 변경 사항을 볼 수 있습니다.

1. 무제한 데이터 공간을 활용하는 확장성 측면에서 이미 한계에 도달했습니다.

2. 아키텍처는 BTCscript의 VM과 TAP의 VM을 분리하여 향후 기능 개발을 위한 좋은 아키텍처 기반을 마련합니다.

비트코인 메인넷에 영향을 주지 않고 비트코인 네트워크에서 튜링 완전성을 달성할 가능성을 독립적으로 탐색하는 것이 가능하며, 이 탐색은 점진적인 방식으로 수행될 수 있습니다.

이 글에서는 비트코인의 확장성 잠재력을 분석합니다. TAP 기술의 지원을 통해 비트코인의 확장성과 성능 모두 궁극적인 목표를 달성할 수 있다면, 비트코인의 광범위한 적용을 위한 견고한 기반이 마련될 것입니다.

2.2. 비트코인의 개발에는 계층화된 프로토콜 설계 접근 방식이 필요합니다.

비트코인이 세계적인 영향력을 확보하려면 광범위한 적용 시나리오를 갖추고 대규모 생태계를 형성해야 합니다. 이처럼 방대하고 복잡한 시스템에 대해 인류는 이미 관련 경험과 방법론, 즉 계층적 설계 철학을 보유하고 있습니다. TCP/IP와 같은 프로토콜은 이미 훌륭한 적용 사례와 귀중한 교훈을 제공합니다.

제 글 "비트코인 레이어 2 구조(V2.0) 기본 사항에 대한 포괄적인 개요"에서는 계층형 프로토콜에 대해 더 자세히 설명합니다. 계층형 설계는 인간이 복잡한 시스템을 처리하는 방법이자 접근 방식입니다. 시스템을 여러 계층으로 나누고 각 계층 간의 관계와 기능을 정의함으로써 모듈성, 유지 관리성, 확장성을 확보하여 시스템의 설계 효율성과 안정성을 향상시킵니다.

계층형 프로토콜의 장점: 각 계층은 독립적이고, 유연성이 좋으며, 구조적으로 분리 가능하고, 구현과 유지 관리가 쉽고, 표준화를 촉진합니다 .

계층적 모듈식 설계는 여러 사람의 협업과 지속적인 개선이 필요한 대규모 엔지니어링 프로젝트를 처리하는 기술 분야에서 흔히 사용되는 접근 방식입니다. 이는 검증되고 효과적인 방법입니다. TCP/IP 프로토콜은 인류 역사상 성공적인 대규모 계층적 프로토콜의 대표적인 사례이며, 인터넷 전체의 기반이 되었습니다.

미래의 웹 3.0(가치의 인터넷이라고도 불릴 수 있음)은 비트코인을 첫 번째 계층으로 하는 네트워크 기반으로 구축될 것입니다. 비트코인의 계층적 설계 개념은 이미 초기 개발 단계에 있습니다. 2계층 아키텍처의 탐색적 사례가 이미 여러 개 존재하는데, 대표적인 예로는 블록체인 기반 2계층, 분산 시스템 기반 2계층(예: 라이트닝 네트워크), 그리고 LNP/BP 프로토콜 기반 RGB가 있습니다. RGB가 BP 프로토콜 기반이면 2계층 아키텍처이고, LNP 프로토콜 기반이면 3계층 아키텍처입니다.

하지만 이번 TAP이 가져온 변화는 버전 1.0에서 2.0으로의 진화처럼 계층화된 프로토콜과는 거리가 멉니다. TAP 프로토콜과 비트코인 메인넷은 매우 유사하고 긴밀하게 연결되어 있기 때문입니다. 이는 다음 사항에서 확인할 수 있습니다.

1. 데이터 구조 측면에서 TAP은 메인넷과 동일한 UTXO 구조인 vUTXO를 채택합니다. 이러한 vUTXO의 생성, 전송, 병합 및 분할은 비트코인 메인넷과 동일하며, 메인넷의 UTXO를 통해 탈중앙화된 스와핑이 가능합니다. SegWit의 vByte에서 TAP의 vUTXO로의 전환은 동일한 설계 철학의 연장이자 발전입니다.

2. 주소 유형 및 실행되는 스크립트 명령어 측면에서 TAP은 비트코인 메인넷과 높은 유사성을 유지하며, 아키텍처는 확장 가능성을 제공합니다. 비트코인 메인넷에서 폐기된 명령어를 복구할 수 있을 뿐만 아니라 필요에 따라 새로운 명령어를 추가할 수도 있습니다. 또한, 이러한 명령어는 별도의 가상 머신(VM) 내에서 실행됩니다.

3. 비트코인 메인넷의 합의 프로토콜을 사용합니다. TAP은 확장성과 성능 확장 측면에서 많은 혁신을 이루었지만, 독립적인 블록체인이나 외부 시스템은 아닙니다. 모든 변경 사항은 비트코인 메인넷의 합의 프로토콜을 사용해야 하며, 비트코인 메인넷을 기반으로 작동하는 확장 기능입니다.

따라서 TAP 관련 기능을 설계할 때, TAP 프로토콜을 바라보고 조직적인 분업을 처리하기 위해 계층화된 프로토콜 방법론을 채택했습니다. 하지만 사물의 진화라는 관점에서 볼 때, 이러한 변화를 BTC2.0의 발전으로 보는 것이 두 프로토콜 간의 긴밀한 관계와 의존성을 유지하는 데 도움이 되고, BTC2.0 개발에 필요한 자원의 조율 및 정리를 용이하게 할 것이라고 생각합니다.

위의 세 가지 관점에서 RGB 프로토콜을 분석해 보면 차이점을 알 수 있습니다. RGB 프로토콜은 1번과 2번의 특징이 전혀 없으며, 비트코인 메인넷의 합의 프로토콜을 사용한다는 점에서만 유사합니다. 이는 RGB가 비트코인 메인넷의 연장선이 아니라 완전히 계층화된 프로토콜임을 보여줍니다.

3. BTC 1.0과 BTC 2.0

TAP 프로토콜이 가져온 중요한 변화는 비트코인의 새로운 발전을 위한 탄탄한 기반과 출발점을 제공했습니다. 이전 섹션의 분석에서 알 수 있듯이, 비트코인 메인넷은 TAP에 크게 의존합니다. 이 글에서는 BTC1.0과 BTC2.0을 사용하여 비트코인 메인넷과 TAP 생성으로 인한 비트코인 네트워크의 확장 및 변화를 구분해 보겠습니다.

3.1. 기본 정의

여기서는 BTC1.0을 비트코인 메인넷에서의 개발로 정의합니다. 비트코인 메인넷에서의 모든 변경 및 탐색은 BTC1.0의 범위에 속합니다. TAP 기술이 등장하기 전에는 거의 모든 탐색이 BTC1.0을 기반으로 진행되었습니다. 여기에는 BTC1.0의 특정 가능성을 검증하기 위한 다양한 비트코인 포크도 포함됩니다.

BTC2.0은 비트코인 메인넷 외부, 특히 TAP(그리고 향후 유사한 프로토콜)과 같은 프로토콜을 탐구하는 것으로 정의됩니다. 이 범위는 비트코인 메인넷 자체의 변경과는 무관하며, 주로 비트코인 메인넷 외부에서 확장성 및 성능 향상을 탐구하는 데 중점을 두고 있습니다. 하지만 비트코인 메인넷의 합의 프로토콜과 기본 기능에 크게 의존합니다. 비트코인 메인넷과의 관계는 매우 밀접하기 때문에 독립적인 개념을 사용하여 비트코인 개발과 분리하기 어렵습니다.

3.2. 구별 방법

BTC 1.0의 개발 원칙은 탈중앙화, 검열 저항성, 프라이버시와 같은 비트코인 메인넷의 근본적인 특성을 유지하여 비트코인 메인넷의 안전하고 안정적인 운영을 보장하는 것입니다. 이 개발 원칙이 명확하게 설명되거나 명확하지 않다면, 계층화된 프로토콜 관점에서 최하위 프로토콜이 가져야 할 특성을 검토해야 합니다. 최하위 프로토콜의 특성을 고려할 때, 명령어를 확장하고 튜링 완전 계산을 달성하려는 거의 모든 시도는 BTC 1.0의 개발 원칙에 부합하지 않습니다. 컴파일러 원칙의 관점에서 볼 때, 가상 머신을 2단계(상태 분기 및 조건 분기 도입)로 진화시키려는 모든 노력 또한 이 원칙에 부합하지 않습니다. 더 나아가, 이 표준을 통해 비트코인 역사에서 명령어를 역사적으로 정리한 것은 더욱 엄격한 BTC 1.0 표준을 유지하기 위한 것이었습니다.

BTC2.0의 개발 원칙은 BTC1.0의 개발 원칙을 위반하는 비트코인 메인넷의 모든 변경 사항을 충족하는 것입니다. 예를 들어, OP_CAT 명령어 확장, 즉 비트코인 메인넷을 튜링 완전 시스템으로 개발하려는 욕구가 있습니다. 또한, 비트코인 메인넷에 적합하지 않은 모든 확장성 및 전력 향상 요구 사항도 BTC2.0에서 구현할 수 있습니다.

TAP 프로토콜에서 공간은 이미 우주를 통해 무한대로 확장되었으며, 이제 TAP-VM을 튜링 완전 시스템으로 발전시킬지 여부만이 문제입니다. 다음 섹션에서는 TAP-VM이 튜링 완전 시스템으로 발전할 가능성과 그 단계를 주로 분석할 것입니다.

참고: TAP는 TAP-VM을 포함한 완전한 프로토콜이므로, 이후 내용에서는 TAP이라는 용어를 사용합니다.

• TAP이 튜링으로 발전한 단계가 완료되었습니다.

TAP에서 튜링 완전성으로의 진화를 논의하는 것은 프로그래밍 언어와 가상 머신 설계에 대한 핵심 지식을 포함하는 매우 전문적인 주제입니다. 컴파일러 이론과 컴파일러 개발 역사의 관점에서 볼 때, 가상 머신(VM)이 비튜링 완전성에서 튜링 완전성으로 진화하는 과정은 일반적으로 단순성에서 복잡성으로, 보안성에서 강력함으로, 그리고 특수성에서 범용성으로 변화하는 과정을 포함합니다. (이 문장은 이 글에서 여러 번 반복됩니다.)

컴파일러 원리에 대한 이론적 분석을 통해, 가상 머신은 비튜링 완전 시스템에서 튜링 완전 시스템으로 확실히 진화할 수 있습니다. 따라서 한 가지 질문만 남습니다. TAP가 튜링 완전 시스템으로 진화해야 할 필요성이 있을까요? (이 질문은 본 기사에서 다루지 않습니다.)

TAP를 튜링 완전성까지 개발해야 한다면, 어떤 프로세스와 방법을 따라야 하고, 개발 과정에서 어떤 교훈을 얻을 수 있을까?

4.1. 컴파일러 원리의 관점에서 본 튜링 완전성

튜링 완전: 모든 계산 가능한 문제를 계산할 수 있는 가상 머신 또는 프로그래밍 언어를 튜링 완전이라고 합니다. 튜링 계산 가능한 모든 함수를 계산할 수 있는 컴퓨팅 시스템을 튜링 완전이라고 합니다. 튜링 완전 언어는 해당 언어의 계산 능력이 범용 튜링 머신과 동등함을 의미하며, 이는 현대 컴퓨터 언어가 가질 수 있는 가장 높은 수준의 능력입니다.

계산 가능성 이론에서, 모든 데이터를 특정 순서로 계산할 수 있도록 하는 데이터 연산 규칙 집합(명령어 집합, 프로그래밍 언어 또는 셀룰러 오토마타)을 튜링 완전성이라고 합니다. 튜링 완전 명령어 집합을 가진 장치는 범용 컴퓨터로 정의됩니다. 튜링 완전하다면, 그 컴퓨터 장치는 조건 점프("if" 및 "goto" 문)를 수행하고 메모리 데이터를 수정할 수 있습니다. 튜링 완전성을 보이는 것은 원시 컴퓨터를 시뮬레이션할 수 있는 능력을 가지며, 가장 단순한 컴퓨터조차도 가장 복잡한 컴퓨터를 시뮬레이션할 수 있습니다. 모든 범용 프로그래밍 언어와 최신 컴퓨터의 명령어 집합은 튜링 완전하며(C++ 템플릿도 튜링 완전함) 제한된 메모리 문제를 해결할 수 있습니다. 튜링 완전 머신은 무한한 메모리를 가지도록 정의되지만, 명령어 집합은 일반적으로 특정하고 유한한 양의 RAM에서만 작동하도록 정의됩니다.

가상 머신(VM)이 튜링 완전하지 않은 상태에서 튜링 완전 상태로 진화하는 과정은 일반적으로 복잡성, 보안, 그리고 범용 기능의 증가 과정을 수반합니다. 여기에는 두 가지 주요 문제가 수반됩니다.

1. 왜 비튜링 완전 시스템으로 시작해야 할까요? 안전성과 신뢰성 때문입니다. 비튜링 완전 시스템은 모든 프로그램의 종료(중단 문제 결정 가능)를 보장하며, 무한 루프가 발생하지 않습니다. 이는 스마트 계약, 구성 언어, 템플릿 엔진과 같은 시나리오에 매우 중요합니다.

2. 튜링 완전성을 추구하는 이유는 무엇일까요? 표현력과 기능성 때문입니다. 튜링 완전 시스템만이 다양하고 복잡한 논리와 알고리즘을 구현하여 범용 프로그래밍 플랫폼이 될 수 있습니다.

따라서 비튜링 완전성에서 튜링 완전성으로의 VM 진화는 본질적으로 "절대적인 보안 및 제어 가능성"에서 "강력하고 범용적인" 설계 목표로 확장되는 과정입니다 . 현대 VM의 궁극적인 목표는 두 가지를 동시에 달성하는 것입니다. 즉, 튜링 완전성의 강력한 기능을 제공하는 동시에 독창적인 설계를 통해 보안과 제어 가능성을 극대화하는 것입니다.

4.2. 비튜링 완전에서 튜링 완전으로의 VM 진화의 여러 가지 뚜렷한 단계

가상 머신(VM)이 튜링 완전하지 않은 상태에서 튜링 완전 상태로 진화하는 과정은 일반적으로 복잡성, 보안성, 그리고 범용 기능이 증가하는 과정을 수반합니다. 이는 다음과 같은 일반적인 단계로 요약할 수 있습니다.

1. 1단계: 순수 계산기(튜링 완전하지 않음)

특징: 기본적인 표현식 계산 기능만 있고, 상태가 없으며 제어 흐름이 없습니다.

• 기능: 기본 산술 연산(덧셈, 뺄셈, 곱셈, 나눗셈), 논리 연산, 비트 연산 등을 지원합니다. 고급 계산기처럼 기능하며, 각 계산은 독립적이며 이전 상태에 따라 달라지지 않습니다.
• 무상태: 메모리 개념이 없거나 메모리가 읽기 전용이고 수정할 수 없습니다. 변수를 정의하거나 수정할 수 없습니다.
• 제어 흐름 없음: 조건 분기(if/else), 루프(for/while) 또는 점프 명령어가 없습니다. 명령어는 순차적으로만 실행될 수 있습니다.
• 튜링 완전하지 않은 이유: 루프나 조건부 판단을 구현할 수 없고, 튜링 머신의 무한히 긴 종이 테이프와 상태 전환을 시뮬레이션할 수 없습니다.
• 역사적 사례: 가장 초기의 매우 간단한 구성 또는 표현식 평가 엔진 중 일부입니다.

2. 2단계: 상태 및 조건 분기 도입(완성을 향한 핵심 단계)

특징: 변경 가능한 상태(메모리)와 간단한 조건 판단이 추가되었지만, 진정한 루프가 부족했습니다.

능력:

(1) 상태: 읽고 쓸 수 있는 메모리(예: 스택, 레지스터, 힙)를 도입하여 변수를 정의하고 수정할 수 있도록 합니다. 이를 통해 계산이 고립되지 않고 기록에 따라 실행됩니다.

(2) 조건 분기: 이는 조건 기반 점프 명령어(예: if_eq, if_lt, jmp를 지정된 오프셋으로 이동)를 도입합니다. 이는 논리적 판단을 구현하는 데 중요합니다.

• 튜링 완전하지 않을 수 있는 이유: VM의 명령어 집합이나 설계가 의도적으로 역방향 점프를 금지하는 경우, 즉 후속 명령어(정방향 점프)로만 점프할 수 있는 경우, 루프를 형성할 수 없습니다. 루프가 없으면 튜링 완전성에 필요한 "무한 계산"의 잠재력을 실현할 수 없습니다(물리적으로는 유한하지만 이론적으로는 무한합니다).
• 역사적/현대적 예: 스크립팅 언어인 비트코인 스크립트는 초창기의 대표적인 예입니다. 무한 루프로 인해 네트워크가 차단되는 것을 방지하기 위해 의도적으로 루프 없이 조건 분기와 순방향 점프만 가능하도록 설계되었으며, 이를 통해 스크립트가 제한된 단계 내에 실행을 완료할 수 있도록 했습니다.

참고: 저는 개인적으로 비트코인 스크립팅 언어가 1단계에서 주로 작동하며, 2단계의 특징을 보이는 부분은 일부에 불과하다고 생각합니다. 대략 1단계는 90% 이상을 차지하고, 2단계는 10% 미만을 차지합니다. 예를 들어, Taproot에 나중에 도입된 MAST(Merkel Abstract Syntax Tree)는 비트코인 메인넷에서는 제대로 작동하지 않지만 TAP에서는 중요한 역할을 합니다. 그 주된 이유는 비트코인 메인넷이 가상 머신을 1단계의 성능 범위 내에서 유지하려는 목표를 가지고 있기 때문입니다.

3. 3단계: 루프 또는 재귀 도입(튜링 완전성 달성)

특징: 루프 구조를 형성하는 기능을 제공합니다.

능력:

(1) 뒤로 점프: 점프 명령어가 이전 명령어 주소로 다시 점프할 수 있도록 합니다. 이는 루프를 직접 형성할 수 있습니다.

(2) 루프 명령어 : 전용 루프 명령어(예: 루프)를 제공합니다.

(3) 간접 점프/함수 호출: 함수 호출과 재귀를 지원함으로써 동일한 루프 효과를 얻을 수 있습니다. 이는 재귀가 루프를 동등하게 대체할 수 있기 때문입니다.

• 이 시점에서 튜링 완전성을 달성하는 이유는 무엇일까요? 조건 분기와 역방향 점프/루프/재귀를 수행할 수 있게 되면, 이 VM은 조건 판단과 반복 실행을 구현할 수 있습니다. 이론적으로 이 두 가지 측면을 결합하면 모든 튜링 머신의 계산 과정을 시뮬레이션하여 튜링 완전성을 달성할 수 있습니다.
• 역사적 사례: 거의 모든 범용 언어(예: JVM, Python VM, .NET CLR)의 가상 머신은 범용 프로그래밍 언어를 실행하도록 설계되었기 때문에 처음부터 튜링 완전했습니다. 가상 머신의 발전은 주로 성능 및 보안 기능 향상에 중점을 두었습니다.

4. 4단계: 튜링 완전성 기반 개선(보안, 성능, 기능)

튜링 완전성이 달성되면 VM 개발의 초점은 더 이상 계산 능력에 맞춰지지 않고 다른 측면에 맞춰질 것입니다.

• 성능: JIT(Just-In-Time) 컴파일, AOT(Ahead-of-Time) 컴파일, 최적화된 컴파일러, 더욱 효율적인 가비지 컬렉션 알고리즘을 소개합니다.
• 보안: 샌드박싱 메커니즘 강화, 기능 시스템 도입, 그리고 더욱 세분화된 메모리 격리 및 제어. WebAssembly는 튜링 완전 기능을 제공하는 동시에 선형 메모리, 구조화된 제어 흐름, 샌드박스 환경을 통해 보안과 결정론을 크게 향상시키는 훌륭한 현대적 사례입니다.
• 특징: 코루틴, async/await, 제네릭, 리플렉션과 같은 고급 언어 기능을 지원합니다.
• 결정론: 일부 블록체인 가상 머신(예: 이더리움 EVM의 후속 모델)의 경우 튜링 완전성을 기반으로 결정론(모든 노드에서 일관된 결과)과 종료(가스 메커니즘을 통해 실제 실행 단계를 제한)를 추구하는 것이 초점이 됩니다.

컴파일러 원리 관점에서 보면 VM 개발은 네 단계로 구성됩니다. 이 개발 경로를 참고하면 TAP 개발의 여러 단계(즉, BTC2.0 개발의 여러 단계)도 대략적으로 파악할 수 있습니다.

4.3. TAP의 첫 번째 단계: 확장된 BTCScript 명령어에 대한 간단한 탐색

앞서 언급했듯이, 초기 비트코인 메인넷 명령어는 성능을 초과하여 범용 가상 머신(VM)의 2단계 성능과 부분적으로 유사했습니다. 이로 인해 이후 명령어가 간소화되었습니다. 비트코인 메인넷의 간소화된 BTCScript 명령어는 이제 컴파일러 원칙의 1단계 성능 요구 사항을 충족하며, 이는 비트코인 메인넷의 보안과 안정성을 보장하기 위한 것입니다.

TAP은 BTC 2.0의 시작이므로, 컴파일러 원리 단계 차별화 관점에서 볼 때 현재 TAP-VM은 범용 VM의 두 번째 단계로 발전해야 합니다. 이 단계를 탐색할 때 TAP-VM은 BTCScript 명령어를 적절하게 확장하여 이전에 삭제된 BTCScript 명령어를 복원할 수 있습니다. 예를 들어 OP_CAT과 같이 널리 예상되는 명령어를 점진적으로 추가할 수 있습니다. 추가된 각 명령어는 기능과 보안을 테스트하기 위해 더 많은 애플리케이션이 필요합니다. 이 단계에서는 TrustlessSwap과 같은 간단한 작업을 수행할 수 있습니다. 또한 더욱 다재다능한 MAST 트리를 사용하는 등 Taproot 기술의 활용 사례를 확대할 수 있습니다.

이 단계에서는 간단한 탈중앙화 거래, 기본 대출, 기본 스테이킹 등 기본적인 BTCFi 기능을 구현할 수 있습니다. 현재 이러한 기능은 TrustlessSwap과 Tapscript의 일부를 통해 구현할 수 있습니다.

4.4. TAP의 두 번째 단계: 분산형 BTCFi 명령어 세트 구축

대부분의 금융 애플리케이션을 지원하기 위한 TAP-VM 개발에는 컴파일러 원리와 애플리케이션 관점 모두에서 필요한 추가 명령어를 도출해야 합니다. 하지만 이 단계가 튜링 완전할 필요는 없습니다. 대출, 스테이킹, Mint 스테이블코인, 그리고 더 복잡한 스왑 기능과 같은 일반적인 BTCFi 애플리케이션을 지원해야 합니다.

이 단계는 일반 VM의 두 번째 단계와 매우 유사하며, 상태 및 조건 분기 도입이 필요합니다. 이러한 상태 및 조건 분기는 MAST 추상 구문 트리에 도입되었습니다. 이러한 MAST 트리는 BTC 1.0의 Taproot 기술에 이미 존재했지만, 이러한 조건문은 비트코인 메인넷의 BTC-VM이 독립적인 TAP-VM에서 분리된 후에야 더욱 효과적으로 작동할 수 있습니다.

4.5. TAP의 세 번째 단계: 더 풍부한 명령어 세트와 예비 튜링 완전성

금융 애플리케이션 외에도 더 복잡한 애플리케이션을 지원하기 위한 TAP-VM의 발전은 애플리케이션의 TAP-VM 구동력에 달려 있습니다. 이 단계는 점진적으로 튜링 완전성 또는 예비 튜링 완전성에 접근하게 될 것입니다.

컴파일러 원리 관점에서 볼 때, 이 단계는 범용 VM의 세 번째 단계로, 루프 및 재귀와 같은 기능을 도입하고, 역방향 및 간접 점프, 전용 루프 명령어, 심지어 함수 기능까지 지원합니다. 2단계에서 지원되는 조건부 및 분기 기능과 결합하면, 이 시점에서 TAP-VM은 이론적으로 모든 계산을 시뮬레이션하여 튜링 완전성을 달성할 수 있습니다. 또는 개발 특성상 튜링 완전성의 초기 단계에 머물더라도 복잡한 함수를 수행할 수 있는 풍부한 명령어 세트를 이미 보유하고 있을 수 있습니다.

이 단계에서 TAP-VM이 튜링 완전성으로 발전하더라도 RGB의 튜링 완전성과는 여전히 상당한 차이가 있을 것입니다. 이는 C++와 Java 같은 언어를 비교하는 것과 유사합니다. 5.1절에서 더 자세히 비교하겠습니다.

4.6. TAP의 네 번째 단계: 성숙한 튜링 완전성 + 풍부한 라이브러리

이 개발 단계에서 TAP-VM은 튜링 완전성을 달성했을 뿐만 아니라, 이론적으로 모든 애플리케이션 기능을 완성할 수 있는 풍부한 클래스 라이브러리(또는 함수 라이브러리)를 갖추게 되었으며, 비교적 풍부한 애플리케이션 예제를 제공합니다. 풍부한 애플리케이션 예제와 클래스 라이브러리 지원 덕분에 개발자는 더욱 쉽게 많은 애플리케이션을 개발할 수 있습니다.

범용 VM 프로젝트의 네 번째 단계와 마찬가지로, 이 단계에서 TAP-VM 개발의 초점은 더 이상 컴퓨팅 성능에 있지 않고, 성능, 보안, 결정론과 같은 더 높은 수준의 가상 머신 지표에 맞춰져 있습니다. 이 과정이 다소 먼 미래로 미뤄질 수 있을까요?

현재 개발 단계에서 TAP의 강력한 기능은 RGB와 상당한 중복을 초래했습니다. 많은 애플리케이션이 TAP 또는 RGB를 사용하여 구현될 수 있습니다. 이러한 중복은 주로 금융 애플리케이션, 특히 비트코인 메인넷에서 발행된 자산에 집중되어 있습니다. 그러나 TAP와 RGB는 더 광범위한 애플리케이션 시나리오에서 여전히 상당한 차이를 보입니다. 다음 섹션에서 이러한 차이점을 분석해 보겠습니다.

5. 튜링 완전 시스템에도 다양한 응용 시나리오가 있습니다.

BTC 생태계에서 우리는 주로 두 가지 튜링 완전 시스템인 TAP와 RGB를 비교하여 어떤 시스템이 다양한 응용 시나리오에 적합한지 설명하거나, 더 나아가 TAP의 응용 시나리오를 설명합니다.

Web2 도메인에서의 경험과 가상 머신(VM)에 대한 풍부한 데이터를 바탕으로, C/C++ 개발 언어 + 런타임 환경은 Java 개발 언어 + 런타임 환경과 효과적으로 비교될 수 있습니다. TAP과 RGB를 비교한 것처럼, 이러한 비교는 몇 가지 귀중한 통찰력을 제공합니다.

5.1. C/C++와 Java 간 애플리케이션 시나리오 비교

핵심 기능 비교표

응용 프로그램 시나리오 요약

1. C/C++ 도메인(직접적인 하드웨어 조작이나 극한의 성능이 필요함)

(1) 시스템 레벨 소프트웨어/인프라 개발

• 운영 체제(예: Linux, Windows 커널)
• 데이터베이스 관리 시스템(예: MySQL, PostgreSQL)
• 컴파일러/인터프리터(GCC, JVM 등)는 실제로 C++로 작성됩니다.
• 웹 서버/고성능 네트워크 프레임워크(예: Nginx, Node.js 기반 계층)

(2) 하드웨어 드라이버 및 임베디드 시스템

• 장치 드라이버: 하드웨어 레지스터와 직접적인 상호 작용이 필요합니다.
• 임베디드/사물 인터넷(IoT) 장치: 이러한 장치는 리소스(예: 마이크로컨트롤러, MCU)가 매우 제한적이며 메모리와 전력 소비에 대한 정밀한 제어가 필요하고 JVM의 오버헤드를 감당할 수 없습니다.

(3) 고성능 컴퓨팅 및 게임 개발

• 게임 엔진(예: Unreal 및 Unity의 기반 시스템)은 복잡한 그래픽 및 물리 계산을 수행하기 위해 하드웨어 성능을 최대한 활용해야 합니다.
• 과학적 컴퓨팅/금융 거래 시스템: 마이크로초 수준의 지연 시간도 중요합니다.
• 그래픽/이미지/오디오/비디오 처리: Photoshop, FFmpeg 등.

(4) 메모리 및 리소스에 대한 세분화된 제어가 필요한 시나리오

어떤 시나리오에서는 수동 메모리 관리가 가비지 수집보다 예측 가능하며 GC로 인해 발생하는 지연 시간을 피할 수 있습니다.

2. Java의 본거지(높은 개발 효율성, 크로스 플랫폼 호환성, 엔터프라이즈급 안정성 요구)

(1) 대규모 엔터프라이즈 애플리케이션을 위한 백엔드 개발

• 웹 애플리케이션 백엔드: Spring Boot 프레임워크는 대규모, 분산형, 고동시성 백엔드 서비스를 구축하는 데 사용되는 Java 엔터프라이즈 개발 분야의 절대적인 선두주자입니다.
• 마이크로서비스 아키텍처: Java 및 JVM(예: Spring Cloud)을 기반으로 하는 수많은 마이크로서비스 프레임워크.
• 분산 시스템: 빅데이터 분야의 Hadoop, Kafka 등이 있습니다.

(2) 안드로이드 애플리케이션 개발

안드로이드의 공식 역사적으로 선호되는 언어입니다(현재는 Kotlin이 선호되는 언어이지만, 기반 코드와 생태계의 상당 부분은 여전히 Java입니다).

(3) 빅데이터와 클라우드 컴퓨팅

Hadoop, Spark, Flink와 같은 빅데이터 처리 프레임워크의 핵심 구성 요소는 대부분 Java 또는 Scala(JVM 언어)로 작성됩니다.

(4) 높은 신뢰성과 긴 수명을 요구하는 시스템

은행, 금융, 전자상거래와 같은 핵심 시스템의 경우 견고성, 보안성, 강력한 커뮤니티 생태계 지원이 매우 중요합니다.

(5) 크로스 플랫폼 데스크톱 애플리케이션

웹만큼 대중적이지는 않지만 Swing/JavaFX는 여전히 크로스 플랫폼 GUI 프로그램을 개발하는 데 사용할 수 있습니다.

3. 어떻게 선택해야 하나요?

• C/C++를 선택할 때:

성능이 최우선 순위입니다(게임, 거래 시스템).

운영 체제나 하드웨어(드라이버, 임베디드 시스템)와 직접 상호 작용해야 합니다.

리소스가 매우 제한적이어서 JVM의 메모리와 CPU 오버헤드를 견딜 수 없습니다.

프로그램의 동작(메모리 레이아웃, 실행 흐름)을 완벽하게 제어할 수 있어야 합니다.

• Java를 선택할 때:

대규모의 복잡한 엔터프라이즈 애플리케이션(웹 백엔드, 마이크로서비스)을 개발해야 합니다.

궁극적인 성과보다 개발 효율성, 유지보수성, 팀워크가 더 중요합니다.

여러 플랫폼에 걸쳐 강력한 기능을 제공해야 하며 각 플랫폼에 대해 별도로 컴파일하고 싶지 않습니다.

메모리 관리 오류를 피하고 오픈 소스 라이브러리와 프레임워크의 풍부한 생태계를 즐기고 싶습니다.

이 프로젝트는 높은 신뢰성과 장기적으로 안정적인 운영이 필요합니다.

간단히 말해서, C/C++는 하드웨어나 운영 체제 계층과 같은 하위 수준에서 작업하는 데 더 적합하고, Java는 비즈니스 및 애플리케이션 계층에서 작업하는 데 더 적합합니다.

5.2. TAP와 RGB 간 응용 시나리오 비교

핵심 기능 비교표 (앞으로 여러분의 도움을 받아 이 비교표를 점차 개선해 나가고 싶습니다).

응용 시나리오 요약 (TAP-VM이 아직 완전히 개발되지 않았고 RGB에 대한 응용 사례가 많지 않기 때문에 다음은 모두 특성에 따른 추측입니다.)

1. TAP의 홈 터프(기본적인 비트코인 유사 기능 필요)

(1) 현금모델에서의 자산발행

(2) 비트코인 네트워크의 BTCFi

(3) 탈중앙화된 기반 프로토콜

2. RGB의 홈 터프(거의 모든 Dapp 유형에 적합)

(1) 비트코인 네트워크에서의 스마트 계약 적용

(2) 더욱 발전되고 복잡한 자산 발행 및 DeFi 애플리케이션

(3) 분산형 ID 및 DAO 거버넌스와 같은 상위 수준 웹3 애플리케이션.

(4) 기타 더 광범위한 웹3 애플리케이션

3. 어떻게 선택해야 하나요?

• TAP-VM을 선택하세요:

비트코인 UTXO와 직접 상호 작용합니다.

현금 모델 자산 발행.

비트코인 스크립트 유형의 기능을 직접 확장합니다.

분산형 비트코인 금융 애플리케이션.

• RGB 선택:

복잡한 논리를 필요로 하는 스마트 계약.

더욱 진보되고 복잡한 DeFi.

비재무적 Web3 애플리케이션.

요약하자면: TAP-VM은 비트코인 메인넷의 애플리케이션이나 비트코인 메인넷 기반 애플리케이션의 직접적인 확장에 더 가깝습니다. RGB는 사용자 계층에 더 가까운 복잡한 논리 기능이 있는 애플리케이션에 적합합니다.

6. BTC 2.0을 더 잘 개발하려면 어떻게 해야 하나요?

이 부분은 저자의 주관적인 판단, 특히 과거 작업 및 프로젝트 엔지니어링 경험에 크게 의존합니다. 따라서 부족한 부분과 편견이 있을 수 있습니다. 특히 이 분야에서 제품을 개발한 분들의 피드백을 통해 이러한 예측과 판단을 더욱 다듬어 나가기를 기대합니다.

앞서 논의한 내용을 바탕으로 비트코인을 BTC1.0과 BTC2.0 단계로 나눌 수 있다면 몇 가지 분명한 이점이 있을 것입니다.

6.1. 명확한 업무 분담과 표준화된 절차

이러한 단계적 구분의 또 다른 장점은 업무와 책임의 구분을 명확히 한다는 것입니다.

1. 판단 및 의사 결정 원칙이 확립되면 설계자는 BTC 1.0 원칙에 부합하는 기능을 비트코인 메인넷에, BTC 2.0 설계 원칙에 부합하는 기능을 TAP 프로토콜에 쉽게 통합할 수 있습니다. 이는 분쟁을 줄일 뿐만 아니라 조직 간 협업을 더욱 원활하게 촉진합니다.

BTC2.0은 TAP 개발을 위한 보다 명확한 단계적 계획을 세우기 위해 컴파일러 원칙과 다른 성숙한 제품의 개발 프로세스를 참조할 수도 있습니다.

2. 일부 프로토콜과 표준은 더 나은 명칭으로 명명될 수 있으며, 검토 기준도 마련되어 있습니다. 예를 들어, TAP의 7개 프로토콜은 현재 다음과 같이 명명되어 있습니다.

• BIP-TAP-ADDR：Taproot 자산 온 체인 주소 초안
• BIP-TAP-MS-SMT：머클 섬 희소 머클 트리 초안
• BIP-TAP-PROOF：Taproot 자산 플랫 파일 증명 형식 초안
• BIP-TAP-PSBT：Taproot Assets PSBT 초안
• BIP-TAP-UNIVERSE: Taproot 자산 유니버스 초안
• BIP-TAP-VM: Taproot 자산 스크립트 v1 초안
• BIP-TAP：TAP: Taproot Assets 프로토콜 초안

만약 BTC2.0 분류 방법이 모든 사람에게 받아들여진다면, 확실히 BIP2로 시작해서 명명될 수 있을 것입니다.

• BIP2: Taproot 자산 온 체인 주소 초안
• BIP2: TAP 머클 합 희소 머클 트리 초안
• BIP2: Taproot 자산 플랫 파일 증명 형식 초안
• BIP2: Taproot Assets PSBT 초안
• BIP2: Taproot 자산 유니버스 초안
• BIP2: Taproot 자산 스크립트 v1 초안
• BIP2: TAP: Taproot Assets 프로토콜 초안

6.2. 자원 통합 및 재편 계획

현재 비트코인 메인넷은 비트코인 코어 팀에서 주로 관리하고 있습니다(2025년 6월 기준 전체 네트워크의 90%가 비트코인 코어를 사용합니다). TAP 프로토콜은 라이트닝 네트워크 랩스에서 관리합니다.

비트코인 코어 소프트웨어는 15년 이상 운영되어 왔으며, 핵심 기능은 비교적 안정적입니다. 향후 상당한 기능 추가가 필요한 시나리오는 거의 없을 것으로 예상되며, 만약 주요 수정이 필요하다면 TAP 프로토콜에서 발생할 가능성이 높습니다. TAP 프로토콜은 아직 개발 초기 단계에 있으며, 계획대로 진행된다면 상당한 개발 리소스가 필요할 것입니다. 기존 개발 리소스를 효과적으로 재활용할 수 있다면 BTC 2.0 개발에 큰 도움이 될 것입니다. 더 중요한 것은 비트코인 메인넷 개발자들이 개발 환경과 프로그래밍 언어 측면에서 TAP 개발팀과 상당한 유사점을 공유한다는 것입니다. 주요 차이점은 개발 지침의 변화뿐입니다.

TAP는 현재 라이트닝 네트워크의 프로토콜일 뿐, 네트워크 전체가 아니기 때문에 상당한 어려움이 예상됩니다. TAP를 독립적인 BTC 2.0 프로젝트로 발전시킬 수 있을지, 그리고 개발 및 리소스가 어떻게 통합될지는 상당한 조율이 필요할 것입니다.

TAP이 실제로 BTC 2.0으로 발전한다면, 비트코인 메인넷 프로젝트(BTC 1.0), 새로운 BTC 2.0, 그리고 라이트닝 네트워크는 상대적으로 독립적이면서도 긴밀하게 연결된 세 가지 프로젝트가 될 것입니다. BTC 2.0은 라이트닝 네트워크와 더욱 긴밀한 기능적 통합을 이루게 될 것이며, BTC 2.0의 새로운 기능을 기반으로 라이트닝 네트워크 또한 더욱 발전할 것입니다.

6.3. 개발 및 경쟁

섹션 5에서는 TAP의 몇 가지 특징을 직접 경쟁자들과 비교했는데, 이는 BTC 2.0과 외부 계층 프로토콜 간의 비교로도 볼 수 있습니다. 현재 개발 단계에서 RGB와 TAP는 자산 발행, 자산 거래, 그리고 더 광범위한 BTCFi 생태계 등 여러 영역에서 상당한 직접 경쟁에 직면하게 될 것입니다. TAP은 비트코인 메인넷과 밀접하게 연관된 영역에서 많은 프로토콜보다 우수한 성능을 보이지만, TAP이 1단계 개발을 신속하게 완료하지 못할 경우 튜링 완전 RGB가 이 영역을 먼저 장악하게 될 것입니다. RGB가 비트코인 메인넷 합의 프로토콜에 의존하는 것만으로도 그 기능이 더 매력적이기 때문에 수많은 비트코인 네이티브 애호가들을 끌어들이기에 충분합니다. TAP이 2단계 개발을 완료하지 못하거나 뒤처질 경우 RGB 역시 뒤처지게 될 것입니다.

TAP은 BTC 2.0으로 진화할까요? 개발 과정은 어떻게 될까요? 최종 형태는 여러 외부 요인에 따라 달라집니다. 비트코인 공간의 이러한 잠재적 발전은 상상력과 도전으로 가득 차 있지만, 어떤 과정을 거치든 TAP은 우리에게 새로운 문을 열어주었습니다.

결론: TAP이 BTC 2.0의 발전을 나타낸다면, TaprootAssets Protocol이라는 이름은 현재 상황을 너무 구체적으로 표현하고 있지 않은가요? BTC 2.0의 발전을 더 잘 나타내기 위해 다른 이름으로 업그레이드되어야 하지 않을까요?

참고문헌

참고: 본 논문은 TAP에 대한 포괄적인 예측 및 분석을 제공하므로, 내용의 상당 부분은 특정 논문에 국한되지 않고 일반적인 지식 요약입니다. 본 논문의 일부 내용은 AI 비서를 활용했으며, 내용의 정확성은 본 논문에 포함되기 전 저자의 업계 경험을 바탕으로 판단되었습니다. 여기에는 C/C++와 Java 간의 애플리케이션 시나리오 비교가 포함됩니다.

컴파일러 원리에 대한 섹션에서는 대학 컴퓨터 과학 프로그램의 교과서 자료와 온라인 기사의 일부를 참조했습니다.

기타 관련 기사는 다음과 같습니다.

1. https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki , Taproot Assets Protocol과 관련된 7개 프로토콜.

2. 비트코인의 분리증명 기술과 세 가지 버전 업그레이드에 대한 철저한 이해

3. "비트코인 레이어 2 구조의 기본에 대한 포괄적인 개요(V2.0)"