原作者：ヒル
この記事は SevenX 調査チームによるオリジナルであり、コミュニケーションと学習のみを目的としており、投資の参考となるものではありません。引用する必要がある場合は出典を明記してください。
最近、Uniswap v4 がリリースされ、機能はまだ完成していませんが、これまでにない可能性をコミュニティで広く模索していただければ幸いです。 DeFi分野におけるUniswap v4の多大な影響を紹介する記事が多数存在する可能性があることを考慮して、この記事ではUniswap v4が新しいブロックチェーンインフラストラクチャであるコプロセッサ（Coprocessor）にどのような影響を与えるのかを探っていきます。
Uniswap v4 の概要
ホワイトペーパーに記載されているように、Uniswap v4 には 4 つの主な改善点があります。
フック: フックは、プール実行中の指定された時点で開発者定義のロジックを実行する、外部にデプロイされたコントラクトです。これらのフックを通じて、インテグレーターは柔軟でカスタマイズ可能な実行を備えた集中流動性プールを作成できます。
シングルトン: Uniswap v4 は、すべてのプールが単一のコントラクトによって管理されるシングルトン設計パターンを採用しており、プールの導入コストを 99% 削減します。
フラッシュ アカウンティング: 各操作は、デルタとも呼ばれる内部純残高を更新し、ロックの終了時にのみ外部送金を行います。 Lightning Accounting は、アトミックスワップや追加などの複雑なプール操作を簡素化します。
ネイティブ ETH: WETH と ETH の取引ペアをサポートします。
ガス節約のほとんどは最後の 3 つの改善によるものですが、間違いなく最もエキサイティングな新機能はこの記事の冒頭で述べたフックです。
フックにより流動性プールがより複雑かつ強力になります
Uniswap v4 の主な機能強化は、フックのロック解除のプログラム可能性を中心に展開されています。この機能により、流動性プールがより複雑かつ強力になり、これまで以上に柔軟でカスタマイズ可能になります。 Uniswap v3 の集中流動性 (Uniswap v2 からの純アップグレード) と比較して、Uniswap v4 のフックは流動性プールの運用方法について幅広い可能性を提供します。
このリリースは Uniswap v3 への実質的なアップグレードと考えることができますが、実際に実装される場合はそうではない可能性があります。 Uniswap v3 プールは、常に Uniswap v2 プールと比較してアップグレードされます。これは、Uniswap v3 で実行できる「最悪の」アップグレードは、価格帯全体にわたって流動性を「集中」させることであり、これは Uniswap v2 と同じ原理で動作するためです。ただし、Uniswap v4 では、流動性プールのプログラム可能性の程度により、良好な取引または流動性提供エクスペリエンスが得られない可能性があり、バグが発生したり、新たな攻撃ベクトルが出現したりする可能性があります。流動性プールの運用方法には多くの変更が加えられているため、フック機能を利用したい開発者は注意して作業を進める必要があります。彼らは、設計の選択がプールの機能に及ぼす影響と、流動性プロバイダーに対する潜在的なリスクを徹底的に理解する必要があります。
Uniswap v4 でのフックの導入は、ブロックチェーン上でのコードの実行方法に大きな変化をもたらします。従来、ブロックチェーン コードは、あらかじめ決められた順序で実行されます。ただし、フックを使用すると、特定のコードが他のコードより前に実行されるように、より柔軟な実行順序が可能になります。この機能は、複雑な計算を単一のスタックで解決するのではなく、スタックの端にプッシュします。
基本的に、フックを使用すると、Uniswap のネイティブ コントラクトの外でより複雑な計算を実行できるようになります。 Uniswap v2 および Uniswap v3 では、この機能は Uniswap の外部で手動計算によって実装され、他のスマート コントラクトなどの外部アクティベーターによってトリガーされる可能性がありましたが、Uniswap v4 ではフックが流動性プールのスマート コントラクトに直接統合されています。この統合により、以前の手動プロセスと比較して、プロセスの透明性、検証可能性、信頼性が向上します。
フックがもたらすもう 1 つの利点は、スケーラビリティです。 Uniswap は、イノベーションを展開するために新しいスマート コントラクト (流動性の移行が必要) やフォークに依存する必要がなくなりました。フックは新しい機能を直接実装し、古い流動性プールに新しい外観を与えます。
今日の Uniswap v4 流動性プールは、他の dApp の明日になります
私は、Uniswap v4 のような独自のスマート コントラクトの外でコンピューティングを推進する dApp がますます増えていくと予想しています。
現在の Uniswap v4 の仕組みは、任意のステップで流動性プールの実行を分割し、任意の条件を挿入し、Uniswap v4 コントラクト外で計算をトリガーできるようにすることです。これまでのところ、同様の状況はフラッシュ ローンのみです。フラッシュ ローンでは、同じブロック内でローンが返されない場合に実行が再開されます。フラッシュローン契約でも計算が行われるというだけです。
Uniswap v4 の設計は、Uniswap v3 では実装できない、または実装が不十分な多くの利点をもたらします。たとえば、埋め込みオラクルを使用できるようになり、潜在的な攻撃ベクトルをもたらすことが多い外部オラクルへの依存が軽減されます。この組み込み設計により、DeFi プロトコルが機能するための重要な要素である価格情報のセキュリティと信頼性が強化されます。
さらに、以前は外部からトリガーする必要があった自動化を、流動性プールに直接組み込むことができるようになりました。この統合により、安全性への懸念が軽減されるだけでなく、外部トリガーに関連する信頼性の問題も解決されます。さらに、流動性プールをよりスムーズかつ効率的に実行できるようになり、全体的なパフォーマンスとユーザー エクスペリエンスが向上します。
最後に、Uniswap v4 で導入されたフックを通じて、より多様なセキュリティ機能を流動性プールに直接実装できます。これまで流動性プールで採用されていたセキュリティ対策は、主に監査、バグ報奨金、保険の購入でした。 Uniswap v4 を使用すると、開発者はさまざまなフェイルセーフ メカニズムと低流動性警告をプールのスマート コントラクトに直接設計して実装できるようになります。この開発により、プールのセキュリティが強化されるだけでなく、流動性プロバイダーの透明性と制御性も向上します。
従来の携帯電話と比較したスマートフォンの利点は、プログラム可能なことです。スマート コントラクトは長い間、「永続スクリプト」の影に隠れて存在してきました。現在、Uniswap v4 の利点により、流動性プールのスマート コントラクトは新たにプログラム可能なアップグレードを受け、より「スマート」になりました。 Nokia から iPhone にアップグレードする機会があるのに、すべての dApp がこの方向にアップグレードしたがらない理由がわかりません。 Nokia は iPhone よりも信頼性が高いため、現状を維持したいと考える一部のスマート コントラクトは理解できますが、私は dApps が将来どこへ向かうのかについて話しています。
dApp は独自の「フック」を使用したいため、スケーリングの問題が発生します
これを他のすべての dApps に適用すると、トリガーする条件を挿入して、生のトランザクション シーケンスの間に任意の計算を挿入できることを想像してください。
これは MEV の仕組みのように聞こえますが、MEV は dApp 開発者にとってオープンな設計空間ではありません。それは、せいぜい外部の MEV 保護を求め、最良の結果を期待しながら、未知の暗い森へのハイキングに似ていました。
Uniswap v4 の柔軟性により、新世代の dApps (または既存の dApps からのアップグレード) が同様の哲学を採用し、実行シーケンスがよりプログラム可能になると考えられます。これらの dApp は通常、1 つのチェーン (L1 または L2) のみにデプロイされるため、ほとんどの状態変更はそのチェーン上で実行されることが予想されます。
dApp の状態変更中に挿入される追加の計算は、チェーン上で実行するには複雑すぎて面倒な場合があります。すぐにガス制限を超えてしまう可能性もあれば、まったく不可能になる可能性もあります。さらに、特にセキュリティと構成可能性の観点から、多くの課題が生じます。
すべての計算が同じように作成されるわけではありません。これは、dApps がオラクルや自動化されたネットワークなどの外部プロトコルに依存していることからもわかります。ただし、この依存はセキュリティ上のリスクを引き起こす可能性があります。
問題を要約すると、すべての計算を単一のチェーン上で状態変化するスマート コントラクトの実行に統合することは、最適とは程遠いです。
解決策のヒント: 現実世界ではすでに解決されています
新世代の dApps (おそらく Uniswap v4 に大きく影響を受けています) によって引き起こされるこの問題を解決するには、問題の核心であるこの単一のチェーンを掘り下げる必要があります。ブロックチェーンは分散コンピューターのように動作し、単一の CPU を使用してすべてのタスクを処理します。 PC では、最新の CPU がこの問題の解決に大きく進歩しました。
コンピューターがシングルコアのモノリシック CPU から、複数の効率コア、パフォーマンス コア、GPU、NPU で構成されるモジュラー設計に移行したのと同じです。
dApp コンピューティングも同様の方法で拡張できます。柔軟性、最適性、セキュリティ、スケーラビリティ、およびアップグレード可能性は、プロセッサを特化し、それらの取り組みを組み合わせて、メイン プロセッサから一部の計算をアウトソーシングすることで実現できます。
現実的な解決策
実際には、コプロセッサには次の 2 種類しかありません。
外部コプロセッサ
組み込みコプロセッサ
外部コプロセッサ
外部コプロセッサはクラウド GPU に似ており、使いやすく強力ですが、CPU と GPU の通信の間に追加のネットワーク遅延が発生します。さらに、GPU を最終的に制御するわけではないため、GPU が正しく機能していることを信頼する必要があります。
Uniswap v4を例に挙げると、過去5分間のTWAP中に一部のETHとUSDCが流動性プールに追加されたと仮定し、TWAP計算がAxiomで完了した場合、Uniswap v4は基本的にイーサリアムをメインプロセッサとして使用し、Axiomを協力者として使用します。 .プロセッサー。
Axiom
Axiom はイーサリアムの ZK コプロセッサであり、すべてのオンチェーン データへのトラストレス アクセスと、データに対して任意の式の計算を実行する機能をスマート コントラクトに提供します。
開発者は、Axiom にクエリを実行し、スマート コントラクトでトラストレスな方法でオンチェーンのゼロ知識 (ZK) 検証結果を使用できます。クエリを完了するために、Axiom は 3 つの手順を実行します。
読み取り: Axiom はゼロ知識証明を使用して、過去のイーサリアム ブロックのブロック ヘッダー、ステータス、トランザクション、およびレシートの読み取りデータをトラストレスに修正します。すべての Ethereum オンチェーン データはこれらの形式のいずれかでエンコードされます。これは、Axiom がアーカイブ ノードにアクセス可能なあらゆるデータにアクセスできることを意味します。
計算: データが取得されると、Axiom は実績のある計算プリミティブをそのデータに対して適用します。これには、基本分析 (合計、カウント、最大、最小) から暗号化 (署名検証、キー集約) および機械学習 (デシジョン ツリー、線形回帰、ニューラル ネットワーク推論) に至るまでの操作が含まれます。すべての計算の妥当性はゼロ知識証明で検証されます。
検証: Axiom には、各クエリの結果に対するゼロ知識妥当性証明が付属しており、(1) 入力データがチェーンから正しくフェッチされたこと、および (2) 計算が正しく適用されたことを証明します。このゼロ知識証明は Axiom スマート コントラクトのオンチェーンで検証され、最終結果はトラストレスな方法ですべてのダウンストリーム スマート コントラクトで利用できるようになります。
ワープコントラクト(レッドストーン経由)
ワープ コントラクトは最も一般的な SmartWeave 実装であり、Arweave 上で信頼性が高く、高速で実稼働対応のスマート コントラクト プラットフォーム/エンジンを作成するように設計されたアーキテクチャです。本質的に、SmartWeave は Arweave トランザクションの順序付けられた配列であり、Arweave にはトランザクション ブロック包含手数料市場が存在しないことによるメリットがあります。これらの独自のプロパティにより、ストレージ コストを超える追加コストなしで、無制限のトランザクション データが可能になります。
SmartWeave は、「遅延評価」と呼ばれる独自のアプローチを使用して、スマート コントラクト コードを実行する責任をネットワーク ノードからスマート コントラクトのユーザーに移します。これは基本的に、トランザクション検証の計算が必要になるまで延期され、ネットワーク ノードの作業負荷が軽減され、トランザクションをより効率的に処理できることを意味します。このアプローチにより、ユーザーは追加料金を発生させることなく必要なだけ計算を実行でき、他のスマート コントラクト システムでは不可能な機能が提供されます。明らかに、ユーザーの CPU 上で何千ものインタラクションが行われるコントラクトを評価しようとしても、最終的には無駄です。この課題を克服するために、Warp の DRE などの抽象化レイヤーが開発されました。この抽象化レイヤーは、契約の計算を処理するバリデーターの分散ネットワークで構成され、最終的に応答時間が大幅に短縮され、ユーザー エクスペリエンスが向上します。
さらに、SmartWeave のオープンな設計により、開発者は任意のプログラミング言語でロジックを作成でき、硬直的なことが多い Solidity コード ベースに新しい代替手段を提供します。シームレスな SmartWeave 統合は、両方のテクノロジーの利点を活用して、特定の高コストまたは高スループットの操作を Warp に委任することにより、EVM チェーン上に構築された既存のソーシャル グラフ プロトコルを強化します。
Hyper Oracle
Hyper Oracle は、ブロックチェーン専用に設計された ZK オラクル ネットワークです。現在、ZK Oracle ネットワークはイーサリアム ブロックチェーン上でのみ動作します。 zkPoS を使用してブロックチェーンの各ブロックからデータ ソースとしてデータを取得し、同時に zkWASM 上で実行されるプログラム可能な zkGraph を使用してデータを処理します。これはすべてトラストレスで安全な方法です。
開発者は、JavaScript を使用してカスタムのオフチェーン計算を定義し、これらの計算を Hyper Oracle ネットワークにデプロイし、Hyper Oracle Meta Apps を利用してスマート コントラクトのインデックス作成と自動化を行うことができます。
Hyper Oracle のインデックス作成と自動化メタ アプリは完全にカスタマイズ可能で柔軟性があります。あらゆる計算を定義でき、すべての計算 (機械学習の計算も含む) は、生成されたゼロ知識証明によって保護されます。
イーサリアム ブロックチェーンは ZK オラクルのオリジナルのオンチェーン データ ソースですが、将来的にはどのネットワークでも使用できるようになります。
Hyper Oracle ZK Oracle Node は、zkPoS と zkWASM という 2 つの主要コンポーネントで構成されます。
- zkPoS は、ゼロ知識を使用してイーサリアムのコンセンサスを証明し、イーサリアム ブロックチェーンのブロック ヘッダーとデータ ルートを取得します。ゼロ知識証明生成プロセスは、証明者の分散ネットワークにアウトソーシングできます。 zkPoS は、zkWASM の外側ループとして機能します。
- zkPoS は、ブロック ヘッダーとデータ ルートを zkWASM に提供します。 zkWASM は、このデータを zkGraph を実行するための基本入力として使用します。
-zkWASM カスタム データ マップまたは zkGraph で定義されたその他の計算を実行し、これらの操作のゼロ知識証明を生成します。 ZK Oracle ノードのオペレーターは、実行する zkGraph の数 (1 つからデプロイされたすべての zkGraph まで) を選択できます。ゼロ知識証明生成プロセスは、証明者の分散ネットワークにアウトソーシングできます。
ZK オラクルはオフチェーン データを出力し、開発者は Hyper Oracle Meta Apps (後続の章で説明します) を通じてこのオフチェーン データを使用できます。データには、その有効性と計算を証明するゼロ知識証明も付属しています。
その他の注目すべき項目
この方法を選択した場合、外部コプロセッサとして使用できるプロジェクトもあります。ただ、これらのプロジェクトはブロックチェーン インフラストラクチャの他の垂直領域と重複しており、コプロセッサとして個別に分類されていません。
RiscZero: dApp が RiscZero を使用してチェーン上のエージェントの機械学習タスクを計算し、その結果を StarkNet 上のゲーム コントラクトに提供する場合、StarkNet をメイン プロセッサとして使用し、RiscZero をコプロセッサとして使用します。
IronMill: dApp が IronMill で zk ループを実行するが、スマート コントラクトを Ethereum にデプロイする場合、Ethereum をメイン プロセッサとして使用し、IronMill をコプロセッサとして使用します。
外部コプロセッサの潜在的な使用例
ガバナンスと投票: オンチェーンの履歴データは、分散型自律組織 (DAO) が各メンバーが持つ投票権の数を記録するのに役立ちます。これは投票に不可欠です。このデータがないとメンバーは投票プロセスに参加できない可能性があり、ガバナンスに支障をきたす可能性があります。
引受業務: オンチェーンの履歴データは、資産管理者が利益を超えて運用者のパフォーマンスを評価するのに役立ちます。彼らは、自分たちが負っているリスクのレベルと経験しているドローダウンの種類を確認できるため、報酬や潜在的な報酬が減額される場合に、より情報に基づいた意思決定を行うのに役立ちます。
分散型取引所: チェーン上の過去の価格データは、分散型取引所が過去の傾向やパターンに基づいて取引するのに役立ち、ユーザーにより高い利益をもたらす可能性があります。さらに、過去の取引データは、取引所のアルゴリズムとユーザー エクスペリエンスの向上に役立ちます。
保険商品: 保険会社は、オンチェーンの履歴データを使用してリスクを評価し、さまざまな種類の保険の保険料を設定できます。たとえば、DeFiプロジェクトの保険料を設定する際、保険会社は過去のオンチェーンデータを調べる場合があります。
クライアント dApp は、ブロック N でトリガーされたときに外部コプロセッサーのスマート コントラクトを呼び出す必要があるため、上記のユースケースはすべて非同期であることに注意してください。コプロセッサが計算結果を返すとき、その結果は少なくとも次のブロック (つまり N+1) で何らかの形式で受け入れられるか検証される必要があります。このようにして、少なくとも次のトリガー ブロックが取得され、共同処理の結果が利用されます。このモデルはまさにクラウド GPU のようなモデルです。機械学習モデルを適切に実行できますが、遅延のせいでペースの速いゲームを快適にプレイすることはできません。
組み込みコプロセッサ
組み込みコプロセッサは、PC マザーボード上の GPU に似ており、CPU の隣にあります。 GPU から CPU への通信遅延は非常に小さいです。また、GPU は完全にユーザーの制御下にあるため、改ざんされていないことを確信できます。ただ、クラウド GPU と同じ速度で機械学習を実行するにはコストがかかります。
引き続き Uniswap v4 を例に挙げます。 TWAP の最後の 5 分間に Artela にデプロイされた流動性プールに一部の ETH と USDC が追加されたと仮定すると、プールが Artela 上の EVM にデプロイされ、TWAP 計算が Aretla 上の WASM で行われる場合、プールは基本的にArtela の EVM をメインプロセッサとして、Artela の WASM をコプロセッサとして使用します。
Artela
Artela は、Tendermint BFT を使用して構築された L1 です。オンチェーンのカスタム関数を実装するための実行レイヤーの動的な拡張をサポートするフレームワークを提供します。各 Artela フル ノードは 2 つの仮想マシンを同時に実行します。
EVM: スマート コントラクトの状態を保存および更新するメイン プロセッサ。
WASM: アスペクト状態を保存および更新するコプロセッサ。
アスペクトは、開発者がスマート コントラクトの状態に触れずに実行したい任意の計算を表します。これは、スマート コントラクトのネイティブな構成機能を超えたカスタム機能を dApps に提供する Rust スクリプトと考えてください。
これを理解するのが難しい場合は、次の 2 つの観点から見てみるとよいでしょう。
ブロックチェーンアーキテクチャの観点から
- アスペクトは新しい実行層です。
- Artela では、ブロックチェーンは 2 つの実行レイヤー (スマート コントラクト用とその他の計算用) を同時に実行します。
- この新しい実行層は、新しい信頼の前提を導入しないため、ブロックチェーン自体のセキュリティには影響しません。どちらの VM も、同じコンセンサスを実行する同じノードのセットによって保護されます。
アプリケーションのランタイムの観点から見ると
- アスペクトは、スマート コントラクトと連携して動作するプログラム可能なモジュールであり、カスタム機能の追加と独立した実行をサポートします。
- 単一のスマート コントラクトよりもいくつかの点で利点があります。
-- 非侵入型: スマート コントラクトのコードを変更せずに、コントラクトの実行の前後に介入できます。
-- 同期実行: トランザクション ライフ サイクル全体を通じてフック ロジックをサポートし、洗練されたカスタマイズを可能にします。
-- グローバル ステータスとベース レイヤ構成に直接アクセスし、システム レベルの機能をサポートします。
-- 柔軟なブロック スペース: より高いトランザクション スループット要件を持つ dApp に、プロトコルで保証された独立したブロック スペースを提供します。
-- 静的プリコンパイルと比較して、dApps をサポートして、実行時に動的でモジュール式のアップグレードを実現し、安定性と柔軟性のバランスをとります。
この組み込みコプロセッサの導入により、Artela は画期的な進歩を遂げました。現在では、任意の拡張モジュール アスペクトをスマート コントラクトと同じトランザクションを通じて実行できるようになりました。開発者はスマート コントラクトをアスペクトにバインドし、スマート コントラクトを呼び出すすべてのトランザクションをアスペクトで処理させることができます。 。
さらに、スマート コントラクトと同様に、アスペクトはチェーン上にデータを保存するため、スマート コントラクトとアスペクトが相互にグローバル状態を読み取ることができます。
これら 2 つの機能により、スマート コントラクトとアスペクト間の構成可能性と相互運用性が大幅に向上します。
アスペクト機能:
スマート コントラクトと比較して、Aspects が提供する機能は主に取引前および取引後の実行に焦点を当てています。アスペクトはスマート コントラクトに代わるものではありませんが、スマート コントラクトを補完します。スマート コントラクトと比較して、アスペクトはアプリケーションに次のような独自の機能を提供します。
- 信頼できるトランザクションを上下逆のブロックに自動的に挿入します (スケジュールされたタスクなど)。
- トランザクションによって引き起こされた状態データの変更の取り消し (承認された契約トランザクションのみを取り消すことができます)。
- 静的環境変数を読み取ります。
- 一時的な実行状態を他のアスペクトの下流に渡します。
- 上流のアスペクトから渡された一時的な実行状態を読み取ります。
- 動的かつモジュール式のアップグレード可能。
アスペクトとスマートコントラクトの違い:
アスペクトとスマートコントラクトの違いは次のとおりです。
- スマート コントラクトはコードを含むアカウントですが、アスペクトはブロックチェーンのネイティブ拡張です。
- アスペクトはトランザクションおよびブロックのライフサイクルのさまざまなポイントで実行できますが、スマート コントラクトは固定ポイントでのみ実行されます。
- スマート コントラクトは、独自の状態とブロックの限定されたコンテキストにアクセスできますが、アスペクトはグローバルな処理コンテキストやシステム レベルの API と対話できます。
- Aspect の実行環境は、ネイティブに近い速度を実現するように設計されています。
アスペクトは単なるコード ロジックの一部であり、アカウントとは何の関係もないため、次のことはできません。
- 契約状況データの書き込み、変更、または削除。
- 新しい契約を作成します。
- ネイティブ トークンを転送、破棄、または保持します。
これらの側面により、Artela はスマート コントラクトの機能を拡張し、より包括的でカスタマイズ可能な開発環境を提供できる独自のプラットフォームとなっています。
*厳密に言えば、上記のアスペクトは「組み込み」アスペクトとも呼ばれ、Artela Chain フルノードによって実行される組み込みコプロセッサであることに注意してください。 dApps は、外部コプロセッサによって実行される独自の異種アスペクトをデプロイすることもできます。これらの外部コプロセッサは、外部ネットワーク上で、または別のコンセンサスのノードのサブセットによって実行できます。 dApp 開発者は、安全かつ賢明である限り、実際にそれを使ってやりたいことを何でもできるため、より柔軟です。まだ調査中であり、具体的な詳細はまだ発表されていない。
組み込みコプロセッサの潜在的な使用例
複雑なゲーム理論メカニズムなど、新しい DeFi プロジェクトに含まれる複雑な計算には、組み込みコプロセッサーのより柔軟で反復的なオンザフライのコンピューティング能力が必要になる場合があります。
さまざまな dApp に対するより柔軟なアクセス制御メカニズム。現在、アクセス制御は通常、スマート コントラクトのアクセス許可に基づくブラックリストまたはホワイトリストに限定されています。組み込みコプロセッサにより、即時かつ詳細なレベルのアクセス制御が可能になります。
フル チェーン ゲーム (FOCG) の特定の複雑な機能。 FOCG は長い間 EVM によって制限されてきました。 EVM が NFT やトークンの転送などの単純な機能を保持し、その他のロジックや状態の更新がコプロセッサによって計算されれば、より単純になる可能性があります。
セキュリティメカニズム。 dApps は、独自のアクティブなセキュリティ監視とフェールセーフ メカニズムを導入できます。たとえば、流動性プールは 10 分ごとに 5% を超える出金をブロックできます。コプロセッサが引き出しの 1 つを検出した場合、スマート コントラクトは停止し、特定の動的な価格範囲内で緊急流動性を注入するなど、何らかの警告メカニズムをトリガーできます。
結論
dApps が大きくなり、肥大化し、過度に複雑になるのは避けられないため、コプロセッサの人気が高まることも避けられません。それが普及するのは時間の問題です。
外部コプロセッサを実行すると、以前にどのチェーンにいたとしても、dApp はコンフォートゾーンに留まることができます。ただし、展開可能な実行環境を探している新しい dApp 開発者にとって、組み込みコプロセッサは PC 上の GPU のようなものです。高性能 PC を名乗るなら、それなりの GPU を搭載している必要があります。
残念ながら、上記のプロジェクトはまだメインネット上で起動されていません。実際にベンチマークを行って、どのプロジェクトがどのユースケースに適しているかを示すことはできません。ただし、否定できないことが 1 つあります。それは、テクノロジーが上昇スパイラルにあるということです。堂々巡りのように見えるかもしれませんが、歴史がテクノロジーが実際に進化することを傍から見ていることを忘れないでください。
スケーラビリティ トライアングル万歳、コプロセッサ万歳。
