はじめに
こんにちは〜！皆様いかがお過ごしでしょうか？ no plan inc. CTOの @serinuntius です。
これはno plan inc.の Advent Calendar 2023の1日目の記事です。
Availというデータの可用性(通称: Data Availability(以降: DA))に特化した、モジュール型のブロックチェーンについて書いていきます。
Avail とは
現在ブロックチェーンの大筋として、１つのチェーンで全ての機能を賄うのではなく、レイヤーを分けてそれぞれのレイヤーで最適なブロックチェーンを作るということが流行っています。[1]これをモジュラーブロックチェーンと言います。なぜそうなってるかについてはいろんな理由がありますが、大体は ブロックチェーンのトリレンマ の問題が大きいです。
モジュラーブロックチェーンにおけるレイヤーの分け方はいろいろありますが、大きく分けて以下のような分け方があります。
- Execution(実行レイヤー)
- トランザクションの実行するレイヤー
- 状態変更する
- ユーザーはここのレイヤーとやり取りして、スマコンを実行したりする
- Settlement(実行確定と紛争解決)
- 実行レイヤーで実行されたトランザクションの実行結果が検証され、紛争が解決される場所
- ここでいう紛争とは、txに不正がないかどうかの検証と、txの実行結果が正しいかどうかの検証
- このレイヤーはモノリシックなブロックチェーンにはない
- 裁判所のような役割を果たす
- Consensus(合意形成)
- ブロックの内容をダウンロードして実行し、状態遷移が正しいかどうかを、みんなでコンセンサスを得る
- 順序づけだったり、ファイナリティーを提供する
-
Data Availability(DA) 🐈🐈🐈 今回のメインテーマ
- 状態遷移の有効性を検証するために必要なデータは、いつでもアクセスできる必要がある
- 悪意のあるノードがデータを隠蔽したり、改ざんしたりすることを防ぐために、データの可用性を保証する必要がある
- DA レイヤーはスケーラビリティのトリレンマの主なボトルネックである
このDAの問題を解決するのがAvailです。
以下のような機能があるみたいです。
- txの順序づけ
- txの公開
- ブロック全体をダウンロードすることなくブロックデータが利用可能であることの検証
また、どのような実行環境にも対応できるそうです。
- EVM
- WASM
- Custom Runtime
さらにモジュール型なので、 sovereign ZKやOPのApp chain, 一般的な目的のロールアップ、サイドチェーン、validiumなど、いろんなレイヤーに組み込むことができるそうです。
特徴: app-id とは？
この機能はDAより広い、クリプトというジャンルで個人的に超超超欲しかったやつです🔥🔥🔥
ブロックチェーンあるあるなのが、みんなで共有のDBを使っているので、不要なデータが多すぎます。例えば、あるアプリケーションを使っているときに、そのアプリケーションのデータを使っているだけなのに、他のアプリケーションのデータもダウンロードしていることが多いです。これは無駄なので、自分が使っているアプリケーションのデータだけをダウンロードしたいですよね。基本的に今まではそんなことはできませんでした。
ですが、Availはそんなことができるようになります。それが app-id です。
Availのヘッダーにはインデックスが含まれており、それによって特定のモジュラーチェーン（Availでは"アプリケーション"と呼ばれています）に関連するデータブロックのみを選択し、ダウンロードできます。
これはシンプルな仕組みですが、めちゃくちゃ有用な機能です。
以下のようなメリットがあります！
- モジュラーアプリケーションは同時にベースレイヤーを他の用途で使用してもほとんど影響を受けません
- アプリケーションはブロック全体をフェッチするのではなく、必要なデータだけをフェッチするため、アプリケーションに無駄なデータをフェッチさせることがなくなります
- ブロックサイズも大きくできる
データ可用性サンプリング(Data Availability Sampling)について
データ可用性サンプリング（DAS）は、ネットワークが全データの小さな部分をサンプルとしてダウンロードすることで、データの利用可能性を確認する手法です。これは、データ冗長化技術に基づき、各ノードがデータセットから小さなランダムな断片を取得することによって行われます。成功したサンプルダウンロードは、全データの利用可能性を高い確信を持って保証します。
冗長情報は、データセットに多項式関数を適用し、元のデータが失われた場合でもこれを復元できるようにすることで生成されます。データサンプルの量は調整可能で、実際のデータの一部が欠如している場合でも、ネットワーク内のどこかのノードが欠けている部分を確実に持っていることになります。
このアプローチにより、ネットワークは、過度の負荷を個々のノードにかけることなく、全体のデータ完全性を維持可能です。データが部分的にしか存在しない場合でも、拡張データから元のデータセットを再構築できるため、データ可用性の高いセキュリティを確保できます。
Availはこちらを採用しているようです。
データ可用性委員会(Data Availability Committee)について
データ可用性委員会（DAC）は、データの利用可能性を保証する信頼できるノードの集まりです。Ethereumなどではランダムなバリデーターサブセットがライトノードのデータ可用性を証明します。
DACはValidiumチェーンにも使われ、紛争時にはデータの利用可能性の証明を担当し、証明はオンチェーンで行われます。
保証金を用いたプルーフ・オブ・ステークシステムでは、バリデーターがデータを保管し、不正行為には保証金没収のリスクがあります。この方式ではセキュリティが向上し、正直な行動が推奨されます。
Avail ライトクライアント
Availのライトクライアント（LC）は、フルノードを必要とせず、リモートピアに対する信頼を前提とせずに、Availブロックチェーンとの対話を可能にします。
これは、ライトクライアントが新しく作成された各ブロックでDASを行うことによって実現されます。LCは、Availネットワーク上で確定したブロックをリッスンし、各新しいブロックで予め決定された数のセルに対してDASを実行します。
ブロック確認後、ユーザーが達成したい確信度のパーセンテージに依存するセルの数でブロック信頼度が計算されます。機能は、データのサンプリングに焦点を当てるライトクライアントと、データを再構築するアプリクライアントに分けられます。ライトクライアントは、libp2pとKademlia DHTを使用し、NATトラバーサルも実行可能です。
起動時には、設定パラメータsync_block_depthに基づきブロック同期が行われます。
このLCはHTTP APIを介して、ブロックの状況、信頼度、アプリケーションデータを問い合わせることができ、必要なデータをローカルに容易にアクセス可能にします。
Avail Validium
Ethereumのトランザクション費用を削減するために、ロールアップが取引をオフチェーンで処理し、結果だけをチェーン上に投稿する手法が用いられます。
Validiumは更なる進歩で、取引データをオフチェーンで利用可能にし、検証の証明のみをEthereumに投稿します。この方法は実行とデータの可用性をオフチェーンで維持しながら、レイヤー1での検証と決済を可能にするため、コスト効率が良いです。
Availはデータ可用性に特化したブロックチェーンで、ロールアップがValidiumになることを可能にします。これにより、トランザクションデータをAvailに投稿し、オフチェーンでのデータ可用性も検証するコントラクトを実装します。
AvailチームはEthereumでのデータ可用性検証を容易にするため、アテステーションブリッジを構築し、検証契約の負担を軽減します。また、Validiumはオフチェーン計算と妥当性証明を利用し、Ethereum上でのデータの保存を避けることで取引量を増やすソリューションです。
技術的な特徴とか気になること
- Substrateベース
- Rustで書かれている
- Avail-Powered Optimismがcoming soonになってる
まとめ
- Availについてまとめました
- DASを実装している
- Substrateベースで、Rustを使って書かれている
- ORU, zkRU共に使えそう
- APP-IDが便利
no plan株式会社について
- no plan株式会社は 「テクノロジーの力でZEROから未来を創造する、精鋭クリエイター集団」 です。
- ブロックチェーン/AI技術をはじめとした、Webサイト開発、ネイティブアプリ開発、チーム育成、などWebサービス全般の開発から運用や教育、支援なども行っています。よくわからない、ふわふわしたノープラン状態でも大丈夫！ご一緒にプランを立てていきましょう！
- no plan株式会社について
- no plan株式会社 | web3実績
- no plan株式会社 | ブログ一覧
エンジニアの採用も積極的に行なっていますので、興味がある方は是非ご連絡ください！
参考文献
-
要出典。少なくとも Bitcoin や Ethereum といった主要なチェーンはそういう構造でスケーリングしようとなっています。 Lightningもここに含めていいのかは微妙なところですが、役割を分けるという意味では同じです ↩︎
Discussion