ストレージプルーフの詳細な解釈: 時間とチェーンを超えたブロックチェーンステータス認識の実現

深潮TechFlow

特邀专栏作者

2023-10-13 02:56

この記事は約6285文字で、全文を読むには約9分かかります

Proof of storage により、イーサリアムは単なる決済層ではなく、アイデンティティと資産所有権の層として浮上することができます。

AI要約

展開

Proof of storage により、イーサリアムは単なる決済層ではなく、アイデンティティと資産所有権の層として浮上することができます。

原作者: LongHash Ventures

オリジナル編集: Deep Chao TechFlow

1時間ごとに記憶を失い、自分が何をしたかを常に人々に尋ねなければならないとしたらどうしますか?これが現在のスマートコントラクトの状況です。イーサリアムのようなブロックチェーンでは、スマートコントラクトは 256 ブロックを超える状態に直接アクセスできません。この問題はマルチチェーンエコシステムではさらに悪化し、さまざまな実行レイヤー間でデータを取得して検証することがさらに困難になります。

2020 年に、Vitalik Buterin と Tomasz Stanczak は、時間を超えてデータにアクセスする方法を提案しました。この EIP ソリューションは停滞していますが、ロールアップを中心とするマルチチェーンの世界でその需要が再浮上しています。現在、プルーフ・オブ・ストレージは、スマートコントラクトに認識と記憶を与えるために最前線に来ています。

オンチェーンデータにアクセスする方法

Dapps はさまざまな方法でデータや状態にアクセスできます。これらのアプローチはすべて、人間/エンティティ、暗号経済セキュリティ、またはコードにおけるアプリケーションからの一定レベルの信頼を必要とし、すべてに特定のトレードオフがあります。

人間/エンティティを信頼する:

アーカイブノード: オペレーターはアーカイブノードを自分で実行することも、Alchemy や Infura などのアーカイブノードサービスプロバイダーに依存して、ジェネシスブロックから始まるすべてのデータにアクセスすることもできます。これらは完全なノードと同じデータを提供しますが、ブロックチェーン全体のすべての履歴状態データも含まれます。 Etherscan や Dune Analytics などのオフチェーンサービスは、アーカイブノードを使用してオンチェーンデータにアクセスします。オフチェーンの参加者はこのデータの正当性を証明でき、オンチェーンのスマートコントラクトはデータが信頼できる参加者/委員会によって署名されたことを検証できます。ただし、基礎となるデータの整合性は検証できません。このアプローチでは、Dapp がアーカイブノードサービスプロバイダーを信頼して、悪意なく正しい方法でインフラストラクチャを実行する必要があります。

信頼できる暗号経済セキュリティ:

インデクサー: インデックス作成プロトコルはブロックチェーン上のすべてのデータを整理し、開発者がオープン API を構築して公開し、アプリケーションがデータをクエリできるようにします。個々のインデクサーは、トークンをステークしてインデックス作成およびクエリ処理サービスを提供するノードオペレーターです。ただし、提供されたデータが間違っている場合、紛争が発生し、仲裁プロセスに時間がかかることがあります。さらに、The Graph などのインデクサーからのデータは、スマートコントラクトのビジネスロジックで直接利用することはできませんが、Web2 ベースのデータ分析のコンテキストで使用されます。
Oracle: Oracle サービスプロバイダーは、多くの独立したノードオペレーターから集約されたデータを使用します。ここでの課題は、オラクルから取得したデータが頻繁に更新されず、範囲が限られている可能性があることです。 Chainlink のようなオラクルは通常、価格情報などの特定の状態のみを維持し、アプリケーション固有の状態や履歴データには対応できません。さらに、このアプローチではデータにある程度の偏りが生じ、ノードオペレーターに対する信頼が必要になります。

トラストコード:

特殊な変数と関数: イーサリアムのようなブロックチェーンには、主にブロックチェーンに関する情報を提供するために使用される、または一般的なユーティリティ関数である特殊な変数と関数があります。スマートコントラクトは、最後の 256 ブロックのブロックハッシュにのみアクセスできます。スケーラビリティ上の理由から、すべてのブロックハッシュが利用できるわけではありません。過去のブロックハッシュにアクセスできれば、それらに対する証拠を検証できるため、非常に便利です。 EVM 実行環境には、古いブロックの内容、以前のトランザクションの内容、またはレシート出力にアクセスできるオペコードがないため、ノードはこれらの内容を安全に忘れても、新しいブロックを処理できます。このアプローチも単一のブロックチェーンに限定されます。

これらのソリューションの課題と制限を考慮すると、オンチェーンストレージとブロックハッシュの提供が明らかに必要とされています。そこで重要になるのが保管証明です。 Proof of Storage をより深く理解するために、ブロックチェーンのデータストレージについて簡単に見てみましょう。

ブロックチェーンでのデータストレージ

ブロックチェーンは、ネットワーク内の多くのコンピューター間で更新および共有されるパブリックデータベースです。データと状態は連続したブロックのグループに保存され、各ブロックは前のブロックヘッダーのハッシュを保存することで暗号的に親ブロックを参照します。

イーサリアムブロックを例に挙げます。イーサリアムは「マークル・パトリシア・ツリー」（MPT）と呼ばれる特別なマークル・ツリーを使用します。 Ethereum ブロックヘッダーには、4 つの異なるマークルパトリシアツリー、つまり状態ツリー、ストレージツリー、レシートツリー、およびトランザクションツリーのルートが含まれています。これら 4 つのツリーは、すべての Ethereum データを含むマップをエンコードします。マークルツリーは、データストレージの効率性を考慮して使用されます。再帰的ハッシュを使用すると、最終的にルートハッシュのみを保存する必要があるため、スペースを大幅に節約できます。これらを使用すると、再帰ハッシュノードが同じルートハッシュにつながることを証明することで、誰でもツリー内の要素の存在を証明できます。マークル証明を使用すると、イーサリアムのライトクライアントは次の質問に答えることで答えを得ることができます。

このトランザクションは特定のブロックに存在しますか?
私のアカウントの現在の残高はいくらですか?
このアカウントは存在しますか?

すべてのトランザクションとすべてのブロックをダウンロードする代わりに、「ライトクライアント」はブロックヘッダーチェーンをダウンロードし、マークル証明を使用して情報を検証することしかできません。これにより、プロセス全体が非常に効率的になります。

保管の証明

Proof of storage を使用すると、暗号化証明を使用して、何かがデータベースに記録され、有効であることを証明できます。そのような証拠を提供できれば、ブロックチェーン上で何かが起こったという検証可能な声明となるでしょう。

保管証明により何が達成できるのでしょうか?

ストレージの証明により、次の 2 つの主な機能が可能になります。

最後の 256 ブロックを超えて、ジェネシスブロックに至るまでの履歴上のオンチェーンデータにアクセスします
コンセンサス検証または L2 ブリッジング (L2 の場合) を使用して、あるブロックチェーンから別のブロックチェーンへオンチェーンデータ (過去および現在) にアクセスします。

保管証明はどのように機能しますか?

簡単に言えば、Proof of Storage は、特定のブロックがブロックチェーンの正規履歴の一部であるかどうかを確認し、要求された特定のデータがブロックの一部であるかどうかを検証します。これは次の方法で実現できます。

オンチェーン処理: Dapps は、最初の信頼できるブロックを取得し、そのブロックを Calldata として渡して前のブロックにアクセスし、ジェネシスブロックまで遡ることができます。これには、大量のオンチェーン計算と大量の Calldata が必要です。このアプローチは、大規模なオンチェーン計算が必要となるため、完全に非現実的です。 Aragon は 2018 年にオンチェーンのアプローチを使用しようとしましたが、オンチェーンのコストが高かったため実現できませんでした。
ゼロ知識証明を使用する: このアプローチはオンチェーン処理に似ていますが、ゼロ知識証明を使用して複雑な計算がオフチェーンに移動される点が異なります。

同じチェーンからのデータへのアクセス: ゼロ知識証明を使用すると、任意の履歴ブロックヘッダーが、実行環境でアクセス可能な最新の 256 個のブロックヘッダーの 1 つの祖先であると主張できます。もう 1 つのアプローチは、ソースチェーンの履歴全体にインデックスを付け、インデックス付けが正しく行われたことを証明するゼロ知識証明を生成することです。この証明は、新しいブロックがソースチェーンに追加されると定期的に更新されます。

クロスチェーンデータにアクセスする: プロバイダーはターゲットチェーン上のソースチェーンからブロックヘッダーを収集し、ゼロ知識コンセンサス証明を使用してこれらのブロックヘッダーの有効性を証明します。ブロックヘッダーは、Axelar、Celer、LayerZero などの既存のクロスチェーンメッセージングソリューションを使用してクエリすることもできます。
ターゲットチェーン上のソースチェーンのブロックヘッダーハッシュ、またはオフチェーンのブロックハッシュアキュムレータのルートハッシュのキャッシュを維持します。このキャッシュは定期的に更新され、特定のブロックが存在し、状態からアクセス可能な最新のブロックハッシュへの暗号リンクがあることをオンチェーンで効率的に証明するために使用されます。このプロセスは、チェーンの連続性の証明と呼ばれます。専用のブロックチェーンを使用して、すべてのソースチェーンのブロックヘッダーを保存することもできます。
ターゲットチェーン上の Dapp のリクエストに基づいて、オフチェーンのインデックス付きデータまたはオンチェーンキャッシュ (リクエストの複雑さに応じて) から履歴データ/ブロックにアクセスします。キャッシュされたブロックヘッダーハッシュはオンチェーンで維持されますが、実際のデータはオフチェーンに保存される場合があります。
マークル包含証明を通じて指定されたブロックにデータが存在するかどうかを確認し、これに対するゼロ知識証明を生成します。この証明は、正しくインデックス付けされたゼロ知識証明またはゼロ知識コンセンサス証明と結合され、トラストレス検証のためにオンチェーンで提供されます。
その後、Dapp はオンチェーンで証明を検証し、データに対して必要なアクションを実行できます。ゼロ知識証明の検証に加えて、ブロック番号やブロックハッシュなどの公開パラメーターも、チェーン上に保持されているブロックヘッダーのキャッシュと照合してチェックされます。

このアプローチを採用したプロジェクトには、Herodotus、Lagrange、Axiom、HyperOracle、Brevis Network、nil Foundation などがあります。複数のブロックチェーン間でアプリケーションをステート対応にするために多大な努力が払われていますが、IBC (チェーン間通信) は、ICQ (チェーン間クエリ) や ICA (クロスチェーンアカウント) などのテクノロジーを使用したアプリケーションを可能にする相互運用性標準として際立っています。）。 ICQ を使用すると、チェーン A 上のアプリケーションが単純な IBC パケットにクエリを含めることでチェーン B のステータスをクエリできるようになり、ICA を使用すると、あるブロックチェーンが別のブロックチェーン上のアカウントを安全に制御できるようになります。それらを組み合わせることで、興味深いクロスチェーンのユースケースをサポートできます。 Saga のような RaaS プロバイダーは、デフォルトで IBC を使用して、すべてのアプリケーションチェーンにこれらの機能を提供します。

ストレージプルーフは、メモリ消費量、プルーフ時間、検証時間、計算効率、開発者のエクスペリエンスの間で最適なバランスを見つけるために、さまざまな方法で最適化できます。プロセス全体は、次の 3 つの主要なサブプロセスに大まかに分けることができます。

データアクセス;
情報処理;
データのアクセスと処理のためのゼロ知識証明の生成。

データアクセス: このサブプロセスでは、サービスプロバイダーは、ネイティブな方法で、またはオンチェーンキャッシュを維持することによって、実行層のソースチェーンのブロックヘッダーにアクセスします。クロスチェーンデータアクセスの場合、ソースチェーンのコンセンサスがターゲットチェーンで検証される必要があります。使用される方法と最適化には次のものがあります。

既存のイーサリアムブロックチェーン: イーサリアムブロックチェーンの既存の構造を使用して、ゼロ知識証明を使用して、現在のブロックヘッダーに対する過去のストレージスロットの値を証明できます。これは大きな包含証明と考えることができます。つまり、高さ b に最も近いブロックヘッダー X があるとすると、X の祖先であるブロックヘッダー Y が高さ bk に存在します。これはイーサリアムコンセンサスのセキュリティに基づいており、効率的な証明システムが必要です。これがラグランジュが採用したアプローチです。
オンチェーンのマークル山脈 (MMR) キャッシュ: マークル山脈は、2 つのツリーが同じサイズに達したときに結合されるマークルツリーのリストとして表示できます。 MMR の単一のマークルツリーは、ツリーの前のルートに親ノードを追加することによって構成されます。 MMR はマークルツリーに似ていますが、要素の効率的な追加や効率的なデータクエリ、特に大規模なデータセットからの連続データの読み取りなど、いくつかの追加の利点があります。マークルツリーを介して新しいヘッドを追加するには、各レベルのすべての姉妹ノードを通過する必要があります。データを効率的に追加するために、Axiom は MMR を使用してブロックヘッダーハッシュのオンチェーンキャッシュを維持します。 Herodotus は、MMR ブロックハッシュアキュムレータのルートハッシュをオンチェーンに保存します。これにより、プルーフを含めることで、フェッチされたデータをこれらのブロックヘッダーハッシュと照合できるようになります。このアプローチでは定期的なキャッシュ更新が必要となるため、分散化されていない場合は活性の問題が発生する可能性があります。
効率と計算コストを最適化するために、Herodotus は 2 つの異なる MMR を維持します。特定のブロックチェーンまたはレイヤーに応じて、アキュムレーターをさまざまなハッシュ関数でカスタマイズできます。 Starknet を証明するときにポセイドンハッシュを使用することは可能ですが、EVM チェーンには Kecck ハッシュを使用します。
オフチェーン MMR キャッシュ: Herodotus は、データが再度要求されたときにより速く取得できるように、以前に取得したクエリと結果のオフチェーンキャッシュを維持します。これには、アーカイブノードを実行するだけではなく、より多くのインフラストラクチャが必要になります。オフチェーンインフラストラクチャの最適化により、エンドユーザーのコストを削減できる可能性があります。
ストレージ用の専用ブロックチェーン: Brevis は、専用のゼロ知識ロールアップ (集約層) を利用して、証明されたすべてのチェーンのすべてのブロックヘッダーを保存します。この集約層がなければ、各チェーンは他のすべてのチェーンのブロックヘッダーを保存する必要があり、N 個のブロックチェーンに対して O(N 2) 個の「接続」が必要になります。アグリゲーション層を導入することにより、各ブロックチェーンはロールアップの状態ルートを保存するだけで済み、全体的な接続が O(N) に削減されます。この層は、複数のブロックヘッダー/クエリ結果の証明を集約し、接続された各ブロックチェーン上で単一の検証証明を送信するためにも使用されます。
L1-L2 メッセージング: L2 は、L1 を介して L2 コントラクトを更新するためのネイティブメッセージングをサポートしているため、ソースチェーンのコンセンサス検証を回避できます。キャッシュはイーサリアム上で更新でき、L1-L2 メッセージングを使用して、オフチェーンでコンパイルされたブロックハッシュまたはツリールートを他の L2 に送信できます。 Herodotus はこのアプローチを採用していますが、これは alt L1 では実現できません。

情報処理：

スマートコントラクトは、データにアクセスするだけでなく、データに対して任意の計算を実行できる必要もあります。一部のユースケースでは計算が必要ない場合もありますが、他の多くのユースケースでは、計算は重要な付加価値サービスです。多くのサービスプロバイダーは、ゼロ知識証明の形式でデータの計算をサポートし、この証明をオンチェーンで提供して、その有効性を検証します。 Axelar、LayerZero、Polyhedra Network などの既存のクロスチェーンメッセージングソリューションをデータアクセスに使用できるため、データ処理がストレージプルーフサービスプロバイダーの差別化ポイントになる可能性があります。

たとえば、HyperOracle を使用すると、開発者は JavaScript を使用してカスタムのオフチェーン計算を定義できます。 Brevis は、Dapps からのデータクエリを受け入れ、実績のあるブロックヘッダーを使用してそれらを処理する、オープンなゼロ知識クエリエンジン市場を設計しました。スマートコントラクトはデータクエリを送信し、そのデータは市場の証明者によって取得されます。証明者は、クエリ入力、関連するブロックヘッダー (Brevis 集約層から)、および結果に基づいて証明を生成します。 Lagrange は、SQL、MapReduce、Spark/RDD などの実証済みの分散プログラミングモデル用のゼロ知識ビッグデータテクノロジスタックを導入します。これらの証明はモジュール式であり、既存のクロスチェーンブリッジングおよびクロスチェーンメッセージングプロトコルのブロックヘッダーから生成できます。ラグランジュのゼロ知識ビッグデータテクノロジースタックの最初の製品は、大量のマルチチェーンデータを含む計算結果を証明するために使用される分散コンピューティングエンジン (有名な MapReduce プログラミングモデルに基づく) であるゼロ知識 MapReduce です。たとえば、単一のゼロ知識 MapReduce 証明は、指定された時間枠内で 4 ～ 5 つのチェーンにデプロイされた DEX の流動性の変化を証明できます。比較的単純なクエリの場合、Herodotus が現在行っているように、計算をオンチェーンで直接実行することもできます。

プルーフの生成:

更新可能なプルーフ: 更新可能なプルーフは、移動ブロックストリーム上でプルーフを計算し、効率的に維持する必要がある場合に使用できます。新しいブロックが作成されると、コントラクト変数 (トークン価格など) の移動平均プルーフを維持するために、新しいプルーフを最初から再計算することなく、既存のプルーフを効率的に更新できます。オンチェーン状態の動的データ並列計算を証明するために、ラグランジュは MPT の一部の上に Recproof と呼ばれるバッチベクトルコミットメントを構築し、リアルタイムで更新して動的に計算しました。 MPT の上に Verkle ツリーを再帰的に作成することにより、Lagrange は大量の動的なオンチェーン状態データを効率的に計算できます。
Verkle ツリー: 親ノードを共有するすべてのノードを必要とする Merkle ツリーとは異なり、Verkle ツリーではルートパスのみが必要です。このパスは、マークルツリー内のすべての姉妹ノードと比較してはるかに小さいです。イーサリアムは、イーサリアムのフルノードが保持する必要がある状態の量を最小限に抑えるために、将来のバージョンで Verkle ツリーを使用することも検討しています。 Brevis は Verkle ツリーを使用して、実績のあるブロックヘッダーとクエリ結果を集約層に保存します。特にツリーに多数の要素が含まれている場合に、データ包含証明のサイズが大幅に削減され、大量のデータに対する効率的な包含証明がサポートされます。
プルーフ生成を高速化するためのメモリプールの監視: Herodotus は最近ターボをリリースしました。これにより、開発者はスマートコントラクトコードに数行のコードを追加してデータクエリを指定できます。 Herodotus は、ターボコントラクトと対話するスマートコントラクトトランザクションのメモリプールを監視します。プルーフ生成プロセスは、トランザクションがメモリプール自体に存在するときに開始されます。証明がオンチェーンで生成および検証されると、結果がオンチェーンのターボ交換コントラクトに書き込まれます。ストレージ証明による認証後にのみ、結果をターボ交換契約に書き込むことができます。これが発生すると、トランザクション手数料の一部がシーケンサーまたはブロックジェネレーターと共有され、手数料が徴収されるまでより長く待つよう奨励されます。単純なデータクエリの場合、ユーザーのトランザクションがブロックに含まれる前に、要求されたデータがすでにオンチェーンで利用可能になっている可能性があります。
状態・保管証明の申請

Proof of State とストレージにより、アプリケーション、ミドルウェア、インフラストラクチャ層でスマートコントラクトの多くの新しいユースケースが可能になります。そのうちのいくつかは次のとおりです。

アプリケーション層:

ガバナンス:

クロスチェーン投票: オンチェーン投票プロトコルにより、チェーン B のユーザーがチェーン A の資産の所有権を証明できるようになります。ユーザーは、新しいチェーンでの投票権を得るために自分の資産をブリッジする必要はありません。例: Herodotus の SnapshotX
ガバナンストークンの配布: アプリケーションは、アクティブユーザーまたはアーリーアダプターにさらに多くのガバナンストークンを配布できます。例: ラグランジュの RetroPGF。

アイデンティティと評判:

所有権の証明: ユーザーは、チェーン B で特定の操作を実行するために、チェーン A 上の特定の NFT、SBT、または資産を所有していることを証明できます。たとえば、ゲームアプリケーションチェーンは、イーサリアムや任意の L2 などの既存の流動性を備えた他のチェーンで NFT コレクションを開始することを決定する可能性があります。これにより、ゲームは実際にクロスチェーン NFT を必要とせずに、他の場所に存在する流動性を活用できるようになります。
使用証明: ユーザーは、プラットフォームでの過去の使用量に基づいて割引またはプレミアム機能を受け取ることができます (ユーザーが Uniswap で X 金額を取引したことの証明)。
OG 証明: ユーザーは、X 日以上経過したアクティブなアカウントを所有していることを証明できます。
オンチェーン信用スコアリング: クロスチェーン信用スコアリングプラットフォームは、単一ユーザーの複数のアカウントからのデータを集約して信用スコアを生成できます。

上記の証明はすべて、カスタマイズされたエクスペリエンスをユーザーに提供するために使用できます。 Dapps は、経験豊富なトレーダーやユーザーを維持し、初心者ユーザーに合理化されたユーザーエクスペリエンスを提供するために割引や特典を提供できます。

Defi:

クロスチェーン融資: ユーザーは、ブリッジングトークンを必要とせずに、チェーン A で資産をロックし、チェーン B で融資を受けることができます。
オンチェーン保険: オンチェーンの履歴データにアクセスすることで障害を特定でき、保険補償は完全にチェーン上で完了できます。
プール内の資産の時間加重平均価格: アプリケーションは、指定された期間内の AMM プール内の資産の平均価格を計算して取得できます。例: Axiom の Uniswap TWAP オラクル。
オプションの価格設定: オンチェーンオプションプロトコルは、分散型取引所の過去 n ブロックにわたる資産のボラティリティを使用してオプションの価格を設定できます。

最後の 2 つの使用例では、新しいブロックがソースチェーンに追加されたときにプルーフを更新する必要があります。

ミドルウェア:

意図: 証拠を保存すると、ユーザーは意図についてより表現力豊かで明確になることができます。ソルバーの仕事はユーザーの意図を満たすために必要な手順を実行することですが、ユーザーはオンチェーンのデータとパラメーターに基づいて条件をより明確に指定できます。ソルバーは、最適なソリューションを見つけるために利用されたオンチェーンデータの有効性を実証することもできます。
アカウントの抽象化: ユーザーはストレージの証明を利用して、他のチェーンからのデータに基づいてルールを設定できます。例: すべてのウォレットには nonce があります。 1 年前のナンスは特定の数値でしたが、現在のナンスは同じであることがわかります。これは、ウォレットがまったく使用されていないことを証明するために使用でき、その後、ウォレットへのアクセスを別のウォレットに委任できます。
オンチェーンの自動化: スマートコントラクトは、オンチェーンデータに依存する事前定義された条件に基づいて、特定のアクションを自動的に実行できます。自動化されたプログラムは、AMM の最適な価格フローを維持したり、不良債権を回避して融資プロトコルを健全に保つために、スマートコントラクトを定期的に呼び出す必要があります。 HyperOracle は自動化とオンチェーンデータアクセスをサポートします。

インフラストラクチャー

トラストレス・オンチェーン・オラクル: オラクル・ネットワーク内の複数の個別のオラクル・ノードからの応答を集約する分散型オラクル・ネットワーク。 Oracle ネットワークはこの冗長性を排除し、暗号化セキュリティを活用してオンチェーンデータを有効にすることができます。オラクルネットワークは、複数のチェーン (L1、L2、および alt L1) からのデータを 1 つのチェーンに集約し、単にproof-of-storage を使用して他の場所でその存在を証明できます。大幅な進歩を遂げている DeFi ソリューションは、カスタムソリューションを使用することもできます。たとえば、最大の流動性ステーキングプロバイダーである Lido Finance は、zkOracle の開発に資金を提供するために Nil Foundation と提携しています。これらのソリューションにより、EVM 履歴データへのトラストレスデータアクセスが可能になり、Lido Finance がステークした 150 億ドルのイーサリアム流動性が保護されます。
クロスチェーンメッセージングプロトコル: 既存のクロスチェーンメッセージングソリューションは、Proof-of-Storage サービスプロバイダーと提携することでメッセージの表現力を高めることができます。これは、ラグランジュがモジュール性に関する論文で提案したアプローチです。

結論は

認識することで、テクノロジー企業は顧客により良いサービスを提供できるようになります。ユーザーのアイデンティティから購買行動、社会的つながりに至るまで、テクノロジー企業はコグニティブ機能を利用して、正確なターゲティング、顧客のセグメンテーション、バイラルマーケティングなどの機能を解き放ちます。従来のテクノロジー企業はユーザーからの明示的な許可を必要とし、ユーザーデータを管理する際には注意が必要です。ただし、許可されたブロックチェーン上のすべてのユーザーデータは公開されており、必ずしもユーザーの身元を明らかにするわけではありません。スマートコントラクトは、ユーザーにより良いサービスを提供するために、公開されているデータを活用できる必要があります。より専門化されたエコシステムの開発と導入により、時間とチェーンにわたる状態認識がますます重要な問題になります。 Proof of storage により、イーサリアムは単なる決済層ではなく、アイデンティティと資産所有権の層として浮上することができます。ユーザーはイーサリアム上で自分のアイデンティティと主要な資産を維持でき、資産を常にブリッジする必要がなく、複数のブロックチェーンにわたって使用できます。私たちは、将来解き放たれる新たな可能性とユースケースに引き続き興奮しています。

クロスチェーン

Odaily公式コミュニティへの参加を歓迎します