CKB のガバナンスと Git からの進化

元のタイトル: 「CKB、バージョン管理、ブロックチェーンの進化」

原作者: Jan Xie、Nervos Chinese Community

私はライナスのファンです。彼は、広く普及しているオープンソースのオペレーティング システムを作成し、私が大好きな本の共著者であり、ほぼすべての開発者が毎日使用する分散バージョン管理システムを構築しました。

私は Git を見た瞬間から使い始め、そのスピードと優雅さに魅了されました。開発者はバージョン管理システム 1 を使用してソース コードを管理し、コードの更新を常に把握したり、友人や同僚と変更を共有したり、新しいエラーが発生したときに以前のバグのないバージョンにロールバックしたりすることができます。 Git は人生をより楽しくしてくれます。CKB でも同じことができるといいのですが。

CKBはGitです

CKB および Cell モデルを作成するプロセスは Git からヒントを得ました。 Git は、Linux カーネルの開発を促進したいという Linus の願いから生まれたもので、コメントからブログ投稿、画像まで、何かを整理したいときにいつでも使用できます。優れた履歴追跡機能を備えたナレッジ ベースです。

Git リポジトリは「リポジトリ」と呼ばれ、内部的に不変の追加専用オブジェクト データベースを維持します (覚えていますか?)。 Git の基本的なストレージ ユニットは Blob (バイナリ ラージ オブジェクト) です。これは、CKB のセルと同様に、リポジトリに保存されるデータを含むオブジェクトです。 Git は各ファイルの各バージョンに対して BLOB オブジェクトを作成します。新しいファイルが作成されるたびに、新しい BLOB が作成されます。既存のファイルを変更するたびに、古い BLOB を変更せずに新しい内容の BLOB を作成します (聞き覚えがありますか?)。各 BLOB はハッシュ化され、BLOB ハッシュは BLOB を参照するための識別子として使用されます。数時間作業した後、いくつかの新しいファイルを作成し、いくつかの既存のファイルを変更し、すべての変更をリポジトリにコミットし、新しいコミットを同僚と同期して、1 日の作業を終了します。

コミットは Git における基本的な履歴ポイントであり、リポジトリの履歴はリポジトリの起源から最新の更新までの一連のコミットで構成されます。コミットとは、特定の時点におけるリポジトリのバージョンであり、作成者、タイムスタンプ、以前のコミット、BLOB ツリーへの参照などのバージョン メタデータが含まれます。ブロック ヘッダーが、マイナー アドレス、タイムスタンプ、親ブロック ハッシュ、トランザクション マークル ツリーのルートを書き込むことによって、ブロックチェーンのすべての更新のメタデータを保持するのと同じです。マイナーがブロックの履歴を拡張することで報酬を得るのと同じように、あなたとあなたの同僚は Git リポジトリの履歴を拡張することで報酬を得ます。

Git リポジトリにはフォークも存在します。人々はさまざまなブランチで作業しますが、どのブランチが「正しい」ブランチであるかは、合意ではなくリポジトリのメンテナーによって決定されます。 Git はコンセンサスのない分散システムであり、データ交換にはアドホックなピアツーピア通信 (ssh や電子メールなど) に依存しています。

Git とブロックチェーンの類似性は、ブロックチェーンやスマート コントラクトの開発者が Git の実証済みの利点の一部を享受できるように、ブロックチェーンに矛盾する設計上の選択を導入するのではなく、Git のアイデアをブロックチェーンに組み込む際にはより慎重になるべきであることも意味します。 CKB の内部は実際には次のようになっています。真の P2P ネットワーキング、グローバル コンセンサス、パワー ブロブを備えた独自の大規模 Git リポジトリであり、匿名の人々のグループによって継続的に更新されます。

これはブロックチェーンではない

セルに好きな名前を付けます

本質的には、Git と CKB はどちらもデータ オブジェクト (BLOB/セル) とハッシュ参照です。ハッシュ参照はオブジェクトの固有の名前であり、振ることでデータの値を抽出することができる魔法の杖です。オブジェクトの名前がわかれば、それを参照し、そのパワーにアクセスできます。 CKB では、スマート コントラクトのコードとユーザー データは分離されているため、ハッシュ参照を使用してコードまたはユーザー データの一部に直接名前を付けることができ、システム 2 内のファーストクラス オブジェクトになります。この細かい粒度により、柔軟で強力なプログラミング モデルが作成されます。いくつか例を挙げます。

コード/データの再利用

セルは参照可能なストレージ ユニットであるため、CKB 上のコード/データを簡単に再利用できます。セル 0xbeef#1 (トランザクション 0xbeef の出力 1) に共有コード/データが格納されていると仮定すると、それを再利用するには、デフォルトのロック スクリプトに示されているように、まずセル 0xbeef#1 をトランザクション依存関係 (cell_deps) としてロードし、次に ckb_load_cell_data システム コールを使用してそこからデータを読み取る必要があります。セル 0xbeef#1 のデータが VM メモリにロードされると、必要に応じてコードまたはデータとして使用できます。このように、CKB は、その上で実行されるスマート コントラクトが使用するコードとデータの共有ライブラリのようなものです。既存のセキュリティレゴブロックを組み合わせてスマートコントラクト4を構築できたら素晴らしいと思いませんか? GitHub のどこかからコードをコピーして同じコードを何度もデプロイする必要がなく、チェーン上の時間とスペースを無駄にすることがなくなります。イーサリアム契約の分析[5][6]では、契約の95%～99%が重複していることが示されました。

イーサリアムで最も複製されたスマートコントラクト

依存関係の削除を心配する必要はありません

上記のコード/データの再利用の例では、セルは不変であるため、つまり誰もそれを変更する方法がないため、依存セルに格納されているコード/データを誰かが変更することを心配する必要はありません。しかし、依存セルの所有者がそれを CKB から直接削除した場合はどうなるでしょうか?そうするとスマート コントラクトは使用できなくなりますか?

これはまさにイーサリアムの場合です。この分野に長く携わってきた人なら、2017年に起きた2億8000万ドルの事故をご存知でしょう[7]。この悲劇は、他の多くのスマート コントラクトで使用されていた Ethereum 上のスマート コントラクトが誤って削除されたことによって引き起こされました。この削除により、それに依存していたすべてのスマート コントラクトが機能しなくなり、それらのスマート コントラクトに保存されているすべての資産が凍結されました。

CKB では、コードのコピーを保持している人 (フルノードや複雑な軽量クライアントを実行している人など) は誰でも同じコードをチェーン上に再度デプロイでき、コード ハッシュへの参照は引き続き有効であるため、このような事故による影響はありません。新しい依存関係セルを使用してトランザクションを構築するだけです。誰もお金を失うことはなく、すべては正常に機能し続けます。

依存関係の削除からの回復

実際、これを意図的に使用して、コードの「展開前の使用」を実装することもできます。セルを保護するために、新しいカスタム ロック スクリプト (スマート コントラクト) を使用するとします。通常の使用前のデプロイプロセスとは異なり、デプロイせずに使用できます。新しいロック スクリプト (コード実装) のコード ハッシュをセル ロック (コード使用) に配置するだけで、これらのセルは新しいロックによって保護され、すぐに有効になります。

実際のロック スクリプト コードの展開は、セルのロックを解除するまで延期できます。ロックを解除したい場合は、まずチェーン上にスクリプト コードをデプロイし、その後別のトランザクションを送信して通常どおりセルのロックを解除する必要があります。セルのロックが解除されたら、デプロイされたコードを削除し、占有されている CKBytes を取り戻して、不要なストレージ コストを削減できます。展開前に使用することのもう 1 つの利点は、プライバシーが向上することです。つまり、ロックを解除するまで、この新しいロックのロジックが何であるかは誰にもわかりません。

進化したCKB

CKB と Git の類似点と利点を理解した後、より興味深い質問を検討してみましょう。CKBが Git リポジトリである場合、CKB を使用して CKB のコードを管理できるでしょうか?

はい！このため、トランザクション署名検証[8]やNervos DAO [9]などのCKBコア機能の一部はスマートコントラクトの形で実装されています。トランザクション署名の検証を例に挙げてみましょう。これはほぼすべてのブロックチェーンのコア機能であり、ネイティブ言語でハードコードされています (たとえば、Bitcoin では C で、go-ethereum では Go で記述されています)。

ブロックチェーンをアップグレードするには、新しいソフトウェア バージョンを多数のノードに配布して展開する必要があり (ソフト/ハード フォーク)、そのためには多くの調整が必要です。 CKB の場合、他のスマート コントラクトと同様に、チェーン上に新しいバージョンをデプロイすることで、トランザクション署名の検証をアップグレードできます。これによりCKBはTezos [10]が提案する長期的なアップグレード可能性を実現できます。

もっとうまくできるはずだ。 CKB では、各ユーザーが自分のデータを所有するため、契約はユーザーと CKB 間の二者間の合意のようなもので、個人が独立した選択を行うことができます。コードハッシュ[11]による契約を使用する場合、それは「私はこの特定のバージョンの契約に同意する」ことを意味します。新しいコントラクトのコード ハッシュは異なるため、開発者が将来コントラクト コードをアップグレードしても心配する必要はありません。ロック/タイプは新しいコントラクトではなく古いコントラクトを参照します。新しいバージョンが展開されると、システム内で古いバージョンと共存することになります。コード ハッシュを介してシステム コントラクトを使用する場合、新しいバージョンは影響せず、アップグレードするかどうかを決定できます。答えが「はい」の場合、すべてのセルを更新して新しいバージョンを使用できます。答えが「いいえ」の場合、何もする必要はなく、古いバージョンを引き続き使用してください。

これは、作成時にセルに添付された契約が変更されていないことを確信できるため、頻繁にオンラインにならない可能性のある保有者にとって親切な保証です。ユーザーの資産は、ロック時に指定した方法で常にロックされます。これは SoV ユーザーに対する究極の保証であり、CKB 資産が他のブロックチェーン上の資産と異なる理由です。これは、ビットコインがソフトフォークのみに従うことで保有者に保護を提供する方法と同じです。唯一の欠点は、セキュリティのアップグレードを行う時期になると「手遅れ」になるリスクがあることです。したがって、利便性のために、開発チームを信頼しており、契約の確認や手動でのアップグレードを心配する必要がないため、常に最新バージョンを使用することを好む人もいます。この場合、契約を参照するためにタイプid[12]を使用します。大まかに言えば、タイプ ID は Git の HEAD のようなもので、常に現在のリビジョンを指す更新可能な参照です。両方のオプション (コード ハッシュによる参照とタイプ ID による参照) を提供することで、適切なアップグレード戦略を選択する権限をユーザーに返します。選択肢があるのは常に良いことです。私たちにはさまざまな選択肢があり、アップグレードを強制される人はいません。

システムスクリプトのアップグレード

長期的には、CKB はますます抽象化とモジュール化が進み、より多くのコア機能が抽出され、オンチェーン スマート コントラクトに実装されるようになります。完全な形では、ソフト/ハードフォークなしで CKB をアップグレードできるはずです。ここで欠けているのは、私たちコミュニティがシステム契約をアップグレードするかどうかをどのように決定するか、あるいは CKB のガバナンス モデルは何かという点です。より正確には、システム コントラクトのタイプ ID をアップグレードする方法を決定します。

現在、CKB はビットコインと同じオフチェーン ガバナンス モデルを使用しており、依然としてソフト/ハード フォークに依存しています。タイプ ID 参照を使用しているユーザーがシステム スクリプトの新しいバージョンを有効にするには、コード セルがロック解除不可能なロックでロックされているため、タイプ ID 参照を更新して最新バージョンを指すようにハード フォークする必要があります(https://explorer.nervos.org/address/ckb1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhzeqga、コード ハッシュを確認してください) 。システム スクリプトのアップグレードはコミュニティによるガバナンスの決定に従う必要があるため、コア チームによって制御されるマルチ署名ロックを使用しないことは意図的な選択です。

当社のポジショニングホワイトペーパーで述べたように、興味深い提案は数多くある一方で、実用的なガバナンスモデルはまだ見つかっていません。適切なガバナンス モデルが見つかったら、ロック解除可能なロックを「ガバナンス ロック」に置き換えて、投票の結果などコミュニティの同意を得てシステム スマート コントラクトをアップグレードできるようになります。それまでは、今のところは不完全なオフチェーン ガバナンス モデルに固執しますが、CKB ガバナンスと進化のバックボーンはすでに存在しています。

参照:

[1]:https://en.wikipedia.org/wiki/バージョンコントロール

[2]:https://talk.nervos.org/t/first-class-asset/405

[3]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_helper.h#L40-L66

[4]:https://talk.nervos.org/t/rfc-swappable-signature-verification-protocol-spec/4802

[5]:https://www.researchgate.net/publication/332799463_Characterizing_Code_Clones_in_the_Ethereum_Smart_Contract_Ecosystem

[6]:https://security.cse.iitk.ac.in/sites/default/files/17111011.pdf

[7]: https://medium.com/hackernoon/what-c​​aused-the-latest-100-million-ethereum-bug-and-a-detection-tool-for-similar-bugs-7b80f8ab7279
[8]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_blake160_sighash_all.c
[9]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/dao.c
[10]: https://tezos.com/
[11]:https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0022-transaction-structure/0022-transaction-structure.md#upgradable-script
[12]:https://docs.ckb.dev/blog/ckbscript-06

オリジナルリンク: https://mp.weixin.qq.com