다음 내용은 Ajian(비트코인 콘텐츠 플랫폼 BTC 연구 편집장)이 작성한 Nervos Talk 포럼에서 재현되었습니다.
시스템의 프로그래밍 가능성을 이해하려면 시스템의 구조적 특성을 식별해야 합니다. 비트코인 스크립트를 기반으로 한 애플리케이션 프로그래밍에 대한 탐구는 CKB Cell의 기본 구조와 프로그래밍 패러다임을 이해하는 데 도움이 됩니다. 그뿐만 아니라 CKB의 프로그래밍 요소를 적절한 부분으로 나누고 각 부분이 가져오는 프로그래밍 가능성의 이점을 이해하는 데 도움이 됩니다.
"프로그래밍 가능성"은 사람들이 블록체인 시스템을 비교할 때 자주 취하는 차원입니다. 그러나 프로그래밍 가능성을 설명하는 방법에 대해서는 의견 차이가 흔합니다. 일반적인 표현은 "XX 블록체인은 튜링 완전 프로그래밍 언어를 지원한다" 또는 "XX 블록체인은 일반 프로그래밍을 지원한다"인데, 이는 여기서 "XX 블록체인"이 강력한 프로그래밍 가능성을 갖고 있음을 의미하기 위한 것입니다. 이러한 진술의 의미에는 어느 정도 진실이 있습니다. Turing-complete 프로그래밍을 지원하는 시스템은 일반적으로 그렇지 않은 시스템보다 프로그래밍하기가 더 쉽습니다. 그러나 스마트 계약 시스템의 구조적 특성에는 여러 가지 측면이 있으며, 이 설명은 그 중 하나만 다루기 때문에 깊이 이해하는 것만으로는 충분하지 않습니다. 개발자는 이로부터 지침을 얻을 수 없으며 일반 사용자는 구별할 수 없습니다. 그것으로부터.
스마트 계약 시스템의 구조적 특징은 다음과 같습니다:
그래서 "임의의 계산을 프로그래밍할 수 있는지 여부"에 더해, 적어도 스마트 계약 시스템의 프로그래밍 가능성에 영향을 미치는 네 가지 특성이 있습니다. 이러한 다른 특성은 구현하기 쉬운 것과 구현하기 어려운 것이 무엇인지, 무엇이 더 경제적인 구현인지, 무엇이 덜 효율적인 구현인지 더 깊은 수준에서 결정하기 때문에 더 중요하다고 말할 수도 있습니다.
예를 들어 사람들은 종종 이더리움을 좋은 프로그래밍 가능성의 예로 들지만, 이더리움의 상태 표현의 기본 형태는 계정이며 P2P 계약(예: 결제 채널, 일대일 베팅 계약 ) ——절대 불가능한 것은 아니고 그저 감사할 따름입니다. 이더리움 생태계에 결제 채널/상태 채널을 구현하려는 프로젝트가 없었던 것은 아닙니다. 이론적 논의도 많이 있지만 현재 이러한 프로젝트가 활성화되지 않은 것 같습니다. 이는 분명히 개발자의 노력 부족 때문이 아닙니다. 오늘날 이더리움에서 활성화된 프로젝트가 모두 "점대점 계약"이 아닌 "자금 풀"의 형태를 취하는 것은 우연이 아닙니다. 마찬가지로 사람들은 이더리움의 프로그래밍 가능성에 매우 만족할 수 있지만 "계정 추상화"(지갑 개념의 일반화로도 이해될 수 있음)를 달성하는 데 있어서는 계정 모델이 본질적으로 부족합니다.
마찬가지로, CKB의 프로그래밍 가능성을 탐구하려면 이러한 측면에서 CKB 스마트 계약 시스템의 구조적 특성을 이해해야 합니다. 우리가 이미 알고 있는 것은 CKB가 임의 계산 프로그래밍을 허용하고, 계약 내 추가 상태 기록을 허용하며, 한 계약이 실행 중에 다른 계약의 상태에 액세스할 수 있도록 허용한다는 것입니다. 그러나 계약의 형태는 트랜잭션의 출력(“셀”이라고 함)이므로 이더리움과 근본적으로 다릅니다. 따라서 이더리움 스마트 계약 시스템과 그 안에 있는 계약 인스턴스를 이해하는 것은 CKB가 이러한 구조적 기능을 구현하는 방법을 이해하는 데 도움이 되지 않으며 CKB의 프로그래밍 가능성을 이해하는 데도 도움이 되지 않습니다.
다행히도 비트코인의 스마트 계약은 CKB의 프로그래밍 가능성을 이해하는 데 최고의 기반을 제공하는 것 같습니다. 이는 비트코인의 상태 표현의 기본 형태가 트랜잭션의 출력("UTXO"라고 함)일 뿐만 아니라 비트코인 커뮤니티에서 제안한 "약정" 개념의 도움으로 CKB가 위의 구조적 특성을 가지며 최종 효과를 여러 부분으로 적절하게 분할하고 하나씩 식별함으로써 프로그래밍 가능성이 향상됩니다.
비트코인 상태 표현의 기본 형태인 비트코인의 UTXO("사용되지 않은 거래 출력")에는 두 가지 필드가 있습니다.
잠금 스크립트라고도 알려진 스크립트 공개 키는 자금을 사용하기 위해 충족해야 하는 조건, 즉 자금 잠금 해제 조건을 설정하는 스마트 계약 프로그램을 나타냅니다.이런 종류의 스크립트는 제한적이지만 놀라운 응용 프로그램을 프로그래밍하는 능력이 부족하지 않으며 CKB의 프로그래밍 가능성을 탐구하는 기초이기도 합니다. 나중에 비트코인 스크립트 프로그래밍의 두 가지 예를 소개하는 특별 섹션이 있을 것입니다.
반면, CKB의 상태 단위는 "Cell"이라고 하며 4개의 필드로 구성됩니다.
Cell은 특정 계산만 프로그래밍하는 대신 모든 계산을 프로그래밍할 수 있으며
Lock 스크립트가 기타(입력 및 출력) 읽기 스크립트 잠금
첫 번째 개념은 OP_IF, OP_ELSE와 같은 비트코인 스크립트의 프로세스 제어 opcode입니다. 이러한 opcode는 컴퓨터 프로그래밍의 IF와 다르지 않습니다. 해당 기능은 다른 입력을 기반으로 다른 명령문을 실행하는 것입니다. 비트코인 스크립트의 맥락에서 이는 시간 잠금 기능과 함께 자금에 대한 여러 잠금 해제 경로를 설정할 수 있음을 의미하며, 이는 작업에 우선순위를 할당할 수 있음을 의미합니다.
유명한 "HTLC(해시 시간 잠금 계약)"를 예로 들어 보겠습니다. 이 스크립트는 다음과 같이 현지어로 번역됩니다.
또는 Bob은 특정 해시 값 H 뒤에 있는 원본 이미지를 공개한 다음 자신의 서명을 제공할 수 있습니다. 자금을 지출하려면
또는 앨리스는 일정 시간이 지난 후 자신의 서명으로 자금을 지출할 수 있습니다.
이 "... 또는..." 효과는 프로세스 제어 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 트리의 잠금 해제 경로로 바꿀 수 있습니다. 각 리프는 독립적입니다. , 따라서 이러한 흐름 제어 opcode를 사용할 필요가 없으며, 하나의 경로를 공개해도 다른 경로를 노출할 필요가 없기 때문에 경제적 문제에 대한 걱정 없이 출력에 잠금 해제된 경로를 더 많이 추가할 수 있습니다.
두 번째 컨셉은 "약정 거래"입니다. 커밋된 거래의 개념은 특정 상황에서 유효한 비트코인 거래가 블록체인에 의해 확인되지 않더라도 여전히 유효하고 구속력이 있다는 것입니다.
예를 들어 Alice와 Bob은 UTXO를 공동으로 소유하고 있으며 이 UTXO에는 두 사람의 서명이 모두 필요합니다. 이 시점에서 Alice는 이를 사용하기 위한 거래를 구성하여 가치의 60%를 Bob에게 전송하고 나머지 가치는 자신에게 전송합니다. Alice는 거래에 대한 자신의 서명을 제공하고 이를 Bob에게 보냅니다. 그러면 Bob의 경우 거래를 비트코인 네트워크에 알리거나 블록체인을 통해 거래를 확인할 필요가 없습니다. 거래의 지불 효과도 실제적이고 신뢰할 수 있습니다. Alice는 이 UTXO를 스스로 사용할 수 없고(따라서 다시 사용할 수 없음) Alice가 제공한 서명이 유효하기 때문에 Bob은 언제든지 자신의 서명을 추가한 다음 거래를 브로드캐스트하여 지불금을 현금화할 수 있습니다. 즉, Alice는 이 유효한(온체인이 아닌) 거래를 통해 Bob에게 “신뢰할 수 있는 약속”을 제공합니다.
약정 거래는 비트코인 애플리케이션 프로그래밍의 핵심 개념입니다. 앞서 언급했듯이 비트코인의 계약은 검증을 기반으로 하고 무상태이며 교차 액세스를 허용하지 않습니다. 그러나 계약이 상태를 전달하지 않는 경우 이러한 상태는 어디에 저장되며 어떻게 계약을 안전하게 진행할 수 있습니까(상태 변경)? 커밋 트랜잭션은 간단한 대답을 제공합니다. 계약 상태는 트랜잭션 형식으로 표현될 수 있으므로 계약 참여자는 블록체인에 표시하지 않고도 상태를 직접 저장할 수 있으며 계약 상태 변경 문제도 변환될 수 있습니다. 커밋된 거래를 안전하게 업데이트하는 방법에 대한 문제 또한 계약 체결의 위험이 우려되는 경우(예: 지출 전에 양 당사자가 서명해야 하는 계약 체결), 상대방이 업데이트를 하지 않을 위험에 직면하게 됩니다. 응답 및 정체) 그런 다음 계약을 미리 소비하는 커밋 트랜잭션을 생성하고 서명하기만 하면 위험이 제거되고 다른 참가자에 대한 신뢰가 제거됩니다.
라이트닝 채널은 블록체인의 결제 확인 없이 두 당사자가 서로 무제한으로 결제할 수 있는 일대일 계약입니다. 예상할 수 있듯이 Promise 트랜잭션을 사용합니다.
"약정 거래"를 설명하는 섹션에서 결제 채널을 소개했습니다. 그러나 2/2 다중 서명만을 활용하는 이 계약은 단방향 결제만 가능합니다. 즉, Alice는 항상 Bob에게 비용을 지불하거나 Bob은 계약 잔액이 소진될 때까지 Alice에게 비용을 지불합니다. 양방향 결제인 경우, 특정 상태 업데이트 이후 한 쪽의 잔액이 이전보다 줄어들 수 있지만 상대방이 마지막으로 커밋한 거래에 서명했다는 의미입니다. 그를 막을 수 있는 방법은 없을까요? TA가 최신 커밋 트랜잭션만 브로드캐스트할 수 있도록 이전 커밋 트랜잭션을 브로드캐스팅합니까?
이 문제에 대한 라이트닝 채널의 솔루션을 “LN-Penalty”라고 합니다. 이제 Alice와 Bob이 각각 채널에 5 BTC를 가지고 있다고 가정합니다. 이제 Alice는 Bob에게 1 BTC를 지불하기를 원하므로 다음과 같은 약정 거래에 서명하고 이를 Bob에게 보냅니다.
Enter #0, 10 BTC: Alie-Bob 2 -of-2 다중 서명 출력(예: 채널 계약)
출력 #0, 4 BTC: Alice 단일 서명
출력 #1, 6 BTC: Alice-Bob 공동 임시 공개 키 #1 단일 서명 또는 T1 시간 잠금, Bob 단일 서명
Bob은 또한 (위 트랜잭션에 해당하는) 약정 트랜잭션에 서명하고 이를 Alice에게 보냅니다.
입력 #0, 10 BTC: Alie-Bob 2-of-2 다중 서명 출력(예: 채널 계약)
출력 #0, 6 BTC: Bob 단일 서명
출력 #1, 4 BTC: 또는 Bob -Alice 공동 임시 공개 키 #1 단일 서명 또는 T1 시간 잠금, 앨리스 단일 서명
여기서 비결은 바로 자신의 공개 키와 상대방이 제공한 공개 키를 사용하여 생성되는 이 "공동 임시 공개 키"에 있습니다. party 예를 들어, Alice-Bob 공동 임시 공개 키는 Alice 자신의 공개 키 중 하나와 Bob이 제공한 공개 키를 사용하여 각각에 해시 값을 곱한 다음 이를 합산하여 얻습니다. 이러한 공개 키가 생성되면 누구도 그 개인 키를 알 수 없습니다. 그러나 Bob이 Alice에게 자신이 제공한 공개 키의 개인 키를 알려주면 Alice는 공동 임시 공개 키의 개인 키를 계산할 수 있습니다. ——이것이 Lightning 채널이 이전 상태를 "실행 취소"할 수 있는 방법의 핵심입니다.
다음번에 양측이 채널 상태를 업데이트(결제 시작)하려고 할 때, 양측은 이전 라운드에서 상대방에게 주어진 임시 공개 키의 개인 키를 교환하게 됩니다. 이러한 방식으로 참가자는 더 이상 자신이 받은 마지막 커밋 트랜잭션을 공개할 수 없습니다. 이 커밋 트랜잭션의 출력에는 자신에게 가치가 두 가지 경로가 있으며 임시 공개 키 경로의 개인 키는 이미 상대방에게 알려져 있습니다. 이전 약속 거래가 공개되면 상대방은 즉시 이 공동 임시 개인 키를 사용하여 이 출력의 모든 자금을 빼앗을 수 있습니다. – 이것이 바로 “LN-Penalty”의 의미입니다.
구체적으로 상호 작용의 순서는 다음과 같습니다. 결제를 시작하는 당사자는 먼저 상대방에게 새로운 임시 공개 키를 요청한 다음 새로운 커밋된 트랜잭션을 구성하여 커밋된 트랜잭션을 받는 당사자에게 이를 전달합니다. 임시 공개 키를 통해 개인 키를 반올림합니다. 이 상호 작용 순서는 참가자가 항상 새로운 커밋 트랜잭션을 먼저 얻은 다음 이전 라운드에서 얻은 커밋 트랜잭션을 무효화하므로 신뢰할 수 없습니다.
요약하면 라이트닝 채널의 주요 디자인은 다음과 같습니다.
양 당사자는 항상 계약의 내부 상태를 표현하기 위해 약정 거래를 사용하고 지불을 나타내기 위해 금액 변경을 사용합니다.
약정 거래에는 항상 동일한 입력 비용이 듭니다. 두 당사자는 동시에 이를 수행해야 합니다. 서명된 입력을 제공해야 합니다. 따라서 모든 약정 거래는 서로 경쟁하며 결국 블록체인에서는 하나만 확인할 수 있습니다.
두 참가자의 서명은 동일한 약정 거래가 아닙니다. 비록 쌍을 이루고 있지만) ; 그리고 그들이 서명한 거래는 항상 자신에게 더 유익합니다. 즉, 참가자가 받은 커밋된 거래는 항상 자신에게 해롭습니다.
이러한 단점은 자신에게 가치를 부여하는 결과에 반영됩니다. 경로 잠금 해제: 한 경로는 자신의 서명으로 잠금을 해제할 수 있지만 잠시 기다려야 합니다. 반면 다른 경로는 상대방의 공개 키를 사용하며 자신의 임시 개인 키 중 하나가 노출되지 않는 경우에만 보호됩니다. 각 결제에서 양측은 이전 라운드에서 상대방이 사용한 임시 개인 키로 새로운 커밋 트랜잭션을 교환합니다. 따라서 임시 개인 키를 전달한 당사자는 더 이상 이전 커밋 트랜잭션을 브로드캐스팅할 수 없습니다. , 마지막으로 커밋된 트랜잭션이 "취소"되고 계약 상태가 업데이트됩니다. (실제로 커밋된 트랜잭션은 모두 유효한 트랜잭션이며 블록체인에 브로드캐스트될 수 있지만 참가자는 강제로 이를 처벌해야 합니다. 감히 다시 브로드캐스트합니다.)
어느 쪽이든 상대방이 서명한 약속된 거래를 통해 언제든지 계약을 철회할 수 있지만, 양 당사자가 기꺼이 협력할 경우 양측이 즉시 돈을 돌려받을 수 있도록 새로운 거래에 서명할 수 있습니다.
마지막으로 HTLC도 약정 거래에 배치할 수 있으므로 라이트닝 채널에서도 결제를 전달할 수 있습니다. 앨리스가 앞뒤로 연결된 라이트닝 채널로 구성된 경로를 찾아 다니엘에게 도달할 수 있다고 가정하면, 다니엘과 채널을 개설하지 않고도 무신뢰 멀티홉 결제가 이루어질 수 있다. 이것은 라이트닝 네트워크입니다.
Alice -- HTLC --> Carol -- HTLC --> Daniel
Alice
앨리스가 그러한 경로를 발견하고 다니엘에게 지불하고 싶을 때 다니엘에게 해시 값을 요청하고 이를 기반으로 HTLC를 구성하여 밥에게 제공하고, Bob이 Carol에게 메시지를 전달하고 동일한 HTLC를 제공하도록 유도합니다. 메시지는 Carol에게 메시지를 Daniel에게 전달하고 동일한 HTLC를 제공하도록 유도합니다. 뉴스가 Daniel에게 전달되면 그는 Carol에게 원본 이미지를 공개하여 HTLC의 가치를 얻고 계약 상태를 업데이트합니다. Carol은 동일한 작업을 수행하여 Bob의 지불금을 받고 채널 상태를 업데이트합니다. Bob은 원본 이미지를 공개하고 계약 상태를 업데이트합니다. 상태를 Alice에게 전달합니다. HTLC의 특성상 이러한 일련의 결제는 함께 성공하거나 함께 실패하므로 신뢰할 수 없습니다.
라이트닝 네트워크는 채널이 차례로 구성되어 있으며, 각 채널(계약)은 서로 독립적입니다. 즉, Alice는 Bob과의 자신의 채널에서 무슨 일이 일어났는지 알면 되고, 다른 사람의 채널에서 얼마나 많은 상호 작용이 발생했는지, 이러한 상호 작용이 어떤 통화를 사용했는지, 심지어 채널을 사용하는지 여부는 신경 쓸 필요가 없습니다. .
라이트닝 네트워크의 확장성은 라이트닝 채널 내 결제 속도가 양 당사자의 하드웨어 리소스 투자에 의해서만 제한된다는 사실뿐만 아니라 분산된 상태 저장으로 인해 단일 노드가 가장 낮은 비용으로 최대의 레버리지를 활용하세요.
Prudent 로그 계약(DLC)은 "어댑터 서명"이라는 암호화 기술을 사용하여 비트코인 스크립트가 외부 이벤트에 의존하는 금융 계약을 프로그래밍할 수 있도록 합니다.
어댑터 서명을 사용하면 개인 키를 추가한 후에만 서명이 유효한 서명이 될 수 있습니다. Schnorr 서명을 예로 들면 Schnorr 서명의 표준 형식은 (R, s)입니다. 여기서:
R = r.G # 서명에 사용된 nonce 값 r에 타원 곡선 생성 지점을 곱합니다. r의 공개 키라고 합니다
s = r + Hash(R || m || P) * p # p는 서명 개인 키이고 P는 공개 키입니다
서명을 확인한다는 것은 s.G = r.G를 확인한다는 의미입니다. + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK
한 쌍의 데이터 (R, s')가 주어졌다고 가정합니다. 여기서:
R = R1 + R2 = r1.G + r2.G
s ' = r1 + Hash(R || m || P) * p
분명히 이는 유효한 Schnorr 서명이 아니며 서명 확인 공식을 통과할 수 없습니다. 그러나 TA가 R2의 개인 키 r2를 알고 있는 한 이를 유효한 서명으로 만들 수 있음을 검증자에게 증명할 수 있습니다.
s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P
Adapter 서명을 사용하면 서명의 유효성이 비밀 데이터에 따라 달라지며 확인할 수 있습니다. 그런데 이것이 금융 계약과 어떤 관련이 있습니까?
Alice와 Bob이 축구 경기 결과에 돈을 걸고 싶어한다고 가정해 보겠습니다. Alice와 Bob은 Green Goblin과 Alina에 각각 1 BTC를 베팅했습니다. 또한 축구 해설 웹사이트인 Carol은 축구 경기 결과가 발표될 때 nonce R_c를 사용하여 결과의 시그니처 s_c_i를 게시할 것을 약속합니다.
3가지 가능한 결과가 있음을 알 수 있습니다(따라서 Carol의 서명에는 3가지 가능성이 있음):
이를 위해 두 사람은 각 결과에 대한 약정 거래를 생성합니다. 예를 들어 첫 번째 결과에 대해 생성한 약정 거래는 다음과 같습니다.
입력 #0, 2 BTC: Alie-Bob 2-of-2 다중 서명 출력(예: 베팅 계약)
출력 #0, 2 BTC: Alice의 단일 서명
그러나 이 거래를 위해 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).
결과가 발표되면 Green Goblin이 승리한다고 가정하고 Carol은 서명(R_c, s_c_1)을 발행합니다. 그런 다음 Alice와 Bob은 모두 상대방의 어댑터 서명과 자신의 서명을 완료하여 위 거래가 유효한 거래가 되도록 합니다. 네트워크에 방송되어 정산 효과를 유발합니다. 그러나 Green Goblin이 이기지 못했다면 Carol은 s_c_1을 출시하지 않았을 것이며 약정된 거래는 유효한 거래가 아니었을 것입니다.
다른 두 거래도 마찬가지입니다. 이러한 방식으로 Alice와 Bob은 상대방을 신뢰하지 않고 이 계약의 실행을 외부 이벤트에 의존하게 만듭니다(정확히 말하면 어설션 머신의 서명 형태로 외부 이벤트 브로드캐스팅에 의존). 선물, 옵션 등 크고 작은 금융 계약은 이러한 방식으로 구현될 수 있습니다.
다른 구현 형태와 비교했을 때 신중한 로그 계약의 가장 큰 특징은 개인 정보 보호입니다. (1) Alice와 Bob은 Carol에게 Carol의 데이터를 사용하고 있다고 말할 필요가 없으며 이는 계약 실행에 영향을 미치지 않습니다. (2) 체인 관찰자(Carol 포함)는 Alice와 Bob의 계약을 통해 거래를 실행하여 어떤 웹사이트 서비스를 사용하고 있는지 확인할 수 없으며 심지어 그들의 계약이 (라이트닝 채널이 아닌) 베팅 계약인지도 확인할 수 없습니다.
비트코인 커뮤니티의 개발자들은 제한 조항으로 분류될 수 있는 다양한 제안을 제안했습니다. 현재 관점에서 볼 때 가장 유명한 제안은 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가 단독으로 지출할 수 있습니다.
Alice가 그렇게 하면 Bob에게 이를 공개하지 않으면 Bob은 그러한 출력이 존재한다는 것을 알지 못할 것입니다. 일단 Alice가 이를 Bob에게 공개하면 Bob은 이 출력을 시간에 민감한 단방향 지불 채널로 사용할 수 있으며 Alice는 즉시 자금을 Bob Pay에 사용할 수 있습니다. 블록체인에서 확인을 기다려야 합니다. Bob은 Alice가 자신의 커밋된 거래를 체인에서 처리하기 전에 Alice가 스스로 거래를 할 수 있도록 허용해야 합니다.
OP_VAULT는 "vaults" 건설을 위해 특별히 제안된 제한 조항 제안입니다.
Vault 계약은 보다 안전하고 발전된 형태의 자기 보관이 가능하도록 설계되었습니다. 현재의 다중 서명 계약은 단일 개인 키의 단일 실패 지점을 피할 수 있지만 공격자가 임계값 수의 개인 키를 획득하면 지갑 소유자는 아무 것도 할 수 없습니다. Vault는 동시에 자금에 단일 지출 한도를 적용하기를 희망합니다. 일반 경로를 사용하여 출금할 경우 대기 기간 동안 출금 작업이 중단되며 출금 작업은 긴급 지갑에 의해 중단될 수 있습니다. 복구 작업. 이러한 계약이 위태로워지더라도 지갑 소유자는 긴급 복구 지점을 이용하여 대응 조치를 취할 수 있습니다.
이론적으로 OP_CTV에서도 이러한 계약을 프로그래밍할 수 있지만 불편한 점이 많습니다. 그 중 하나는 처리 수수료입니다. 거래를 약속하는 동시에 거래에 대해 지불할 처리 수수료도 약속합니다. 이러한 계약의 목적을 고려하면 계약을 맺고 돈을 인출하는 데 걸리는 시간이 매우 길어서 적절한 수수료를 예측하는 것이 거의 불가능합니다. OP_CTV는 입력을 제한하지 않으므로 입력을 늘려 처리 수수료를 늘릴 수 있지만 제공된 입력은 모두 처리 수수료가 되므로 반대의 경우 CPFP, 즉 인출된 자금을 수수료로 지출하는 것은 비현실적입니다. 신규 거래 시 제공됩니다. 또한 OP_CTV를 사용한다는 것은 이러한 안전 계약을 일괄적으로 철회할 수 없다는 의미이기도 합니다(물론 일괄적으로 복원할 수도 없음).
OP_VAULT 제안은 새로운 opcode(OP_VAULT 및 OP_UNVAULT)를 제안하여 이러한 문제를 해결하려고 시도합니다. OP_UNVAULT는 일괄 복구용으로 설계되었으므로 지금은 언급하지 않겠습니다. OP_VAULT의 작업은 다음과 같습니다. 이를 스크립트 트리의 분기에 배치하면 특정 매개변수 없이 실행 가능한 opcode(예: OP_CTV)를 약속하는 데 사용할 수 있습니다. 이 분기를 사용할 때 트랜잭션은 특정 매개변수를 전달할 수 있습니다. 하지만 다른 지점은 변경할 수 없습니다. 따라서 처리 수수료를 설정할 필요가 없으며 이 지점에도 시간 잠금이 있다고 가정하면 처리 수수료를 설정할 수 있습니다. 그러면 위치만 변경할 수 있으므로 최종적으로 시간 잠금이 적용됩니다. 분기가 있는 경우 새 스크립트 트리의 다른 분기(긴급 복구 분기 포함)는 변경되지 않으므로 이러한 철회 작업을 중단할 수 있습니다.
또한 언급할 가치가 있는 두 가지 사항이 있습니다. (1) OP_VAULT opcode의 동작은 다른 제한 제안과 유사합니다. OP_TLUV는 이것이 이미 특정 항목에 대한 "계산" 개념을 발생시켰다고 정확하게 지적했습니다. 범위: OP_TLUV /OP_VAULT는 먼저 사용자가 새 트랜잭션을 통해 매개변수를 opcode에 전달할 수 있도록 opcode를 약속하여 전체 스크립트 트리 리프를 업데이트합니다. 이는 더 이상 "특정 조건에 따라 들어오는 데이터를 확인"하는 것이 아니라 " 들어오는 데이터를 기반으로 새로운 의미 있는 데이터를 생성하지만 활성화할 수 있는 계산은 상대적으로 제한되어 있습니다.
전체 OP_VAULT 제안은 더 나은 결과를 얻기 위해 mempool 정책(예: v3 형식 트랜잭션)에 대한 일부 제안도 활용합니다. 이는 "프로그래밍"이 우리가 생각하는 것보다 훨씬 더 많은 의미를 가질 수 있음을 상기시켜 줍니다. (비슷한 예는 Nervos 네트워크의 공개 거래입니다.)
위의 두 장에서는 보다 제한된 구조(Bitcoin UTXO)에서 CKB를 사용하는 방법을 소개했습니다. 이 구조에 자체 검사 기능을 추가하는 방법도 도입되었습니다.
UTXO 이러한 애플리케이션을 프로그래밍하는 능력은 부족하지 않지만 독자는 다음과 같이 단점이나 최적화할 수 있는 영역을 쉽게 발견할 수 있습니다.
사실 비트코인 커뮤니티는 기본적으로 Sighash 제안(BIP-118 AnyPrevOut)과 관련된 이러한 질문에 대한 답변을 제시했습니다.
그러나 CKB에서 프로그래밍하는 경우 BIP-118을 지금 사용할 수 있습니다(이 Sighash 태그는 내부 검사 및 서명 확인 기능으로 시뮬레이션할 수 있습니다).
비트코인 프로그래밍을 배움으로써 우리는 "트랜잭션 출력" 형식을 프로그래밍하는 방법(CKB가 프로그래밍할 수 있는 것)뿐만 아니라 이러한 애플리케이션을 개선하는 방법(CKB에서 이러한 애플리케이션을 프로그래밍하면 무엇을 할 수 있는지)을 알게 됩니다. CKB의 기능을 사용하여 개선하세요). CKB 개발자에게 비트코인 스크립트 기반 프로그래밍은 학습 교과서 또는 지름길로 간주될 수 있습니다.
아래에서는 CKB 프로그래밍의 각 모듈의 프로그래밍 가능성을 하나씩 분석합니다. 지금은 내성적 능력을 고려하지 맙시다.
위에서 언급했듯이 UTXO는 임의 계산을 프로그래밍할 수 없습니다. 잠금 스크립트는 위에서 언급한 라이트닝 채널 및 DLC를 포함하되 이에 국한되지 않고 UTXO 프로그래밍을 기반으로 하는 모든 것을 잠금 스크립트가 (제한 사항이 배포되기 전에) 프로그래밍할 수 있음을 의미합니다.
또한 계산을 확인할 수 있는 이 기능을 통해 Lock Script는 더 많은 인증 방법을 사용할 수 있으며 UTXO보다 더 유연합니다. 예를 들어, 한 당사자는 ECDSA 서명을 사용하고 다른 당사자는 RSA 서명을 사용하는 CKB에서 Lightning 채널을 구현할 수 있습니다.
실제로 이것은 사람들이 CKB에서 탐색하기 시작한 가장 초기 영역 중 하나입니다. 소위 "계정 추상화"를 달성하기 위해 사용자의 자율적인 관리에서 유연한 신원 확인 기능을 사용하는 것입니다. - 거래 유효성 승인 및 제어 복원 모두 유연하고 사실상 무제한입니다. 원칙적으로 이는 "다중 지출 지점"과 "모든 인증 방법"의 조합입니다. 구현 사례로는 JoyID Wallet, UniPass가 있습니다.
또한 Lock Script는 Eltoo 제안을 구현할 수도 있으므로 최신 커밋된 트랜잭션만 유지하면 되는 라이트닝 채널을 실현할 수 있습니다(실제로 Eltoo는 모든 지점 간 계약을 단순화할 수 있습니다).
위에서 언급했듯이 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 트랜잭션도 비트코인 트랜잭션에 의존하기 때문에 여기서 커밋 트랜잭션을 구성하는 것은 다소 어려울 것입니다. 전체적으로 문제는 해결될 수 있지만 토큰은 일류 시민입니다.
다음으로 성찰의 능력을 고려해 보겠습니다.
잠금 스크립트는 다른 잠금 스크립트를 읽습니다.
이는 제안된 제한 사항이 구현된 후 비트코인 UTXO에서 완전한 프로그래밍 가능성을 의미합니다. 위에서 언급한 안전 계약과 OP_CTV 기반 애플리케이션(예: 혼잡 제어)이 포함됩니다.
XueJie는 매우 흥미로운 예를 언급한 적이 있습니다. CKB에서 이 셀을 트랜잭션의 입력으로 사용할 때 출력하는 셀(동일한 잠금 스크립트를 사용하는 셀)에 더 많은 용량이 있으면 이 셀을 구현할 수 있습니다. 입력은 서명을 제공할 필요가 없으며 거래의 유효성에 영향을 미치지 않습니다. 사실, 그러한 세포는 성찰하는 능력 없이는 불가능할 것입니다. 이러한 추심 계좌 셀은 자금을 모을 수 있기 때문에 기관의 추심 방법으로 매우 적합합니다. 단점은 개인 정보 보호가 취약하다는 것입니다.
이 기능의 흥미로운 적용은 주식 토큰입니다. 잠금 스크립트는 다른 입력의 토큰 수를 기반으로 자체 용량을 사용할 수 있는지 여부와 용량을 어디에 사용할 수 있는지 결정합니다(잠금 스크립트를 검사하는 기능 필요).
확실하지는 않지만 유용하다고 가정할 수 있습니다. 예를 들어 Type Script에서 트랜잭션의 입출력을 확인할 수 있는 Lock Script는 그대로 유지됩니다.
카드 교환? n개의 토큰을 모으면 더 큰 토큰으로 교환할 수 있습니다: )
이전의 프로그래밍 가능한 임의 컴퓨팅 스마트 계약 시스템(예: Ethereum)과 비교하여 Nervos 네트워크는 다른 구조를 채택합니다. Nervos 네트워크를 이해하기 위한 기초를 형성하는 것은 종종 어렵습니다. 본 논문에서는 CKB Cell보다 더 제한된 구조인 BTC UTXO의 응용 프로그래밍부터 시작하여 CKB Cell의 프로그래밍 가능성을 이해하는 방법을 제안합니다. 또한, Cell의 "교차 계약 액세스" 기능을 이해하기 위해 "인트로스펙션" 개념을 사용함으로써 인트로스펙션 기능이 사용되는 상황을 구분하고 이에 대한 구체적인 용도를 결정할 수 있습니다.
개정:
1. Cell의 교차 액세스 기능(예: 내부 검사 기능)에 관계없이 잠금 스크립트는 상태 및 익스트림 프로그래밍 기능을 갖춘 비트코인 스크립트로 간주될 수 있습니다. 따라서 이를 기반으로 모든 비트코인 기반 프로그램을 프로그래밍할 수 있습니다. 스크립트 적용
2. Cell의 교차 액세스 기능(예: 자체 검사 기능)에 관계없이 잠금 스크립트와 유형 스크립트의 구별은 UDT의 자산 정의와 저장 방법을 분리합니다. 또한 상태를 노출할 수 있는 유형 스크립트(및 데이터)는 UDT가 일급 시민이라는 효과를 구현합니다.
위 내용은 비트코인 애플리케이션 프로그래밍부터 시작해 만 단어로 CKB의 프로그래밍 가능성을 자세히 설명합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
