Nervos開発者・Tannr AllardによるAMA第一弾
Q：Nervos DAOについて説明してください
A：「Nervos DAO」には、180エポックの間続く「デポジット期間」の概念があります。CKBytesをDAOにデポジットし、後続の180エポックの前にそれらを撤回するトランザクションを作成した場合、そのデポジット期間の終わりにCKBytesが撤回されます。
DAOには、こちらからアクセスできます。
Q：年間13.44億トークンは総インフレですか？
A：二次発行による総インフレです。
Q：総インフレが年13.44億トークンであった場合、どうなりますか？また、Nervos DAOによる追加のインフレがありますか？
A：13.44億という数字は、二次発行による総インフレ数です。Nervos DAOは追加のインフレを提供せず、トークンをDAOにロックしたアドレスに2次発行の一部を分配します。トークンはマイナーに対するブロック報酬としても生成されます。
Q：Nervos Foundationは、ジェネシスブロック内のCKBytesの15％を占めるデータの書き込みを行いますが、ジェネシスブロックの残りの10％のCKBytesはNervos DAOにロックされず、残ります。これらのトークンの秘密鍵は誰が管理していますか？凍結されているのでしょうか？
A：こちらから、ジェネシスブロック生成中に作られたセルのロックスクリプトを表示し、システムセル及びバーンされたトークンが正しいロックスクリプトを使用していることを確認できます。
また、ブロック内の最初のトランザクションはこちらから確認できます。
resource / specs / mainnet.tomlの下のckbリポジトリから確認することもできます。
Q：トランザクション本体でcell_depsとheader_depsはどのように構成されるのですか？これは不変ですか？
A：これは、使用しているSDKに依存しますが、基本的に、depsはアウトポイントです。トランザクションにdepを含めるには、含めるセルのアウトポイントが必要です。つまり、セルが既にチェーン上に存在している必要があります。
Q：トランザクション上で「InvalidCodeHash」と表示されました。これはどういう意味ですか？
A：「invalidCodeHash」というエラーメッセージは、トランザクションのセルのスクリプトリファレンスに問題があることを示しています。セルには選択制のtypeフィールドと必須のlockフィールドがあることに注意してください。これらのフィールドの両方には、チェーン上の他のセルに格納されている実行可能コードへの参照情報を含むJSONのようなオブジェクトが含まれています。トランザクションが処理されているとき、すべての依存関係がロードされます。トランザクションの入力と出力が処理されているとき、この手順の一部には、typeフィールドとlockフィールドによって参照されるスクリプトのロードと実行が含まれます。JSONのようなスクリプト構造のcodeHashは、depセル（トランザクションのdepフィールドで参照されるセル）タイプフィールドまたはそのデータフィールドのハッシュを参照します。
Q：Nervos DAOでロックすると、CKBytesをいくつ獲得できますか？
A：取得できるCKBytesの数は、二次発行による総供給量の増加に比例します。そのため、トークンを1年間ロックし、二次発行により総供給量が4％増加した場合、供給量も4％増加します。ジェネシスブロックからの最初の供給は33.6B CKBytesであり、二次発行は1.344B CKBytesという一定の年率で発生します。ジェネシスブロックから最初の年の終わりまでのAPCは3.7％になります。詳細はこちらを参照してください。
Q：セル内のステートフルアプリに関する記事はありますか？CKBモデルでは、セルを読み取るtxの確認はセルを破壊しますか？
A：現在、コミュニティ向け教育コンテンツの作成と、開発を可能な限り簡単にするためのツールの構築に取り組んでいます。セルモデルについては既にいくつかの優れたコンテンツがあります。これについては、RFCのレポをご覧ください。また、フォーラムで開発に関する議論を行っています。セルがインプットとして使用される場合、セルは破壊されます。ただし、トランザクションにはdepsフィールドもあるため、セルを破壊することなく、トランザクション内のスクリプトからアクセスできる依存関係としてセルを含めることができます。
Q：CKBスクリプトのテスト用インフラはありますか？
A：CKBスクリプトのデバッガーのプロトタイプを以下に示します。私たちはCKB開発のためのより良いツールを作成するために一生懸命取り組んでおり、コミュニティの参加を歓迎します。これこそ分散型ネットワークです！デバッガーリポジトリは、NervosのGithubにあります。CKB-バーチャルマシンの共同開発者の1人であるXuejieがこのデバッガーの使用方法を説明する素晴らしい記事を書いています。
Q：セルを同じトランザクションの入出力にすることはできますか？もし可能ならば、やり方を教えて下さい。
A：セルを同じトランザクションのインプット・アウトプットにすることはできません。セルは、セルを作成したトランザクションのトランザクションハッシュと、トランザクションの出力内のターゲットセルのインデックスを含むアウトポイントを介して参照されます。それにもかかわらず、CKBのプログラミングモデルは非常に柔軟性が高く、セル間通信を実現する方法は複数あります。
Q：CKB残高は何バイトですか？
A：1 CKByteは、セルの1バイトの容量を表します。CKBytesの内部単位は「shannons（シャノン）」で測定されます。1CKByteは10 ^ 8シャノンに相当します。
Q：①ブロックプロデューサーがそれを再計算する必要があり、かつ②データが完全にオンチェーンである場合、クライアントが新しい状態を計算するポイントは何ですか？
A：ブロックプロデューサーは、新しい状態を計算する必要はありません。ノードは検証スクリプトを実行して状態の変更を検証し、これらのスクリプトは開発者が選択したアルゴリズムを使用できます。たとえば、NFTを使用して収集可能なカードゲームを構築している場合、オークション機能とそのための市場全体を構築することができます。これはすべてオフチェーンで構築できます。重要なデータのみをチェーンに保存する必要があります。たとえば、カードの所有権です。そのため、この洗練された計算はすべてチェーン外で実行でき、新しい所有者の最終的な決済のみがチェーン上で送信されます。
Q：検証と生成の切り離しについて、クライアントとノードの両方が計算を実行する必要がある場合の利点は何ですか？
A：検証と生成を分離する目的は、人々が高度なセキュリティと分散化を備えたレイヤー1ブロックチェーンの特性をより活用できるようにすることにあります。検証スクリプトは技術的には一種の計算であるため、CKBが計算と検証を分離するわけではありません。むしろ、オンチェーンスクリプトはそれ以上の状態変更を生成しません。単に状態の変化を確認するだけです。これには複数の利点があります。第一に、これによりプログラミングモデルがよりシンプルで、推論が容易になります。状態変更の結果は、スクリプトの実行により、考慮すべきな予測不能な副作用が発生しないため、事前に判明しています。第二に、生成の責任をオンチェーンに求めることはリソースの浪費になります。レイヤー1の目的は、ブロックチェーンに高度なセキュリティと分散性を具備させることであり、これにより、オンチェーンデータの真実性と有効性についての強力な保証が提供されます。要するに、検証が分散的ではない場合、状態生成は分散である必要はありません。検証は生成ではなく、上記の保証を提供するからです。過去数年間に、レイヤー1とレイヤー2のプロジェクトが自然に分割されるという進化が見られます。レイヤー2プロジェクトは非常に多様です。状態生成をチェーンから外すことにより、状態の生成方法を制限することを避け、決済と検証にCKBを使用したいレイヤー2プロジェクトに与えられる可能性と柔軟性を開きます。
Q：検証者はジェネレーターと同じ量の仕事をしますか？
A：ジェネレーターは、トランザクションとしてパッケージ化してCKBに送信することで状態変更を生成する責任があるため、計算を実行してその状態変更を作成し、その状態変更を検証します（最初に不必要な費用を発生させる無効なtxを送信する理由がありますか？）。オンチェーンで動作する検証ロジックは、より最適化されたアルゴリズムおよび/またはそのアルゴリズムの実装を使用できます。一般に、ジェネレーターは検証者よりも多くの計算作業を実行する必要があります。検証は、リソースがより制限されるオンチェーンで行われるため、オンチェーンでの作業が多いほど手数料が高くなり、トランザクションサイズ及びトランザクション検証の結果として執行されるスクリプトの計算に制限が生じます。ここでは、検証ルールは開発者に一任されています。しかし、ジェネレーターはおそらく、正しい状態（少なくともほとんどの場合）のみが送信されるようにするために、さらに多くの作業を実行するでしょう。
Q：イーサリアムのコントラクトを使用してセルをシミュレートできますか？
A：シミュレートしたい内容によっては、これは非常に困難です。セルは単なるデータ構造です。ただし、1つのコントラクトまたは一連のコントラクトにセルセットを格納できます。CKBでは、セルデータフィールドに実行可能なバイナリコードを含めることができます。Ethereumでは、実行可能コードはEVMバイトコードに制限されていますが、CKBはRISC-V VMで構築されています。したがって、イーサリアムのセルのように見えるものを作成できますが、それらを正しく動作させるのは非常に困難です。おそらく実行できますが、ほとんど役に立たないものになるでしょう。
シミュレートが困難な理由はVMによるものだけではありません。
EVM互換言語を使用してRISC-V VMを構築し、その上にセルを構築し、コントラクトごとに1つのセルを関連付ける…などといった、.前述したようなかなり厄介な手順が要求されます。
