비트코인 애플리케이션 프로그래밍에서 CKB의 프로그래밍 가능성 이해

星球君的朋友们

Odaily资深作者

2023-11-03 14:04 (UTC+8)

이 기사는 약 11786자로, 전체를 읽는 데 약 17분이 소요됩니다

이 글은 CKB Cell보다 더 제한된 구조인 BTC UTXO의 응용 프로그래밍에서 시작하여 CKB Cell의 프로그래밍 가능성을 이해하는 방법을 제안합니다.

AI 요약

이 글은 CKB Cell보다 더 제한된 구조인 BTC UTXO의 응용 프로그래밍에서 시작하여 CKB Cell의 프로그래밍 가능성을 이해하는 방법을 제안합니다.

원작자 : Ajian

요약

시스템의 프로그래밍 가능성을 이해하려면 시스템의 구조적 특성을 식별해야 합니다. 비트코인 스크립트를 기반으로 한 애플리케이션 프로그래밍에 대한 탐구는 CKB Cell의 기본 구조와 프로그래밍 패러다임을 이해하는 데 도움이 됩니다. 그뿐만 아니라 CKB의 프로그래밍 요소를 적절한 부분으로 나누고 각 부분이 가져오는 프로그래밍 가능성의 이점을 이해하는 데 도움이 될 수 있습니다.

I. 소개

프로그래밍 가능성은 사람들이 블록체인 시스템을 비교할 때 자주 취하는 차원입니다. 그러나 프로그래밍 가능성을 설명하는 방법에 대해서는 의견 차이가 흔합니다. 일반적인 표현은 XX 블록체인은 튜링 완전 프로그래밍 언어를 지원합니다 또는 XX 블록체인은 일반 프로그래밍을 지원합니다라고 하는데, 이는 여기서 XX 블록체인이 강력한 프로그래밍 가능성을 갖고 있음을 의미합니다. 이러한 진술의 의미에는 어느 정도 진실이 있습니다. Turing-complete 프로그래밍을 지원하는 시스템은 일반적으로 그렇지 않은 시스템보다 프로그래밍하기가 더 쉽습니다. 그러나 스마트 계약 시스템의 구조적 특성에는 여러 가지 측면이 있으며, 이 설명은 그 중 하나만 다루기 때문에 충분히 깊은 이해를 얻는 것만으로는 충분하지 않습니다. 개발자는 이에 대한 지침을 얻을 수 없으며 일반 사용자는 구별할 수 없습니다. 그것에서 그것. 사기.

스마트 계약 시스템의 구조적 특성은 다음과 같습니다.

상태 표현의 기본 형태(계약)(계정 대 거래 출력)
임의 계산 프로그래밍을 허용할지 여부(튜링 완전성이라는 용어는 이 측면과 관련이 있음)
실행이 새 데이터를 생성합니까, 아니면 부울 값만 전달합니까? (계산 vs 검증)
계약 내에서 추가 상태 기록을 허용할지 여부
한 계약이 실행 중에 다른 계약의 상태에 액세스할 수 있는지 여부

따라서 임의의 계산을 프로그래밍할 수 있는지 여부 외에도 스마트 계약 시스템의 프로그래밍 가능성에 영향을 미치는 최소한 4가지 특성이 있습니다. 이러한 다른 특성은 구현하기 쉬운 것과 구현하기 어려운 것, 더 경제적인 구현과 덜 효율적인 구현을 더 깊은 수준에서 결정하기 때문에 더 중요하다고 말할 수도 있습니다.

예를 들어 사람들은 좋은 프로그래밍 가능성의 예로 이더리움을 자주 사용하지만, 이더리움의 상태 표현의 기본 형태는 계정이므로 P2P 계약(예: 결제 채널, 일대일)을 프로그래밍하기가 어렵습니다. -원베팅 계약) — — 절대 불가능한 것은 아니고 그저 감사할 따름입니다. 이더리움 생태계에 결제 채널/상태 채널을 구현하려는 프로젝트가 없었던 것은 아니며 많은 이론적 논의가 있지만 이러한 프로젝트는 현재로서는 활성화되지 않은 것 같습니다. 이는 분명히 개발자가 열심히 일하지 않았기 때문일 수 없습니다. 오늘날 이더리움에서 활성화된 프로젝트가 모두 점대점 계약이 아닌 자금 풀의 형태를 취하는 것은 우연이 아닙니다. 마찬가지로 사람들은 이더리움의 프로그래밍 가능성에 매우 만족할 수 있지만 계정 추상화(지갑 개념의 일반화로도 이해될 수 있음)를 달성하는 데 있어서는 계정 모델이 본질적으로 부족합니다.

마찬가지로 CKB의 프로그래밍 가능성을 탐구하려면 이러한 측면에서 CKB 스마트 계약 시스템의 구조적 특성을 이해해야 합니다. 우리가 이미 알고 있는 것은 CKB가 임의 계산 프로그래밍을 허용하고, 계약 내 추가 상태 기록을 허용하며, 한 계약이 실행 중에 다른 계약의 상태에 액세스할 수 있도록 허용한다는 것입니다. 그러나 계약의 형태는 트랜잭션의 출력(셀이라고 함)이므로 이더리움과 근본적으로 다릅니다. 따라서 이더리움 스마트 계약 시스템과 그 안에 있는 계약 인스턴스를 이해하는 것은 CKB가 이러한 구조적 기능을 구현하는 방법을 이해하는 데 도움이 되지 않으며 CKB의 프로그래밍 가능성을 이해하는 데도 도움이 되지 않습니다.

다행스럽게도 비트코인의 스마트 계약은 우리가 CKB의 프로그래밍 가능성을 이해하는 데 최고의 기반을 제공하는 것 같습니다. 이는 비트코인의 상태 표현의 기본 형태가 트랜잭션의 출력(UTXO라고 함)일 뿐만 아니라 비트코인 커뮤니티에서 제안한 약정 개념의 도움으로 CKB가 위의 구조적 특성을 가지며, 최종 효과를 여러 부분으로 적절하게 분할하고 하나씩 식별함으로써 프로그래밍 가능성이 향상됩니다.

2. CKB vs BTC: 무엇이 더 있나요?

(1) 기본 구조

비트코인 상태 표현의 기본 형태인 비트코인의 UTXO(사용되지 않은 거래 출력)에는 두 가지 필드가 있습니다.

Satoshi로 표시되는 금액은 UTXO의 비트코인 가치를 나타냅니다.
잠금 스크립트라고도 알려진 스크립트 공개 키는 자금을 사용하기 위해 충족해야 하는 조건, 즉 자금 잠금 해제 조건을 설정하는 스마트 계약 프로그램을 나타냅니다.

최신 스마트 계약 시스템에 비해 비트코인 스크립트는 상당히 제한적입니다.

임의 계산 프로그래밍을 허용하지 않으며 검증에 사용할 수 있는 몇 가지 실제 계산만 있습니다(서명 확인, 해시 사전 이미지 확인, 시간 확인).
계약 내에서 추가 상태를 기록하는 것을 허용하지 않습니다. (예를 들어 스크립트를 사용하여 단일 지출의 비율/한도를 제한할 수 없으며 토큰을 숨길 수도 없습니다.)
또한 실행 중에 다른 계약의 상태에 대한 액세스를 허용하지 않습니다(각 스크립트는 독립적인 유니버스이며 서로 의존하지 않습니다).

이러한 종류의 스크립트는 제한적이지만 놀라운 응용 프로그램을 프로그래밍하는 능력이 부족하지 않으며 CKB 프로그래밍 가능성을 탐구하는 기초이기도 합니다. 나중에 비트코인 스크립트 프로그래밍의 두 가지 예를 소개하는 특별 섹션이 있을 것입니다.

대조적으로, CKB의 상태 단위는 Cell이라고 불리며 4개의 필드를 가지고 있습니다:

UTXO의 양과 유사한 용량은 셀이 점유할 수 있는 공간의 크기를 바이트 단위로 표현합니다.
UTXO와 유사한 스크립트 공개 키인 Lock Script는 Cell의 소유권을 정의하며, 제공된 데이터가 Lock Script를 통과할 수 있는 경우에만 Cell을 업데이트할 수 있습니다(Cell을 해제하고 이러한 용량을 사용한다고도 할 수 있음). 새로운 셀을 생성하기 위해) ;
데이터, 데이터, 모든 데이터의 양은 용량에 따라 제한됩니다.
선택적 스크립트인 Type Script는 데이터 업데이트 조건을 설정하는 데 사용됩니다.

또한 Lock Script 및 Type Script는 임의의 계산을 프로그래밍할 수 있습니다. 서명 확인 알고리즘을 프로그래밍할 수 있고 해시 알고리즘에 대한 사전 이미지 검사 등을 프로그래밍할 수도 있습니다.

독자는 UTXO에 비해 Cell의 프로그래밍 가능성이 향상되었음을 쉽게 확인할 수 있습니다.

셀은 특정 계산만이 아닌 임의의 계산을 프로그래밍할 수 있으며 소유권 확인이 더욱 유연해집니다.
데이터 및 유형 스크립트 필드로 인해 셀은 추가 상태를 기록할 수 있으며, 이를 통해 셀은 소위 UDT(사용자 정의 토큰)를 전달할 수 있습니다.

Cell의 자체 트랜잭션 출력 구조와 결합하면 이 두 지점이 가져올 수 있는 이점은 이미 매우 큽니다. 그러나 위의 설명만으로는 Cell이 한 계약이 런타임에 다른 계약에 액세스하는 구현 방법을 아직 알 수 없습니다. .상태의. 이를 위해 우리는 비트코인 커뮤니티가 오랫동안 논의해 온 개념인 계약으로 전환해야 합니다.

(2) 제한과 성찰

제한의 원래 의도는 일정 금액을 지출할 수 있는 곳을 제한하는 것입니다. 현재 비트코인(아직 제약 제안을 배포하지 않은)에서는 자금이 잠금 해제되면 어디에서나 사용할 수 있습니다(모든 스크립트 공개 키에 지불 가능). 하지만 제한 조항의 취지는 특정 장소에서만 사용되도록 어떤 방식으로든 제한할 수 있다는 것입니다. 예를 들어 특정 UTXO는 특정 거래에서만 사용할 수 있습니다. 그러면 누군가 서명을 제공할 수 있더라도 이 UTXO의 경우, 지출할 수 있는 금액도 거래에 따라 결정됩니다. 이 기능은 다소 이상해 보일 수 있지만 몇 가지 흥미로운 응용 프로그램을 생성할 수 있으며 이에 대해서는 나중에 전용 섹션에서 소개하겠습니다. 중요한 것은 이것이 CKB 프로그래밍 가능성에 대한 더 깊은 이해의 열쇠라는 것입니다.

Rusty Russell은 제한 조항이 트랜잭션의 내성 검사 능력으로 이해될 수 있다는 점, 즉 UTXO A가 트랜잭션 B에 의해 소비되면 스크립트 운영자가 트랜잭션 B의 일부(또는 전체)를 읽을 수 있다는 점을 올바르게 지적했습니다. 을 클릭한 다음 스크립트에서 미리 요구하는 매개변수와 일치하는지 확인하세요. 예를 들어, 트랜잭션 A의 첫 번째 출력의 스크립트 공개 키가 UTXO A의 스크립트 공개 키와 일치하는지 여부(이것이 제한 조항의 원래 의미입니다).

예리한 독자라면 전체 내부 검사 기능을 사용할 수 있다면 한 트랜잭션의 입력이 동일한 트랜잭션의 다른 입력 상태를 읽을 수 있다는 사실을 알게 될 것입니다. 이는 앞서 한 계약이 런타임 시 다른 입력에 액세스합니다.라고 말한 내용을 실현합니다. 능력. 실제로 CKB Cell은 정확히 이런 방식으로 설계되었습니다.

이를 바탕으로 우리는 이 완전한 성찰 능력을 네 가지 상황으로 나눌 수 있습니다.

잠금 스크립트는 다른(입력 및 출력) 잠금 스크립트를 읽습니다.
잠금 스크립트는 기타(입력 및 출력) 유형 스크립트(및 데이터)를 읽습니다.
Type 스크립트는 다른(입력 및 출력) 잠금 스크립트를 읽습니다.
Type Script는 기타(입력 및 출력) Type Script(및 데이터)를 읽습니다.

이를 통해 특정 가정(잠금 스크립트와 유형 스크립트의 기능적 구분) 하에서 다양한 애플리케이션 시나리오에서 각 부분의 자체 검사 기능의 역할을 분석할 수 있습니다. 즉, 각 부분이 우리에게 가져오는 프로그래밍 가능성의 이점을 분석할 수 있습니다.

다음 두 장에서는 CKB Cell이 어떻게 프로그래밍되고 더 잘 수행되는지 구체적으로 이해하기 위해 현재 비트코인 스크립트 프로그래밍(제한 제안 없음)과 제한 제안이 구현할 것으로 예상되는 기능을 살펴보겠습니다.

3. 비트코인 스크립트 프로그래밍

이 섹션에서는 비트코인 스크립트를 기반으로 하는 애플리케이션 프로그래밍의 예로 Lightning Channel/Lightning Network 및 Discreet Log Contract(DLC)를 사용합니다. 계속 진행하기 전에 두 가지 개념을 이해해야 합니다.

(1) OP_IF 및 약정 거래

첫 번째 개념은 OP_IF, OP_ELSE와 같은 비트코인 스크립트의 프로세스 제어 opcode입니다. 이러한 opcode는 컴퓨터 프로그래밍의 IF와 다르지 않으며, 해당 기능은 다양한 입력을 기반으로 다양한 명령문을 실행하는 것입니다. 비트코인 스크립트의 맥락에서 이는 자금에 대한 여러 잠금 해제 경로를 설정할 수 있음을 의미하며, 시간 잠금 기능과 함께 사용하면 작업에 우선순위를 할당할 수 있음을 의미합니다.

유명한 HTLC(해시 시간 잠금 계약)를 예로 들면 이 스크립트를 현지어로 번역하면 다음과 같습니다.

또는 Bob은 특정 해시 값 H 뒤에 있는 원본 이미지를 공개한 다음 자신의 서명을 제공하여 자금을 사용할 수 있습니다.
또는 Alice는 일정 기간 T 후에 자신의 서명으로 자금을 사용할 수 있습니다.

이 ... 또는... 효과는 프로세스 제어 opcode를 통해 달성됩니다.

HTLC의 가장 두드러진 장점은 여러 작업을 함께 묶고 원자성을 달성할 수 있다는 것입니다. 예를 들어, Alice가 Bob과 BTC를 CKB로 교환하려는 경우 Bob은 먼저 해시 값을 제공하고 Nervos 네트워크에서 HTLC를 생성할 수 있습니다. 그런 다음 Alice는 동일한 해시 값을 사용하여 Bitcoin에서 HTLC를 생성합니다. 또는 Bob은 Alice가 지불한 BTC를 비트코인으로 가져가고 원본 이미지도 공개하여 Alice가 Nervos 네트워크에서 CKB를 가져갈 수 있도록 합니다. 또는 Bob이 원본 이미지를 공개하지 않고 두 계약이 모두 만료되어 Alice와 Bob 모두 투자한 자금을 돌려받을 수 있습니다.

Taproot 소프트 포크가 활성화된 후 다중 잠금 해제 경로 기능은 MAST(Merkle Abstract Syntax Tree)의 도입으로 더욱 강화되었습니다. 잠금 해제 경로를 Merkle 트리의 리프로 바꿀 수 있습니다. 각 리프는 독립적입니다. 따라서 그러한 흐름 제어 연산 코드를 사용할 필요가 없으며, 하나의 경로를 공개해도 다른 경로를 노출할 필요가 없기 때문에 경제성 문제에 대한 걱정 없이 출력에 더 많은 수의 잠금 해제된 경로를 추가할 수 있습니다.

두 번째 개념은 커밋 거래입니다. 커밋된 거래의 개념은 특정 상황에서 유효한 비트코인 거래가 블록체인에 의해 확인되지 않더라도 여전히 유효하고 구속력이 있다는 것입니다.

예를 들어, Alice와 Bob은 UTXO를 공동으로 소유하고 있으며, 이 UTXO에는 두 사람의 서명이 모두 필요합니다. 이때 Alice는 이를 사용하기 위한 트랜잭션을 구성하여 가치의 60%를 Bob에게 전송하고 나머지 가치는 자신에게 전송합니다. Alice는 트랜잭션에 대한 자신의 서명을 제공하고 이를 Bob에게 보냅니다. 그러면 Bob의 경우 비트코인 네트워크에 거래를 방송할 필요도 없고 블록체인에서 거래를 확인할 필요도 없으며 거래의 지불 효과도 현실적이고 신뢰할 수 있습니다. Alice는 이 UTXO를 스스로 사용할 수 없고 따라서 반복적으로 사용할 수 없고 Alice가 제공한 서명이 유효하기 때문에 Bob은 언제든지 자신의 서명을 추가한 다음 거래를 브로드캐스트하여 지불금을 현금화할 수 있습니다. 즉, Alice는 이 유효한(온체인이 아닌) 거래를 통해 Bob에게 신뢰할 수 있는 약속을 제공했습니다.

커밋 트랜잭션은 비트코인 애플리케이션 프로그래밍의 핵심 개념입니다. 앞에서 언급했듯이 비트코인의 계약은 검증을 기반으로 하고 무상태이며 교차 액세스를 허용하지 않습니다. 그러나 계약이 상태를 전달하지 않는 경우 이러한 상태는 어디에 저장되며 어떻게 계약을 안전하게 진행(상태 변경)할 수 있습니까? 커밋 트랜잭션은 간단한 대답을 제공합니다. 계약 상태를 트랜잭션 형식으로 표현할 수 있으므로 계약 참여자는 상태를 블록체인에 표시하지 않고도 자체적으로 저장할 수 있습니다. 계약 상태 변경 문제도 다음과 같이 변환될 수 있습니다. 커밋된 거래를 안전하게 업데이트하는 방법에 대한 문제, 또한 계약 체결의 위험이 걱정되는 경우(예: 지출 전에 양 당사자가 서명해야 하는 계약 체결), 상대방이 업데이트를 하지 않을 위험에 직면하게 됩니다. 응답 및 정체) 그런 다음 계약을 미리 소비하는 커밋 트랜잭션을 생성하고 서명하기만 하면 위험이 제거되고 다른 참가자에 대한 신뢰가 제거됩니다.

(2) 라이트닝 채널 및 라이트닝 네트워크

라이트닝 채널은 블록체인에서 결제를 확인하지 않고도 두 당사자가 무제한으로 서로에게 결제할 수 있는 일대일 계약입니다. 예상할 수 있듯이 약속 트랜잭션을 사용합니다.

약정 거래를 설명하는 섹션에서 결제 채널을 소개했습니다. 그러나 2/2 다중 서명만을 활용하는 이 계약은 단방향 결제만 가능합니다. 즉, Alice는 항상 Bob에게 비용을 지불하거나 Bob은 계약 잔액이 소진될 때까지 Alice에게 비용을 지불합니다. 양방향 결제인 경우 특정 상태 업데이트 이후 한 쪽의 잔액이 이전보다 줄어들 수 있지만 상대방이 마지막으로 커밋한 거래에 서명한 상태라는 뜻입니다. 이를 막을 수 있는 방법은 없을까요? TA가 최신 커밋 트랜잭션만 브로드캐스트할 수 있도록 이전 커밋 트랜잭션을 브로드캐스팅합니까?

이 문제에 대한 라이트닝 채널의 솔루션을 LN-Penalty라고 합니다. 이제 Alice와 Bob이 채널에 각각 5 BTC를 가지고 있다고 가정하면 이제 Alice는 Bob에게 1 BTC를 지불하기를 원하므로 다음과 같은 약정 거래에 서명하고 이를 Bob에게 보냅니다.

#0, 10 BTC를 입력하세요:
Alie-Bob 2/2 다중 서명 출력(예: 채널 계약)

출력 #0, 4 BTC:
앨리스 싱글 시그니처

출력 #1, 6 BTC:
어느 하나
Alice-Bob 공동 임시 공개 키 #1 단일 서명
어느 하나
T 1 시간 잠금, Bob 단일 서명

Bob은 또한 위의 트랜잭션에 해당하는 커밋 트랜잭션에 서명하고 이를 Alice에게 보냅니다.

#0, 10 BTC를 입력하세요:
Alie-Bob 2/2 다중 서명 출력(예: 채널 계약)

출력 #0, 6 BTC:
밥 싱글 시그니처

출력 #1, 4 BTC:
어느 하나
Bob-Alice 공동 임시 공개 키 #1 단일 서명
어느 하나
T 1 타임락, 앨리스 싱글 시그니처

여기서의 비결은 공동 임시 공개키인데, 이는 자신의 공개키와 상대방이 제공한 공개키를 이용하여 생성되는데, 예를 들어 앨리스-밥 공동 임시 공개키는 앨리스가 자신의 공개키 중 하나를 이용하여 생성하는 것이다. , 그리고 Bob이 제공한 공개 키에 각각 해시 값을 곱한 다음 더해집니다. 이러한 공개 키가 생성되면 누구도 그 개인 키를 알 수 없습니다. 그러나 Bob이 Alice에게 자신이 제공한 공개 키의 개인 키를 알려주면 Alice는 공동 임시 공개 키의 개인 키를 계산할 수 있습니다. ——이것이 이전 상태를 실행 취소하는 Lightning 채널 기능의 핵심입니다.

다음에 양 당사자가 채널 상태를 업데이트(결제 시작)하려고 할 때 두 당사자는 이전 라운드에서 상대방에게 제공된 임시 공개 키의 개인 키를 교환합니다. 이러한 방식으로 참가자는 더 이상 자신이 받은 마지막 커밋 트랜잭션을 감히 공개할 수 없습니다. 이 커밋 트랜잭션의 출력은 자신에게 가치를 할당하는 두 가지 경로가 있고 임시 공개 키 경로의 개인 키는 이미 상대방에게 알려져 있습니다. 이전 약속 거래가 공개되면 상대방은 즉시 이 공동 임시 개인 키를 사용하여 이 출력의 모든 자금을 빼앗을 수 있습니다. – 이것이 바로 “LN-Penalty”의 의미입니다.

구체적으로 상호 작용의 순서는 다음과 같습니다. 결제를 시작하는 당사자는 먼저 상대방에게 새로운 임시 공개 키를 요청한 다음 새로운 커밋 트랜잭션을 구성하여 상대방에게 전달합니다. 커밋 트랜잭션을 획득한 당사자는 상대방이 이전 라운드에서 수행한 작업 주어진 임시 공개 키의 개인 키. 이 상호 작용 순서는 참가자가 항상 새로운 커밋 트랜잭션을 먼저 얻은 다음 이전 라운드에서 얻은 커밋 트랜잭션을 무효화하므로 신뢰할 수 없습니다.

요약하면 라이트닝 채널의 주요 설계는 다음과 같습니다.

양 당사자는 항상 계약의 내부 상태를 표현하기 위해 약정 거래를 사용하고 지불을 표현하기 위해 금액 변경을 사용합니다.
커밋 트랜잭션에는 항상 동일한 입력(양 당사자가 동시에 서명을 제공해야 하는 입력)이 필요하므로 모든 커밋 트랜잭션은 서로 경쟁하며 궁극적으로 블록체인에서는 하나만 확인할 수 있습니다.
두 참가자는 동일한 커밋 트랜잭션에 서명하지 않고(페어링되어 있음에도 불구하고) 항상 자신에게 더 이익이 되는 트랜잭션에 서명합니다. 그들에게 불리하다;
이러한 단점은 자신에게 값을 할당하는 출력에 두 개의 잠금 해제 경로가 있다는 점에서 반영됩니다. 하나의 경로는 자신의 서명으로 잠금을 해제할 수 있지만 잠시 기다려야 하며, 다른 경로는 상대방의 공개 키를 사용합니다. 임시 개인 키는 노출되지 않은 경우에만 보호됩니다.
각 결제에서 양측은 이전 라운드에서 상대방이 사용했던 임시 개인키와 새로운 커밋 트랜잭션을 교환하므로, 임시 개인키를 넘겨준 당사자는 더 이상 이전 커밋 트랜잭션을 방송할 수 없습니다. 마지막으로 커밋된 트랜잭션은 취소되고 계약 상태가 업데이트됩니다. (사실 이러한 커밋된 트랜잭션은 모두 유효한 트랜잭션이며 블록체인에 브로드캐스트될 수 있지만 참가자는 이를 강제로 처벌해야 합니다. 감히 브로드캐스트하지 마십시오. 더 이상)
어느 쪽이든 상대방이 서명한 약정 거래를 통해 언제든지 계약을 종료할 수 있지만, 양 당사자가 기꺼이 협력할 경우 새로운 거래에 서명하여 양측이 즉시 돈을 돌려받을 수 있습니다.

마지막으로 HTLC는 약정 거래에도 포함될 수 있으므로 라이트닝 채널도 결제를 전달할 수 있습니다. 앨리스가 앞뒤로 연결된 라이트닝 채널로 구성된 경로를 찾아 다니엘에게 도달할 수 있다고 가정하면, 다니엘과 채널을 개설하지 않고도 무신뢰 멀티홉 결제가 이루어질 수 있다. 이것이 라이트닝 네트워크입니다:

Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
Alice <-- 원본 이미지-- Bob <-- 원본 이미지-- Carol <-- 원본 이미지-- Daniel

Alice가 그러한 경로를 발견하고 Daniel에게 비용을 지불하려고 하면 Daniel에게 해시 값을 요청하여 Bob에게 HTLC를 구성하고 Bob에게 메시지를 Carol에게 전달하고 동일한 HTLC를 제공하도록 요청합니다. 이 메시지는 Carol에게도 메시지를 전달하도록 요청합니다. Daniel에게 동일한 HTLC를 제공합니다. 이 소식이 Daniel에게 전달되면 그는 원본 이미지를 Carol에게 공개하여 HTLC의 가치를 얻고 계약 상태를 업데이트합니다. Carol은 동일한 작업을 수행하여 Bob의 지불을 받고 채널 상태를 업데이트합니다. 마지막으로 Bob은 원본 이미지를 공개하고 계약 상태를 업데이트합니다. 상태를 Alice에게 전달합니다. HTLC의 특성상 이러한 일련의 결제는 함께 성공하거나 함께 실패하므로 신뢰할 수 없습니다.

라이트닝 네트워크는 채널이 차례로 구성되어 있으며, 각 채널(계약)은 서로 독립적입니다. 즉, Alice는 Bob과의 자신의 채널에서 무슨 일이 일어났는지 알면 되고, 다른 사람의 채널에서 얼마나 많은 상호 작용이 발생했는지, 이러한 상호 작용이 어떤 통화를 사용했는지, 심지어 그것이 실제인지 여부는 신경 쓸 필요가 없습니다. 채널 사용) .

라이트닝 네트워크의 확장성은 라이트닝 채널 내의 결제 속도가 양 당사자의 하드웨어 리소스 투자에 의해서만 제한된다는 사실뿐만 아니라 분산된 상태 저장으로 인해 단일 노드가 활용할 수 있다는 사실에도 반영됩니다. 최저 비용으로 최대의 레버리지를 제공합니다.

(3) 신중한 로그 계약

Discreet Log Contracts(DLC)는 어댑터 서명이라는 암호화 기술을 사용하여 비트코인 스크립트가 외부 이벤트에 의존하는 금융 계약을 프로그래밍할 수 있도록 합니다.

어댑터 서명을 사용하면 개인 키를 추가한 후에만 서명이 유효해집니다. Schnorr 서명을 예로 들면 Schnorr 서명의 표준 형식은 (R, s)입니다. 여기서:

R = r.G
# 서명에 사용된 nonce 값 r에 타원곡선 생성점을 곱하는데, 이는 r의 공개키라고도 할 수 있습니다.
s = r + Hash(R || m || P) * p
# p는 서명 개인 키이고, P는 공개 키입니다.
서명을 검증한다는 것은 sG = rG + Hash(R -- m -- P) * pG = R + Hash(R -- m -- P) * PK 를 검증한다는 의미입니다.

다음과 같은 데이터 쌍(R,s)이 주어졌다고 가정합니다.

R = R 1 + R 2 = r 1.G + r 2.G
s' = r 1 + Hash(R || m || P) * p

분명히 이것은 유효한 Schnorr 서명이 아니며 서명 검증 공식을 통과할 수 없지만 TA가 R 2 의 개인 키 r 2 를 알고 있는 한 유효한 서명으로 바뀔 수 있음을 검증자에게 증명할 수 있습니다. . :

s'.G + R 2 = R 1 + Hash(R || m || P) * P + R 2 = R + Hash(R || m || P) * P

어댑터 서명을 사용하면 서명의 유효성이 비밀 데이터에 따라 달라지며 확인할 수 있습니다. 그런데 이것이 금융 계약과 어떤 관련이 있습니까?

앨리스와 밥이 축구 경기의 결과에 돈을 걸고 싶다고 가정해 보세요. Alice와 Bob은 각각 Green Goblin과 Alina에 1 BTC를 베팅했습니다. 또한 축구 해설 웹사이트 Carol은 축구 경기 결과가 발표될 때 nonce R_c를 사용하여 결과의 시그니처 s_c_i를 게시할 것을 약속합니다.

볼 수 있듯이 세 가지 가능한 결과가 있습니다(따라서 Carol의 서명에는 세 가지 가능성이 있습니다).

- 그린 고블린이 이기고 앨리스가 1 BTC를 얻습니다.

- Alina가 이기고 Bob이 1 BTC를 얻습니다.

- 추첨 시 두 사람의 자금은 원래 경로로 반환됩니다.

이를 위해 두 사람은 각 결과에 대한 약정 거래를 생성합니다. 예를 들어, 첫 번째 결과를 위해 생성한 약속 트랜잭션은 다음과 같습니다.

#0, 2 BTC를 입력하세요:
Alie-Bob 2/2 다중 서명 출력(예: 베팅 계약)

출력 #0, 2 BTC:
앨리스 싱글 시그니처

그러나 이 트랜잭션을 위해 Alice와 Bob이 생성한 서명은 (R,s)가 아니라 어댑터 서명(R,s)입니다. 계약., 그리고 비밀 가치가 공개되어야 합니다. 이 비밀값은 바로 캐롤의 시그니처인 s_c_ 1.G의 원본 이미지입니다! Carol 서명의 nonce 값이 결정되었으므로(R_c), s_c_ 1.G를 구성할 수 있습니다(s_c_ 1.G = R_c + Hash(R_c -- The Green Goblin Wins -- PK_c) * PK_c).

결과가 발표되면 그린 고블린이 승리한다는 가정 하에 Carol이 서명(R_c, s_c_ 1)을 발행하게 되며, 그러면 Alice와 Bob 모두 상대방의 어댑터 서명을 완성하고 자신의 서명을 추가하여 위 거래를 유효한 거래로 만들 수 있습니다. 네트워크에 방송하고 정산 효과를 유발합니다. 그러나 고블린이 이기지 못했다면 Carol은 s_c_ 1 을 공개하지 않았을 것이고 약정된 거래는 유효한 거래가 아니었을 것입니다.

비유하자면 다른 두 트랜잭션에서도 마찬가지입니다. 이러한 방식으로 Alice와 Bob은 상대방을 신뢰하지 않고 이 계약의 실행을 외부 이벤트에 의존하게 만듭니다(정확히 말하면 어설션 머신의 서명 형태로 외부 이벤트 브로드캐스팅에 의존). 선물, 옵션 등 크고 작은 금융 계약은 이러한 방식으로 구현될 수 있습니다.

다른 구현 형태와 비교할 때 신중한 로그 계약의 가장 큰 특징은 개인 정보 보호입니다. (1) Alice와 Bob은 Carol에게 Carol의 데이터를 사용하고 있다고 말할 필요가 없으며 이는 계약 실행에 전혀 영향을 미치지 않습니다. (2) 온체인 관찰 누구든(Carol 포함) Alice와 Bob의 계약을 통해 거래를 실행하여 자신이 어떤 웹사이트의 서비스를 사용하고 있는지 확인할 수 없으며, 심지어 그들의 계약이 (라이트닝 채널이 아닌) 베팅 계약인지도 확인할 수 없습니다.

4. 제한 조항의 적용 소개

(1) OP_CTV 및 혼잡제어

비트코인 커뮤니티의 개발자들은 제한사항으로 분류될 수 있는 다양한 제안을 해왔습니다. 현재 관점에서 가장 유명한 제안은 OP_CHECKTEMPLATEVERIFY(OP_CTV)로, 그 개념은 비교적 단순하지만 상당한 유연성을 유지하고 있어 단순성을 옹호하는 비트코인 커뮤니티에서 환영을 받고 있다. OP_CTV의 아이디어는 스크립트에 해시 값을 커밋하여 해시 값으로 표시되는 트랜잭션으로만 자금을 사용할 수 있도록 제한하는 것입니다. 이 해시 값은 트랜잭션 및 대부분의 필드의 출력을 커밋하지만 커밋은 하지 않습니다. 거래 입력은 입력 수량에만 적용됩니다.

혼잡제어는 OP_CTV의 특징을 잘 보여주는 예이다. 기본 적용 시나리오는 다수의 사용자가 거래소(신뢰가 필요한 환경)에서 자본 풀로 철수하도록 돕는 것입니다. 이 자본 풀은 OP_CTV를 사용하여 향후 소비 방법을 계획하므로 사용자가 이 신뢰에서 벗어날 수 있도록 보장할 수 있습니다. 자유로운 환경의 펀드 풀은 누구의 도움도 필요하지 않으며, 이 펀드 풀은 UTXO로만 나타나기 때문에 온체인 거래 수요가 높을 때(n 출력에서 1 출력으로 감소) 많은 양의 처리 수수료를 지불하지 않습니다. ; 또한 n개의 거래에서 거래가 1개의 거래로 감소되었습니다. 풀에 있는 사용자는 기회를 기다린 후 풀에서 탈퇴할 수 있습니다.

Alice, Bob, Carol이 각각 거래소에서 BTC 5개, BTC 3개, BTC 2개를 인출하려고 한다고 가정합니다. 그러면 거래소는 OP_CTV 브랜치 3개로 10 BTC를 출력할 수 있습니다. Alice가 돈을 인출하려고 한다고 가정하면 지점 1을 사용할 수 있습니다. 이 지점의 OP_CTV에서 사용되는 해시 값으로 표시되는 트랜잭션은 두 개의 출력을 형성하며, 하나의 출력은 5 BTC를 Alice에게 할당하는 것이고, 다른 출력은 자금 풀입니다. 또한 OP_CTV를 사용하여 Bob이 3 BTC를 인출하고 나머지 2 BTC를 Carol에게 보내는 것만 허용하는 거래를 커밋합니다.

Bob이나 Carol이 돈을 인출하려는 경우에도 마찬가지입니다. 돈을 인출할 때 해당 OP_CTV 수표를 통과할 수 있는 거래만 사용할 수 있습니다. 즉, 해당 금액만 스스로 지불할 수 있으며 마음대로 돈을 인출할 수 없습니다. 나머지 자금은 다음을 사용하여 잠긴 자금 풀에 들어갑니다. OP_CTV는 사용자가 자금을 인출하는 순서에 관계없이 나머지 사용자가 풀에서 무신뢰로 인출할 수 있도록 보장합니다.

추상적으로 말하면, 여기서 OP_CTV의 역할은 계약의 수명이 다할 때까지의 경로를 계획하는 것입니다. 따라서 여기의 자본 풀 계약은 어떤 경로를 택하거나 어떤 상태에 도달하더라도 무신뢰 종료의 속성을 유지할 수 있습니다. .

이런 종류의 OP_CTV에는 숨겨진 단방향 결제 채널이라는 매우 흥미로운 사용법도 있습니다. Alice가 이러한 자금 풀을 형성하고 다음 스크립트를 사용하여 자금이 무신뢰 없이 출력으로 인출될 수 있도록 보장한다고 가정합니다.

또는 Alice와 Bob이 함께 지출합니다.
아니면 시간이 좀 지나면 앨리스가 혼자 보낼 수도 있어요

Alice가 이를 Bob에게 공개하지 않으면 Bob은 그러한 출력이 존재한다는 것을 알지 못할 것입니다. 일단 Alice가 이를 Bob에게 공개하면 Bob은 이 출력을 시간에 민감한 단방향 지불 채널로 사용할 수 있으며 Alice는 즉시 자금을 사용하여 다음 작업을 수행할 수 있습니다. Bob은 블록체인에서 확인을 기다리지 않고도 결제할 수 있습니다. Bob은 Alice가 자신의 약정 거래를 체인에서 사용하기 전에 Alice가 자신의 약정 거래를 체인에서 받도록 허용하기만 하면 됩니다.

(2) OP_금고 및 금고

OP_VAULT는 볼트 구축을 위해 특별히 설계된 제한 제안입니다.

볼트(Vault) 계약은 보다 안전하고 발전된 형태의 자기 보관이 가능하도록 설계되었습니다. 현재의 다중 서명 계약은 단일 개인 키의 단일 실패 지점을 피할 수 있지만 공격자가 임계값 수의 개인 키를 획득하면 지갑 소유자는 아무 것도 할 수 없습니다. Vault는 자금에 대해 단일 지출 한도를 부과하기를 희망하며 동시에 일반 경로를 사용하여 출금할 때 출금 작업은 대기 기간을 적용하며 대기 기간 동안 비상 지갑에 의해 출금 작업이 중단될 수 있습니다. 복구 작업. 이러한 계약이 위반되더라도 지갑 소유자는 긴급 복구 지점을 이용하여 대응 조치를 취할 수 있습니다.

이론적으로 OP_CTV에서도 이러한 계약을 프로그래밍할 수 있지만 불편한 점이 많으며 그 중 하나가 처리 수수료입니다. 거래를 커밋하는 동안 해당 거래에 대해 지불할 처리 수수료도 함께 약속합니다. 이러한 계약의 목적을 고려하면 계약을 맺고 돈을 인출하는 데 걸리는 시간이 매우 길어서 적절한 수수료를 예측하는 것이 거의 불가능합니다. OP_CTV는 투입을 제한하지 않기 때문에 투입을 늘려서 처리수수료를 늘릴 수는 있지만, 제공된 투입이 모두 취급수수료가 되기 때문에 비현실적이다. 신규 거래에는 수수료가 제공됩니다. 또한, OP_CTV를 사용한다는 것은 이러한 안전한 계약이 일괄적으로 자금을 인출할 수 없다는 것을 의미합니다(물론 일괄적으로 복원할 수도 없습니다).

OP_VAULT 제안은 새로운 opcode(OP_VAULT 및 OP_UNVAULT)를 제안하여 이러한 문제를 해결하려고 시도합니다. OP_UNVAULT는 일괄 복구용으로 설계되었으므로 지금은 언급하지 않겠습니다. OP_VAULT의 작업은 다음과 같습니다. 이를 스크립트 트리의 분기에 배치하면 특정 매개변수 없이 실행 가능한 opcode(예: OP_CTV)를 약속하는 데 사용할 수 있습니다. 이 분기를 사용할 때 트랜잭션은 특정 매개변수를 전달할 수 있습니다. 하지만 다른 지점은 변경할 수 없습니다. 따라서 수수료를 설정할 필요가 없고, 이 지점을 사용할 때 수수료를 설정할 수 있으며, 이 지점에도 시간 잠금이 있다고 가정하면 시간 잠금이 적용됩니다. 마지막으로 위치만 변경할 수 있기 때문입니다. Branch가 있는 경우 새 스크립트 트리의 다른 분기(긴급 복구 분기 포함)는 변경되지 않으므로 이러한 철회 작업을 중단할 수 있습니다.

또한 언급할 가치가 있는 두 가지 사항이 있습니다: (1) OP_VAULT opcode는 다른 제한 제안인 OP_TLUV와 유사하게 동작합니다. Jeremy Rubin은 이것이 이미 어느 정도 계산 개념을 발생시켰다는 것을 정확하게 지적했습니다: OP_TLUV/ OP_VAULT는 먼저 사용자가 새 트랜잭션을 통해 매개변수를 opcode에 전달할 수 있도록 opcode를 약속하여 전체 스크립트 트리 리프를 업데이트합니다. 이는 더 이상 특정 조건에 따라 들어오는 데이터를 확인하는 것이 아니라 새 트랜잭션을 생성합니다 들어오는 데이터를 기반으로 의미 있는 데이터를 생성하지만 이를 통해 가능한 계산은 상대적으로 제한됩니다.

(2) 전체 OP_VAULT 제안은 더 나은 결과를 얻기 위해 트랜잭션 풀 정책(mempool 정책)(예: v3 형식 트랜잭션)에 대한 일부 제안을 활용합니다. 이는 프로그래밍이 우리가 생각하는 것보다 더 넓은 의미를 가질 수 있음을 상기시켜 줍니다. (비슷한 예는 Nervos 네트워크의 Open Transaction입니다.)

5. CKB 이해하기

위의 두 장에서 우리는 스크립트를 사용하여 보다 제한된 구조(Bitcoin UTXO)에서 흥미로운 애플리케이션을 프로그래밍하는 방법을 소개했으며, 이 구조에 자체 검사 기능을 추가하기 위한 제안도 소개했습니다.

UTXO에는 이러한 애플리케이션을 프로그래밍할 수 있는 기능이 있지만 독자는 다음과 같은 단점이나 최적화할 수 있는 영역을 쉽게 감지할 수 있습니다.

LN-Penalty에서 채널 참가자는 저장 부담을 구성하는 상대방의 사기를 처리하기 위해 과거의 각 약정 거래와 해당 페널티 비밀 값을 저장해야 합니다. 최신 커밋 트랜잭션만 적용되고 이전 커밋 트랜잭션은 적용되지 않도록 보장할 수 있는 메커니즘이 있다면 이러한 부담을 없앨 수 있을 뿐만 아니라 노드가 오류로 인해 이전 커밋을 착각할 가능성도 제거할 수 있습니다. .거래가 온체인에 있어서 예기치 않게 처벌을 받는 문제.
DLC에서는 이벤트로 인해 발생할 수 있는 결과가 여러 가지라고 가정하고, 양측이 사전에 많은 서명을 생성해 서로 제출해야 한다는 점도 부담이 크다. 공개키와 직접 바인딩되어 있어서 위치이전이 쉽지 않은데 컨트랙트 포지션을 이전할 수 있는 방법이 있나요?

실제로 비트코인 커뮤니티는 기본적으로 Sighash 제안(BIP-118 AnyPrevOut)과 관련된 이러한 질문에 대한 답변을 제시했습니다.

그러나 CKB에서 프로그래밍하는 경우 BIP-118을 이제 사용할 수 있습니다(Sighash 태그는 서명을 내부적으로 검사하고 구체적으로 확인하는 기능으로 시뮬레이션할 수 있습니다).

비트코인 프로그래밍을 배움으로써 우리는 트랜잭션 출력 형식(CKB가 프로그래밍할 수 있는 것)을 프로그래밍하는 방법을 알 뿐만 아니라 이러한 애플리케이션을 개선하는 방법도 알게 됩니다(CKB에서 이러한 애플리케이션을 프로그래밍하는 경우 CKB 능력을 사용하여 개선할 수 있는 방법) 그들을). CKB 개발자에게 비트코인 스크립트 기반 프로그래밍은 학습 교과서 또는 지름길로 간주될 수 있습니다.

아래에서는 CKB 프로그래밍의 각 모듈의 프로그래밍 가능성을 하나씩 분석합니다. 지금은 내성적 능력을 고려하지 맙시다.

(1) 임의 계산을 위한 프로그래밍 가능한 잠금 스크립트

위에서 언급했듯이 UTXO는 임의의 계산으로 프로그래밍할 수 없습니다. 잠금 스크립트는 위에서 언급한 라이트닝 채널과 DLC를 포함하되 이에 국한되지 않고 UTXO 프로그래밍을 기반으로 모든 것을 프로그래밍할 수 있다는 의미입니다(제한 사항이 배포되기 전에).

또한 계산을 검증하는 이 기능을 통해 Lock Script는 더 많은 인증 방법을 사용할 수 있으며 UTXO보다 더 유연합니다. 예를 들어, 한 당사자는 ECDSA 서명을 사용하고 다른 당사자는 RSA 서명을 사용하는 CKB에서 라이트닝 채널을 구현할 수 있습니다.

실제로 이것은 사람들이 CKB에서 탐색하기 시작한 가장 초기 영역 중 하나입니다. 소위 계정 추상화(인증 및 거래 유효성)를 달성하기 위해 사용자의 자율적 관리에 대한 유연한 신원 확인 기능을 사용합니다. 제어 복원은 매우 유연합니다. 거의 무제한입니다. 원칙적으로 이는 다중 지출 지점과 모든 인증 방법의 조합입니다. 구현 사례로는 Joyid Wallet, UniPass가 있습니다.

또한 Lock Script는 Eltoo 제안을 구현하여 최신 커밋된 트랜잭션만 유지하면 되는 라이트닝 채널을 활성화할 수 있습니다(사실 Eltoo는 모든 지점 간 계약을 단순화할 수 있습니다).

(2) 어떠한 계산도 프로그래밍할 수 있는 Type Script

위에서 언급했듯이 Type Script의 가장 큰 용도 중 하나는 UDT 프로그래밍입니다. 잠금 스크립트와 결합하면 UDT 기반 Lightning 채널(및 기타 유형의 계약)을 구현할 수 있습니다.

실제로 Lock Script와 Type Script의 분리는 보안 업그레이드로 간주될 수 있습니다. Lock Script는 보관 방법이나 계약 프로토콜 구현에 중점을 두고 있는 반면 Type Script는 UDT 정의에 중점을 둡니다.

또한 UDT 정의를 기반으로 검사를 시작하는 기능을 통해 UDT는 CKB와 유사한 방식으로 계약에 참여할 수 있습니다(UDT는 일급 시민입니다).

예: 저자는 비트코인에 무신뢰 NFT 보안 대출을 구현하는 프로토콜을 제안한 적이 있습니다. 이 프로토콜의 핵심은 입력 값이 출력 값보다 작은 커밋 트랜잭션입니다(따라서 아직 유효한 트랜잭션이 아닙니다.) 그러나 이 트랜잭션에 충분한 입력이 제공되면 A입니다. 유효한 거래: 대출 기관이 상환할 수 있게 되면 대출 기관은 약속된 NFT를 자체적으로 유지할 수 없습니다. 그러나 이 약정 거래의 무신뢰 특성은 입력 및 출력 금액을 확인하는 거래를 기반으로 하므로 대출 기관과 대출 기관 모두 다른 통화(예: 프로토콜에 의해 발행된 RGB USDT), 비트코인의 약정 거래는 대출 기관이 충분한 양의 USDT를 반환하는 한 NFT를 돌려받을 수 있다는 것을 보장할 수 없습니다. 왜냐하면 비트코인 거래는 USDT의 상태를 전혀 알지 못하기 때문입니다. ! (개정: 즉, USDT 상환을 조건으로 하는 약정 거래 구축이 불가능합니다.)

UDT 정의를 기반으로 수표를 시작할 수 있다면 대출 기관은 또 다른 약정 거래에 서명하여 대출 기관이 USDT를 사용하여 대출금을 상환할 수 있게 됩니다. 거래는 USDT 입력량과 USDT 출력량을 확인하여 사용자에게 USDT를 사용하여 무신뢰 상환을 제공합니다.

수정: 담보로 사용되는 NFT와 상환에 사용되는 토큰이 동일한 프로토콜(예: RGB)을 사용하여 발행된다고 가정하면 여기서의 문제는 해결될 수 있습니다.RGB 프로토콜을 기반으로 커밋 트랜잭션을 구성하여 NFT가 상태 전환과 상환은 동시에 발생할 수 있습니다(트랜잭션은 RGB 프로토콜 내에서 두 가지 상태 전환을 바인딩하는 데 사용됩니다). 그러나 RGB 트랜잭션도 비트코인 트랜잭션에 의존하기 때문에 여기서 커밋 트랜잭션을 구성하는 것은 다소 어려울 것입니다. 대체로 문제는 해결될 수 있지만 토큰은 일류 시민입니다.

다음으로 우리는 자기 성찰의 능력을 고려합니다.

(3) 잠금 스크립트는 다른 잠금 스크립트를 읽습니다.

이는 제안된 제한 사항이 구현된 후 비트코인 UTXO에 대한 모든 프로그래밍 가능성이 있음을 의미합니다. 위에서 언급한 안전 계약과 OP_CTV 기반 애플리케이션(예: 혼잡 제어)이 포함됩니다.

XueJie는 매우 흥미로운 예를 언급한 적이 있습니다: CKB에서 수금 계정 셀을 구현할 수 있습니다. 이 셀을 트랜잭션의 입력으로 사용할 때 출력되는 셀(동일한 잠금 스크립트를 사용하는 셀)의 용량이 더 크면 이 입력은 서명을 제공할 필요가 없으며 거래의 유효성에 영향을 미치지 않습니다. 사실 이 Cell은 자기 성찰 능력이 없으면 구현할 수 없습니다. 이러한 추심계좌 Cell은 자금을 모을 수 있기 때문에 기관의 추심방식으로 매우 적합하지만, 개인정보 보호가 좋지 않다는 단점이 있습니다.

(4) 잠금 스크립트는 다른 유형 스크립트(및 데이터)를 읽습니다.

이 기능의 흥미로운 적용은 주식 토큰입니다. 잠금 스크립트는 다른 입력의 토큰 수를 기반으로 자체 용량을 사용할 수 있는지 여부와 용량을 어디에 사용할 수 있는지 결정합니다(잠금 스크립트를 검사하는 기능 필요).

(5) Type 스크립트는 다른 잠금 스크립트를 읽습니다.

확실하지는 않지만 유용하다고 가정할 수 있습니다. 예를 들어, 트랜잭션의 입력과 출력을 확인할 수 있는 Lock 스크립트는 Type Script에서 변경되지 않고 그대로 유지됩니다.

(6) Type Script는 다른 Type Script(및 데이터)를 읽습니다.

트레이딩 카드? n개의 토큰을 모으면 더 큰 토큰으로 교환할 수 있습니다 :)

6. 결론

임의 계산을 위한 이전의 프로그래밍 가능 스마트 계약 시스템(예: Ethereum)과 비교하여 Nervos 네트워크는 다른 구조를 채택하므로 이전 스마트 계약 시스템에 대한 이해가 Nervos 네트워크를 이해하기 위한 기초를 형성하기 어려운 경우가 많습니다. 이 글은 CKB Cell보다 더 제한된 구조인 BTC UTXO의 응용 프로그래밍에서 시작하여 CKB Cell의 프로그래밍 가능성을 이해하는 방법을 제안합니다. 또한, Cell의 교차 계약 액세스 기능을 이해하기 위해 인트로스펙션 개념을 사용함으로써 인트로스펙션 기능이 사용되는 상황을 구분하고 이에 대한 구체적인 용도를 결정할 수 있습니다.

개정:

Cell의 교차 액세스 기능(즉, 내부 검사 기능)에 관계없이 잠금 스크립트는 상태 및 익스트림 프로그래밍 기능을 갖춘 비트코인 스크립트로 간주될 수 있습니다. 따라서 비트코인 스크립트를 기반으로 하는 모든 애플리케이션은 이것만으로 프로그래밍할 수 있습니다.
Cell의 교차 액세스 기능(즉, 자체 검사 기능)에 관계없이 잠금 스크립트와 유형 스크립트의 구별은 보안 업그레이드로 간주될 수 있습니다. UDT의 자산 정의와 저장 방법을 분리합니다. 데이터) UDT가 일류 시민이라는 효과를 얻습니다.

위의 두 가지 점은 BTC + RGB와 동일한 패러다임을 갖지만 프로그래밍 기능이 더 강력하다는 것을 의미합니다.

Cell의 내성 능력을 고려하면 Cell은 post-covenants BTC UTXO보다 강력한 프로그래밍 능력을 얻을 수 있으며, BTC + RGB로는 달성하기 어려운 것을 달성할 수 있습니다(BTC는 RGB 상태를 읽을 수 없기 때문).

이러한 용도에 대해 본 글에서는 구체적인 사례를 많이 제시할 수 없지만, 이는 저자가 CKB의 생태에 대한 이해가 부족하기 때문입니다. 시간이 지날수록 사람들은 점점 더 많은 상상력을 쏟아 붓고 오늘날에는 상상할 수 없는 응용 프로그램을 결합하게 될 것이라고 믿습니다.