이 기사의 저자는 Jan입니다. 이 기사에서는 암호화된 자산을 블록체인에서 "일급 시민"으로 만드는 First-class Asset: Cell 모델에서 지원되는 매우 흥미로운 DApp 디자인 패턴에 대해 설명합니다.

함수형 프로그래밍을 좋아하는 엔지니어는 용어에 익숙해야 합니다. 중국어로 번역된 일급 함수는 "일급 함수" 또는 "일급 함수"라고 해야 합니다. 일급 함수는 함수가 완전히 독립적인 개념인 프로그래밍 언어 클래스를 나타냅니다. 함수는 변수에 값으로 할당되거나 다른 함수에 매개 변수로 전달되거나 다음과 같이 사용될 수 있습니다. 반환 값은 다른 함수에서 전달됩니다. 기능. 이러한 언어에서는 데이터 조작과 같은 기능을 조작할 수 있으므로 이러한 언어에서 기능과 데이터는 "일급 시민"입니다. 일급 함수는 함수형 언어의 핵심 기능이며 함수형 프로그래밍의 많은 힘이 여기에서 나옵니다.

보조 제목

상태 모델에 대한 빠른 입문서

셀 모델 이전에는 기본적으로 다양한 블록체인에서 사용되는 두 가지 상태 모델인 UTXO 모델과 계정 모델이 있었습니다.

UTXO 모델의 대표는 비트코인입니다. UTXO는 Unspent Transaction Output의 약자로, UTXO는 간단히 비트코인으로 이해할 수 있지만 일반 코인과 달리 각 UTXO의 액면가는 다릅니다. 각 UTXO는 락 스크립트(Lock Script)를 통해 코인의 소유자가 누구인지 기록함과 동시에 소유자만이 코인을 사용할 수 있도록 합니다. 각 비트코인 ​​풀 노드는 비트코인 ​​원장의 현재 상태(즉, 현재 원장)라고 부르는 모든 현재 UTXO의 모음을 유지합니다. 모든 비트코인 ​​전송은 UTXO 세트에서 여러 개의 코인(발신자에 속함)을 제거하고 여러 개의 새로운 코인(수취인 및/또는 발신자에 속함)을 추가하는 프로세스입니다. 전체 원장 상태는 UTXO의 가장 작은 단위를 기준으로 구성되므로 UTXO 모델이라고 합니다.

텍스트

그래서 우리는 코인(Coin)이 UTXO 모델에서 First-class Citizen이라고 하고, 각 UTXO는 독립적인 식별자(트랜잭션 ID + 출력 지수)를 가진 객체이며, 코인은 사용자가 직접 운영하는 객체(사용자가 구성하는 트랜잭션에는 UTXO가 포함되어 있으며 계정은 Coin이 설정한 상위 개념을 기반으로 합니다(지갑에만 존재함). 따라서 UTXO는 일류 코인입니다.

계정 모델에서 계정은 일급 시민이며 계정 잔액에 집계된 코인에는 독립적인 식별자가 없습니다. 계정은 사용자가 직접 운영하는 대상이며, 자산의 양도는 사용자의 대리인인 계정에 의해 실현되며, 수령인이 계약 계정인 경우에 가장 두드러집니다. 이러한 모델에서 사용자 정의 암호화 자산(예: ERC 20)은 점대점 전송보다는 제3자 회계 방식에 가깝습니다. 암호화된 자산 스마트 계약 관리)은 자산 전송 프로세스를 도입하여 스마트 계약의 설계 복잡성을 증가시킵니다(스마트 계약은 자산이 전송될 때 자동으로 실행되는 논리로 생각할 수 있습니다). 이러한 복잡성을 줄이기 위해 Account 모델의 트랜잭션은 특별한 논리(Value 필드)를 추가해야 하지만 이러한 특별한 논리는 기본 자산에만 도움이 되며 기본 자산과 사용자 정의 자산에 대해 서로 다른 코드 경로를 유발합니다.

이러한 문제에 대해 Kelvin Fitcher는Looking at ownership in the EVM분석이 잘 되어 있어서 여기서는 반복하지 않겠습니다.

이러한 배경을 통해 CKB의 디자인 컨셉을 이해하는 것이 더 쉬울 것입니다.

셀 모델을 사용하면 디자인을 단순화하고 사용자 정의 자산(User Defined Assets)을 Nervos CKB의 "일급 시민"(일급 자산이라고 함)으로 구현할 수 있습니다.

보조 제목

First-class State

일류 자산을 실현하는 방법은 무엇입니까?

어느 쪽이든 소유자와 자산 간의 관계를 문서화해야 합니다. 이러한 관계 레코드는 본질적으로 합의 상태입니다. First-class Asset을 갖기 위해서는 먼저 First-class State가 있어야 하며 이것이 Cell 모델의 출발점이다.

Nervos CKB의 이름은 Common Knowledge Base(공통 지식 기반)의 약자입니다. Nervos 네트워크에서 블록체인을 "Common Knowledge Base"라고 부르는 이유는 그 책임이 네트워크의 공통 상태에 대한 글로벌 합의를 지속적으로 형성하는 것이기 때문입니다. 즉, CKB는 글로벌 합의 라이브러리에 의해 유지되는 상태입니다. 상태 라이브러리의 기본 모델은 자연스럽게 전체 상태를 구성할 더 작은 상태 단위로 나눕니다. 이 작은 상태 단위는 셀입니다.

Cell은 독립적인 식별자(Transaction ID + Cell Output Index)를 가진 상태 단위이므로 직접 참조하여 스크립트에 매개변수로 전달할 수 있습니다. CKB "일등 시민"입니다. 셀은 일급 상태일 뿐만 아니라 가장 단순한 일급 상태이기도 합니다. 셀에는 용량, 데이터, 잠금 및 계약만 있습니다(선택 사항, 계약은 코드 조각이거나 코드 셀을 가리키는 참조일 수 있음). 필드.

아래 그림과 같이 Cell의 소유자는 중개자 없이 Cell에 저장된 상태를 직접 업데이트할 수 있으며, Account 모델에서는 사용자가 계약 코드(계정 내 코드)를 통해서만 계정 내 상태를 조작할 수 있습니다. .사실 컨트랙트의 손에서 호스팅됩니다.

Cells를 통해 CKB는 실제로 상태 저장 프로그래밍 모델을 얻는다는 점을 지적할 가치가 있습니다. 이더리움 프로그래밍 모델의 표현력은 튜링의 완전한 가상머신에서 나온다는 것이 공통된 견해입니다. ://en.wikipedia.org/wiki/Total_functional_programming).

CKB는 Cell과 CKB-VM의 조합을 통해 새로운 상태 저장 스마트 계약 프로그래밍 모델을 구현합니다(간단하지만 강력합니다! 이것은 또 다른 기사입니다). 이 프로그래밍 모델은 Layer 2에 더 적합합니다. 왜냐하면 Layer 2 프로토콜의 일반적인 패턴을 분석하면 프로토콜 계층 간의 상호 작용 개체가 이벤트 개체(Event Transaction)가 아닌 상태 개체(State Transaction)여야 한다는 것을 알 수 있고 Layer 1은 계산 계층이 아닌 상태 계층이어야 합니다.

CKB 프로그래밍 모델의 또 다른 특징은 데이터(상태)와 코드 사이에 구분이 없다는 것입니다. 이 문장은 Account 모델과 달리 컨트랙트의 state와 code를 Cell의 Data 필드에 저장할 수 있고, 그 code를 저장한 Cell은 다른 Cell에서 참조할 수 있다는 의미입니다. ), 계약 상태 및 코드를 함께 묶고 한 곳에 저장할 필요가 없습니다. 개발자는 간단한 명령을 통해 코드 셀 또는 데이터 셀의 내용을 런타임 메모리에 로드한 다음 필요에 따라 코드 실행 또는 데이터 읽기 및 쓰기로 해석할 수 있습니다.

이러한 기본 지원을 통해 계약의 코드와 상태를 서로 다른 위치에 별도로 저장할 수 있습니다. 코드 셀의 코드(데이터) 필드는 코드를 저장하고 상태 셀의 상태(데이터) 필드는 상태를 저장합니다. Cell, contract ref는 자신이 저장한 State에 대한 비즈니스 로직 제약 조건을 설정하기 위해 Code Cell을 참조하고 Lock 참조는 State Cell의 소유권을 표현하기 위해 다른 Code Cell을 참조합니다. 각 State Cell은 서로 다른 사용자에게 속할 수 있으므로 Cell 모델의 독립적인 사용자 상태는 구현하기가 매우 쉽습니다(Account 모델에서 계약 상태는 종종 여러 사용자 상태로 구성됩니다. 예를 들어 ERC 20 계약에서 둘 다 Alice Bob의 토큰 잔액은 동일한 계약의 내부 상태에 기록됩니다).

CKB-VM에서 계약서 작성에 대해 더 알고 싶다면 다음 두 기사를 읽어보세요.

• Hello CKB！

• An Introduction to Nervos CKB-VM

보조 제목

First-class Asset

CKB의 사용자 정의 자산은 다음과 같이 구성될 수 있습니다.

• 자산 정의 계약(자산 정의)을 설계하고 자산의 주요 제약(예: 총 수량, 발행자, 거래 전후 변경되지 않은 수량 등)을 지정합니다.

• 자산 정의 셀에 계약 코드를 저장하십시오.

• 발행권한이 만족되면 발행자는 자산을 발행하고 다른 State Cell에 자산 상태를 저장합니다. 상태 셀의 계약 필드는 자산 정의를 저장하는 코드 셀을 참조하여 상태 셀의 변경이 자산 정의의 제약 조건을 따르도록 합니다.

• 자산 셀의 소유자는 잠금을 업데이트하여 자산 셀의 소유자를 변경할 수 있습니다.

이러한 디자인에서 사용자 정의된 자산은 시스템에 독립적인 개체로 존재하고 각 자산은 셀이며 각 자산은 고유한 식별자를 가지고 있음을 알 수 있습니다. Asset Cell은 UTXO의 일반화된 버전이라고 완전히 생각할 수 있습니다. 이러한 일류 자산에는 다음과 같은 이점이 있습니다.

• Asset Cell은 다른 계약의 매개변수로 참조되고 직접 전달될 수 있습니다. 자산 셀을 참조하는 입력에 올바른 사용자 권한이 있는 한 계약은 사용자의 자산 셀을 정상적으로 사용할 수 있습니다.

• 자산 정의는 자산 상태와 분리됩니다. 자산 정의 셀의 소유자는 자산의 발행자이며 자산 셀은 각 사용자에게 속합니다. Asset Cell의 Authorization 로직과 Business 로직이 분리되어 있으며, Asset Definition의 로직과는 무관한 자체 Lock에 의해 소유권이 완전히 결정됩니다. 발행자, 개발자 또는 자산 정의 계약이지만 진정으로 그리고 완전히 사용자가 소유합니다.

• 사용자의 자산은 서로 격리되어 있으며 사용자의 자산 상태는 독립적입니다. CKB의 경제 모델은 상태 저장 인센티브에 중점을 둡니다. 사용자는 블록체인에 상태를 저장하기 위해 쓰기 비용을 지불해야 할 뿐만 아니라 저장 시간에 비례하는 저장 비용도 부담해야 합니다. 사용자의 자산 상태가 혼재되어 한곳에 보관된다면(예: ERC 20) 이러한 상태의 보관 비용을 누가 부담할 것인가가 문제가 될 것입니다. (CKB 경제논문 열심히 하고 있습니다...);

• 자산 정의 셀의 잠금 논리가 허용하는 한 자산 정의를 독립적으로 업데이트할 수 있습니다.

보조 제목

Summary

Cell 모델은 매우 추상적인 모델로, 사실 First-class Asset on Cell을 구현할 수 있을 뿐만 아니라 Account on Cell도 시뮬레이션할 수 있습니다. 이 기사의 소개를 통해 Cell 모델이 UTXO 모델 및 Account 모델과 다른 새로운 디자인임을 알 수 있습니다. 상태 모델의 차이 외에도 CKB는 계산(즉, 상태 생성)을 체인 외부로 전송하고 체인에서 상태의 논리만 확인하면 됩니다. 상태 모델과 계산 검증의 고유한 분리는 새로운 DApp 패러다임과 디자인 패턴이 필연적으로 CKB 프로그래밍 모델에 나타날 것이라고 결정합니다.

CKB 백서를 완성한 지 거의 1년이 지난 지금, 우리는 점점 더 많은 사람들이 First-class State와 First-class Asset의 두 가지 새로운 아이디어에 주목하고 논의하기 시작하는 것을 보았습니다(모두가 사용하는 용어는 다르지만) . 동일), 우리는 이러한 발전에 대해 매우 기쁘게 생각합니다. First-class State 및 First-class Asset에 대해 더 논의하고 싶거나 CKB의 프로그래밍 모델에 대한 흥미로운 아이디어가 있는 경우 토론을 위해 저희에게 연락하십시오 ~

CKB의 코드는 완전히 오픈소스로 공개되었으며, 이 글에서 소개한 내용을 코드로 구현하였습니다. 코드에 대한 의견을 환영합니다.

• https://github.com/nervosnetwork/ckb-demo-ruby-sdk (CKB에서 Ruby 스크립트로 프로그래밍한 예, CKB에서 프로그래밍 모델을 이해하는 데 가장 좋은 항목)

• https://github.com/nervosnetwork/ckb

• https://github.com/nervosnetwork/ckb-vm

CKB와 Cell 모델 설계에 도움을 주신 Ian Yang, Xuejie Xiao, Kevin Wang에게 감사드립니다 ~