Please provide the full text or content that needs to be translated. The current request only contains a title or instruction but lacks the actual material to translate.
TechFlow Selected TechFlow Selected
Please provide the full text or content that needs to be translated. The current request only contains a title or instruction but lacks the actual material to translate.
Understanding the working principles of DePIN and Web3 IoT projects from a protocol design perspective.
Navigating Web3 tides with focused insightsAuthor: Pika, Sui Ambassador, DePIN Researcher
Editor: Faust, Geeks Web3
Introduction: Although the DePIN sector is currently gaining significant traction, there remain technical barriers preventing large-scale integration of IoT devices with blockchains. Generally, connecting IoT hardware to a blockchain involves three critical stages:
1. Trustworthy operation of hardware devices;
2. Collecting, verifying, and providing data;
3. Distributing data to various applications.
Each of these stages presents distinct attack scenarios and countermeasures, requiring the introduction of various mechanism designs. This article reviews and analyzes, from the perspective of project workflows and protocol design, the entire process by which IoT devices generate trustworthy data, verify and store data, produce computational proofs, and roll up data onto blockchains. If you are a founder in the DePIN space, we hope this article provides methodological and technical insights beneficial to your project's development.
In the following sections, we use air quality monitoring as an example, analyzing alongside three DePIN infrastructure platforms—IoTeX, DePHY, and peaq—to illustrate how DePIN infrastructures function. These infrastructure platforms bridge IoT devices with blockchain/Web3 systems, enabling project teams to rapidly launch DePIN application projects.
Trustworthy Operation of Hardware Devices
Trustworthiness of hardware devices includes trust in device identity and verifiable, tamper-proof execution of programs.
Basic Operational Model of DePIN
In most DePIN project incentive schemes, operators of hardware devices provide services and use them as leverage to claim rewards from the incentive system. For example, in Helium, hotspot network devices earn HNT rewards by providing signal coverage. However, before receiving incentives from the system, DePIN devices must first present evidence proving they have indeed expended certain "effort" as required.
This type of proof, used to demonstrate that a physical-world service has been provided or certain activities carried out, is known as Proof of Physical Work (PoPW). In the protocol design of DePIN projects, PoPW plays a pivotal role, accompanied by various attack scenarios and corresponding countermeasures.
DePIN projects rely on blockchains for incentive distribution and token allocation. Similar to public-key cryptography in traditional blockchains, DePIN device identity verification also requires public-private key pairs—private keys are used to generate and sign "Proof of Physical Work," while public keys are used externally to verify such proofs or serve as device identifiers (Device ID).
Additionally, directly using a device’s on-chain address to receive token incentives is inconvenient. Therefore, DePIN projects often deploy a smart contract on-chain that records the on-chain account addresses of different device holders, forming one-to-one or many-to-one mappings like in a database. This way, token rewards intended for off-chain physical devices can be directly sent to the holder’s on-chain wallet.
Sybil Attacks
Most incentive-based platforms face "Sybil attacks," where individuals may control numerous accounts or devices, or generate multiple identities to impersonate multiple users and claim multiple rewards. Taking our earlier example of air quality monitoring, the more devices providing this service, the greater the total rewards distributed. Someone could technically generate multiple air quality readings and corresponding device signatures rapidly, creating numerous PoPW entries for profit. This would lead to excessive inflation of the DePIN project’s token supply, so such cheating must be prevented.
To combat Sybil attacks without resorting to privacy-invasive methods like KYC, the most common approaches are POW and POS. In Bitcoin, miners must expend substantial computational power to earn mining rewards; in POS blockchains, participants must stake significant assets.
In the DePIN domain, anti-Sybil measures can be summarized as "increasing the cost of generating PoPW." Since PoPW generation depends on valid device identity information (private keys), raising the cost of acquiring such identities prevents low-cost generation of fraudulent proofs.
Toward this goal, a relatively effective solution is to grant exclusive authority over identity generation to DePIN device manufacturers, customizing devices by embedding unique identity tags into each unit. This is analogous to a government maintaining centralized citizen identity records—only those registered in the official database qualify for subsidies.
(Image source: DigKey)
During manufacturing, DePIN device makers use software to generate root keys over a sufficiently long period, then randomly select root keys to be written into chips via eFuse technology. For context, eFuse (programmable electronic fuse) is an electronic technique for storing information in integrated circuits, where recorded data typically cannot be altered or erased, offering strong security guarantees.
Under this production process, neither device owners nor manufacturers can access the device’s private key or root key. The hardware device can derive and use operational keys—including signing private keys and publicly verifiable public keys—from the root key within a TEE (Trusted Execution Environment). Keys remain invisible to any entity or program outside the TEE.
With this model, to receive token incentives, one must purchase devices from authorized vendors. A Sybil attacker attempting to bypass the manufacturer and generate PoPW at low cost would need to compromise the vendor’s secure system to register their own generated public keys into the network-approved device list. Launching such attacks at low cost is extremely difficult unless the manufacturer itself colludes maliciously.
Once suspicious misconduct by a manufacturer is detected, community consensus can expose the behavior, potentially damaging both the manufacturer and the DePIN project. However, in most cases, device manufacturers are core beneficiaries of the DePIN network protocol, and thus generally lack incentives to act maliciously—because they stand to earn more from selling hardware than from mining DePIN tokens, making honest operations the more rational choice.
(Image source: Pintu Academy)
If hardware devices are not uniformly supplied by a centralized manufacturer, the system must first confirm that any new device joining the DePIN network possesses the required characteristics. For instance, the system checks whether newly added devices contain dedicated hardware modules—devices lacking such modules typically fail authentication. Acquiring such hardware modules incurs costs, thereby increasing the expense of launching Sybil attacks and achieving the anti-Sybil objective. Under these conditions, operating legitimate devices remains a more rational and secure strategy than attempting Sybil attacks.
Data Tampering Attacks
Let’s imagine a scenario: if a device’s air quality readings are rewarded more when exhibiting higher volatility, every device would have strong incentives to falsify data to appear highly volatile. Even devices authenticated by centralized manufacturers could “inject” manipulated logic during data computation, altering raw collected data.
How can we ensure DePIN devices are honest and haven’t arbitrarily modified collected data? This requires Trusted Firmware technology, notably TEE (Trusted Execution Environment) and SPE (Secure Processing Environment). These hardware-level technologies ensure data is processed according to pre-verified programs on the device, eliminating unauthorized manipulation during computation.
(Image source: Trustonic)
Briefly, TEE (Trusted Execution Environment) is typically implemented within processors or processor cores to protect sensitive data and perform sensitive operations. TEE provides a trusted execution environment where code and data enjoy hardware-level protection against malware, malicious attacks, or unauthorized access. For example, hardware wallets like Ledger and Keystone utilize TEE technology.
Most modern chips support TEE, especially those designed for mobile devices, IoT devices, and cloud services. High-performance processors, security chips, smartphone SoCs (system-on-chips), and cloud server chips commonly integrate TEE due to the high security demands of their application scenarios.
However, not all hardware supports trusted firmware. Some lower-end microcontrollers, sensor chips, and custom embedded chips may lack TEE support. For these low-cost chips, attackers might use probe attacks to extract stored identity information and forge device identities and behaviors. For example, extracting a private key from the chip and using it to sign tampered or fabricated data, making it appear as if the data originated from legitimate device operations.
But probe attacks require specialized equipment and precise operations and data analysis processes, resulting in high costs—often exceeding the market price of the low-cost chips themselves. Rather than cracking low-end devices via probe attacks to profit, attackers would prefer simply purchasing more low-cost devices.
Data Source Attack Scenarios
As previously mentioned, TEE ensures that hardware devices truthfully generate results, proving that data wasn't maliciously altered once inside the device—but it cannot guarantee the trustworthiness of input sources before processing begins. This resembles the challenges faced by oracle protocols.
For example, an air quality monitor placed near a factory exhaust might be covered overnight with a sealed glass jar, rendering its readings inaccurate. However, such attack scenarios are rarely profitable and usually not worth the effort. From the perspective of a DePIN network protocol, as long as a device performs honest and trustworthy computations and fulfills the workload requirements set by the incentive protocol, it should theoretically be eligible for rewards.
Solution Overview
IoTeX
IoTeX offers the W3bStream development toolkit to connect IoT devices to blockchains and Web3. The W3bStream IoT SDK includes fundamental components such as communication and messaging, identity and credential services, and cryptographic services.
W3bStream’s IoT SDK features comprehensive cryptographic development support, including implementations of multiple cryptographic algorithms such as PSA Crypto API, Cryptographic primitives, Cryptographic services, HAL, Tooling, and Root of Trust modules.
With these modules, data generated by devices can be securely or less securely signed across various hardware platforms and transmitted over networks for subsequent validation.
DePHY
DePHY provides DID (Device ID) certification services at the IoT end. DIDs are minted by manufacturers, with each device having exactly one unique DID. DID metadata is customizable and may include serial numbers, model types, warranty information, etc.
For hardware supporting TEE, manufacturers initially generate key pairs and write keys into chips via eFuse. DePHY’s DID service helps manufacturers generate DIDs based on device public keys. The private keys generated by manufacturers are written only into IoT devices and retained solely by the manufacturer.
Since trusted firmware enables secure message signing and keeps hardware-side private keys confidential, if forged device private keys are detected in the network, it strongly indicates malicious behavior by the manufacturer, allowing accountability through traceability.
After purchasing a device, users obtain activation information and invoke an on-chain activation contract to bind the device’s DID with their on-chain address, thereby integrating into the DePHY network protocol. After completing the DID setup, bidirectional data flow between user and device becomes possible.
When a user sends control commands from their on-chain account to the device, the process is as follows:
1. Confirm the user has access control permissions. Since access rights are stored as metadata on the DID, permission can be verified by checking the DID;
2. Allow the user and device to establish a private channel for remote control. Beyond NoStr relays, DePHY relayers also include peer-to-peer network nodes capable of supporting direct channels, with other nodes helping relay traffic, enabling real-time off-chain device control.
When IoT devices send data to the blockchain, the subsequent data layer reads the device’s authorization status from its DID—only registered and permitted devices can upload data, such as those registered by manufacturers.
Another notable feature of this DID service is its certification of IoT device functional traits. This certification identifies whether a hardware device possesses specific capabilities qualifying it for participation in certain blockchain network incentive programs. For example, a WiFi transmitter identified with LoRaWAN capability (trait) can be deemed capable of providing wireless connectivity and thus eligible to join the Helium network. Similarly, GPS trait, TEE trait, etc., exist.
In terms of extended services, DePHY’s DID also supports staking and integration with programmable wallets, facilitating participation in on-chain activities.
peaq
peaq’s approach is unusual, structured in three tiers: device-originated authentication, pattern recognition validation, and oracle-based authentication.
1. Device-Originated Authentication. peaq similarly offers functions to generate key pairs, sign messages using private keys on devices, and bind device addresses (peaq ID) to user addresses. However, no implementation of trusted firmware appears in their open-source code. peaq’s simple method of signing device information with private keys cannot guarantee honest device operation or untampered data. peaq operates more like an optimistic rollup, assuming devices do not misbehave and later validating data credibility in subsequent stages.
2. Pattern Recognition Validation. The second method combines machine learning and pattern recognition. By training models on historical data, incoming data is compared against prior patterns to assess credibility. However, statistical models can only detect anomalies, not verify whether IoT devices operate honestly.
For example, an air quality monitor in City A located in a basement may produce readings vastly different from others, yet still represent honest operation. Conversely, if rewards are high enough, hackers may employ GANs or similar techniques to generate data indistinguishable to machine learning models—especially when detection models are publicly shared.
3. Oracle-Based Authentication. The third method involves selecting more trusted data sources as oracles to cross-validate data collected by other DePIN devices. For instance, if the project deploys a highly accurate air quality monitor in City A, readings from other monitors deviating significantly are considered untrustworthy.
This approach introduces reliance on authoritative data sources into the blockchain, potentially causing systemic sampling bias if the oracle source itself is skewed.
Based on current information, peaq’s infrastructure cannot guarantee trustworthiness of devices and data at the IoT level. (Note: The author reviewed peaq’s official website, developer documentation, GitHub repositories, and a sole 2018 whitepaper draft. Despite contacting the development team via email, no additional clarifying materials were received before publication.)
Data Generation and Publication (DA)
The second stage of the DePIN workflow primarily involves collecting and verifying data transmitted from IoT devices, storing it, and making it available for downstream stages—ensuring data is delivered completely, accurately, and reconstructibly to designated recipients, known as the Data Availability (DA) layer.
IoT devices typically broadcast data and signature credentials via protocols like HTTP or MQTT. Upon receiving this data, DePIN infrastructure’s data layer must verify its authenticity and aggregate validated data for storage.
MQTT (MQ Telemetry Transport) is a lightweight, open, publish-subscribe messaging protocol designed for constrained devices such as sensors and embedded systems, enabling communication under low-bandwidth and unstable network conditions—ideal for IoT applications.
Verifying IoT device messages involves two aspects: device trustworthy execution authentication and message authentication.
Device trustworthy execution authentication can leverage TEE. TEE isolates data collection code within protected regions of the device, ensuring secure data gathering.
Another method is zero-knowledge proofs (ZKP), allowing devices to prove data accuracy without revealing underlying details. Implementation varies by device: powerful devices can generate ZKPs locally, while resource-constrained ones may require remote generation.
After confirming device trustworthiness, using DID to verify message signatures confirms the message originated from that device.
Solution Overview
IoTeX
In W3bStream, this phase consists of three parts: trusted data collection and verification, data cleansing, and data storage.
-
Trusted data collection and verification employ TEE and zero-knowledge proofs.
-
Data cleansing standardizes data formats from diverse devices for easier storage and processing.
-
Data storage allows different applications to configure storage adapters for various backend systems.
In the current W3bStream implementation, different IoT devices can either send data directly to W3bStream servers or route data through intermediate servers before forwarding to W3bStream endpoints.
Upon receiving incoming data, W3bStream acts as a central dispatcher, routing data to different processing programs. DePIN projects within the W3bStream ecosystem register on W3bStream and define event triggers (Event Strategy) and processing applets (Applet).
Each IoT device has a device account belonging to one and only one W3bStream project. Thus, when a device message reaches the W3bStream server, it can first be redirected based on registration binding and then undergo data trust verification.
Regarding the aforementioned event trigger logic, developers can define events such as data received via HTTP API endpoints or MQTT topics, blockchain event logs, or blockchain height changes—and bind corresponding applets to handle them.
Processing applets define one or more executable functions compiled into WASM format. Data cleansing and formatting are executed via applets, with processed data stored in a project-defined key-value database.
DePHY
DePHY adopts a more decentralized approach to data handling and provisioning, termed the DePHY Message Network.
The DePHY Message Network comprises permissionless DePHY relayer nodes. IoT devices can transmit data through any DePHY relayer’s RPC endpoint. Incoming data first invokes middleware to validate trust using DID.
Trusted data must synchronize across different relayers to reach consensus. DePHY uses the NoStr protocol for this purpose. Originally designed for decentralized social media (remember when people replaced Twitter with NoStr?), NoStr turns out to be surprisingly suitable for synchronizing DePIN data.
In the DePHY network, data fragments stored by each IoT device can be organized into a Merkle tree. Nodes synchronize the Merkle root and full tree hash among themselves. Once a relayer obtains the Merkle Root and Tree Hash, it can quickly identify missing data segments and retrieve them from other relayers—an extremely efficient method for achieving consensus finality.
Running DePHY Message Network nodes is permissionless—anyone can stake assets and operate a node. More nodes mean higher network security and accessibility. DePHY nodes can earn rewards via zk contingent payments. Applications needing data indices pay relayers based on ZK proofs verifying successful data retrieval.
Anyone can connect to the DePHY network to listen or read data. Project-operated nodes can apply filters to store only relevant DePIN device data. By accumulating raw data, the DePHY Message Network serves as a DA layer for future tasks.
The DePHY protocol requires relayers to store received data locally for a minimum duration before migrating cold data to permanent storage platforms like Arweave. Treating all data as hot data would excessively increase node storage costs, raising full-node operation barriers and discouraging individual participation.
Through this hot/cold data classification design, DePHY significantly reduces full-node operating costs, better handling massive volumes of IoT data.
peaq
The previous two solutions collect and store data off-chain before rolling it up to the blockchain—because IoT applications inherently generate enormous data volumes and require low-latency communication. Directly executing DePIN transactions on-chain would severely limit processing capacity and incur high storage costs.
Even node consensus alone introduces intolerable latency. peaq takes a different path, building its own blockchain to directly host these computations and transactions. Built on Substrate, once the mainnet launches and more DePIN devices join, peaq will inevitably face performance bottlenecks, unable to sustain such massive computational and transaction loads.
Due to peaq’s lack of trusted firmware functionality, it cannot effectively verify data authenticity. Regarding data storage, peaq’s documentation explicitly describes integrating IPFS distributed storage into Substrate-based blockchains.
Distributing Data to Different Applications
The third stage of the DePIN workflow involves extracting data from the DA layer according to blockchain application needs, performing computations or generating zero-knowledge proofs, and efficiently syncing results onto the blockchain.
Solution Overview
IoTeX
W3bStream refers to this stage as Data Proof Aggregation. This network consists of numerous aggregator nodes forming a shared computing resource pool accessible to all DePIN projects.
Each aggregator node records its operational status (busy/idle) on-chain. When a DePIN project submits a computation request, an idle aggregator is selected based on on-chain monitoring.
The selected aggregator retrieves required data from storage, performs computations per project requirements, generates proof of computation, and submits the proof to the blockchain for smart contract validation. After completion, the aggregator returns to idle state.
When generating proofs, aggregators use layered aggregation circuits. These circuits consist of four components:
-
Data Compression Circuit: Similar to Merkle trees, verifies all collected data stems from a specific Merkle root.
-
Signature Batch Verification Circuit: Validates batches of device data, each associated with a digital signature.
-
DePIN Computation Circuit: Proves that DePIN devices correctly executed specific computational logic—e.g., verifying step counts in health projects or energy output in solar plants.
-
Proof Aggregation Circuit: Combines all proofs into a single succinct proof for final verification by Layer1 smart contracts.
Data proof aggregation is crucial for ensuring computational integrity and verifiability in DePIN projects, providing a reliable and efficient method for validating off-chain computations and data processing.
IoTeX’s revenue model primarily operates at this stage—users can stake IOTX tokens to run aggregator nodes. More aggregators mean greater computational capacity, forming a robust computing layer.
DePHY
At the data distribution layer, DePHY provides co-processors to monitor finalized messages from the DePHY Message Network, perform state transitions (state change), compress data, and submit it to the blockchain.
State transition functions, akin to smart contracts, are customized by different DePIN projects and may include zkVM or TEE-based data packaging and computation solutions. DePHY provides scaffolding tools to help projects develop and deploy these components with high flexibility.
Beyond DePHY’s co-processors, DePIN projects can also use scaffolds to connect DA-layer data to other infrastructure compute layers for on-chain submission.
Comprehensive Analysis
Despite the current hype around DePIN, significant technical hurdles remain for large-scale integration of IoT devices with blockchains. This article examines, from a technical implementation standpoint, the full workflow—from trustworthy data generation and verification to storage, computation-based proof generation, and blockchain rollup—enabling IoT integration with Web3 applications. If you're a DePIN entrepreneur, we hope this article offers valuable methodological and technical guidance for your project's development.
Among the three analyzed DePIN infrastructures, peaq remains—as online comments six years ago suggested—just hype. Both DePHY and IoTeX adopt off-chain data collection followed by rollup to on-chain, enabling low-latency, trustworthy IoT data integration with blockchains.
DePHY and IoTeX differ in focus: DePHY’s DID includes hardware trait verification and bidirectional data transmission, emphasizing a decentralized DA layer as a loosely coupled module for DePIN projects; IoTeX offers high development completeness with a full workflow, focusing on event-driven applet binding, leaning toward the compute layer. DePIN builders can choose and combine solutions based on actual needs.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
