CelestiaはDAモジュールの看板になるのでしょうか？

出典： CryptoYC Tech

Celestiaとは

Celestiaの前身はLazyLedgerです。「データの可用性」に特化したインフラストラクチャです。もちろん、Celestia自体は一つのチェーンですが、状態計算の問題には関与していません。したがって、ここからデータの可用性の重要性やスケーラビリティとの関係など、一連の先験的な問題が派生します。

ここで、従来のブロックチェーンのデータ問題を見てみましょう。ETHを例にとると、現在ほとんどのノードはライトノードであり、ブロック生成を担当せず、ブロックを検証するだけです。しかし、検証されるのはブロックヘッダーだけであるため、ブロック生産者が正しい有効なブロックヘッダーを発表したが、取引データを含まない/隠蔽した場合、データの可用性の問題が発生し、ライトノードは容易に欺かれたり無効なブロックを受け入れたりする可能性があります。

また、フルノードはライトノードにデータ可用性証明や無効ブロックの詐欺証明を生成できないため、ライトノードがブロックデータ自体を検証するには、自分で行う必要があります。あるいは、ほとんどのデータが誠実で信頼できると仮定します。

明らかに、安全のためには、ほとんどのノードがすべての取引データをダウンロードし、データの可用性を検証する必要があり、これがスケーラビリティの問題を引き起こします。

ここまで来ると、データ可用性の二つのボトルネックが明らかになります：

• 可用性証明： 他のノードに、このブロックのデータが真実で可用であることを伝える。

• 詐欺証明： ブロックが有効であるかどうか。

これがCelestiaが解決しようとしている二つの問題です。

どうやって解決するのか

では、Celestiaはどのようにこの二つの問題を解決するのでしょうか？とてもシンプルです：チェーン上の実行を放棄し、チェーン上の状態変換を放棄し、二次元Reed-Solomonエラー訂正符号と専用の名前空間マークルツリー構造を通じてデータの可用性を確保し、実行部分はエンドユーザー自身に任せます。では、この二つのものを簡単に見てみましょう。

二次元R-Sエラー訂正符号

このものは要約すると、特定の情報を伝達する際、情報そのものだけでなく、いくつかの冗長性を加えて誤りに耐えられるようにすることです。簡単な例を挙げると：

• 例えば、私は他の人に情報1 2 3を伝えたいと思っていますが、情報伝達の過程で一部の情報が失われたり誤って伝わる可能性があることを知っています。したがって、他の人が私が伝えた情報を最大限正しく確認できるように、one two threeを伝えることにします。

• もし他の人が受け取った情報がon, to, theeであった場合、受け手が内容の形式を知っていれば、この例では数字であるため、元のデータが1 2 3であると高い確率で確認できます。

もちろん、ここには閾値問題が関わります。情報が合計n個の断片から成ると仮定し、k個の断片が正しく伝送されれば、完全な情報が復元できるということです。つまり、成功した伝達の割合が＞k/nであればよいのです。標準のReed-Solomonエラー訂正符号に従うと、この閾値は50%です。

Celestiaに具体的に言うと、彼らは新しいサンプリング方法を提案しました：二次元サンプリング。 情報を横と縦の数が同じ二次元の断片に分割します。詐欺証明（データ可用性証明）を検証する際、ライトノードは横方向または縦方向のデータをダウンロードするだけで済み、これによりダウンロードするデータ量は直接 √N（データがn*nの断片に分割されていると仮定）になります。

もちろん、完全なデータをダウンロードしていないため、ライトノードは各行と各列のマークルツリーの根をブロックヘッダーの一部としてダウンロードして検証する必要があります。これにより、データの最大の可用性が保証されます。こうして、Celestiaネットワーク全体がP2Pベースのシードダウンロードネットワークに変わります。少ないデータで、データの可用性を高い確率で確認できます。

名前空間マークルツリー

私たちは、イーサリアムの状態更新がグローバルに同期されていることを知っています。状態変換のたびにすべてのアドレスの状態が更新されます。不適切な例を挙げると：私がイーサリアム上でwww.cryptoyc.comのデータを更新した場合、ノードは状態を更新する際にcryptoycのデータだけでなく、無関係なデータ（例えばwww.123.comの状態）も更新および検証します。明らかに、これは不合理です。

したがって、Celestiaはデータを保存する際にnamespace merkle treeを使用しており、エンドノードがアプリケーションを実行する際に、自分のアプリケーションに関連するデータだけをダウンロードすることができるようにしています。イーサリアムのようにすべてのブロックデータをダウンロードする必要はありません。この構造を通じて、対応する機能のノードは、エンドノードに必要なデータ状態のみを返すことができます。

このマークルツリーの詳細な構造と構成ルールについては、興味があるときにまた説明します。要約すると、この構造は名前空間ハッシュ（nsHash、名前空間識別子をプレフィックスとするラッパーハッシュ）を基本データとし、根ノードはすべての子ノードの関連する名前データを含んでいます（この「関連」という言葉は非常に重要です）。具体的に保存されるデータはJSON形式です。そして、nsHashはminNs、MaxNs、hash(x)の三つの要素で構成されています。

• minNs: その根ノードが所属する子ノードの中で最小の名前空間識別子。

• maxNs: その根ノードが所属する子ノードの中で最大の名前空間識別子。

• hash(x): 子ノードのハッシュ値で、通常のブロックと似ています。

全体の構造はこの例図で表現できます：

ホワイトペーパー：https://arxiv.org/pdf/1905.09274.pdf

全体のプロセスはARのsmartwaveと非常に似ています：チェーンはデータの保存と合意を担当し、実行はエンドユーザーに任せます。開発言語に制限はなく、実行のボトルネックもありません。また、ノードはデータをダウンロードする際に、自分のアプリケーションに関連するデータだけをダウンロードし、全体のブロックデータをダウンロードする必要がなく、効率が向上します。

しかし、二者の違いは、Celestiaがストレージと合意の役割を再び分離したため、Celestiaネットワークには三つの役割があります：合意ノード、ストレージノード、クライアントノード。

役割分担と基本プロセス

Celestiaの役割分担と基本的な運用プロセスをより良く理解するために、彼らが達成したい目的から説明します。

• まず、Celestiaはデータの可用性と状態変換/計算を分離したいと考えています。なぜ合意とは言わないのかというと、合意自体がデータの可用性と真実性を確認するものであるため、データの可用性と再び分けるのは難しいからです。そうでなければ、もはやブロックチェーンとは言えません。

• 次に、自分が必要な情報だけをダウンロードして計算に使用すること。Celestiaは、計算を実行するノードが計算を実行する際に、自分が必要とする情報だけを検索し、全体のブロックチェーンの情報をダウンロードして状態変換を行う必要がないことを望んでいます。

• データの完全性。データが破壊されると隠れることを発見できる。

• アプリケーション状態の主権独立。第二点と似ており、実行ノードは他の無関係なアプリケーションの情報を実行する必要はありません。依存アプリケーション（例えば、あるアプリケーションが別の支払い機能のアプリケーションを呼び出す必要がある場合）を除いて。

目的が分かったので、彼らの分担を見てみましょう。

• ブロックチェーンの合意を保証するために、専用の合意ノードがあります。

• データの可用性のために、専用のストレージノードがあります。

• 上記の二つがあれば、実行のタスクはエンドユーザーに任せられ、これらはすべて実行ノードと見なされます。

これらのノードは、ピアツーピアのネットワークトポロジー構造を形成してCelestiaネットワーク全体を構成します。注意すべきは、実行ノードは少なくとも一つのストレージノードに接続する必要があり、自分のアプリケーションの状態変換を実行するためです。

ここで検証ルールについて触れておきます。通常、二つのタイプに分かれます：

• シンプルな検証ルール：通常のブロックチェーンの検証方法で、すべての情報Mをダウンロードし、Root(M) = mRootを検証します。一度検証がtrueであれば、Mとブロックヘッダーhを配布し、少なくとも一定の時間t'（ネットワークの最大遅延）Mデータを保存する必要があります。他のノードが情報を受け取れるように（他の検証ノードやストレージノードを含む）。

• 確率的検証ルール：これがCelestiaが主に推奨する2D Reed-Solomonです。基本原理は上で説明しました。ここで公式の例を挙げて効果を見てみましょう。

  もしエラー訂正符号の閾値が1/4で、ブロックが4096片（64*64）に分割されると、各ノードはわずか15個のサンプルをダウンロードするだけで、データが可用であることを99%の確率で確認できます（具体的な検証は別の純数学論文で扱われており、私はまだ見ていません）。つまり、各ノードは元のデータ断片の0.4%だけをダウンロードすることで、データが可用であるかどうかを高い確率で推測できます。

  もちろん、確率的検証ルールでは、すべてのノードがダウンロードしたデータの合計がこのエラー訂正符号の閾値を超える必要があります。例えば、閾値が50%の場合、すべてのノードがダウンロードしたデータの合計は元のデータ断片の50%以上（重複なし）に達する必要があります。このデータの可用性が確認され、最終的にブロック生成に参加できます。

さて、基本的な構造が理解できたので、アプリケーションがどのように動作するかを見てみましょう。

アプリケーションノードの動作

まず、上で述べたように、アプリケーションの実行はエンドユーザーによって行われます。彼らはこのネットワークの中で単なるユーザーではなく、実行ノードでもあります。パラメータを渡すことで、対応するハッシュとnid（名前空間ID、上記の特別なデータ構造で、自分のアプリケーションの名前空間に関連する情報を取得するために使用され、他の無関係な情報を取得する必要がありません）を取得し、アプリケーションの実行状態変換に必要なすべての情報を取得します。オフチェーンで実行した後、データをチェーン上にアップロードし、他の実行ノードが実行を取得できるようにします。

もちろん、Celestiaは実行結果の検証を担当しないため、アプリケーションロジックに違反する取引が発生する可能性があります。したがって、ここで新しい関数transitionが追加され、アプリケーションはこの関数を呼び出して状態を返し、その状態を使用して取引の合法性を確認します。

取引が違法であれば、全体の取引は元の状態にロールバックされます。合法な取引のみがstate'を返します。

もちろん、ここから新たな問題が生じます：アプリケーションのアップグレード。これは実際にはsmartwaveの処理と同じです： もし取引が既存のアプリケーションとは異なるロジックを使用し、取引が行われなかった場合、そのノードが実行しているアプリケーションは新しいアプリケーションとしてカウントされるため、他の元のアプリケーションを使用している人には影響しません。つまり、ハードフォークは必要なく、アプリケーションは自分が望むアップグレードをローカルの実行ロジックを変更し、新しいアプリケーションとして登録するだけで済みます。ハードフォークが不要であれば、他のアプリケーションにも影響を与えません。

もう一つの問題も解決する必要があります：アプリケーション間の呼び出しはどうするか？

アプリケーション間の呼び出し

想像してみてください、もし私たちがドメイン名登録のコントラクトを使用し、支払いを行い、ドメイン名を購入する場合です。市場には多くの支払いツールコントラクトがあるため、私たちが使用するドメイン名登録コントラクトは、第三者の支払いコントラクトを呼び出してこのビジネスプロセスを完了します。

この時、Celestiaの方式に従うと問題が発生します：アプリケーションの独立主権により、各アプリケーションの状態は互いに干渉しないため、私たちのドメイン名登録アプリケーションは明らかに他のアプリケーションに干渉します。この場合、どうすればよいのでしょうか？

• 前提条件呼び出し：Aコントラクトを完了する前に、Bコントラクトを完了する必要があります（Bコントラクトの状態を変更することに相当します）。この時、Bコントラクトは他のコントラクトからの呼び出しを許可する専用の関数を設定できます。上記のドメイン名登録コントラクトはこの一例です。この場合、CelestiaはAコントラクトを実行する際に、Aが必要とするデータだけでなく、Bのデータもダウンロードする必要があり、Bを実行した後にAを実行します。Aの実行はBの状態に依存します。一方、Bコントラクトを実行するノードは、Aのデータをダウンロードする必要はありません。なぜなら、Bの実行はAに依存しないからです。

• 後提条件呼び出し：Aコントラクトを完了した後、Bコントラクトを変更する必要があります。例えば、メール購読サービスでは、メールを購読した後、他のコントラクトが購読サービスの状態に従ってメールを送信する必要があります。この時、Bコントラクトは実行時にAコントラクトをダウンロードし、Aコントラクトを実行した後にBコントラクトを実行する必要があります。このような呼び出しは、Celestiaの想定では非常に少ないはずです。なぜなら、他のアプリケーションの状態を直接変更することは独立主権の初志に反するからです。この場合、すべてのデータをダウンロードする必要が避けられません。

まとめ

これで、Celestiaの主体が紹介されました。私たちは、それがsmartwaveと非常に似ていることに気づきます。あるいは、これは現在の一般的なブロックチェーン構造とは異なるもう一つの構造であり、完全に組み合わせ可能な構造です。データの可用性を保証するだけで、実行を担当せず、実行を検証することもなく、USBメモリのように、挿入すればすぐに使用できる（中継チェーンとは異なり、中継チェーンは状態変換も担当します）。

生まれつきクロスチェーンに対応し、さまざまなクロスチェーンの原子インタラクションにも互換性があります（特別なマークルツリーはJSON情報を保存しており、内容に制約がありません）。ARよりも優れている点は、検証の有効性に必要なデータ量がはるかに少ないため、非常に将来性があります。現在不確定な点はトークンエコノミーです。トークンエコノミーがどのようになるかはわかりません。

もちろん、Celestia+OptimintとArweave+KYVEのどちらが最終的に勝つかは、実際にはわかりません。なぜなら、これら二つは筆者が非常に好きなプロジェクトであり、どちらも素晴らしいからです。

最後に、比較図を見て、Celestiaの向上がどれほど大きいかを見てみましょう。

ホワイトペーパー：https://arxiv.org/pdf/1905.09274.pdf

やはり素晴らしい！