ブロックチェーンから LLM まで、データ インデックス作成テクノロジーの進化と課題の詳細な解釈

サトシ・ナカモトがジェネシス・ブロックにメッセージを埋め込むことを決定して以来、ビットコイン・チェーンのデータ構造は一連の変更を受けてきました。

私は 2022 年にブロックチェーン開発について詳しく勉強し始め、最初に読んだ本は「Mastering Ethereum」でした。この本は素晴らしいもので、イーサリアムとブロックチェーンの基礎についての深い理解を提供してくれました。ただし、今日の観点から見ると、この本に記載されている開発テクニックの一部はやや時代遅れになっています。準備手順では、ウォレット dApp であっても、個人のラップトップでノードを実行する必要があり、ライト ノードを独自にダウンロードする必要があります。これは、2015 年から 2018 年のブロックチェーン開発エコシステムにおける初期の開発者とハッカーの行動パターンを反映しています。

2017 年当時、ノード サービス プロバイダーは存在しませんでした。需要と供給の観点から見ると、ユーザーのアクティビティが限られているため、その主な機能はトランザクションを実行することです。これは、処理する RPC リクエストがそれほど多くなく、リクエストの転送も頻繁ではないため、フル ノードを自分で維持またはホストすることはそれほど負担ではないことを意味します。イーサリアムの初期導入者のほとんどは技術オタクです。これらの初期ユーザーはブロックチェーン開発を深く理解しており、コマンド ラインまたは統合開発環境を介してイーサリアム ノードを直接保守し、トランザクションを作成し、アカウントを管理することに慣れています。

したがって、初期のプロジェクトは通常、非常にクリーンな UI/UX を備えていることがわかります。これらのプロジェクトの中にはフロントエンドさえ持たないものもあり、ユーザーのアクティビティはかなり低いです。これらのプロジェクトの特性は、主にユーザーの行動とチェーンのデータ構造という 2 つの要素によって決まります。

ノードプロバイダーの台頭

プログラミングの知識を持たないユーザーがブロックチェーン ネットワークに参加することが増えるにつれ、分散型アプリケーションの技術アーキテクチャも変化しました。ユーザーによるノードのホスティングという元のモードは、プロジェクト関係者によるノードのホスティングに徐々に変化してきました。

人々はノード ホスティング サービスを選択する傾向があります。主な理由は、チェーン上のデータの急速な増加により、個人ホスティング ノードのコストが時間の経過とともに徐々に増加するためです。

ただし、小規模プロジェクトの開発者にとって、プロジェクト チームによる自己ホスト型ノードは依然として課題であり、継続的なメンテナンス投資とハードウェア コストが必要です。したがって、この複雑なノード ホスティング プロセスは通常、ノード メンテナンスを専門とする会社に委託されます。これらの企業の大規模な建設と資金調達のタイミングが、北米のテクノロジー業界におけるクラウドサービスの上昇傾向と一致していることは注目に値します。

|プロジェクト |カテゴリー | | 設立年月 | | --- | --- | --- | |錬金術 |ノード | 2017年 | | Infura | Nodes | 2016 | | NowNodes |ノード | 2019年 | |クイックノード |ノード | 2017年 | |アンカー |ノード | 2017年 | |チェーンスタック |ノード | 2018年 |

特にDeFiやNFTなどの関連プロトコルが登場しつつある今、単にノードをリモートでホストするだけでは問題を完全に解決することはできません。ブロックチェーンノード自体によって提供されるデータは生データと呼ばれ、標準化もクリーン化もされていないため、開発者は多くのデータの問題に対処する必要があります。その中のデータを抽出、クリーニング、ロードする必要があります。

たとえば、私が NFT プロジェクトの開発者で、NFT トランザクションを実行したり、NFT を表示したりしたいとします。次に、フロントエンドは個人 EOA アカウントの NFT データをリアルタイムで読み取る必要があります。 NFT は実際には標準化された形式のトークンにすぎません。 NFT を所有するということは、NFT 契約によって生成された一意の ID を持つトークンを所有することを意味し、NFT の画像は実際にはメタデータであり、SVG データまたは IPFS 上の画像へのリンクである可能性があります。 Ethereum の Geth クライアントはインデックス作成命令を提供しますが、フロントエンド要件が大きい一部のプロジェクトでは、継続的に Geth をリクエストしてからフロントエンドに戻るのは現実的ではありません。注文オークションや NFT トランザクション集約などの一部の機能では、ユーザーの指示を収集するためにオフチェーンで実行し、適切なタイミングでこれらの指示をチェーンに送信する必要があります。

したがって、単純なデータ層が誕生しました。ユーザーのリアルタイム性と精度の要件を満たすために、プロジェクト当事者は独自のデータベースとデータ分析機能を構築する必要があります。

**データ インデクサーはどのように進化しましたか? **

プロジェクトの開始は通常、比較的簡単な作業です。アイデアがあり、いくつかの目標を設定し、最高のエンジニアを見つけて、通常フロントエンドといくつかのスマート コントラクトを含む実用的なプロトタイプを構築します。

しかし、プロジェクトを大規模化するのは非常に困難です。プロジェクトの初日からデザイン構造について深く考える必要があります。そうしないと、私が通常「着氷の問題」と呼んでいる問題がすぐに発生する可能性があります。

この用語は映画「アイアンマン」から借用しましたが、ほとんどのスタートアップの状況を説明するのに非常に適しているようです。スタートアップが急速に成長する（多くのユーザーを魅了する）と、最初から予見していなかったトラブルに遭遇することがよくあります。映画では、悪役は「着氷の問題」を考慮していなかったために、自分の戦争装備が宇宙に飛ぶとは予想していませんでした。同様に、多くの Web3 プロジェクトの開発者にとって、「凍結問題」には、大量のユーザーによる採用による負担の増加への対処が含まれます。ユーザー数が劇的に増加すると、サーバー側に大きな負荷がかかります。ネットワークの問題やノードのシャットダウンなど、ブロックチェーン自体に関連する問題もあります。

ほとんどの場合、バックエンドの問題です。たとえば、一部のブロックチェーン ゲーム プロトコルでは、この状況は珍しいことではありません。チェーン上のデータを解析するためにサーバーを追加し、さらに多くのデータ エンジニアを雇うことを計画していたとき、これほど多くのユーザーが参加するとは予想していませんでした。彼らがそれに気づいたときには、もう手遅れでした。そして、これらの技術的な問題は、バックエンドエンジニアを増やすだけでは解決できません。前に述べたように、これらの考慮事項は最初から計画に組み込まれるべきです。

2 番目の問題には、新しいブロックチェーンの追加が含まれます。おそらく最初からサーバー側の問題を回避し、優秀なエンジニアを多数雇ったのでしょう。ただし、ユーザーは現在のブロックチェーンに満足していない可能性があります。彼らは、あなたのサービスが zk チェーンや L2 チェーンなどの他の人気のあるチェーンでも実行されることを望んでいます。プロジェクトの構造は次のようになります。

このタイプのシステムでは、データを完全に制御できるため、管理が向上し、セキュリティが強化されます。システムは通話リクエストを制限し、過負荷のリスクを軽減し、効率を高めます。また、セットアップはフロントエンドと互換性があるため、シームレスな統合とユーザー エクスペリエンスが保証されます。

ただし、運用およびメンテナンスのコストが倍増するため、リソースに負担がかかる可能性があります。毎回新しいブロックチェーンを追加するには繰り返し作業が必要となり、時間がかかり非効率的になる可能性があります。大規模なデータセットからデータを選択するとクエリ時間が短縮され、プロセスが遅くなる可能性があります。ロールバックや再編成などのブロックチェーン ネットワークの問題により、データが汚染され、データの整合性と信頼性が損なわれる可能性があります。

プロジェクトは、チーム メンバーを反映するように設計されています。ノードを追加してバックエンドに重点を置いたシステムを構築しようとすると、それらのノードを操作して生データをデコードするために、より多くのエンジニアを雇用する必要があることを意味します。

このモデルは、電子商取引プラットフォームやアプリケーション開発者が独自の IDC (インターネット データ センター) 施設を構築することを選択したインターネットの初期の時代に似ています。ただし、ユーザーのリクエストが増大し、ブロックチェーン ネットワークの状態が爆発的に増加するにつれて、コストとプログラム設計の複雑さが連動して増加します。さらに、このアプローチは市場の急速な拡大を妨げます。一部の高性能パブリック ブロックチェーンでは、ハードウェアを集中的に使用するノード操作が必要ですが、データの同期とクリーニングには人的リソースと時間コストが消費されます。

ブロックチェーンベースの NFT マーケットプレイスやクールなゲームを構築しようとしている場合、チームメンバーの 65% がバックエンドおよびデータ エンジニアであることは驚くべきことではありませんか?

**おそらく開発者は、より良い製品の構築に集中できるように、なぜ誰もこのオンチェーン データをデコードして送信しないのか疑問に思うでしょう。 **

**これがインデクサーが存在する理由だと思います。 **

Web3 アプリケーションやブロックチェーン ネットワークへのアクセスの難しさを軽減するために、私たちを含む多くの開発チームは、アーカイブ ノードのメンテナンス、オンチェーン データ ETL (抽出、変換、ロード)、データベース呼び出しなどの手順を統合することを選択しています。これらの業務は当初、プロジェクトチーム自身でメンテナンスする必要がありましたが、現在ではマルチチェーンデータとノードAPIを提供することで統合的な運用を実現しています。

これらの API を利用すると、ユーザーはニーズに応じてオンチェーン データをカスタマイズできます。これは、一般的な NFT メタデータから特定のアドレスのオンチェーン アクティビティの監視、特定のトークン流動性プールのトランザクション データの追跡まで、あらゆるものをカバーします。私は、このアプローチを最新の Web3 プロジェクトの構造の一部としてよく参照します。

データ層およびインデックス層プロジェクトの資金調達と建設は主に 2022 年に実施されます。これらのインデックス レイヤーとデータ レイヤーのプロジェクトのビジネス プラクティスは、その基礎となるデータ アーキテクチャの設計、特に OLAP (On-Line Analytical Processing) システムの設計と密接に関連していると私は考えています。適切なコア エンジンを採用することが、インデックス速度の向上や安定性の確保など、インデックス レイヤーのパフォーマンスを最適化する鍵となります。一般的に使用されるエンジンには、Hive、Spark SQL、Presto、Kylin、Impala、Druid、ClickHouse などが含まれます。中でもClickHouseはインターネット企業で広く使われている強力なデータベースで、2016年にオープンソース化され、2021年には2億5,000万ドルの資金調達を受けました。

したがって、新世代のデータベースと改良されたデータ インデックス最適化アーキテクチャの出現により、Web3 データ インデックス レイヤーが作成されました。これにより、この分野の企業は、より高速かつ効率的な方法でデータ API サービスを提供できるようになります。

しかし、オンチェーンデータインデックスの構築は依然として 2 つの暗雲に覆われています。

二つの暗雲

最初のダーク クラウドは、サーバー側のブロックチェーン ネットワークの安定性の影響に関するものです。ブロックチェーン ネットワークは強力な安定性を持っていますが、データの送信および処理中はそうではありません。たとえば、ブロックチェーンの再編成 (reorg) やロールバック (ロールバック) などのイベントは、インデクサーのデータの安定性に課題を引き起こす可能性があります。

ブロックチェーンの再編成とは、ノードが一時的に同期を失い、2 つの異なるバージョンのブロックチェーンが同時に存在することを意味します。このような状況は、システム障害、ネットワーク遅延、さらには悪意のある動作によって引き起こされる可能性があります。ノードが再同期すると、ノードは単一の公式チェーンに収束し、以前の代替の「フォークされた」ブロックは破棄されます。

再編成が発生するまでに、インデクサーは最終的に破棄されたブロックのデータを処理し、データベースを汚染する可能性があります。したがって、インデクサーはこの状況に適応して、無効なチェーン上のデータを破棄し、新しく受け入れられたチェーン上のデータを再処理する必要があります。

このような調整により、リソースの使用量が増加し、データの利用が遅れる可能性があります。極端な場合には、頻繁または大規模なブロックの再編成が、API を使用してデータをフェッチする Web3 アプリケーションなど、インデクサーに依存するサービスの信頼性とパフォーマンスに重大な影響を与える可能性があります。

さらに、ブロックチェーンネットワーク全体でのデータ形式の互換性とデータ標準の多様性に関する問題にも直面しています。

ブロックチェーン技術の分野には、さまざまなネットワークがあり、それぞれが独自のデータ標準を持っています。たとえば、EVM (Ethereum Virtual Machine) 互換チェーン、非 EVM チェーン、zk (ゼロ知識) チェーンがあり、それぞれが独自の特別なデータ構造と形式を持っています。

これは間違いなくインデクサーにとって大きな課題です。 API を通じて有用で正確なデータを提供するには、インデクサーはこれらの多様なデータ形式を処理できる必要があります。ただし、ブロックチェーン データには普遍的な標準がないため、インデクサーごとに異なる API 標準が使用される場合があります。これにより、あるインデクサーから抽出および変換されたデータが別のシステムで使用できなくなる可能性がある、データ互換性の問題が発生する可能性があります。

さらに、開発者がこのマルチチェーンの世界を探索する際、これらの異なるデータ標準に対処するという課題に直面することがよくあります。あるブロックチェーン ネットワークで機能するソリューションが別のブロックチェーン ネットワークでは機能しない可能性があるため、複数のネットワークと対話できるアプリケーションの開発が困難になります。

実際、ブロックチェーンインデックス業界が直面している課題は、20世紀初頭にケルビン卿によって特定され、最終的に量子力学や熱力学などの革新的な分野を生み出した物理学における2つの未解決の問題を思い出させます。

これらの課題に直面して、業界は確かに、レイテンシの導入や Kafka パイプラインへのストリーミングの統合、さらにはブロックチェーン インデックス業界を強化するための標準コンソーシアムの設立など、いくつかの措置を講じてきました。これらの対策は現在、ブロックチェーン ネットワークの不安定性とデータ標準の多様性に対処できるため、インデクサーは正確で信頼性の高いデータを提供できます。

しかし、量子理論の出現が物理世界の理解に革命をもたらしたのと同様に、ブロックチェーン データ インフラストラクチャを改善するためのより根本的な方法を検討することもできます。

**結局のところ、きちんと整理されたデータ ウェアハウスとスタックを備えた既存のインフラストラクチャは、完璧すぎて美しすぎるように思えるかもしれません。 **

それで、**他の方法はありますか? **

パターンを見つける

ノードプロバイダーとインデクサーの出現に関する元のトピックに戻り、特有の問題を考えてみましょう。 2010年にはノードオペレーターが現れなかったのに、2022年に突然インデクサーが大量に出現し多額の投資を受けたのはなぜでしょうか?

私の上記はこれらの質問に部分的に答えたと思います。これは、暗号化の分野だけでなく、ソフトウェア業界でもクラウド コンピューティングとデータ ウェアハウジングのテクノロジが広く使用されているためです。

暗号化の世界でも、特に ERC20 および ERC721 標準が公共メディアで普及したときに、何か特別なことが起こりました。さらに、DeFiの夏により、オンチェーンデータはより複雑になりました。さまざまなコールトランザクションは、初期段階のような単純なトランザクションデータではなく、異なるスマートコントラクト上でルーティングされ、オンチェーンデータの形式と複雑さは驚くべき変化と成長を遂げています。

仮想通貨コミュニティでは、従来の Web2 テクノロジーから分離することが常に強調されてきましたが、無視できないのは、仮想通貨インフラストラクチャの開発は、数学、暗号化、クラウド テクノロジー、ビッグ データの分野での継続的な開発とブレークスルーに依存しているということです。 . .中国の伝統的なほぞ穴とほぞの構造と同様に、暗号通貨エコシステムのさまざまなコンポーネントは密接に関連しています。

科学技術の進歩と革新的な応用は、常に何らかの客観的な原則に拘束されます。たとえば、楕円曲線暗号化テクノロジの基本的なサポートがなければ、今日の暗号通貨エコシステムは存在できません。同様に、ゼロ知識証明の実用化は、1985 年に MIT によって出版されたゼロ知識証明に関する重要な研究論文がなければ不可能でした。したがって、興味深いパターンがわかります。 ** ノード サービス プロバイダーの幅広いアプリケーションと拡大は、世界的なクラウド サービスと仮想化テクノロジーの急速な成長に基づいています。 ** 同時に、チェーン上のデータ層の開発は、優れたオープンソース データベース アーキテクチャとサービスの精力的な開発に基づいています。これらのアーキテクチャは、多くのビジネス インテリジェンス製品が提供するデータ ソリューションです。近年頼りにしています**。これらはすべて、スタートアップが商業的な実現可能性を達成するために満たさなければならない技術的な前提条件です。 Web3 プロジェクトに関しては、高度なインフラストラクチャを採用するプロジェクトが、時代遅れのアーキテクチャに依存するプロジェクトよりも有利になる傾向があります。より高速でユーザーフレンドリーなNFT取引所によるOpenSeaの市場シェアの侵食は、その鮮明な例です。

さらに、人工知能 (AI) と LLM テクノロジーが徐々に成熟し、広く応用される可能性があるという明らかな傾向も見られます。

**したがって、重要な疑問が生じます。AI はチェーン上のデータのパターンをどのように変更するのでしょうか? **

＃＃＃ 占い

未来の予測には常に困難が伴いますが、ブロックチェーン開発で遭遇する問題を理解することで、考えられる答えを探ることができます。 **開発者はオンチェーン データに対して明確な需要を持っています。開発者が必要としているのは、正確でタイムリーで理解しやすいオンチェーン データです。 **

私たちが現在直面している問題の 1 つは、特定のデータをバッチで取得または表示するために複雑な SQL クエリが必要になることです。これが、Dune が提供するオープンソース SQL 機能が暗号通貨コミュニティで非常に人気がある理由です。ユーザーは SQL を書いてチャートを最初から作成する必要はなく、注目したいスマート コントラクトのアドレスをフォークして変更するだけで、必要なチャートを作成できます。ただし、特定の条件下で流動性またはエアドロップ データのみを表示したい平均的なユーザーにとって、これはまだ複雑すぎます。

私の考えでは、この問題を解決するための最初のステップは、LLM と自然言語処理を活用することです。

よりユーザー中心の「データ クエリ」インターフェイスを構築し、LLM 技術を活用できます。既存のケースでは、ユーザーは SQL や GraphQL などの複雑なクエリ言語を使用して、API またはスタジオから対応するオンチェーン データを抽出する必要があります。ただし、LLM を使用すると、より直感的で人間らしい質問方法を導入できます。このようにして、ユーザーは質問を「自然言語」で表現でき、LLM はそれを適切なクエリに変換して、ユーザーが必要とする回答を提供します。

開発者の観点から見ると、人工知能はチェーン上のコントラクト イベントの分析と ABI デコードを最適化することもできます。現在、多くの DeFi 契約の詳細については、開発者が手動で解析してデコードする必要があります。しかし、人工知能を導入すれば、さまざまなコントラクト分解技術を大幅に改善し、対応するABIを迅速に取得できるようになります。この構成をラージ言語モデル (LLM) と組み合わせると、関数シグネチャをインテリジェントに解析し、さまざまなデータ型を効率的に処理できます。さらに、「ストリームコンピューティング」処理フレームワークと組み合わせることで、トランザクションデータの分析をリアルタイムに処理し、ユーザーの当面のニーズに応えることができます。

よりグローバルな観点から見ると、インデクサーの目標はユーザーに正確なデータを提供することです。以前に強調したように、オンチェーン データ レイヤーの潜在的な問題は、個々のデータが異なるインデクサー データベースに分散し、相互に分離されていることです。多様なデータのニーズを満たすために、一部の設計者は、ユーザーが単一のデータセットから必要な情報を選択できるように、チェーン上のすべてのデータをデータベースに統合することを選択します。一部のプロトコルでは、DeFi データや NFT データなど、一部のデータのみを含めることを選択します。しかし、データ規格に互換性がないという問題は依然として存在します。場合によっては、開発者は複数のソースからデータを取得し、独自のデータベースで再フォーマットする必要があるため、メンテナンスの負担が確実に増加します。さらに、あるデータ プロバイダーに問題が発生した場合、タイムリーに別のプロバイダーに移行することはできません。

では、LLM と AI はこの問題をどのように解決できるのでしょうか? LlamaIndex は私に啓示を与えてくれました。開発者がインデクサーを必要とせず、デプロイされたプロキシ サービス (エージェント) を使用してチェーン上の生データを直接読み取る場合はどうなるでしょうか?このエージェントは、インデクサーと LLM のテクノロジーを組み合わせています。ユーザーの観点から見ると、API やクエリ言語について何も知る必要はなく、質問するだけですぐにフィードバックが得られます。

LLM と人工知能テクノロジーを搭載したエージェントは、生データを理解して処理し、ユーザーが理解しやすい形式に変換します。これにより、ユーザーは複雑な API やクエリ言語に直面する必要がなくなり、自然言語で質問するだけでリアルタイムのフィードバックを得ることができます。この機能により、データのアクセスしやすさと使いやすさが向上し、より幅広いユーザーベースがオンチェーンデータにアクセスできるようになります。

さらに、エージェントサービス (Agent) の方法により、データ規格の非互換性の問題も解決されます。生のオンチェーンデータを解析して処理できるように設計されているため、さまざまなデータ形式や標準に適応できます。その結果、開発者はさまざまなソースからのデータを再フォーマットする必要がなくなり、作業負荷が軽減されます。

もちろん、これはオンチェーンデータの将来の開発軌道に関する単なる推測にすぎません。しかしテクノロジーの世界では、多くの場合、こうした大胆なアイデアや理論が革命的な進歩を推進します。車輪の発明であれ、ブロックチェーンの誕生であれ、すべての大きな進歩は誰かの思い込みや「クレイジーな」アイデアから始まるということを忘れてはなりません。

変化と不確実性を受け入れる一方で、私たちは可能性の限界を押し広げ続けるという課題にも直面しています。このような背景に対して、私たちは AI、LLM、ブロックチェーンの組み合わせがよりオープンで包括的な技術分野を生み出す世界を思い描いています。

Chainbase はこのビジョンを支持し、その実現に全力で取り組んでいます。

Chainbase の使命は、オープン、フレンドリー、透明性のある持続可能な暗号化データ インフラストラクチャを作成することです。私たちの目標は、開発者によるこのデータの使用を簡素化し、バックエンド テクノロジー スタックの複雑なリファクタリングの必要性を排除することです。このようにして、テクノロジーがユーザーにサービスを提供するだけでなく、ユーザーに力を与える未来をもたらしたいと考えています。

ただし、これは私たちのロードマップではないことを明確にしなければなりません。むしろ、これは、開発者関係の代表者として、コミュニティにおけるオンチェーン データの最近の開発と進歩についての私の個人的な考察です。