広い定義によれば、EVM スマート コントラクトは、共有可能な分散データベース上に展開されるイベント駆動型のステートフル コンピューター プログラムです。この設計は元々、分散化とセキュリティを確保することを目的としており、各ノードはスマート コントラクトのすべての操作を実行する必要があり、各コントラクトのステータスの変更はリアルタイムで記録され、ブロックチェーンに永続的に保存される必要があり、EVM スマート コントラクトの各トランザクションは可能です。ただし、チェーン上の状態の複雑さが増すにつれて、特に複数のスマート コントラクトが頻繁に更新を必要とする場合、状態ロックの競合のリスクが高まり、個々のノードがこれらの状態を管理および同期することがますます困難になります。 (ロック競合)と状態の同期がより顕著です。
この文脈において、ログ駆動型スマート コントラクトは、従来のアーキテクチャの制限を打ち破る新しいパラダイムとなっています。このアーキテクチャは、コントラクト状態ストレージをチェーンから切り離し、不変のメッセージ ログに隠すことにより、スケーラビリティを向上させるだけでなく、フル ノードの計算負荷を大幅に軽減します。 AO ホログラフィック ステートは、この新しいパラダイムを代表するもので、Arweave の永続ストレージと分散コンピューティングを使用して、より透過的でスケーラブルなスマート コントラクト実行方法を作成します。
ログ駆動型スマートコントラクトとは何ですか?
ログ駆動型スマート コントラクトは、従来のスマート コントラクトとは異なり、状態駆動型であり、すべての変更の履歴記録を保持せずに、現在のシステムの最新ステータスを直接保存します。代わりに、ユーザーの対話ログ (またはトランザクション イベント ログ) を記録することによって、状態の動的な計算を実行します。これは、すべてのスマート コントラクト インタラクション (トランザクション、ステータス更新など) によって不変ログが生成され、これらのログが永続ストレージ層に永続的に保存されることを意味します。現在の状態をクエリする必要がある場合、どのノードもこれらのログを通じて現在のコントラクト状態を再計算するだけで済みます。
- インタラクション ログ: スマート コントラクトの各操作またはトランザクションは、イベント駆動型プログラミングのイベント トリガーと同様に、コントラクトのステータスの変化を記録します。
- 動的な状態の再構築: 契約の現在の状態は直接保存されませんが、関連するすべてのログを読み取って計算することによって取得されます。スマート コントラクトの状態は、ログを読み取ることでいつでも再構築できます。
- 不変ストレージ レイヤー: ログは通常、長期保存用に特別に設計された不変ストレージ レイヤーである Arweave に保存され、すべてのログ レコードが永続的で改ざんできないことが保証されます。
イーサリアム拡張ソリューションであるオプティミスティック ロールアップの検証メカニズムも、このログ駆動型スマート コントラクト アーキテクチャにある程度似ています。ロールアップ サブチェーンはトランザクション バッチを生成し、イーサリアム メイン チェーンに送信しますが、完全なものは保存されません。コントラクト ステータスを保持しますが、状態の再構築と検証を行うために「状態ルート」と「トランザクション ログ」を渡します。メイン チェーンには、サブチェーンによって送信された単純なトランザクション証明書のみがあり、その後 7 日間のチャレンジ解決メカニズムを通じてステータスが検証されます。誰でも (理論上、現在は OP のみがホワイトリストを検証できます)、送信されたトランザクション ログを通じてステータスを再計算し、異議を申し立てることができます。
AO履歴ステータス変更ログ - ホログラフィックステータス
ホログラフィック ステートは AO の重要なイノベーションであり、分散コンピューティングに無制限のスケーラビリティを提供します。AO は、計算自体の状態について合意に達するのではなく、インタラクション ログが Arweave に保存されるようにすることで、ステータスの「ホログラム」を作成します。
従来のアーキテクチャでは、各ノードは完全なコントラクト状態を保存する必要があり、時間の経過とともに状態ストレージの必要性は増加し続けています。これらのボトルネックを克服するために、AO ホログラフィック ステート アーキテクチャが誕生しました。AO ホログラフィック ステートは、独自のログ駆動方式を使用してコントラクトのすべての状態変更を記録し、状態の一貫性と整合性を確保しながら、複雑な処理を簡素化します。インタラクション シナリオ。プロセスの状態は主に Arweave に保存されている対話ログに暗黙的に含まれており、参加者であれば誰でも確定的に計算できます。このアプローチにより、プロセスのステータスは直接監視されませんが、独立して検証でき、ネットワーク全体で一貫した状態になることが保証されます。 Arweave の不変ストレージ機能を活用してスケーラビリティを確保し、計算オーバーヘッドを削減しながら、分散コンピューティングの強化に対する AO の取り組みを強調しています。
これは、ホログラフィック状態の「無限のスケーラビリティ」も反映しています。つまり、コントラクトの履歴状態変更ログのみが記録され、状態はオンデマンドで再構築されます。ノードはリアルタイム計算を継続的に実行する必要がないため、消費量が削減されます。コンピューティング リソースの。
ログ駆動型とステート駆動型
注: この章では、まったく新しい契約ソリューションを紹介し、客観的な事実について説明します。どのソリューションが優れているかを選択する傾向はありません。
データログストレージの違い
イーサリアムは契約の履歴ステータス変更ログを保存しないのですか?イーサリアムもコントラクトの状態変更履歴ログを保存しますが、その処理方法は AO ホログラフィック状態アーキテクチャとは大きく異なります。
イーサリアム ノードは、ネットワーク全体の現在の状態ツリー (MPT ツリー、マークル パトリシア ツリー) を保持します。新しいトランザクションがブロックにパッケージ化されて実行されると、状態ツリーはすぐに更新され、各ノードが保存する必要がある最新の状態が反映されます。そして、この状態ツリーを維持します。状態ツリーは、アカウントのステータス更新 (残高、ノンス、スマート コントラクト ストレージの変更など) を記録し、これらの更新をブロックの状態ルート (状態ルート) に書き込みます。ログはトランザクション受領書に保存される単なる追加情報であり、状態ツリーのどの部分にも影響を与えたり、記録したりすることはありません。
イーサリアムはすべてのトランザクションと関連イベントを記録しますが、このデータはコントラクトの特定の状態変化と同じではありません。ログは本来、イベント監視およびクエリ機能のために設計されました。イーサリアムのログには通常、ステータス データではなくイベント データが記録されます。イベントは、スマート コントラクトのemitキーワードを通じて生成できます。これらのイベントは、外部アプリケーションによる簡単なクエリのために、トランザクションの実行中にいくつかの重要な情報のみを記録します。これらのイベントには、コントラクトストレージ変数やコントラクトステータスの詳細な変更が含まれていないため、イーサリアムのログを使用して、AO ホログラフィック状態のようなコントラクトステータスを再構築することはできません。
コントラクト状態を再構築するには、すべての履歴トランザクションの再生と状態ツリーの再構築に依存する必要があります。したがって、AO ホログラフィック ステートにはイーサリアムのログよりも多くの情報が保存されるため、本質的にはハードディスク ストレージを犠牲にしてメモリとリアルタイム コンピューティングの負担を軽減する戦略になります。 EIP-4844 で一時データ型「ブロブ」が導入されたとしても、イーサリアムのデータ ストレージ コストは高すぎるため、ロールアップはより多くのデータをイーサリアム メイン チェーンに低コストで送信できるようになります。ただし、 BLOB データはコンセンサス レイヤー ノードに約 18 日間保存された後に削除されます。これは、永続的なログ ストレージと永続的なトレーサビリティの概念に準拠しないため、このパラダイムは短期的には Ethereum には適用されない可能性があります。シャーディングのアップグレード後に採用され、他の公開企業向けにチェーンは、安価で簡単に拡張可能なハードディスク ストレージを可能にし、メモリとコンピューティング リソースを解放するストレージ チェーンである Arweave を継承する可能性があります。
状態のインフレとフォールトトレランスの問題
イーサリアムの設計は、国家インフレという隠れた問題につながります。各フルノードはすべての契約とアカウントの最新ステータスをリアルタイムで維持する必要があるため、ステータス データはブロック データとは異なり、永続的に保存された後は頻繁に読み書きする必要がありません。ステータスデータは何度も読み書きが必要になります。 ステータスデータの量が増えると、読み書きの負担がどんどん重くなります。
完全な状態ツリーを直接保存するイーサリアムと比較して、ホログラフィック状態はログを介したグローバル状態への依存を軽減します。状態ストレージをリアルタイム メモリからハードディスクに移動することにより、ノードはグローバル状態をリアルタイムで更新および維持する必要がなく、オンデマンドで状態を再構築し、状態更新を個別のログ レコードに分割できます。
この設計コンセプトは、いくつかの重要な利点をもたらします。 まず、ログ駆動モデルは、すべての操作がログに基づいて順次実行され、状態の変化の一貫性と検証可能性が確保されるため、状態の競合と競合状態の発生を軽減します。第 2 に、ログ駆動型スマート コントラクトは状態のバックトラッキングを当然サポートしており、AO ホログラフィック ステートはより低いオーバーヘッドで状態の再構築を実現できるため、スマート コントラクトの耐障害性と透明性が高まります。
非同期ブロックチェーン DeFi の難しさ
私が言わなければならないのは、実用的なアプリケーションの観点から見ると、特に DeFi 分野では、AO のような非同期ブロックチェーンはスケーラビリティの点で理論的には優れていますが、非同期ブロックチェーン上のイーサリアムと同様に構成可能性は依然として課題であるということです。特定の時点で一貫した状態に到達するには、複数のアクターを調整する必要があります。そのためには、すべてのトランザクションの順序と依存関係を正確に調整する必要があります。ネットワークの特定のノードでのトランザクションの処理が遅れると、次のような問題が発生する可能性があります。全体的なトランザクション ロジックが間違っているか、ステータスに一貫性がありません。非同期環境での同時実行性の高い DeFi トランザクションは、二重支出や状態の混乱などの問題が非常に発生しやすく、実際にエコロジー DeFi アプリケーションのセキュリティと信頼性に脅威をもたらします。
ログ駆動型スマート コントラクトは、ログ駆動型アーキテクチャを通じて、トランザクションの実行を複数のノードで非同期に処理でき、各トランザクションの変更がログ システムを通じて記録されるため、これらの問題をある程度軽減できます。トランザクションの実行順序はノードごとに異なりますが、最終的にシステムはバックトレース ログを通じて正しい状態を再構築できます。もう 1 つの大きな利点は、障害からの回復です。ログ ドライバーを介して、システムは各トランザクション ステップの詳細情報を記録でき、トランザクションが失敗した場合、ログを利用して以前の正しい状態にロールバックしたり、非同期補正を実行したりできます。このメカニズムは、DeFi システムの高い耐障害性にとって非常に重要であり、特に同時トランザクションが多い環境では、全体の安定性に影響を与えることなく一部のトランザクションが失敗することを許容しますが、ログ追跡を通じて最終的な一貫性を確保します。さらに、サプライチェーン管理シナリオでは、ログ駆動型スマートコントラクトにより、全プロセスの商品トレーサビリティと検証を実現できます。生産、輸送、倉庫などにおける各商品の状態変化がログを通じて記録され、全体を明確に表示できます。製品のライフサイクル。
結論
今日の急速に発展しているブロックチェーン技術分野において、ログ駆動型スマート コントラクト アーキテクチャは、従来のアーキテクチャにおける状態管理とスケーラビリティの問題を解決するための新しい視点を提供します。 AO ホログラフィック アーキテクチャは、状態ストレージをチェーンから切り離し、コントラクト状態の変更を改ざん不可能なインタラクション ログに記録することにより、コンピューティング リソースの消費を削減するだけでなく、システムのスケーラビリティも大幅に向上します。
ログ駆動型スマート コントラクトの中核は、ログ駆動型アプローチを通じて状態の動的な計算と再構築を確実に実行し、それによってグローバル状態のリアルタイム メンテナンスの必要性を軽減することです。この設計により、ノードはオンデマンドでコントラクト状態を再構築できるようになり、状態の拡張によって引き起こされるストレージとコンピューティングの負荷の問題を回避できます。同時に、コントラクト自体はログの順序に従って実行されるため、状態の競合や競合状態が効果的に軽減され、コントラクト実行の一貫性と透明性が向上します。
ブロックチェーン アプリケーションがますます複雑になるにつれて、ログ駆動型スマート コントラクトは将来的に分散コンピューティングの重要なトレンドとなり、非同期ブロックチェーンにおけるコンポーザビリティの課題を解決すると期待される新しいアイデアを開発者に提供します。
