비트코인 상의 범용 컴퓨팅을 향한 길: 비트코인 확장을 위한 STARK 구상

2024.07.29

비트코인 상의 범용 컴퓨팅을 향한 길: 비트코인 확장을 위한 STARK 구상

이 글은 비트코인에서 범용 컴퓨팅을 구현하는 작업과 관련된 각 단계에 대해 논의할 것이다.

2024.07.29 - 08:18:25

Web3 심층 보도에 집중하고 흐름을 통찰

이 글은 비트코인에서 범용 컴퓨팅을 구현하는 작업과 관련된 각 단계에 대해 논의할 것이다.

작성: StarkWare

번역: Starknet 중문 커뮤니티

1. 서론

본문에서는 비트코인 위에서 일반 계산을 구현하는 작업과 그에 수반되는 단계들을 논의할 것이다. 실제로 비트코인 스크립트 상에서 임의의 로직을 계산할 수 있는 능력을 실현하는 것은 매력적인 목표인데, 이는 비트코인을 비관리형 애플리케이션과 탈중앙화 금융 영역으로 끌어들일 수 있기 때문이다.

과거에는 두 가지 심각한 제약 — 비트코인 스크립트의 길이와 연산 코드의 표현 능력 — 때문에 비트코인 상의 일반 계산은 거의 불가능하다고 여겨졌다. 전자는 짧은 스크립트를 제외한 모든 트랜잭션을 금지하며, 후자는 스크립트 연산 코드가 계산할 수 있는 내용을 제한한다. 이 두 제약은 함께 비트코인 계산의 실현 가능성을 극도로 어렵게 만들었는데, 많은 애플리케이션이 이러한 조건 하에서는 구현될 수 없기 때문이다.

그러나 최근 몇 년간 상황은 분명히 개선되었다. 사실 2021년 탭루트(Taproot) 업그레이드 이후, 스크립트 길이의 제약이 사라졌고, 비트코인 스크립트는 현저하게 길어질 수 있게 되었다(사실상 탭루트 스크립트는 때때로 체인 상에서 스크립트 일부분만 결제를 요구하기도 하지만, 본문에서는 이 기능을 다루지 않을 것이다). 또한 연산 코드의 표현력 부족 문제를 해결하기 위해 우리는 단 하나의 간단한 연산 코드만으로도 무한한 표현력을 효과적으로 달성할 수 있음을 발견했다.

위에서 언급한 연산 코드는 OP_CAT라고 불리며, 2012년부터 비트코인 스크립트에서 비활성화되어 왔다. 이는 매우 단순한 연산 코드로, 스택 상의 요소들을 연결하는 기능을 제공하며, 소프트포크를 통해 비트코인에 비침습적으로 활성화할 수 있으며, 그 구현은 단지 13줄의 코드만 필요로 한다. 보기엔 별 것 아닌 이 연산 코드로부터 이렇게 큰 힘이 유래한다는 점은 믿기 어려운 일이며, 따라서 본문의 핵심 목적은 바로 이를 자세히 설명하는 것이다.

아래에서는 비트코인 상의 계산 과정을 깊이 있게 살펴보며, 그 구현 방식과 존재하는 제약사항부터 시작할 것이다.

이어서 우리는 두 가지 도구 — Covenant와 STARK 증명 — 에 대해 개략적으로 설명하고, 이들이 비트코인 스크립트 내에서 작동한다면 비트코인 상의 일반 계산이 가능해진다는 것을 입증할 것이다. 더불어 본문에서는 STARK 증명의 덕택으로 이러한 계산이 다음과 같은 유용한 추가 속성까지 갖출 수 있음을 논의할 것이다:

확장성— 체인 상 트랜잭션 처리와 계산이 가능해지며, 수수료는 극도로 낮아진다.
표현력— 로직을 비트코인 스크립트보다 훨씬 강력한 다양한 프로그래밍 언어로 작성할 수 있다. 이는 비트코인 프로그래밍의 인간 친화성과 보안성에 매우 중요하다.
체인 상 보안성— 어떤 형태의 계산이든, 비트코인 스크립트는 위임된 계산에 대한 수학적 증명만 검증한다.
유연성— 비트코인 상의 계산이 글로벌 상태를 저장할 수 있어, 다양한 애플리케이션을 가능하게 한다.

마지막으로 OP_CAT이 무엇이며, 어떻게 위의 도구들을 실현하는지에 대해 논의할 것이다. 또한 우리가 이 분야에서 진행한 노력들과 미래의 방향성에 대해서도 언급할 것이다.

주의: 본문은 명확한 사고 모델을 제공하기 위해 일부 기술적 문제를 단순화하였다. 실제 구현 시에는 "디테일이 결정한다".

2. UTXO 모델과 잠금 스크립트

이 섹션에서는 비트코인의 UTXO 모델을 간략히 개요할 것이며, 각 UTXO는 잠금 스크립트 뒤에 위치한다. 이미 잘 알고 있다면 다음 섹션으로 넘어가도 좋다.

비트코인 트랜잭션을 이해하는 첫 번째 단계는 그것들이 미사용 트랜잭션 출력(UTXO) 모델에 따라 구성되고 처리된다는 점을 주목하는 것이다(그림 1 참조). 비트코인 트랜잭션은 여러 개의 입력과 출력을 가질 수 있으며, 각 출력은 다른 트랜잭션에서 소비 가능한 일정량의 비트코인을 나타낸다. 반대로, 트랜잭션의 입력은 다른 비트코인 트랜잭션 출력의 지출을 의미한다. 물론 입력의 비트코인 총량과 출력의 비트코인 총량이 대략 같아야 하며(차액은 마이너에게 지급되는 수수료다).

그림 1: UTXO 모델에서의 트랜잭션. 각 트랜잭션의 입력과 출력은 일정량의 비트코인과 연결되며, 출력의 누적 금액은 입력의 금액을 초과할 수 없다. 미사용 트랜잭션 출력(UTXO)은 파란색으로 표시된다.

각 트랜잭션 출력은 잠금 스크립트(scriptPubKey)에 의해 잠겨 있으며, 이 스크립트는 주어진 입력(scriptSig)(소위 지출자가 제공함)를 수락하거나 거부한다. 따라서 미사용 트랜잭션 출력(UTXO)에서 자금을 이전하려면 올바른 scriptSig를 생성할 수 있어야 하며, 생성하는 트랜잭션에 해당 UTXO를 입력으로 포함해야 한다.

기본적으로 잠금 스크립트는 하드코딩된 공개키를 기반으로 디지털 서명을 검증하여, 잠긴 비트코인의 소유권을 정의한다. 좀 더 일반적으로 말하면, UTXO가 존재할 때마다 해당 잠금 스크립트 뒤에 잠긴 비트코인의 소유자는 올바른 scriptSig를 제공할 수 있는 사람이라고 할 수 있다. 따라서 각 비트코인 소유자의 총 잔고는 해당 소유자와 관련된 모든 UTXO의 누적치로 결정된다(예: 동일한 사람이 디지털 서명한 모든 UTXO).

3. 비트코인 스크립트의 한계

지난 섹션은 잠금 스크립트의 일반적인 상황과 그것이 비트코인 트랜잭션 및 비트코인 자체와 어떻게 상호작용하는지를 개요하였다. 이번 섹션에서는 잠금 스크립트 자체와 그 구성 내용에 집중할 것이다.

비트코인 상의 잠금 스크립트는 Forth와 유사한 스택 기반 언어로 작성되며, 이를 「비트코인 스크립트」라고 부른다. 비트코인 스크립트는 루프가 없으므로, 스크립트의 실행 시간이 길이에 비례하기 때문에 연산 코드의 수를 기준으로 스크립트의 비용을 측정한다. 그림 2에서 두 입력값의 합이 12인지 확인하는 간단한 프로그램의 개념도를 볼 수 있다.

그림 2*: 두 입력 값의 합이 12인지 확인하는 간단한 프로그램. 프로그램 실행은 scriptSig를 잠금 스크립트 자체와 연결한 후 좌측에서 우측으로 연산 코드를 처리함으로써 이루어진다. scriptSig는 요소를 스택에 푸시하는 역할만 한다. (a) 계산의 첫 번째 단계. (b) 계산 중간 과정. (c) 계산의 마지막 단계(잠금 스크립트가 입력을 수락함).

우리는 비트코인 스크립트는매우 많은 한계를 가지고 있다는 점을 지적해야 하며, 이는 간단한 로직 개발조차 매우 어렵거나 아예 불가능하게 만든다. 이러한 한계들은 다음과 같다:

스택 크기는 최대 1000개 요소로 제한된다.
곱셈 연산 코드가 없다(사실 31바이트 정수 곱셈조차 약 1만 4천 개의 연산 코드를 사용해 시뮬레이션해야 한다).
Pay2Taproot 출력 유형(탭루트 업그레이드 이후)의 경우, 단일 트랜잭션에 포함 가능한 연산 코드 총합은 블록 전체를 차지하는 약 400만 개 정도이며, 다른 출력 유형의 경우 연산 코드 총합은 단지 1만 개에 불과하다.
산술 연산(덧셈, 뺄셈)은 4바이트 요소로 제한된다.

마지막 항목에서 언급된 4바이트 제한은 특히 문제가 된다. 이는 예를 들어 암호화 연산에 필요한 20바이트 이상의 긴 요소들을 수정할 수 없다는 것을 의미한다.

예를 들어 데이터를 연결한 후 암호화 연산을 적용하는 매우 흔한 작업은 암호화 연산 코드를 무시하고 4바이트 요소 배열로 표현된 데이터에 대한 연산으로 시뮬레이션하는 경우를 제외하고는 수행할 수 없다. 후자의 방법은 비용이 매우 크며, 단일 해시 연산을 시뮬레이션하는 데 수십만 개의 연산 코드가 필요할 수 있다.

마지막으로, 비트코인 스크립트 개발이 어렵기 때문에 코드가 자연스럽게 오류와 취약점에 더 노출된다는 점을 지적하고자 한다.

4. 비트코인 스크립트에서 상태 유지의 어려움

지난 섹션은 비트코인 스크립트의 많은 부족함을 이미 보여주었지만, 우리는 비트코인 잠금 스크립트의 가장 큰 제약이 지출자의 입력만 읽을 수 있다는 점이라고 생각한다. 이는 두 가지 심각한 제약을 의미한다:

비트코인 스크립트는 상태를 유지하지 못한다. 즉, 저장 장치의 데이터를 읽거나 쓸 수 없다. 이더리움 가상 머신(EVM)에 비유하자면, SLOAD/SSTORE와 같은 연산 코드가 없으며, 이는 일반 계산을 위한 기본 기능이다.
비트코인 스크립트는 비트코인이 어떻게 지출되는지를 강제할 수 없다(몇 가지 예외를 제외하면). 이 문제는 Covenant를 통해 해결할 수 있는데, Covenant은 잠금 스크립트에 그러한 능력을 부여한다. (예를 들어 체인 상 금고라는 간단한 애플리케이션을 상상할 수 있다. 이는 지출이 허용되는 주소를 제한함으로써 작동한다. 보다 일반적으로 말하면, Covenant은 광범위한 응용이 가능한 매우 강력한 도구이다.)

그런 다음 우리는 Covenant을 구성함으로써 이미 상태성을 얻을 수 있음을 알게 될 것이다. 직관적으로 보면, 당신은 Covenant을 사용하여 트랜잭션 데이터 자체 내에서 저장소의 읽기와 쓰기를 시뮬레이션할 수 있기 때문이다.

사실 위에서 언급한 것만으로도 비트코인 스크립트와 그 복잡성의 전모를 설명하기에는 충분하지 않다. 그러나 적어도 우리는 비트코인 스크립트를 작성하는 것이 결코 쉬운 일이 아니라는 것을 확실히 알 수 있다. 비트코인 스크립트는 매우 엄격한 제약을 가진다:

스택 크기가 1000개 요소를 초과해서는 안 된다.
곱셈과 같은 간단한 연산을 시뮬레이션하려면 많은 연산 코드를 사용해야 한다. 일반적으로 번거로운 비트코인 스크립트 언어로 로직을 작성해야 한다.
4바이트 형식으로 인코딩된 요소로 작업해야 한다. 특히 암호화 연산 코드의 입력을 조작하거나 변경할 수 없다.
당신의 로직은 상태를 유지할 수 없으며, 단일 트랜잭션에 맞춰야 한다.
검증 후에도 당신의 로직은 비트코인이 어떻게 지출되는지를 제어할 수 없다.

또한 위의 제약 조건에 따라 코드를 작성하면 오류와 취약점이 발생하기 쉽다.

지불과 같은 매우 간단한 애플리케이션은 위 제약을 만족할 수 있지만, 약간이라도 복잡한 애플리케이션은 장애에 부딪히게 된다. 아래에서는 Covenant와 STARK 증명이 어떻게 이러한 한계를 돌파할 수 있는지 알아볼 것이다. 또한 OP_CAT이 비트코인 스크립트에 위 기능을 어떻게 제공하는지도 논의할 것이다.

5. Covenant을 통한 비트코인 상 스마트 계약

이번 섹션에서는 비트코인의 Covenant이 어떻게 로직 상태를 유지하는지 살펴보고, 더 일반적으로 비트코인 상의 「스마트 계약」이 무엇인지 설명할 것이다. 여기서 스마트 계약이란 일련의 함수를 포함하는 상태를 가지는 로직을 의미하며, 이 함수들은 사전 정의된 규칙에 따라 호출되어 상태를 다른 유효한 상태로 전환시킬 수 있다.

좀 더 구체적으로, 비트코인 계약은 다음 기능이 필요하다:

지속적인 로직과 상태
로직/상태 변화를 제어할 수 있는 능력

앞서 언급했듯이, 위 기능들은 Covenant를 통해 실현할 수 있다. 기억하라, 기본적으로 잠금 스크립트는 직접 입력된 데이터(scriptSig)만 읽을 수 있다. 그러나 Covenant을 통해 잠금 스크립트는 지출자 트랜잭션의 모든 데이터 필드와 잠금 스크립트가 위치한 트랜잭션의 데이터 필드, 심지어 다른 트랜잭션의 데이터까지 읽을 수 있다. 그림 3은 Covenant 사용 시 잠금 스크립트가 접근할 수 있는 다양한 부분을 보여준다.

그림 3: 잠금 스크립트(자물쇠로 시각화됨)가 접근할 수 있는 일부 데이터 필드(빨간색 화살표 표시). 지출자 트랜잭션의 데이터 필드에 접근하는 것 외에도, 잠금 스크립트는 잠금 스크립트가 위치한 트랜잭션(tx1)의 데이터 필드와 지출자 트랜잭션에 의해 동시에 소비되는 다른 트랜잭션(tx2)의 데이터 필드에도 접근할 수 있다.

우리는 위에서 설명한 Covenant이 비트코인 상에서 일반 스마트 계약을 구축하는 데 충분하다고 생각한다. 실제로 일반적인 방법은 트랜잭션 데이터 자체에 상태를 인코딩하고, 그 상태가 새 값으로 전환되는 것이 유효한지 검사하는 것이다.为此, 우리의 트랜잭션은 두 개의 출력을 가질 것이다:

첫 번째 출력은 계약의 로직(잠금 스크립트를 통해)과 계약에 묶인 자금을 보관한다.
두 번째 출력은 스마트 계약의 현재 상태를 보관한다. 이 UTXO의 잠금 스크립트는 상태만 저장하며, 절대 소비되지 않는다(실제로 묶인 비트코인은 0이다).

잠금 스크립트 로직은 다음 규칙을 수행할 것이다:

지출자 트랜잭션은 완전히 동일한 형태를 가져야 한다(두 개의 출력만 있고, 모든 자금이 첫 번째 출력에 묶여야 함);
첫 번째 출력은 동일한 잠금 스크립트 로직을 가져야 한다;
두 번째 출력은 유효한 상태여야 한다;
현재 잠금 스크립트에 제공된 입력은 현재 상태에서 새 상태로의 전환이 유효하다고 잠금 스크립트를 납득시켜야 한다(유효성은 로직 설계자가 정의함)

그림 4는 이러한 구조의 개념도이다. Weikeng Chen이 작성한 바와 같이, 많은 사람들이 이러한 구조에 공식적인 이름을 붙이자고 제안하였으며, 「상태 꼬리마차(state caboose)」가 후보 이름으로 부상하였다. 꼬리마차(caboose)는 화물 열차의 끝에 연결된 철도 차량으로, 승무원 전용 차량이자 그들의 작업 공간이다.

그림 4: 「상태 꼬리마차」 설계 패턴을 따르는 비트코인 상의 스마트 계약. 잠금 스크립트는 지출자 트랜잭션이 동일한 형태와 잠금 스크립트를 가지며, 이전 상태 S에서 유효한 새 상태 S'로의 전환이 이루어지도록 보장한다.

간단한 예로, 간단한 카운터 스마트 계약을 상상할 수 있다. 이 계약의 상태는 지출자가 제공하는 값만큼 항상 증가하며, 이는 실제로 「누적」 함수를 호출하는 것이다. 이 카운터 스마트 계약은 그림 5에 나와 있다.

그림 5: 입력(scriptSig)을 더하여 상태에 누적시키는 간단한 스마트 계약.

마지막으로 지적할 점은, 「계약을 호출」하고 계약을 새로운 유효한 상태로 전환하기 위해 사용자는 매 호출 시마다 새로운 지출자 트랜잭션을 만들어야 한다는 것이다. 이더리움 스마트 계약과 달리, 비트코인 스마트 계약은 본질적으로 순차적이다. 트랜잭션은 현재 상태와 새 상태를 동시에 약속해야 한다. 비트코인 상에서 스마트 계약을 구축할 때는 이러한 순차적 특성을 반드시 고려해야 한다. 비록 이 제약을 완화할 수 있는 일부 방안이 존재하지만, 본문에서는 이를 다루지 않을 것이다.

종합하면, 우리는 Covenant이 비트코인 상에 스마트 계약을 가능하게 한다는 것을 알았으며, 이론적으로는 계산을 충분히 많은 트랜잭션으로 나누면 비트코인 상에서 임의의 길이 계산이 가능하다. 그러나 Covenant만 사용하는 것은 여전히 비트코인 스크립트의 대부분 제약 — 스택 크기 제한, 연산 코드 수 제한, 그리고 일반적으로 비트코인 스크립트 언어의 제약에 따라 프로그래밍해야 하는 것 — 을 받는다.

다음 섹션에서는 STARK 증명 시스템이 체인 상 계산 점유율을 줄이고, 완전히 다른 언어로 스크립트를 작성할 수 있도록 함으로써 위 제약들을 어떻게 완화하는지 살펴볼 것이다. 이 방법은 프로그래밍 효율성과 보안성을 크게 향상시킨다.

6. 비트코인 STARK 검증기

이 섹션의 목적은 비트코인 상에서 계산을 수행하면서 비트코인 스크립트를 통한 실제 계산량을 최소한으로 줄이는 방법을 탐구하는 것이다. 우리의 일반적인 접근법은 계산 위임을 통해 계산을 오프체인으로 이전하는 것이며(여러 엔티티가 참여할 수 있음), 검증 단계만 체인 상의 비트코인 스크립트에서 수행된다.

이제 중요한 질문이 생긴다: 우리는 오프체인 계산이 올바르게 수행되었는지 어떻게 보장할 수 있는가? 실제로 이 문제를 해결하는 자연스러운 후보는 증명 시스템이다. 간단히 말해, 증명 시스템은 앨리스(증명자)가 「증명(proof)」을 제공함으로써 밥(검증자)에게 어떤 진술의 정확성을 납득시키는 것을 가능하게 하며, 핵심은 다음과 같다:

증명자의 도움 없이 비교할 때, 검증자는 훨씬 적은 작업만으로 그 진술을 검증할 수 있다.
또한 검증자는 증명자가 잘못된 진술을 믿게 만들 수 없도록 보호받는다.

증명 대상 진술은 난제의 해법에서부터 더 관련 있는 계산 위임 예제에 이르기까지 거의 모든 것이 될 수 있다. 구체적으로, 앨리스는 f(x)=y임을 밥에게 증명할 것이며, 밥이 f(x)를 직접 계산하지 않아도 된다(그림 6 참조).

그림 6: 계산 위임을 위한 증명 시스템. 증명자는 y=f(x)를 계산하고 검증자에게 이 진술의 정확성을 납득시킨다. 핵심은 y≠f(x)라면 증명자가 검증자를 속여 사실이라고 믿게 할 수 없다는 점이다.

따라서 우리는 블록체인 상의 계산 점유율을 줄이는 방법으로 비트코인 스크립트에 증명 시스템의 검증기를 구현하는 것이다. 따라서 스마트 계약을 호출할 때 호출자는 올바른 상태 전환에 대한 증명을 제공하며, 비트코인 스마트 계약은 상태 전환 자체를 직접 검사하는 대신 그 상태 전환 증명의 정확성을 검증할 것이다(그림 7 참조).

또한 이 방법은 중요한 이점이 하나 더 있는데, 비트코인 스크립트의 로직이 애플리케이션에 관계없이 고정되어 유지된다는 점이다. 이는 오류 발생 가능성을 크게 줄이고 감사를 단순화한다. 이는 간단한 사실에서 비롯된다: 동일한 검증 알고리즘은 계산할 함수를 미리 알지 못하더라도 y=f(x) 문장이나 y=g(x) 문장을 모두 검증할 수 있다.

그림 7: 그림 4의 「상태 꼬리마차」 설계 패턴을 따르는 비트코인 상 스마트 계약이지만, 검증기가 추가되었다. 이번에는 잠금 스크립트가 S에서 S'로의 전환이 유효한지 직접 검사하지 않고, 그 전환이 올바름을 증명하는 것을 검증한다.

많은 증명 시스템이 존재하지만, 우리는 STARK 증명 시스템(STARK)을 선택했는데, 이는 다음과 같은 매력적인 특징들을 갖고 있기 때문이다:

양자 이후 보안성
신뢰할 수 있는 설정 필요 없음
비트코인에 새로운 암호화 가정 추가 없음
가장 빠른 확장성
실전 검증됨, 1조 달러 이상의 결제에서 신뢰받음

마지막으로, 다른 증명 시스템과 비교하여 ⬇️

STARK는 비트코인에 친화적이며, 그 검증기 구성 요소를 비트코인 스크립트에 구현하기가 더 쉽다. 본질적으로 STARK는 주로 해시 기반이며, 쌍(pairing) 기반 증명과 비교해 대수적 연산이 매우 적기 때문이다.

비트코인 스크립트에서 대수적 연산의 비용은 매우 높기 때문에, 이것이 바로 STARK가 비트코인 친화적인 이유다. 또한 Circle-STARK 변형은 필드가 매우 작아 특히 비트코인에 친화적이다.

따라서 비트코인 검증기가 거의 모든 계산을 비교적 쉽게 검증할 수 있으므로, 우리는 어떤 유형의 계산을 검증할지 선택할 수 있다. 주목할 점은 이것이 어떤 형태의 CPU 실행일 수도 있다는 것이다. 또한 CPU 기반으로 고급 프로그래밍 언어를 설계할 수 있다. 이를 위해 우리는 StarkWare에서 Cairo를 개발하였으며, 이는 Rust와 유사하고 인간 친화적이며 안전한 프로그래밍 언어로, 효율적인 증명과 검증을 위해 특별히 설계되었다. 비트코인에서 Cairo 실행을 증명하는 것은 큰 이점을 가져올 수 있다.

종합하면, STARK 검증기와 Covenant을 사용함으로써 우리는 비트코인 상에서 일반 계산을 실현할 수 있다. 또한 이러한 계산은 다음과 같은 매력적인 추가 특성을 갖는다:

확장성— 체인 상 트랜잭션 처리와 계산이 가능해지며, 수수료는 극도로 낮아진다.
표현력— 로직을 비트코인 스크립트보다 훨씬 강력한 다양한 프로그래밍 언어로 작성할 수 있다. 이는 비트코인 프로그래밍의 인간 친화성과 보안성에 매우 중요하다.
체인 상 보안성— 어떤 형태의 계산이든, 비트코인 스크립트는 위임된 계산에 대한 수학적 증명만 검증한다.
유연성— 비트코인 상의 계산이 글로벌 상태를 저장할 수 있어, 다양한 애플리케이션을 가능하게 한다.

7. OP_CAT을 사용한 연결 및 기타 기능

위에서 언급했듯이, OP_CAT은 현재 비활성화된 간단한 연산 코드로, 비트코인 스크립트가 스택 상의 요소들을 연결할 수 있게 해준다. 이 단순한 연산의 중요성은 과소평가할 수 없는데, 이는 동시에 비트코인 상에서 Covenant와 STARK를 실현할 수 있기 때문이다. 구체적인 방법은 다음과 같다:

STARK— 사실 이는 그리 놀랄 일이 아니다. 왜냐하면 STARK는 실제로 데이터를 연결한 후 해시를 계산하는 것으로, 해시 계산은 대수적 연산과 달리 비트코인 스크립트의 네이티브 연산이기 때문에 비용을 크게 절감할 수 있기 때문이다. STARK의 주요 해시 계산은 Merkle 경로 검증(그림 8 참조)과 Fiat-Shamir 변환이다. (또한 Circle-STARK 변형은 필드 크기가 31바이트에 불과하여 비트코인 스크립트의 4바이트 제한을 충족시키며, 비트코인 친화적인 알고리즘이 된다.)
Covenant— 2021년 Andrew Poelstra는 Schnorr 기법이라는 소위 놀라운 관찰을 제시했는데, OP_CAT을 이용해 비트코인 상에서 Covenant를 구현할 수 있다는 것이다. 여기서 Schnorr 알고리즘은 Pay2Taproot 출력 유형의 디지털 서명이며, 다른 출력 유형의 경우 Robin Linus가 관찰한 유사한 ECDSA 기법을 사용할 수 있다. 간단히 말해, Covenant를 실현하기 위해서는 OP_CHECKSIG를 사용해야 하는데, 이는 지출자 트랜잭션과 관련된 데이터를 스택에 넣을 수 있는 유일한 연산 코드이다. 이러한 작업 과정은 간단하지 않지만, 몇 가지 조작을 통해 모든 필요한 데이터에 접근할 수 있다.

마지막 항목에 대해, Pay2Taproot 출력에 상태를 저장하는 것은 일부 기술적 난제를 수반한다. 그러나 Pay2WitnessScriptHash와 같은 다른 출력 유형을 사용하여 상태를 저장할 수 있다. 이는 앞서 언급한 그림 4와 그림 5의 「상태 꼬리마차」 기술을 가능하게 하며, 트랜잭션에는 두 개의 출력이 있다.

그림 8: *Merkle 경로 검증, 해시 및 문자열 연결 연산 포함. Merkle 경로의 각 부분(파란색 문자열)이 연결되어 적절한 해시 처리를 거친다. 그런 다음 Merkle 루트와 동등성 검사를 수행한다. OP_CAT 연산은 ||로 표기된다.*

8. 현재 상황과 미래

Weikeng Chen과 Pinghzou Yuan이 이끄는 오픈소스 프로젝트에서, 우리는 공동으로 Bitcoin Wildlife Sanctuary를 건설하고 있다. 주요 프로젝트 두 가지는 다음과 같다:

Circle-STARK 검증기, 이는 비트코인 심볼 상에서 단순한 진술(피보나치 수와 관련됨)의 STARK 증명을 검증하는 워킹 데모를 제공한다. 당신은 이 주소를 통해 진행 상황을 추적할 수 있다.
Covenant 프레임워크, 이미 간단한 카운터 Covenant을 통해 적용되었다. 검증기도 이 프레임워크를 사용한다.

이러한 노력들을 통해 우리는 비트코인에 효율적이고 안전하며 개발자 친화적인 OP_CAT 스마트 계약을 가져오려는 목표를 가지고 있다. 우리는 이것이 비트코인 컴퓨팅 분야에 있어 희망적이고 흥미로운 전망이라고 생각한다.

9. 맺음말

종합하면, 본문을 통해 우리는 다음을 알게 되었다:

Covenant는 비트코인 스크립트의 강력한 도구로, 비트코인 상에서 스마트 계약을 만들 수 있게 한다. Covenant은 비트코인 기능을 단순한 가치 이전을 넘어서 확장한다.
그러나 Covenant이 있더라도 비트코인 스크립트는 여전히 스택 크기 제한과 사용 가능한 연산 코드 유형 제한 등 많은 제약이 있다. 이는 Covenant만으로 구현할 수 있는 스마트 계약의 복잡성과 표현력을 제한한다.
STARK는 오프체인 계산 실행을 효과적으로 검증할 수 있으므로 이러한 제약을 완화하는 유망한 해결책을 제공한다. STARK를 활용하면 비트코인 스마트 계약 내에서 더 복잡한 계산을 수행할 수 있으며, 체인 상 계산 점유율을 최소화할 수 있다.
Cairo는 STARK를 사용한 효율적인 증명과 검증을 위해 특별히 설계된 프로그래밍 언어로, 비트코인 스마트 계약에 매우 적합하다. 더 복잡한 스마트 계약을 만들 수 있으며, 인간 친화성, 기능성, 보안성을 향상시킨다.
OP_CAT은 요소를 연결하는 비트코인 스크립트 연산 코드이다. OP_CAT은 비트코인 상에서 Covenant과 STARK를 실현하는 데 중요한 역할을 하며, 궁극적으로 비트코인에 강력한 일반 계산 능력을 가져다준다.