紹介

1時間ごとに記憶を失ったらどうなるでしょうか? そして、あなたは常に誰かにあなたが何をしたかを教えてもらう必要がありますか? それがスマートコントラクトの現状です。 イーサリアムのようなブロックチェーンでは、スマートコントラクトは256ブロックを超える状態に直接アクセスすることはできません。 この問題は、マルチチェーンエコシステムではさらに悪化し、異なる実行レイヤー間でのデータの取得と検証はさらに困難になります。

2020年、ヴィタリック・ブテリン氏とトマシュ・スタンチャク氏は、時間を超えてデータにアクセスする方法 を提案し ました。 EIPは停滞していますが、ロールアップ中心のマルチチェーンの世界では、その必要性が再浮上しています。 今日、ストレージプルーフは、スマートコントラクトに認識と記憶を与えるためのフロンティアとして浮上しています。

オンチェーンデータへのアクセス

dappsがデータや状態にアクセスする方法はいくつかあります。 すべてのアプローチでは、アプリケーションが人間/エンティティ、または暗号の経済的セキュリティまたはコードを信頼する必要があり、いくつかのトレードオフがあります。

人間/エンティティへの信頼:

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

暗号の経済的安全性を信頼する:

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

信頼コード:

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

これらのソリューションの課題と制限を考えると、ブロックハッシュをオンチェーンで保存して提供する必要性は明らかです。 ここで、保管証明の出番です。 ストレージプルーフをよりよく理解するために、ブロックチェーンのデータストレージを簡単に見てみましょう。

ブロックチェーンへのデータ保存

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

イーサリアムブロックを例にとってみましょう。 イーサリアムは、「マークル・パトリシア・ツリー」(MPT)と呼ばれる特定のタイプのマークルツリーを活用しています。 イーサリアムのブロックヘッダーには、4つの異なるMerkle-Patriciaトライのルートが含まれています。 状態トライ、ストレージ試行、レシート試行、およびトランザクション試行。 これらの4つの試行は、すべてのイーサリアムデータを構成するマッピングをエンコードします。 マークルツリーは、データストレージの効率性のために使用されます。 再帰ハッシュを使用すると、最終的にルートハッシュのみを保存する必要があるため、多くのスペースを節約できます。 これにより、ノードを再帰的にハッシュすると同じルートハッシュにつながることを証明することで、誰でもツリー内の要素の存在を証明できます。 マークルプルーフにより、イーサリアムのライトクライアントは、次のような質問に対する回答を得ることができます。

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

「ライトクライアント」は、すべてのトランザクションとすべてのブロックをダウンロードする代わりに、ブロックヘッダーのチェーンをダウンロードし、マークルプルーフを使用して情報を検証することしかできません。 これにより、プロセス全体が非常に効率的になります。 Vitalik によるこの ブログ と Maven11 の研究 記事 を参照して、Merkle Trees に関連する実装、利点、および課題をよりよく理解してください。

保管証明

ストレージ証明により、データベースで何かがコミットされ、暗号化コミットメントを使用して有効であることを証明できます。 そのような証拠を提供できれば、ブロックチェーン上で何かが起こったという検証可能な主張です。

Storage Proofsで実現できること

ストレージプルーフは、次の2つの主要な機能を可能にします。

1. 過去256ブロックを超えて、ジェネシスブロックまでさかのぼる過去のオンチェーンデータにアクセスできます。
2. コンセンサス検証またはL2の場合はL1-L2ブリッジの助けを借りて、別のブロックチェーン上のあるブロックチェーンのオンチェーンデータ(過去および現在)にアクセスします

ストレージプルーフはどのように機能しますか?

ストレージプルーフは、特定のブロックがブロックチェーンの正規履歴の一部であるかどうかを非常に高レベルでチェックし、要求された特定のデータがブロックの一部であるかどうかを確認します。 これは、次の方法で実現できます。

• オンチェーン処理:dappsは、最初の信頼されたブロックを取得し、そのブロックをcalldataとして渡して前のブロックにアクセスし、ジェネシスブロックまでさかのぼることができます。 これには、オンチェーンで多くの計算と膨大な量の通話データが必要です。 このアプローチは、オンチェーンで膨大な量の計算が必要なため、実用的にはまったく実現不可能です。 アラゴン は2018年にオンチェーンアプローチの使用を試みましたが、オンチェーンコストが高いため実現できませんでした。
• ZK証明の使用:このアプローチは、ZK証明を使用して複雑な計算をオフチェーンに移動することを除いて、オンチェーン処理と似ています。

1. 同じチェーン上のデータへのアクセス:ZK証明は、任意の履歴ブロックヘッダーが、実行環境内でアクセス可能な最新の256個のブロックヘッダーの1つの祖先であることをアサートするために使用できます。 もう1つのアプローチは、ソースチェーンの履歴全体にインデックスを付け、同じZKプルーフを生成して、インデックス作成が正しく行われたことを証明することです。 この証明は、新しいブロックがソースチェーンに追加されると定期的に更新されます。 チェーンをまたいでデータにアクセスする: プロバイダーは、宛先チェーン上のソースチェーンのブロックヘッダーを収集し、ZKコンセンサスプルーフを使用してこれらのブロックヘッダーの有効性を証明します。 また、Axelar、Celer、LayerZeroなどの既存のAMPソリューションを使用して、ブロックヘッダーをクエリすることもできます。
2. ソースチェーンのブロックヘッダーのハッシュのキャッシュ、またはオフチェーンのブロックハッシュアキュムレータのルートハッシュは、宛先チェーンで維持されます。 このキャッシュは定期的に更新され、特定のブロックが存在し、状態からアクセス可能な最近のブロックハッシュへの暗号化リンクがあることをオンチェーンで効率的に証明するために使用されます。 このプロセスは、チェーンの連続性の証明として知られています。 また、専用のブロックチェーンを使用して、すべてのソースチェーンのブロックヘッダーを保存することも可能です。
3. ヒストリカルデータ/ブロックは、宛先チェーン上のdappの要求に応じて、オフチェーンのインデックス付きデータまたはオンチェーンキャッシュ(リクエストの複雑さに応じて)からアクセスされます。 ブロックヘッダーのハッシュのキャッシュはオンチェーンで維持されますが、実際のデータはオフチェーンに保存される可能性があります。
4. 指定されたブロック内のデータの存在は、マークル包含証明によってチェックされ、同じzk証明が生成されます。 この証明は、正しいインデックス作成のzk証明またはZKコンセンサス証明と組み合わされ、証明はトラストレス検証のためにオンチェーンで利用可能になります。
5. その後、dappsはこの証明をオンチェーンで検証し、データを使用して目的のアクションを実行できます。 ZKプルーフの検証とともに、ブロック番号やブロックハッシュなどのパブリックパラメータが、オンチェーンで維持されているブロックヘッダーのキャッシュと照合されます。

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

メモリ消費量、証明時間、検証時間、コンピューティング効率、開発者エクスペリエンスの適切なバランスを見つけるために、ストレージ証明を最適化する方法はたくさんあります。 全体のプロセスは、大きく3つの主要なサブプロセスに分けることができます。

• データアクセス
• データ処理
• ZKデータアクセスと処理のためのプルーフ生成

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

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

データ処理：

スマートコントラクトは、データへのアクセスに加えて、データ上で任意の計算を行うことができる必要があります。 一部のユースケースでは計算が不要な場合がありますが、他の多くのユースケースでは重要な付加価値サービスです。 サービスプロバイダーの多くは、計算のzkプルーフを生成し、有効性のためにオンチェーンで提供できるため、データの計算を可能にします。 Axelar、LayerZero、Polyhedra Networkなどの既存のAMPソリューションはデータアクセスに使用できる可能性があるため、データ処理はストレージプルーフサービスプロバイダーの差別化要因になる可能性があります。

たとえば、Hyper Oracleでは、開発者はJavaScriptを使用してカスタムオフチェーン計算を定義できます。 Brevisは、dAppsからデータクエリを受け入れ、認証されたブロックヘッダーを使用して処理するZKクエリエンジンのオープンマーケットプレイスを設計しました。 スマートコントラクトはデータクエリを送信し、マーケットプレイスの証明者によって取得されます。 Prover は、クエリ入力、関連するブロックヘッダー (Brevis 集約レイヤーから)、および結果に基づいて証明を生成します。 ラグランジュは、SQL、MapReduce、Spark/RDDなどの分散プログラミングモデルを実証するために、ZK Big Data Stackを導入しました。 プルーフはモジュール式で、既存のクロスチェーンブリッジやAMPプロトコルから発信される任意のブロックヘッダーから生成できます。 ラグランジュZK BigDataスタックの最初の製品であるZK MapReduceは、かなりのマルチチェーンデータを含む計算結果を証明するための分散計算エンジン(よく知られたMapReduceプログラミングモデルに基づく)です。 例えば、1つのZKMRプルーフを使用して、指定された時間枠で4〜5チェーンに展開されたDEXの流動性の変化を証明できます。 比較的単純なクエリの場合、現在ヘロドトスが行っているように、計算をオンチェーンで直接行うこともできます。

プルーフ生成:

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

状態/ストレージ証明の適用

状態とストレージの証明は、アプリケーション、ミドルウェア、インフラストラクチャ層でのスマートコントラクトの多くの新しいユースケースを解き放つことができます。 これらのいくつかは次のとおりです。

アプリケーション層:

統治：

• クロスチェーン投票:オンチェーン投票プロトコルにより、チェーンBのユーザーはチェーンAの資産の所有権を証明することができ、ユーザーは新しいチェーンで議決権を得るために資産をブリッジする必要がなくなります。 例: ヘロドトスの SnapshotX
• ガバナンス トークンの配布: アプリケーションは、アクティブ ユーザーまたは早期導入者により多くのガバナンス トークンを配布できます。 例: ラグランジュ上の RetroPGF

アイデンティティとレピュテーション:

• 所有権の証明:ユーザーは、チェーンA上の特定のNFT、SBT、または資産の所有権の証明を提供し、チェーンBで特定のアクションを実行できるようにすることができます。例えば、ゲームアプリチェーンは、イーサリアムやL2のような既存の流動性を持つ別のチェーンでNFTコレクションをローンチすることを決定するかもしれません。 これにより、ゲームは他の場所に存在する流動性を利用し、実際にNFTをブリッジする必要がなく、NFTユーティリティをブリッジすることができます。
• 使用証明:ユーザーは、プラットフォームの使用履歴に基づいて割引またはプレミアム機能を授与される可能性があります(ユーザーがUniswapでXボリュームを取引したことを証明します)
• OGの証明:ユーザーは、X日以上経過したアクティブなアカウントを所有していることを証明できます
• オンチェーンのクレジットスコア:マルチチェーンのクレジットスコアプラットフォームは、1人のユーザーの複数のアカウントからデータを集約して、クレジットスコアを生成することができます

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

デフィ:

• クロスチェーンレンディング:ユーザーは、トークンをブリッジする代わりに、チェーンAの資産をロックインし、チェーンBでローンを組むことができます。
• オンチェーン保険:過去のオンチェーンデータにアクセスすることで障害を判断でき、保険は完全にオンチェーンで決済できます。
• プール内の資産価格のTWAP(平均小売価格): アプリケーションは、指定された期間におけるAMMプール内の資産の平均価格を計算してフェッチできます。 例: Uniswap TWAP Oracle と Axiom
• オプション価格:オンチェーンオプションプロトコルは、分散型取引所の過去nブロックにわたる資産のボラティリティを使用してオプションの価格を設定する場合があります。

最後の 2 つのユースケースでは、新しいブロックがソースチェーンに追加されるたびに証明を更新する必要があります。

ミドルウェア:

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

インフラ

• トラストレスなオンチェーンオラクル:分散型オラクルネットワークは、オラクルネットワーク内の多数の個々のオラクルノードからの応答を集約します。 Oracle Networksは、この冗長性を排除し、オンチェーン・データに暗号化セキュリティを活用できます。 Oracleネットワークは、複数のチェーン(L1、L2、およびalt L1)から単一のチェーンにデータを取り込み、他の場所のストレージ証明を使用して存在を証明できます。 大きな牽引力を持つDeFiソリューションは、カスタムソリューションでも機能する可能性があります。 例えば、最大の流動性ステーキングプロバイダーであるLido Financeは、Nil Foundationと提携し、 zkOracleの開発に資金を提供しています。 このソリューションにより、EVM内の履歴データへのトラストレスなデータアクセスが可能になり、Lido Financeがステーキングしたイーサリアムの流動性で150億ドルが確保されます。
• AMP プロトコル:既存の AMP ソリューションは、ストレージプルーフ サービス プロバイダーと提携することで、メッセージの表現力を高めることができます。 これは、ラグランジュが モジュラーテーゼ の記事で提案したアプローチです。

結論

認識は、テクノロジー企業が顧客により良いサービスを提供する力を与えます。 ユーザーアイデンティティから購買行動、ソーシャルグラフまで、テクノロジー企業は認知度を活用して、精密なターゲティング、顧客セグメンテーション、バイラルマーケティングなどの機能を解き放ちます。 従来のテクノロジー企業は、ユーザーからの明示的な許可が必要であり、ユーザーデータの管理には注意が必要です。 しかし、パーミッションレスブロックチェーン上のすべてのユーザーデータは、必ずしもユーザーの身元を明らかにすることなく公開されています。 スマートコントラクトは、公開されているデータを活用して、ユーザーにより良いサービスを提供できる必要があります。 より専門的なエコシステムの開発と採用により、時代を超えて国家の認識が高まり、ブロックチェーンは解決すべきますます重要な問題になります。 ストレージプルーフは、イーサリアムを決済レイヤーであると同時に、アイデンティティと資産所有レイヤーとして浮上させることができます。 ユーザーは、自分のアイデンティティと重要な資産をイーサリアム上で維持することができ、常に資産をブリッジすることなく、複数のブロックチェーンで使用することができます。 私たちは、将来解き放たれる新しい可能性とユースケースに興奮し続けています。

免責事項：

1. この記事は[medium]からの転載です。 すべての著作権は原著作者[LongHash Ventures]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。