データ検証とは何ですか?

データ検証は、一連のデータを使用する前にその正確性、完全性、品質を明確にするプロセスです。これは、特定のテキスト、住所、日付など、あらゆる形式のデータに適用できます。

データはすべてのソリューションの基盤を構成しており、ソリューションが効果的であるためにはデータが正確でなければならないことは言うまでもありません。 Web3 では、開発者、アナリスト、ネットワーク参加者はすべて、ブロックチェーンを継続させるためにデータに依存しています。これらのプレーヤーにとって、エラー、不一致、ユーザーの危険、プロジェクトの完全性の侵害を防ぐために、有効なデータを使用することが非常に重要です。

Web3 における妥当性の必要性

Web3 分野における多くの障害は、有効なデータへの効率的なパブリック アクセスを実現することで解決できます。 1 つは、ブロックチェーンがスケールするにつれて、最終的に生成されるデータの量が過大になり、チェーン全体の状態を手元に保持できるノードがほとんどなくなることです。これにより、多くのノードが共有スナップショットに依存し、スナップショットが完全に正確で最新であると信じてしまい、エラーが発生する余地が残されてしまいます。

イーサリアムもこの状況では同じ状況にあり、フルノードに何のインセンティブも提供していないため、間もなくチェーンの履歴データの公開リソースが制限されることになるでしょう。完全なノードにアクセスするには、ユーザーは独自のノードを実行するか、パブリックにアクセスできるデータにアクセスするためにプロバイダーに料金を支払う必要があります。

データ検証によって解決されるもう 1 つの主要な問題は、オラクルの問題です。プロジェクトがオフチェーン データをソースする場合、確定的な Web2 データへの簡単なアクセス ポイントを提供するオラクルが頼りになるツールです。ただし、オンチェーンに大量のデータを持ち込むと、単一障害点が発生します。

オラクルには通常、真に分散型の検証機能が組み込まれていないことを考えると、オラクルが提供するデータが真実であるか、まだ操作されていないとは言えません。起こり得ること、そしてすでにかなり頻繁に起こっていることは、攻撃者がプロトコルを直接標的にするのではなく、そのプロトコルによって供給されるデータをオラクルから標的にすることです。これは、攻撃者にとって、状況を有利に操作するための全体的に簡単な方法です。

このような悪意のあるイベントが減少しなくなったため、検証ソリューションが登場し始めています。ただし、適切なデータ検証は言うは易く行うは難しです。

検証の課題と非効率性

ブロックチェーン内およびブロックチェーン間で機能を実行するプロセスにおける各データを検証し、同期を保つ必要があることを考えると、データを適切に検証することは、思っているよりも複雑です。

データ検証を実装する最も簡単で一般的な方法は、集中サーバーを使用して、1 つのエンティティのみがデータの一部が正確であるかどうかを決定する先頭に立つことです。これにより、高速パフォーマンスが促進され、世界中で合意に達する必要がなくなりました。ただし、一元化によって、エラーや悪意のある行為者が存在する可能性が大きく広がります。

検証プロセスが集中化されている場合、主要なアクターの作業が正しいことを他のアクターがチェックして確認するインセンティブがないことを意味します。また、これは、ハッカーが意思決定を完全に制御するために引き継がなければならないアクターが 1 つだけであることを意味しますが、分散化により、ハッカーが全体の 50% 以上を引き継ぐ必要があるため、ハッキングのリスクが減少します。ノードのネットワークを制御することで、全体としてバイアスや検証エラーが大幅に減少します。

分散型ソリューション

Web3 の基本理念は分散化であり、ネットワーク ユーザーと関係者全体に権限、信頼、その他の美徳を分散します。アクションは地球の隅々まで移動する必要があるため、100% 分散化すると多少の時間遅延が発生しますが、データの検証に関しては、超高速のパフォーマンスよりも分散化の方が重要です。

一般に、データの一部が有効かどうかを判断するには、常に汎用ソリューション、つまり開発者がデータセットごとにカスタム検証メソッドを作成する必要があります。ただし、これらのさまざまなランタイムを管理し、すべてのデータ セットが適切に取得され、迅速かつ効率的に検証されるようにすることが不足しています。

分散型の Proof of Stake (PoS) データレイクは、データの中継を担当するコード (別名ランタイム) を実行するデータ プールを提供することで、これを解決できます。これには、検証関数の抽象実装も含まれています。配置されている関数は、データが有効かどうかに応じて true または false を返すだけです。次に、チェーンはバンドルされたデータの結果 (有効、無効、ドロップのいずれか) を計算し、正しいデータへのアクセスのみを提供するように有効なデータ バンドルのみを追跡します。

各プールにはノードのグループがあり、ランダムに選択された 1 つがデータのアップロードを担当し、残りの 1 つがデータが有効かどうかの投票を担当します。各投票には、ノードがステーキングするトークンの数に応じて重み付けされた値があります。投票が最終的に完了すると、次のデータ バンドルをアップロードする責任が、ランダムに選択された別のノードに切り替わります。そうすることで、集中化のリスクが回避されます。つまり、データをアップロードするノードが常に 1 つだけの場合、攻撃のリスク要因が高くなります。

真の分散型検証を確実にするためのもう 1 つの重要な要素は、PoS を介したインセンティブです。データの各プールはデータのフェッチ、アップロード、検証をノードに依存しているため、トークン報酬を通じて良好な動作を促進し、トークン スラッシュを通じて悪い動作やエラーを罰することが重要です。

Web3 のデータ インフラストラクチャと整合性は、スケーラブルでトラストレスな未来を確保するために、真に有効なデータの使用に大きく依存しています。時間が経つにつれ、特に Web3 において、データ検証の重要性を認識するプロジェクトが増え、データ検証時に考慮される側面がさらに増えることは間違いありません。私たちにできる最善のことは、このトピックに関する構築と教育を続けることです。

著者: Fabian Riewe 氏、Web3 データ レイク ソリューションである KYVE の共同創設者兼 CEO。

ファビアンは、地元の教育技術スタートアップ企業の技術責任者としてキャリアをスタートしました。 2019 年のハッカソンが彼を Web3 に魅了し始め、6 か月後には最初に成功したプロジェクト ArVerify を設立しました。ArVerify は、Arweave エコシステムで大規模に採用されたオンチェーン KYC システムです。その直後の 2021 年に、分散型 Web3 データレイクである KYVE を John Letey と共同設立しました。