SevenX Ventures: Uniswap V4後、協処理器にはどれほどの応用スペースがあるのか？

著者：Hill

最近、Uniswap v4がリリースされました。機能はまだ完全ではありませんが、私たちはコミュニティが前例のない可能性を広く探求できることを期待しています。Uniswap v4がDeFi分野に与える巨大な影響を紹介する多くの記事が出ることが予想されるため、本稿ではUniswap v4が新しいブロックチェーンインフラストラクチャであるコプロセッサ（Coprocessor）をどのように刺激するかを探ります。

Uniswap v4の概要

そのホワイトペーパーに記載されているように、Uniswap v4には主に4つの改善点があります：

• フック（Hook）：フックは外部デプロイ型のコントラクトで、プールの実行中の指定されたポイントで開発者が定義したロジックを実行します。これらのフックを通じて、統合者は柔軟でカスタマイズ可能な集中流動性プールを作成できます。

• シングルトン（Singleton）：Uniswap v4はシングルトンデザインパターンを採用しており、すべてのプールが単一のコントラクトによって管理されるため、プールのデプロイコストが99%削減されます。

• フラッシュアカウンティング（Flash Accounting）：各操作は内部の純残高、すなわちインクリメントを更新し、ロックが終了したときにのみ外部の振替が行われます。フラッシュアカウンティングは、原子交換や追加などの複雑なプール操作を簡素化します。

• ネイティブETH：WETHとETHの取引ペアをサポートします。

節約されたガス代の大部分は後の3つの改善によるものですが、間違いなく最もエキサイティングな新機能は、冒頭で言及した新しいハイライトであるフックです。

フックによって流動性プールがより複雑で強力に

Uniswap v4の主な強化機能は、フックによって解放されるプログラマビリティにあります。この機能により、流動性プールはより複雑で強力になり、これまで以上に柔軟でカスタマイズ可能になります。Uniswap v3の集中流動性（Uniswap v2のネットアップグレード）と比較して、Uniswap v4のフックは流動性プールの運用方法に対してより広範な可能性を提供します。

このバージョンはUniswap v3のネットアップグレードと見なすことができますが、実際の実装ではそうではないかもしれません。Uniswap v2プールと比較して、Uniswap v3プールは常にアップグレードの一種です。なぜなら、Uniswap v3で実行できる「最悪の」アップグレードは流動性を「集中」させることであり、その動作はUniswap v2と同じだからです。しかし、Uniswap v4では、流動性プールのプログラマビリティが良好な取引や流動性提供体験をもたらさない可能性があり、エラーが発生したり、新しい攻撃の媒介が生じる可能性があります。流動性プールの運用方法が多くの変更を受けているため、フックの特性を利用しようとする開発者は慎重に行動する必要があります。彼らは設計選択がプールの機能や流動性提供者の潜在的リスクに与える影響を十分に理解する必要があります。

Uniswap v4にフックが導入されたことは、コードがブロックチェーン上で実行される方法に重大な変化をもたらしました。従来、ブロックチェーンコードは予め定められた順序で実行されます。しかし、フックはより柔軟な実行順序を可能にし、特定のコードが他のコードの前に実行されることを保証します。この機能は、複雑な計算をスタックの端に押しやり、単一のスタックで解決するのではなくなります。

本質的に、フックはUniswapのネイティブコントラクトの外でより複雑な計算を実行することをサポートします。Uniswap v2やUniswap v3では、Uniswapの外で手動計算を行い、他のスマートコントラクトなどの外部トリガーによって起動することが可能でしたが、Uniswap v4ではフックが流動性プールのスマートコントラクトに直接統合されました。この統合により、以前の手動プロセスと比較して、プロセスがより透明で検証可能かつ信頼不要になります。

フックがもたらすもう一つの利点はスケーラビリティです。Uniswapはもはや新しいスマートコントラクト（流動性移行が必要）やフォークに依存する必要がなくなりました。フックは新機能を直接実現でき、古い流動性プールを刷新します。

Uniswap v4の流動性プールの今日が、他のdAppの明日

私の予想では、ますます多くのdAppがUniswap v4のように計算を自分のスマートコントラクトの外に押し出すことになるでしょう。

Uniswap v4の現在の運用方法は、流動性プールの実行を任意のステップで分割でき、任意の条件を挿入し、Uniswap v4コントラクトの外で計算をトリガーできることを許可します。これまでのところ、唯一の類似の状況はフラッシュローンであり、同じブロック内で返済されない場合、実行が復元されます。ただし、計算は依然としてフラッシュローンコントラクト内で行われます。

Uniswap v4のデザインは、Uniswap v3では実現できなかった、または効果が不十分だった多くの利点をもたらしました。たとえば、埋め込み型オラクルを使用することで、外部オラクルに依存することによる潜在的な攻撃の媒介を減らすことができます。この埋め込み型デザインは、価格情報の安全性と信頼性を強化し、DeFiプロトコルが機能するための重要な要素となります。

さらに、以前は外部でトリガーされる必要があった自動化が、現在では流動性プールに直接埋め込むことができます。この統合は、安全性の問題を軽減するだけでなく、外部トリガーに関連する信頼性の問題も解決します。また、流動性プールがよりスムーズかつ効率的に運営できるようになり、全体的なパフォーマンスとユーザー体験が向上します。

最後に、Uniswap v4に導入されたフックにより、流動性プール内でより多様な安全機能を直接実現できます。過去には、流動性プールが採用していた安全対策は主に監査、バグ報奨金、保険の購入でした。Uniswap v4を利用することで、開発者は今やプールのスマートコントラクト内でさまざまな失敗安全メカニズムや低流動性警告を設計・実装できます。この進展は、プールの安全性を強化するだけでなく、流動性提供者により高い透明性とコントロールを提供します。

従来の携帯電話と比較して、スマートフォンの利点はプログラマビリティにあります。スマートコントラクトは長い間「持続的スクリプト」の影に隠れていました。今や、Uniswap v4の利点を活用することで、流動性プールのスマートコントラクトは新たなプログラマブルなアップグレードを受け、「よりスマート」になりました。ノキアからiPhoneにアップグレードする機会があるのに、なぜすべてのdAppがこの方向にアップグレードしたいと思わないのか理解できません。ノキアがiPhoneよりも信頼性が高いので、いくつかのスマートコントラクトが現状を維持したいと思うのは理解できますが、私が言っているのはdAppの未来の発展方向です。

dAppは自分の「フック」を使用したいと考えていますが、そこには拡張の問題があります。

すべての他のdAppに適用することを想像してみてください。私たちはその中にトリガーされる条件を挿入し、元のトランザクションシーケンスの間に任意の計算を挿入できます。

これはMEVの動作原理のように聞こえますが、MEVはdApp開発者向けのオープンなデザインスペースではありません。これはむしろ未知の暗い森を歩くようなもので、せいぜい外部MEVの保護を求めることになりますが、最良の結果を期待するしかありません。

Uniswap v4の柔軟性が新世代のdApp（または既存のdAppのアップグレード）に類似の理念を採用させ、実行シーケンスのプログラマビリティを高めることを促進したと仮定します。これらのdAppは通常、単一のチェーン（L1またはL2）にのみデプロイされるため、私たちはほとんどの状態変更がそのチェーン上で実行されると予想しています。

• dAppの状態変更プロセスに挿入された追加の計算は、あまりにも複雑で煩雑であり、そのチェーン上で実行できない可能性があります。私たちはすぐにガス制限を超えるか、まったく実現できないかもしれません。また、特に安全性や相互運用性の面で多くの課題をもたらすでしょう。

• すべての計算が平等ではありません。dAppがオラクルや自動化ネットワークなどの外部プロトコルに依存していることがその証拠です。しかし、この依存は安全リスクをもたらす可能性があります。

問題をまとめると、すべての計算を単一のチェーン上の変更状態のスマートコントラクト実行に統合することは、最良の方法ではありません。

解決策のヒント：現実世界で既に解決されています

新世代のdAppがもたらすこの問題を解決するために（おそらくUniswap v4に大きく触発されて）、私たちは問題の核心に深く掘り下げる必要があります：この単一のチェーン。ブロックチェーンの動作は、分散型コンピュータのように、すべてのタスクを1つのCPUで処理します。個人用コンピュータでは、現代のCPUはこの問題を解決する上で大きな進歩を遂げています。

コンピュータは、単核の単一チップCPUから、複数の効率的なコア、性能コア、GPU、NPUで構成されたモジュール設計に移行しました。

dAppの計算も同様の方法でスケールアップできます。プロセッサを専門化し、その成果を組み合わせることで、一部の計算をメインプロセッサの外にアウトソーシングすることで、柔軟性、最適性、安全性、スケーラビリティ、アップグレード性を実現できます。

実際の解決策

実際には、協処理器には2つのタイプしかありません：

• 外部協処理器

• 埋め込み協処理器

外部協処理器

外部協処理器は、クラウドGPUに似ており、使いやすく強力ですが、CPUとGPU間の通信には追加のネットワーク遅延があります。また、GPUは最終的にはあなたの制御下にはないため、正しく作業を行っていると信じる必要があります。

Uniswap v4の例を挙げると、最後の5分間のTWAP時にETHとUSDCを流動性プールに追加した場合、TWAP計算がAxiomで完了したとすると、Uniswap v4は基本的にEthereumをメインプロセッサとして、Axiomを協処理器として使用しています。

Axiom

AxiomはEthereumのZK協処理器であり、スマートコントラクトに対してすべてのオンチェーンデータへの信頼不要のアクセスと、データに対する任意の式計算の能力を提供します。

開発者はAxiomにクエリを行い、そのスマートコントラクト内で信頼不要の方法でゼロ知識（ZK）で検証された結果を使用できます。クエリを完了するために、Axiomは3つのステップを実行します：

• 読み取り：Axiomはゼロ知識証明を使用して、信頼不要の方法で任意の過去のEthereumブロックのブロックヘッダー、状態、トランザクション、受領書の読み取りデータを修正します。すべてのEthereumオンチェーンデータは、いずれかの形式でエンコードされているため、Axiomはアーカイブノードがアクセスできる任意のデータにアクセスできます。

• 計算：データを取得した後、Axiomはそれに基づいて検証された計算基元を適用します。これには、基本的な分析（合計、カウント、最大値、最小値）から暗号（署名検証、鍵の集約）、機械学習（決定木、線形回帰、ニューラルネットワーク推論）までのさまざまな操作が含まれます。各計算の有効性はゼロ知識証明で検証されます。

• 検証：Axiomは各クエリの結果にゼロ知識の有効性証明を添付し、（1）オンチェーンから正しく入力データが取得されたことを証明し、（2）計算が正しく適用されたことを証明します。このゼロ知識証明はAxiomスマートコントラクト内でオンチェーン検証され、最終的な結果はすべての下流スマートコントラクトで信頼不要の方法で使用されます。

Warpコントラクト（RedStone経由）

Warpコントラクトは最も一般的なSmartWeaveの実装であり、このアーキテクチャはArweave上で信頼性が高く迅速な生産準備型スマートコントラクトプラットフォーム/エンジンを作成することを目的としています。実質的に、SmartWeaveはArweaveトランザクションの順序付けられた配列であり、Arweave上のトランザクションブロックの収録（Block Inclusion）費用市場の欠如から恩恵を受けています。これらの独特の属性により、無限のトランザクションデータが可能になり、ストレージコストを除いて追加の費用は発生しません。

SmartWeaveは「遅延評価」と呼ばれる独特のアプローチを採用しており、スマートコントラクトコードの実行責任をネットワークノードからスマートコントラクトのユーザーに移転します。本質的に、これはトランザクション検証の計算が必要なときまで延期され、ネットワークノードの作業負荷が軽減され、トランザクションをより効率的に処理できることを意味します。この方法により、ユーザーは必要に応じて可能な限り多くの計算を実行でき、追加の費用が発生しないため、他のスマートコントラクトシステムでは実現できない機能を提供します。明らかに、数千回の相互作用を持つ契約をユーザーのCPU上で評価しようとするのは無駄です。この課題を克服するために、WarpのDREのような抽象層が開発されました。この抽象層は、契約計算を処理する分散検証者ネットワークで構成され、最終的に応答時間を大幅に短縮し、ユーザー体験を改善します。

さらに、SmartWeaveのオープンなデザインにより、開発者は任意のプログラミング言語でロジックを記述でき、しばしば硬直したSolidityコードベースに代わる新しい選択肢を提供します。高コストまたは高スループットの操作をWarpに委任することで、シームレスなSmartWeave統合は、EVMチェーンに基づいて構築された既存のソーシャルグラフプロトコルを強化し、これら2つの技術の利点を最大限に活用します。

Hyper Oracle

Hyper Oracleはブロックチェーン専用に設計されたZKオラクルネットワークです。現在、ZKオラクルネットワークはEthereumブロックチェーンでのみ運用されています。これは、zkPoSを使用してブロックチェーンの各ブロックからデータを取得し、それをデータソースとして使用し、zkWASM上で実行されるプログラム可能なzkGraphがデータを処理するすべての操作を信頼不要かつ安全な方法で行います。

開発者はJavaScriptを使用してカスタムオフチェーン計算を定義し、これらの計算をHyper Oracleネットワークにデプロイし、Hyper Oracle Meta Appsを利用してスマートコントラクトをインデックス化および自動化できます。

Hyper Oracleのインデックス化および自動化Meta Appsは完全にカスタマイズ可能で非常に柔軟です。任意の計算を定義でき、すべての計算（機械学習計算を含む）は生成されたゼロ知識証明によって保護されます。

• EthereumブロックチェーンはZKオラクルの元のオンチェーンデータソースですが、将来的には任意のネットワークが使用できます。

• Hyper Oracle ZKオラクルノードは2つの主要なコンポーネントを含みます：zkPoSとzkWASM。

• zkPoSは、ゼロ知識を使用してEthereumのコンセンサスを証明し、Ethereumブロックチェーンのブロックヘッダーとデータルートを取得します。ゼロ知識証明生成プロセスは、分散型の証明者ネットワークにアウトソーシングできます。zkPoSはzkWASMの外部ループとして機能します。

• zkPoSはブロックヘッダーとデータルートをzkWASMに提供します。zkWASMはこのデータをzkGraphを実行するための基本入力として使用します。

• zkWASMはカスタムデータマッピングまたはzkGraphで定義された任意の計算を実行し、これらの操作のゼロ知識証明を生成します。ZKオラクルノードのオペレーターは、実行したい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に非常に似ています。あなたの機械学習モデルをうまく実行できますが、遅延のために、快適に高速ゲームをプレイすることはできません。

埋め込み協処理器

埋め込み協処理器は、個人用コンピュータのマザーボード上のGPUに似ており、CPUの隣に位置しています。GPUとCPUの通信遅延は非常に小さく、GPUは完全にあなたの制御下にあるため、改ざんされていないことを非常に確信できます。ただし、クラウドGPUのように迅速に機械学習を実行するには、高額なコストがかかります。

Uniswap v4の例を挙げると、最後の5分間のTWAP時にETHとUSDCをArtela上にデプロイされた流動性プールに追加した場合、そのプールがArtela上のEVMにデプロイされ、TWAP計算がArtela上のWASMで完了した場合、そのプールは基本的にArtelaのEVMをメインプロセッサとして、ArtelaのWASMを協処理器として使用しています。

Artela

ArtelaはTendermint BFTを使用して構築されたL1です。これは、オンチェーンのカスタム機能を実現するために、任意の実行レイヤーの動的拡張をサポートするフレームワークを提供します。各Artelaフルノードは同時に2つの仮想マシンを実行します。

• EVM：スマートコントラクトの状態を保存および更新するメインプロセッサ。

• WASM：Aspectの状態を保存および更新する協処理器。

Aspectsは、開発者がスマートコントラクトの状態に触れることなく実行したい任意の計算を表します。これは、dAppにスマートコントラクトのネイティブな相互運用性を超えるカスタム機能を提供するRustスクリプトのように考えることができます。

これが理解しにくい場合は、以下の2つの観点から見ることを試みてください：

• ブロックチェーンアーキテクチャの観点から

• Aspectは新しい実行レイヤーです。

• Artelaでは、ブロックチェーンが同時に2つの実行レイヤーを実行します------1つはスマートコントラクト用、もう1つは他の計算用です。

• この新しい実行レイヤーは新しい信頼仮定を導入せず、ブロックチェーン自体の安全性に影響を与えません。2つの仮想マシンは、同じコンセンサスを実行する同じノードグループによって保護されています。

• アプリケーション実行時の観点から

• Aspectsはスマートコントラクトと協調して動作するプログラム可能なモジュールであり、カスタム機能の追加と独立した実行をサポートします。

• いくつかの点で、単一のスマートコントラクトよりも優れています：

  -- 非侵入性：スマートコントラクトコードを変更することなく、契約の実行前後に介入できます。

  -- 同期実行：トランザクションライフサイクル全体にわたってフックロジックをサポートし、精緻なカスタマイズを可能にします。

  -- グローバル状態と基盤レイヤー設定への直接アクセスをサポートし、システムレベルの機能を提供します。

  -- 弾力的なブロックスペース：トランザクションスループット要求が高いdAppに対して、プロトコルで保証された独立したブロックスペースを提供します。

  -- 静的なプレコンパイルと比較して、dAppが実行時に動的かつモジュール化されたアップグレードを実現し、安定性と柔軟性のバランスを取ることをサポートします。

この埋め込み協処理器を導入することで、Artelaはエキサイティングなブレークスルーを達成しました。現在、任意の拡張モジュールであるAspectsは、スマートコントラクトと同じトランザクションで実行できます。開発者はスマートコントラクトをAspectsにバインドし、スマートコントラクトを呼び出すすべてのトランザクションがAspectsによって処理されるようにできます。

さらに、スマートコントラクトと同様に、Aspectsはオンチェーンでデータを保存し、スマートコントラクトとAspectsが互いのグローバル状態を読み取ることをサポートします。

これらの2つの特性は、スマートコントラクトとAspects間の相互運用性と相互作用を大幅に向上させます。

• Aspectの機能：

  スマートコントラクトと比較して、Aspectsが提供する機能は主にトランザクション前後の実行に重点を置いています。Aspectsはスマートコントラクトを置き換えるのではなく、補完します。スマートコントラクトと比較して、Aspectsはアプリケーションに以下の独自の機能を提供します：

• 信頼性の高いトランザクションを逆転したブロックに自動的に挿入します（たとえば、スケジュールされたタスク用）。

• トランザクションによって引き起こされた状態データの変更の逆転（承認された契約トランザクションのみが逆転可能）。

• 静的環境変数の読み取り。

• 一時的な実行状態を下流の他のAspectsに渡す。

• 上流のAspectから渡された一時的な実行状態を読み取る。

• 動的かつモジュール化されたアップグレード性。

• Aspectとスマートコントラクトの違い：

  Aspectとスマートコントラクトの違いは次のとおりです：

• スマートコントラクトはコードを持つアカウントですが、Aspectはブロックチェーンのネイティブ拡張です。

• Aspectはトランザクションとブロックライフサイクルの異なるポイントで実行できますが、スマートコントラクトは固定されたポイントでのみ実行されます。

• スマートコントラクトは自分の状態とブロックの限られたコンテキストにアクセスできますが、Aspectはグローバル処理コンテキストやシステムレベルのAPIと相互作用できます。

• Aspectの実行環境は、ネイティブ速度に近づけるように設計されています。

  Aspectは単なるコードロジックの断片であり、アカウントとは無関係であるため、次のことはできません：

• 契約状態データの書き込み、変更、または削除。

• 新しい契約の作成。

• ネイティブトークンの移転、破棄、または保有。

これらのAspectにより、Artelaはスマートコントラクトの機能を拡張し、より包括的でカスタマイズ可能な開発環境を提供する独自のプラットフォームとなります。

*注意：厳密には、上記のAspectは「内蔵」Aspectとも呼ばれ、Artela Chainのフルノードによって実行される埋め込み協処理器です。dAppはまた、外部協処理器によって実行される独自の異種Aspectをデプロイすることもできます。これらの外部協処理器は、外部ネットワーク上で実行されるか、別のコンセンサスのノードのサブセットによって実行される可能性があります。これはより柔軟であり、dApp開発者は実際に安全かつ合理的な操作を実行するために、何でも実行できます。現在も探求中であり、具体的な詳細はまだ発表されていません。

埋め込み協処理器の潜在的なユースケース

• 新しいDeFiプロジェクトに関連する複雑な計算（たとえば、複雑なゲーム理論メカニズム）は、埋め込み協処理器に柔軟性と反復性の高い即時計算能力を必要とするかもしれません。

• 各種dAppに対するより柔軟なアクセス制御メカニズム。現在、アクセス制御は通常、スマートコントラクトの権限に基づくブラックリストまたはホワイトリストに限定されています。埋め込み協処理器は、即時かつ精緻なアクセス制御レベルを解放できます。

• フルチェーンゲーム（FOCG）における特定の複雑な機能。FOCGは長い間EVMの制約を受けてきました。EVMがNFTやトークンの移転などのより単純な機能を保持し、他のロジックや状態更新が協処理器によって計算される場合、状況はより簡単になるかもしれません。

• セキュリティメカニズム。dAppは独自の積極的なセキュリティ監視と失敗安全メカニズムを導入できます。たとえば、流動性プールは10分ごとに5%を超える引き出しを防止できます。協処理器がそのうちの1つの引き出しを検出した場合、スマートコントラクトは停止し、特定の動的価格範囲内で緊急流動性を注入するなどの警報メカニズムをトリガーできます。

結論

dAppが巨大で、肥大化し、過度に複雑になることは避けられないため、協処理器の普及も必然です。これは単に時間と採用曲線の問題です。

外部協処理器を運用することで、dAppは自分の快適なゾーンに留まることができます：以前はどのチェーンにあったとしても。しかし、新しいdApp開発者がデプロイ可能な実行環境を探している場合、埋め込み協処理器は個人用コンピュータのGPUのようなものです。高性能な個人用コンピュータを名乗るのであれば、まともなGPUを持っている必要があります。

残念ながら、上記のプロジェクトはまだメインネットにローンチされていません。私たちは本当にベンチマークテストを行うことができず、どのプロジェクトがどのユースケースに最適かを示すことができません。しかし、1つのことは間違いありません。それは、技術が螺旋的に上昇しているということです。私たちは原地で回っているように見えますが、側面から見ると、歴史は技術が本当に進化していることを証明するでしょう。

スケーラビリティ不可能三角形万歳、協処理器万歳。