IoTeX、DePHY、peaqなどのインフラストラクチャの動作原理について詳しく説明します。

2024.03.18

共有先

TechFlow厳選深潮セレクト

IoTeX、DePHY、peaqなどのインフラストラクチャの動作原理について詳しく説明します。

DePINとWeb3 IoTプロジェクトの動作原理をプロトコル設計の観点から理解する。

2024.03.18 - 15:56:13

Web3業界の深掘り報道に専念し潮流を洞察

DePINとWeb3 IoTプロジェクトの動作原理をプロトコル設計の観点から理解する。

執筆：Pika、Sui パブリックチェーンアンバサダー、DePIN 研究員

編集：Faust、Geek web3

導入：現在、DePIN 分野は非常に注目されていますが、DePIN 関連のIoTデバイスをブロックチェーンに大規模に接続するには、依然として技術的な障壁があります。一般的に、IoTハードウェアをブロックチェーンに接続するには、以下の3つの重要な段階を経る必要があります。

1. ハードウェアデバイスの信頼できる実行

2. データの収集・検証および提供

3. データをさまざまなアプリケーションに配信

これらの各段階には異なる攻撃シナリオと対抗手段があり、さまざまなメカニズム設計を導入する必要があります。本稿ではプロジェクトの作業プロセスとプロトコル設計の観点から、IoTデバイスが信頼性のあるデータを生成し、検証して保存し、計算によって証明を生み出し、最終的にブロックチェーンにデータをロールアップする一連の流れを振り返り分析します。もし皆さんがDePIN分野の起業家であれば、本稿がプロジェクト開発における方法論や技術設計の参考になれば幸いです。

以下では、空気質モニタリングのケースを例に、IoTeX、DePHY、peaqという3つのDePINインフラを用いて分析し、DePINインフラプラットフォームがどのように機能するかを説明します。このようなインフラプラットフォームは、IoTデバイスとブロックチェーン/Web3インフラを接続し、プロジェクトチームが迅速にDePINアプリケーションプロジェクトを立ち上げるのを支援します。

ハードウェアデバイスの信頼できる実行

ハードウェアデバイスの信頼性とは、デバイスのアイデンティティの信頼性と、プログラムの実行が改ざんされていないことを検証可能であるという信頼性を含みます。

DePINの基本的な動作モデル

多くのDePINプロジェクトのインセンティブスキームでは、ハードウェアデバイスの運営者がサービスを提供し、その見返りとして報酬を得ようとします。たとえばHeliumでは、ネットワークホットスポットデバイスが信号カバレッジを提供することでHNT報酬を得ます。しかし、報酬を受け取る前に、DePINデバイスは実際に規定された「努力」をしたことを証明する証拠を提示しなければなりません。

現実世界で特定のサービスを提供したり、ある活動を行ったことを証明するこの種の証明は、「物理的作業証明」（Proof of Physical Work, PoPW）と呼ばれます。DePINプロジェクトのプロトコル設計において、物理的作業証明は極めて重要な位置を占めており、それに対応するさまざまな攻撃シナリオと対策も存在します。

DePINプロジェクトは、インセンティブの分配とトークン配布のためにブロックチェーンに依存しています。従来のパブリックチェーンの公開鍵・秘密鍵方式と同様に、DePINデバイスの認証プロセスでも公開鍵・秘密鍵を使用する必要があります。秘密鍵は「物理的作業証明」の生成と署名に使用され、公開鍵は外部からの証明の検証や、ハードウェアデバイスのID（Device ID）として使われます。

さらに、直接デバイスのオンチェーンアドレスでトークン報酬を受け取るのは不便なため、DePINプロジェクトチームはオンチェーンにスマートコントラクトを展開することが多く、コントラクト内には複数のデバイス所有者のオンチェーンアカウントアドレスが記録されます。これはデータベースにおける一対一または多対一の関係に似ています。この方法により、オフチェーンの物理デバイスが受け取るべきトークン報酬を、所有者のオンチェーンアカウントに直接送金できます。

シビル攻撃

ほとんどのインセンティブ型プラットフォームは「シビル攻撃」という問題に直面します。つまり、誰かが多数のアカウントやデバイスを操作したり、異なる身元証明を生成して複数の人物になりすまし、複数の報酬を不正に受け取ろうとする行為です。先ほど述べた空気質モニタリングの例では、サービスを提供するデバイスが多いほど、システムが支払う報酬も増加します。誰かが技術的手法で大量の空気質データと対応するデバイス署名を生成し、多数の物理的作業証明を作成して利益を得ようとするかもしれません。これにより、DePINプロジェクトのトークンは過度のインフレに陥る可能性があるため、こうした不正行為を阻止する必要があります。

KYCなどのプライバシーを損なう方法を使わずにシビル攻撃を防ぐ最も一般的な手段は、PoWとPoSです。ビットコインプロトコルでは、マイナーが膨大な計算リソースを投入して初めてマイニング報酬を得られます。PoSチェーンでは、参加者が大量の資産をステーキングする必要があります。

DePIN分野において、シビル攻撃への対策は「物理的作業証明の生成コストを引き上げること」に帰着します。物理的作業証明の生成は有効なデバイスID情報（秘密鍵）に依存しているため、ID情報の取得コストを高めることで、低コストで大量の作業証明を生成する不正行為を防ぐことができます。

上記の目的に対して、比較的効果的な解決策の一つは、DePINデバイスメーカーにID情報の生成権限を独占させ、デバイスをカスタマイズして、各デバイスに固有のIDタグを登録することです。これは、警察機関がすべての市民の身分情報を一元管理し、警察データベースに登録されている人だけが政府補助金を受け取れる資格を持つことに似ています。

（画像出典：DigKey）

製造工程では、DePINデバイスメーカーは十分な時間をかけてルートキーを生成し、ランダムに選択したルートキーをeFuse技術でチップに書き込みます。ここで簡単に解説すると、eFuse（プログラマブル電子ヒューズ）は集積回路内で情報を保存する電子技術であり、書き込まれた情報は通常改ざんや消去が不可能で、高いセキュリティを保証します。

この製造プロセスにより、デバイス所有者もメーカー自身も、デバイスの秘密鍵やルートキーを知ることができなくなります。ハードウェアデバイスはTEE（Trusted Execution Environment）の隔離環境内で、ルートキーから作業用キー（ワーキングキー）を派生させ、署名に使う秘密鍵と、外部からデバイスIDを検証するための公開鍵を使用できます。TEE外のユーザーまたはプログラムは、これらのキーの詳細を知ることはできません。

この方式では、トークン報酬を得るには専用メーカーからデバイスを購入する必要があります。シビル攻撃者がメーカーを迂回して低コストで大量の作業証明を生成しようとすれば、メーカーのセキュリティシステムを突破し、自ら生成したキーの公開鍵をネットワークの許可されたデバイスに登録する必要があります。シビル攻撃者は、メーカーが内部から不正を行う以外は、低コストで攻撃を仕掛けるのは極めて困難です。

また、デバイスメーカーに不正の疑いが生じた場合、社会的コンセンサスによってメーカーを公表し、制裁を加えることができます。これはしばしばDePINプロジェクト全体に悪影響を及ぼします。ただし、大多数の場合、デバイスメーカーはDePINネットワークプロトコルの主要受益者であるため、不正をする動機はほとんどありません。ネットワークプロトコルが円滑に機能し続けることで、マイニングマシンの販売収益がDePINマイニング収益よりも高くなるため、メーカーはむしろ不正をしない方向に傾くのです。

（画像出典：Pintu Academy）

もしハードウェアデバイスが中央集権的なメーカーによって統一供給されない場合、任意のデバイスがDePINネットワークに接続する際、システムはまずそのデバイスがプロトコルが要求する特性を持っているかを確認する必要があります。例えば、新しく参加するデバイスに専用のハードウェアモジュールがあるかどうかをチェックし、なければ認証を通過できないようにします。このようなハードウェアモジュールを搭載するには一定の資金が必要であり、これがシビル攻撃のコストを引き上げ、結果としてシビル対策になります。このような状況では、正常にデバイスを運用する方が、シビル攻撃を仕掛けるより賢明かつ安全です。

データ改ざん攻撃

仮に、空気質モニタリングデータの変動幅が大きいほど、システムがそのデータを価値が高いと判断し、より多くの報酬を与えるとしましょう。この場合、あらゆるデバイスは意図的にデータを偽造して高変動性を示そうとする動機を持ちます。中央集権的なメーカーによるID認証を受けたデバイスであっても、データ処理中に「細工」を行い、収集した生データを改変する可能性があります。

どうすればDePINデバイスが誠実で信頼でき、収集したデータを恣意的に改変していないことを保証できるでしょうか？ここでは信頼できるファームウェア（Trusted Firmware）技術が必要となり、特に有名なのがTEE（Trusted Execution Environment）やSPE（Secure Processing Environment）です。これらのハードウェアレベルの技術により、デバイス上で事前に検証済みのプログラムに従ってデータが処理され、計算過程に「細工」がないことが保証されます。

（画像出典：Trustonic）

簡単に説明すると、TEE（信頼実行環境）はプロセッサまたはプロセッサコア内に実装され、機密データの保護や機密操作の実行を目的としています。TEEはコードとデータにハードウェアレベルのセキュリティ保護を提供し、マルウェア、悪意ある攻撃、または不正アクセスから守ります。例えば、LedgerやKeystoneといったハードウォレットはTEE技術を利用しています。

現代の多くのチップはTEEをサポートしており、特にモバイル端末、IoTデバイス、クラウドサービス向けのチップに多く見られます。高性能プロセッサ、セキュリティチップ、スマートフォンSoC（システムオンチップ）、クラウドサーバーチップなどは、高いセキュリティ要件があるため、TEE技術を統合していることが多いです。

しかし、すべてのハードウェアが信頼できるファームウェアをサポートしているわけではなく、一部の低価格マイクロコントローラ、センサチップ、カスタム組み込みチップはTEE非対応です。こうした低コストチップは、プローブ攻撃などの手法でチップ内に保存されたID情報を取得し、デバイスIDと挙動を偽造されるリスクがあります。例えば、チップに保存された秘密鍵を取得し、それを用いて改ざんまたは偽造されたデータに署名し、まるでデバイス自体が生成したデータのように見せかける攻撃です。

しかし、プローブ攻撃は専門設備と正確な操作、データ解析プロセスを必要とし、攻撃コストが非常に高く、市場でこうした低コストチップを直接購入するコストよりも遥かに高くなります。低価格デバイスのID情報をプローブ攻撃などで偽造して利益を得るよりも、攻撃者はむしろ直接多数の低コストデバイスを購入するほうが合理的です。

データソース攻撃シナリオ

前述のTEEはハードウェアデバイスが忠実にデータを生成することを保証できますが、これはデータがデバイス内部に入力された後、悪意ある処理が行われていないことを示すだけであり、計算処理前の入力元が信頼できるかどうかまでは保証できません。これはオラクルプロトコルが直面する課題と似ています。

例えば、ある空気質モニターが排気工場の近くに設置され、夜間に密閉ガラス容器で覆われた場合、取得されるデータは明らかに不正確です。しかし、このような攻撃シナリオは利益が少なく、攻撃者が敢えて行う必要はほとんどありません。DePINネットワークプロトコルにとって、デバイスが誠実かつ信頼できる計算プロセスを満たし、インセンティブプロトコルが要求する作業量を達成していれば、理論的には報酬を受け取るべきです。

ソリューション紹介

IoTeX

IoTeXはW3bStreamという開発ツールを提供し、IoTデバイスをブロックチェーンおよびWeb3に接続します。W3bStreamのIoT側SDKには、通信・メッセージング、IDおよび認証サービス、暗号化サービスなどの基本コンポーネントが含まれています。

W3bStreamのIoT SDKは暗号化機能の開発が非常に整備されており、PSA Crypto API、暗号プリミティブ、暗号サービス、HAL、ツール、信頼の根（Root of Trust）などのモジュールを含んでいます。

これらのモジュールにより、さまざまなハードウェアデバイス上で、安全または安全性の低い方法で生成されたデータに署名し、ネットワークを通じて後続のデータ層に送信して検証できるようになります。

DePHY

DePHYはIoT側でDID（Device ID）認証サービスを提供します。DIDはメーカーによって発行され、各デバイスには1つだけ対応するDIDがあります。DIDのメタデータはカスタマイズ可能で、デバイスのシリアル番号、モデル、保証情報などを含めることができます。

TEE対応ハードウェアデバイスの場合、最初にメーカーが鍵ペアを生成し、eFuseを使ってチップに書き込みます。DePHYのDIDサービスは、メーカーがデバイスの公開鍵に基づいてDIDを生成するのを支援します。メーカーが生成した秘密鍵は、IoTデバイスに書き込まれると同時に、メーカーのみが保持します。

信頼できるファームウェアにより、安全で信頼性の高いメッセージ署名とハードウェア側の秘密鍵の秘匿が可能になるため、ネットワーク内でデバイスの秘密鍵を不正に生成している行為が発覚した場合、ほぼ確実にメーカーが悪意を持って行動していると断定でき、その責任を追跡できます。

DePHYのユーザーはデバイスを購入後、デバイスのアクティベーション情報を取得し、オンチェーンのアクティベーションコントラクトを呼び出して、ハードウェアデバイスのDIDを自分のオンチェーンアドレスに関連づけ、DePHYネットワークプロトコルに接続します。DID設定プロセスを経たIoTデバイスは、ユーザーとデバイス間での双方向データ通信を実現できます。

ユーザーがオンチェーンアカウントからデバイスに制御命令を送信する際のプロセスは以下の通りです。

1. ユーザーが制御アクセス権限を持っているか確認する。デバイスのアクセス制御権限はメタデータとしてDIDに記録されるため、DIDをチェックすることで権限を確認できます。

2. ユーザーとデバイスが秘密チャネルを開通して接続し、ユーザーがデバイスを制御できるようにする。DePHYリレーヤーはNoStrリレーに加え、ピアツーピアネットワークノードも含み、ポイントツーポイントチャネルをサポートし、他のノードがトラフィックの中継を担当します。これにより、ユーザーはオフチェーンでリアルタイムにデバイスを制御できます。

IoTデバイスがブロックチェーンにデータを送信する際、後続のデータ層はDIDからデバイスの許可状態を読み取ります。登録されて許可されたデバイスのみがデータをアップロードできます。たとえば、メーカーに登録されたデバイスのみです。

DIDサービスのもう一つの興味深い機能は、IoTデバイスの機能的特性（trait）の認証を提供することです。この認証により、IoTハードウェアデバイスが特定の機能を持っているかを識別し、特定のブロックチェーンネットワークのインセンティブ活動に参加する資格があるかを判断できます。たとえば、WiFi送信機がLoRaWAN機能（trait）を持っていると識別されれば、無線ネットワーク接続を提供できると見なされ、Heliumネットワークに参加できます。同様に、GPS trait、TEE traitなどもあります。

拡張サービスに関して、DePHYのDIDはステーキング参加やプログラマブルウォレットとのリンクもサポートしており、オンチェーン活動への参加を容易にします。

peaq

peaqのソリューションはやや特異で、3つのレベルに分かれています：デバイス由来の認証、パターン認識による検証、オラクルベースの認証です。

1. デバイス由来の認証。 peaqは鍵ペアの生成、デバイス上の秘密鍵による情報署名、デバイスアドレスpeaq IDとユーザーアドレスのバインドなどの機能も提供します。しかし、オープンソースコードには信頼できるファームウェアの機能実装が見当たりません。peaqは単純に秘密鍵でデバイス情報を署名する認証方式を採用しており、デバイスの誠実な動作やデータの改ざん防止を保証できません。peaqはむしろオプティミスティックロールアップのようなもので、デバイスが悪意を持たないと仮定し、後段でデータの信頼性を検証するスタンスです。

2. パターン認識による検証。 2つ目の方式は、機械学習とパターン認識を組み合わせたものです。過去のデータからモデルを学習し、新しいデータをそのモデルと比較して信頼性を判断します。しかし、統計モデルは異常データを識別できるだけであり、IoTデバイスが誠実に動作しているかを判断することはできません。

たとえば、都市Aの空気質モニターが地下室に設置され、他のモニターと異なるデータを生成しても、それはデータ偽造ではなく、デバイスが誠実に動作している可能性があります。一方、利益が十分大きければ、ハッカーはGANなどの手法で機械学習が判別困難なデータを生成でき、特に判別モデルが公開されている場合はなおさらです。

3. オラクルベースの認証。 3つ目の方式は、より信頼できるデータ源をオラクルとして選び、他のDePINデバイスが収集したデータと比較検証する方法です。たとえば、プロジェクトチームが都市Aに高精度の空気質モニターを設置し、他のモニターのデータが大きく逸脱すれば、信頼できないとみなします。

この方式は一方でブロックチェーンに権威を導入・依存させるだけでなく、オラクルデータ源のサンプリングバイアスにより、ネットワーク全体のデータ収集に偏りが生じる可能性もあります。

現時点の資料によると、peaqのインフラはIoT側でデバイスとデータの信頼性を保証できません。（注：筆者はpeaqの公式サイト、開発ドキュメント、GitHubリポジトリ、および唯一の2018年版ホワイトペーパードラフトを調査しました。開発チームにメールで問い合わせましたが、原稿執筆時点で追加資料は得られませんでした）

データの生成と公開（DA）

DePINの作業プロセスの第2段階は、主にIoTデバイスから送られてきたデータの収集・検証、保存、そして後続の段階へのデータ提供です。データが完全かつ誤りなく、復元可能な形で特定の受信者に送信されることを保証する必要があり、これをデータ可用性層（DA層）と呼びます。

IoTデバイスは通常、HTTP、MQTTなどのプロトコルを通じてデータと署名認証情報をブロードキャストします。DePINインフラのデータ層は、デバイスからの情報を受信した際に、データの信頼性を検証し、検証を通過したデータを集約・保存します。

ここで補足すると、MQTT（MQ Telemetry Transport）は軽量でオープンな、パブリッシュ／サブスクライブ方式に基づくメッセージ転送プロトコルであり、センサーや組み込みシステムなどリソースが制限されたデバイスの接続を目的としています。低帯域幅や不安定なネットワーク環境下での通信に適しており、IoTアプリケーションに最適です。

IoTデバイスのメッセージ検証プロセスでは、デバイスの信頼できる実行の認証とメッセージの認証が含まれます。

デバイスの信頼できる実行の認証にはTEEを組み合わせることができます。TEEはデータ収集コードをデバイスの保護領域に隔離することで、データの安全な収集を確保します。

もう一つの方法はゼロ知識証明（ZKP）です。この方法により、デバイスはデータ収集の正確性を証明しつつ、基礎となるデータの詳細を漏らしません。この方式はデバイスによって異なり、性能の高いデバイスはローカルでZKPを生成でき、制限されたデバイスはリモート生成を行うことも可能です。

デバイスの信頼性を認証した後、DIDを使ってメッセージ署名を検証すれば、そのメッセージが該当デバイスによって生成されたことを確認できます。

ソリューション紹介

IoTeX

W3bStreamでは、信頼できるデータ収集・検証、データクリーニング、データ保存の3つの部分に分けられます。

信頼できるデータ収集・検証にはTEEとゼロ知識証明（ZKP）の手法を使用。
データクリーニングとは、異なるタイプのデバイスがアップロードしたデータのフォーマットを統一・標準化し、保存や処理を容易にするプロセスです。
データ保存段階では、異なるアプリケーションプロジェクトがストレージアダプターを設定することで、異なるストレージシステムを選択できます。

現在のW3bStream実装では、異なるIoTデバイスはデータを直接W3bStreamのサービスポイントに送信するか、一旦サーバーで収集した後、W3bStreamのサーバーポイントに送信できます。

受信したデータに対して、W3bStreamは中心的なディスパッチャーとして、入ってきたデータを異なるプログラムに振り分けます。W3bStreamエコシステム内のDePINプロジェクトは、W3bStream上で登録申請を行い、イベントトリガー条件（Event Strategy）と処理プログラム（Applet）を定義します。

各IoTデバイスにはデバイスアカウント（device account）があり、1つのW3bStreamプロジェクトに属し、しかもただ1つのプロジェクトにしか属できません。したがって、IoTデバイスのメッセージがW3bStreamのサーバーポートに到達したとき、まず登録・バインド情報に基づき特定のプロジェクトにリダイレクトされ、データの信頼性を検証できます。

前述のイベントトリガー条件では、HTTP APIエンドポイント、MQTTトピックから受信したデータ、ブロックチェーン上のイベント記録の検出、ブロックチェーンの高さの検出など、トリガー可能なイベント（Event triggers）の種類を定義でき、対応する処理プログラムをバインドできます。

処理プログラム（Applet）には1つ以上の実行関数が定義され、WASM形式にコンパイルされます。データのクリーニングやフォーマット整理はAppletによって実行されます。処理後のデータは、プロジェクトが定義したkey-valueデータベースに保存されます。

DePHY

DePHYプロジェクトは、データの処理と提供にさらに分散化されたアプローチを採用しており、これをDePHYメッセージネットワーク（DePHY Message Network）と呼んでいます。

DePHYメッセージネットワークは、無許可のDePHYリレーノード（relayer）で構成されています。IoTデバイスは任意のDePHYリレーノードのRPCポートを通じてデータを送信でき、受信したデータはまずミドルウェアを呼び出し、DIDを利用してデータの信頼性を検証します。

信頼性検証を通過したデータは、異なるリレーノード間で同期され、コンセンサスを形成します。DePHYメッセージネットワークはNoStrプロトコルを採用しています。NoStrはもともと分散型ソーシャルメディア構築用でしたが、以前Twitterの代替として話題になりました。DePINデータの同期にも巧みに適用されています。

DePHYネットワークでは、各IoTデバイスが保存するデータの断片をMerkle木として構成し、ノード間でMerkleルートと木全体のtreeハッシュを同期します。あるRelayerがMerkleルートとtreeハッシュを取得すると、不足しているデータを迅速に特定し、他のRelayerから補完できます。この方法により、非常に効率的にコンセンサス確定（Finalize）を達成できます。

DePHYメッセージネットワークのノード運営はパーミッションレスであり、誰でも資産をステーキングしてDePHYネットワークノードを運営できます。ノード数が増えれば増えるほど、ネットワークのセキュリティとアクセシビリティが向上します。DePHYノードはzk条件付き支払い（Zero-Knowledge Contingent Payments）方式で報酬を得られます。つまり、データ索引を必要とするアプリケーションがDePHYリレーノードにデータを要求する際、データ検索のZK証明の有無に基づき、リレーノードにいくら支払うかを決定します。

同時に、誰でもDePHYネットワークに接続してデータの監視・読み取りが可能です。プロジェクト運営のノードはフィルタリングルールを設定し、自プロジェクトに関連するDePINデバイスデータのみを保存できます。生データが蓄積されるため、DePHYメッセージネットワークは後続の他のタスクのデータ可用性層として機能できます。

DePHYプロトコルは、リレーノードが稼働中、受信したデータを一定期間ローカルに保存することを要求し、その後、Arweaveのような永続的ストレージプラットフォームに冷データを移行します。すべてのデータをホットデータとして扱えば、最終的にノードのストレージコストが上がり、フルノードの運営ハードルが上がり、一般ユーザーがフルノードを運営できなくなってしまいます。

ホットデータとコールドデータの分類処理により、DePHYはメッセージネットワークのフルノード運営コストを大幅に削減し、膨大なIoTデータに効果的に対応できます。

peaq

前述の2つの方式は、データ収集と保存をオフチェーンで実行し、その後ロールアップしてオンチェーンに持ち込むものです。これはIoTアプリケーションが生成するデータ量が非常に大きく、かつ通信遅延の要件があるためです。ブロックチェーン上で直接DePINトランザクションを実行すれば、データ処理能力が限られ、ストレージコストも非常に高くなります。

ノード間のコンセンサス待ちだけで耐え難い遅延が発生します。peaqは独自のアプローチを取り、自社でパブリックチェーンを構築し、直接これらの計算とトランザクションを実行します。Substrateベースで開発されており、メインネットが実際稼働し始め、DePINデバイスが増えれば、peaqのパフォーマンスボトルネックにより、膨大な計算とトランザクション要求を処理できなくなるでしょう。

peaqは信頼できるファームウェア機能を備えていないため、データの信頼性を有効に検証できません。データ保存に関して、peaqは開発ドキュメントでSubstrateベースのブロックチェーンにIPFS分散ストレージを接続する方法を紹介しています。

データをさまざまなアプリケーションに配信

DePIN作業プロセスの第3段階は、ブロックチェーンアプリケーションの要件に応じて、データ可用性層のデータを抽出し、計算やゼロ知識証明を実行して、その結果を効率的にブロックチェーンに同期することです。

ソリューション紹介

IoTeX

W3bStreamはこの段階を「データ証明集約（Data Proof Aggregation）」と呼びます。この部分のネットワークは多数のアグリゲーターノード（Aggregator Nodes）から構成され、計算リソースプール（computing resource pool）を形成し、すべてのDePINプロジェクトが共有して利用できます。

各アグリゲーターノードはブロックチェーン上に自身の稼働状態（忙しいか空いているか）を記録します。DePINプロジェクトからの計算要求があると、オンチェーンの状態監視（monitor）に基づき、空いているアグリゲーターノードを選択して処理を行います。

選ばれたアグリゲーターノードは、まずストレージ層から必要なデータを検索します。次に、DePINプロジェクトの要求に応じてデータを計算処理し、その結果の証明を生成します。最後に、証明結果をブロックチェーン上のスマートコントラクトが検証できるように送信します。作業プロセスが完了すると、アグリゲーターノードは再び空き状態に戻ります。

アグリゲーターノードが証明を生成する際、階層的集約回路（layered aggregation circuit）を使用します。階層的集約回路は4つの部分から構成されます。

データ圧縮回路： Merkle木と同様に、収集されたすべてのデータが特定のMerkleルートから来ていることを検証します。
署名バッチ検証回路： デバイスからのデータの有効性をまとめて検証します。各データは署名と関連付けられています。
DePIN計算回路： DePINデバイスが特定の計算ロジックに従って正しく命令を実行したことを証明します。たとえば、医療健康プロジェクトで歩数を検証したり、太陽光発電所で発電量を検証したりします。
証明集約回路： すべての証明を1つの証明に集約し、Layer1のスマートコントラクトが最終的に検証できるようにします。