この記事の著者は Jan です。この記事では、Cell モデルでサポートされている非常に興味深い DApp 設計パターン、つまり暗号化された資産をブロックチェーン内の「第一級市民」にするファーストクラス アセットについて説明しています。

関数型プログラミングが好きなエンジニアならよく知っている用語です。「第一級関数」は、中国語に訳すと「第一級関数」または「第一級関数」と呼ばれます。ファーストクラス関数とは、関数が完全に独立した概念であるプログラミング言語のクラスを指します。関数は値として変数に割り当てたり、パラメーターとして他の関数に渡したり、戻り値が他の関数から渡されたりすることができます。機能。このような言語では、データを操作するように関数を操作できるため、これらの言語では関数とデータは「第一級市民」です。 First-class Function は関数型言語の重要な機能であり、関数型プログラミングのパワーの多くはそこから得られます。

副題

状態モデルの簡単な入門書

Cell モデルが登場する前は、基本的に、UTXO モデルと Account モデルという 2 つの状態モデルがさまざまなブロックチェーンで使用されていました。

UTXOモデルの代表はビットコインです。 UTXOとはUnspent Transaction Outputの略で、簡単に言うとビットコインのようなものですが、通常のコインとは異なり、UTXOの額面はそれぞれ異なります。各 UTXO は、ロック スクリプト (Lock Script) を通じてコインの所有者が誰であるかを記録し、同時に所有者だけがコインを使用できるようにします。各ビットコイン フル ノードは、現在のすべての UTXO のコレクションを維持します。これをビットコイン台帳の現在の状態 (つまり、現在の台帳) と呼びます。すべてのビットコイン転送は、UTXO セットからいくつかのコイン (送信者に属する) を削除し、いくつかの新しいコイン (受取人および/または送信者に属する) を追加するプロセスです。台帳状態全体は UTXO の最小単位に基づいて構築されるため、これを UTXO モデルと呼びます。

文章

したがって、コイン (Coin) は UTXO モデルのファーストクラス シチズンであり、各 UTXO は独立した識別子 (トランザクション ID + 出力インデックス) を持つオブジェクトであり、Coin はユーザーによって直接操作されるオブジェクト (ユーザーが構築する) であると言います。トランザクションにはUTXOが含まれます）、アカウントはCoinによって確立された上位概念に基づいています（ウォレット内にのみ存在します）。したがって、UTXOはファーストクラスのコインです。

アカウント モデルでは、アカウントは第一級市民であり、アカウント残高に集計されたコインには独立した識別子がありません。アカウントはユーザーの直接操作の対象であり、資産の譲渡はユーザーの代理人であるアカウントによって実現されますが、これは受取人が契約アカウントである場合に最も顕著です。このようなモデルでは、ユーザー定義の暗号化資産 (ERC 20 など) は、ポイントツーポイント転送ではなく、サードパーティの会計手法に似ています。この違いにより、サードパーティ (ここでのサードパーティとは、管理された暗号化資産スマート コントラクト) では、資産転送プロセスが導入され、スマート コントラクトの設計が複雑になります (スマート コントラクトは、資産が転送されるときに自動的に実行されるロジックと考えることができます)。この複雑さを軽減するには、Account モデルのトランザクションに特別なロジック (Value フィールド) を追加する必要がありますが、そのような特別なロジックはネイティブ アセットにのみ役立ち、ネイティブ アセットとユーザー定義アセットで異なるコード パスが発生します。

これらの問題について、ケルビン・フィッチャーは次のように書いています。Looking at ownership in the EVM分析はよく行われているので、ここでは繰り返しません。

これらの背景を踏まえると、CKB の設計コンセプトをより簡単に理解できるはずです。

Cell モデルを使用すると、設計を簡素化し、ユーザー定義アセット (User Defined Assets) を Nervos CKB の「ファーストクラス アセット」として実装できます。これはファーストクラス アセットと呼ばれます。

副題

First-class State

一流の資産を実現するにはどうすればよいですか?

いずれにせよ、所有者と資産との関係を文書化する必要があります。これらの関係レコードは本質的にコンセンサス状態です。ファーストクラスの資産を持つには、まずファーストクラスの状態が必要です。これがセル モデルの開始点です。

Nervos CKBの名前はCommon Knowledge Base（共通知識ベース）の略称に由来しています。 Nervos ネットワークのブロックチェーンを「Common Knowledge Base」と呼ぶ理由は、その責任がネットワークの共通の状態に関するグローバルなコンセンサスを継続的に形成することであるためです、言い換えれば、CKB はグローバルなコンセンサス ライブラリによって維持される状態です。州ライブラリの基本モデルは、自然に州全体をより小さな州単位に分割して組織化します。これらの小さな状態単位がセルです。

Cell は独立した識別子 (トランザクション ID + セル出力インデックス) を持つステート単位であるため、直接参照したり、パラメーターとしてスクリプトに渡すことができます。CKB における「一級市民」、つまりステートを意味します。 CKBは「第一級国民」です。セルはファーストクラスの状態であるだけでなく、最も単純なファーストクラスの状態でもあります。セルには容量、データ、ロック、およびコントラクトのみがあります (オプション。コントラクトはコードの一部またはコード セルを指す参照にすることができます)。田畑。

下図に示すように、Cell の所有者は、Cell に保存されている状態を仲介者を介さずに直接更新できますが、Account モデルでは、ユーザーはコントラクト コード (アカウント内のコード) を通じてのみアカウント内の状態を操作できます。 . 実際には、契約の手でホストされています。

Cells を使用すると、CKB は実際にステートフル プログラミング モデルを獲得できることを指摘する価値があります。一般的な見解は、イーサリアム プログラミング モデルの表現力はチューリングの完全な仮想マシンから来ているということです。実際、スマート コントラクトを有効にしてアカウントを通じてコン​​ピューティング状態を保存できることは、EVM よりも利点です (チューリングの不完全な言語も非常に強力です。表現力: https ://en.wikipedia.org/wiki/Total_function_programming)。

CKB は、Cell と CKB-VM の組み合わせを通じて、新しいステートフル スマート コントラクト プログラミング モデルを実装します (シンプルでありながら強力です! これは別の記事です)。このプログラミング モデルは、レイヤー 2 により適しています。レイヤー 2 プロトコルの共通パターンを分析すると、プロトコル層間の対話オブジェクトは、イベント オブジェクト (イベント トランザクション) ではなく状態オブジェクト (状態トランザクション) である必要があることがわかります。 1 は計算層ではなく状態層である必要があります。

CKB プログラミング モデルのもう 1 つの特徴は、データ (状態) とコードが区別されないことです。この文は、Account モデルとは異なり、コントラクトの状態とコードを Cell の Data フィールドに保存でき、コードを保存した Cell は他の Cell から参照できることを意味します (これらは First-class State であるため)。 )、コントラクトの状態 また、コードをまとめて 1 か所に保管する必要はありません。開発者は、簡単な命令を通じてコード セルまたはデータ セルの内容をランタイム メモリにロードし、必要に応じてコードの実行またはデータの読み取りおよび書き込みとして解釈できます。

これらの基礎的なサポートにより、コントラクトのコードと状態をさまざまな場所に個別に保存できます。コード セルのコード (データ) フィールドにはコードが保存され、状態セルの状態 (データ) フィールドには状態が保存されます。セル、コントラクト参照はコード セルを参照して、それ自体で保存された状態に対するビジネス ロジック制約を確立します。ロック参照は別のコード セルを参照して、状態セルの所有権を表現します。各状態セルは異なるユーザーに属することができるため、セル モデルの下で独立したユーザー状態を実装するのは非常に簡単です (アカウント モデルの下では、契約状態は多くの場合複数のユーザー状態で構成されます。たとえば、ERC 20 契約では、両方のアリスおよびボブのトークン残高は、同じコントラクトの内部状態に記録されます)。

CKB-VM での契約書の作成について詳しく知りたい場合は、次の 2 つの記事をお読みください。

• Hello CKB！

• An Introduction to Nervos CKB-VM

副題

First-class Asset

CKB のユーザー定義アセットは次のように構成できます。

• 資産定義契約（資産定義）を設計し、資産の主な制約（総数量、発行者、取引前後で変わらない数量など）を指定します。

• 契約コードを資産定義セルに保存します。

• 発行権限が満たされると、発行者は資産を発行し、資産ステータスを別のステート セルに保存します。ステート セルのコントラクト フィールドは、資産定義を保存するコード セルを参照し、ステート セルの変更が資産定義の制約に従うようにします。

• アセット セルの所有者は、ロックを更新することでアセット セルの所有者を変更できます。

このような設計では、ユーザー定義の資産が独立したオブジェクトとしてシステム内に存在し、各資産がセルであり、各資産が独自の識別子を持っていることがわかります。 Asset Cell は UTXO の汎用バージョンであると完全に考えることができます。このようなファーストクラス資産には次の利点があります。

• アセットセルは参照でき、他のコントラクトのパラメータとして直接渡すことができます。アセット セルを参照する入力に正しいユーザー権限がある限り、コントラクトはユーザーのアセット セルを通常どおり使用できます。

• 資産定義は資産状態から分離されます。アセット定義セルの所有者はアセットの発行者ですが、アセット セルは各ユーザーに属します。アセットセルの認可ロジックとビジネスロジックは分離されており、所有権はアセット定義のロジックとは関係なく、独自のロックによって完全に決定されるため、ファーストクラスのアセットはアセットの手にホストされません。発行者、開発者、または資産定義契約ですが、真に完全にユーザーが所有します。

• ユーザーの資産は互いに分離されており、ユーザーの資産ステータスは独立しています。 CKB の経済モデルは状態ストレージのインセンティブに焦点を当てています。ユーザーはブロックチェーン上に状態を保存するために書き込み料金を支払う必要があるだけでなく、保存時間に比例するストレージ コストも負担する必要があります。ユーザーの資産ステータスが混在して 1 か所に保管されている場合 (ERC20 など)、これらのステータスの保管コストを誰が負担するかが問題になります。 (CKB 経済論文は頑張っています...);

• アセット定義は、アセット定義セルのロック ロジックが許可する限り、独立して更新できます。

副題

Summary

Cell モデルは高度に抽象化されたモデルであり、実際、Cell 上でファーストクラスのアセットを実装できるだけでなく、Cell 上でアカウントをシミュレートすることもできます。この記事の紹介を通じて、Cell モデルが UTXO モデルや Account モデルとは異なる新しい設計であることがわかります。状態モデルの違いに加えて、CKB では計算 (つまり状態生成) をチェーンの外側に転送し、チェーン上の状態の論理を検証するだけで済みます。状態モデルと計算検証を独自に分離することにより、新しい DApp パラダイムと設計パターンが CKB プログラミング モデルに必然的に現れることが決まります。

CKB白書が完成してからほぼ1年が経ち、ますます多くの人々がファーストクラス国家とファーストクラス資産という2つの新しいアイデアに注目し、議論し始めています（ただし、使用する用語は人それぞれ異なります） . 同）、私たちはこれらの発展に非常に興奮しています。ファーストクラスの国家とファーストクラスの資産についてさらに議論することに興味がある場合、または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 に感謝します ~