Introduction: Although the DePIN track is very popular at the moment, there are still technical obstacles for DePIN-related IoT devices to be connected to the blockchain on a large scale. Generally speaking, if you want to connect IoT hardware to the blockchain, you have to go through the following three key stages:

1. Trusted Operation of Hardware Devices;

2. Collecting, Verifying, and Providing Data;

3. Distributing Data to Different Applications.

In these three stages, there are different attack scenarios and countermeasures, requiring the introduction of various mechanism designs. This article reviews and analyzes, from the perspective of project workflow and protocol design, the entire process of IoT devices generating trusted data, verifying and storing data, generating proofs through computation, and rolling up data to the blockchain. If you are an entrepreneur in the DePIN track, it is hoped that this article can provide assistance in methodology and technical design for the development of your project.

In the following sections, we will use the scenario of air quality detection as an example and analyze how the three DePIN infrastructure platforms - IoTeX, DePHY, and peaq - work. Such infrastructure platforms can interface with IoT devices and blockchain/Web3 facilities, helping project teams quickly launch DePIN application projects.

Trusted Operation of Hardware Devices

The trust of hardware devices includes trust in device identity and trust in program execution that can be verified without tampering.

DePIN’s basic working model

In most DePIN projects’ incentive schemes, operators of hardware devices provide services externally to leverage them for rewards from the incentive system. For example, in Helium, network hotspots earn HNT rewards by providing signal coverage. However, before receiving rewards from the system, DePIN devices need to present evidence proving that they have indeed made certain “efforts” as required.

These proofs, used to demonstrate that one has provided a certain type of service or engaged in certain activities in the real world, are called Proof of Physical Work (PoPW). In the protocol design of DePIN projects, Proof of Physical Work plays a crucial role, and accordingly, there are various attack scenarios and corresponding countermeasures.

DePIN projects rely on blockchain for incentive distribution and token allocation. Similar to the public-private key system in traditional public chains, the identity verification process of DePIN devices also requires the use of public-private keys. The private key is used to generate and sign the “Proof of Physical Work,” while the public key is used by external parties to verify the proof or serves as the identity label (Device ID) for the hardware device.

In addition, directly receiving token incentives at the device’s on-chain address is not convenient. Therefore, DePIN project teams often deploy a smart contract on-chain, where the contract records the on-chain account addresses of different device holders, similar to a one-to-one or one-to-many relationship in a database. In this way, the token rewards that off-chain physical devices should receive can be directly sent to the on-chain accounts of the device holders.

Witch Attack

The vast majority of platforms that provide incentive mechanisms encounter “Sybil attacks,” where individuals may manipulate a large number of accounts or devices, or generate different identity proofs to disguise themselves as multiple entities, in order to receive multiple rewards. Taking the example of air quality detection mentioned earlier, the more devices there are providing this service, the more rewards the system distributes. Some individuals can use technical means to quickly generate multiple sets of air quality data and corresponding device signatures, creating numerous proofs of physical work to profit from them. This could lead to high inflation of tokens in DePIN projects, so it’s crucial to prevent such cheating behavior.

The concept of combating Sybil attacks, without resorting to privacy-compromising methods like KYC, often involves Proof of Work (PoW) and Proof of Stake (PoS). In the Bitcoin protocol, miners must expend significant computational resources to earn mining rewards, while in PoS public chains, network participants directly stake significant assets.

In the field of DePIN, countering Sybil attacks can be summarized as “raising the cost of generating physical work proofs.” Since the generation of physical work proofs relies on valid device identity information (private keys), simply raising the cost of acquiring identity information can prevent cheating behaviors where low-cost methods generate a large number of proofs of work.

To achieve this goal, a relatively effective solution is to allow DePIN device manufacturers to monopolize the generation authority of identity information, customize devices, and assign a unique identity label to each device. This is analogous to having the Public Security Bureau centrally record the identity information of all citizens, so only those whose information can be verified in the Public Security Bureau database are eligible to receive government subsidies.

(Image source: DigKey)

In the production process, DePIN device manufacturers use programs to generate a root key over a sufficiently long period, and then randomly select and write the root key into the chip using eFuse technology. For clarification, eFuse (Electrically Programmable Fuse) is an electronic technology used to store information in integrated circuits. The information programmed into eFuse is typically resistant to tampering or erasure, providing strong security assurance.

In this production flow, neither the device owner nor the manufacturer can access the device’s private key or the root key. Hardware devices can export and use working keys, including the private key for signing information and the public key for verifying device identity, within the Trusted Execution Environment (TEE) isolation environment. Individuals or programs outside the TEE environment cannot perceive the details of the keys.

In the aforementioned model, if you want to receive token incentives, you must purchase devices from the exclusive manufacturer. If Sybil attackers want to circumvent the device manufacturer and generate a large number of proofs of work at a low cost, they would need to crack the manufacturer’s security system and register their own generated key’s public key into the network permissioned devices. Sybil attackers would find it difficult to launch low-cost attacks unless the device manufacturer is involved in fraudulent activities.

If suspicions arise regarding the malpractice of device manufacturers, people can expose them through social consensus, which often leads to repercussions for the DePIN project itself. However, in most cases, device manufacturers, as key beneficiaries of the DePIN network protocol, do not have malicious motives. It’s because, if the network protocol operates smoothly, they can make more money selling mining machines than from DePIN mining. Therefore, they are more inclined to act in a non-malicious manner.

(Image source: Pintu Academy)

If hardware devices are not uniformly supplied by centralized manufacturers, the system needs to confirm that any device joining the DePIN network possesses the required protocol characteristics. For example, the system would check whether these newly added devices have exclusive hardware modules, as devices without such modules often cannot pass authentication. Acquiring the aforementioned hardware modules requires a certain amount of funds, which raises the cost of Sybil attacks and thus achieves the goal of countering Sybil attacks. In this scenario, it is wiser and more prudent to operate devices normally rather than engage in Sybil attacks.

Data tampering attacks

Let’s brainstorm a bit. If the system assigns higher rewards to data with greater volatility, such as air quality detection data collected by a device, then any device has ample motivation to fabricate data to deliberately exhibit higher volatility. Even devices authenticated by centralized manufacturers could tamper with the collected raw data during the data computation process.

How can we ensure that DePIN devices are honest and trustworthy, and that they do not arbitrarily modify the collected data? This requires the use of Trusted Firmware technology, with the most well-known being Trusted Execution Environment (TEE) and Secure Processing Environment (SPE). These hardware-level technologies ensure that data is executed on the device according to pre-verified programs and that there is no tampering during the computation process.

(Image source: Trustonic)

Here’s a brief overview: Trusted Execution Environment (TEE) is typically implemented within a processor or processor core to protect sensitive data and execute sensitive operations. TEE provides a trusted execution environment where code and data are safeguarded at the hardware level to prevent malicious software, malicious attacks, or unauthorized access. Hardware wallets such as Ledger and Keystone utilize TEE technology.

Most modern chips support TEE, especially those designed for mobile devices, IoT devices, and cloud services. Generally, high-performance processors, secure chips, smartphone SoCs (System-on-Chips), and cloud server chips integrate TEE technology because the applications involved often have high security requirements.

However, not all hardware supports trusted firmware. Some lower-end microcontrollers, sensor chips, and customized embedded chips may lack support for TEE. For these low-cost chips, attackers may resort to probe attacks to obtain identity information stored within the chip, enabling them to forge device identities and behavior. For example, attackers could extract private key data stored on the chip and then use the private key to sign tampered or forged data, making it appear as though the data originated from the device itself.

However, probe attacks rely on specialized equipment and precise operations, with a high cost of attack, far exceeding the cost of directly obtaining such low-cost chips from the market. Instead of profiting from attacking and forging identities of low-end devices through probe attacks, attackers would be more inclined to simply purchase more low-cost devices.

Data Source Attack Scenarios

As mentioned earlier, TEE can ensure that hardware devices generate data results truthfully, proving that the data has not been maliciously manipulated after being input into the device. However, it cannot ensure the trustworthiness of the data source before processing. This is akin to the challenges faced by oracle protocols.

For instance, if an air quality detector is placed near a factory emitting pollutants, but someone encloses the detector in a sealed glass jar at night, the data obtained by the air quality detector will be inaccurate. However, such attack scenarios are often unprofitable and unnecessary for attackers, as they involve significant effort without much benefit. For the DePIN network protocol, as long as devices undergo an honest and trustworthy computation process and meet the workload requirements specified by the incentive protocol, they should theoretically receive rewards.

Introduction of the solution

IoTeX

IoTeX provides the W3bStream development tool to integrate IoT devices into the blockchain and Web3. In the W3bStream IoT-side SDK, basic components such as communication and message passing, identity and credential services, and cryptographic services are included.

The IoT SDK of W3bStream offers comprehensive development of encryption functionalities, encompassing various implemented encryption algorithms such as PSA Crypto API, Cryptographic primitives, Cryptographic services, HAL, Tooling, Root of Trust, and other modules.

With these modules, it is possible to sign the data generated by devices in a secure or less secure manner on various hardware devices and transmit it over the network to subsequent data layers for verification.

DePHY

DePHY provides DID (Device ID) authentication services for IoT devices. Each device is forged with a DID by the manufacturer, with each device having one and only one corresponding DID. The metadata of the DID can be customized and may include device serial number, model, warranty information, and so on.

For hardware devices that support TEE, the manufacturer initially generates a key pair and uses eFuse to write the key into the chip. DePHY’s DID service can assist manufacturers in generating DID based on the device’s public key. The private key generated by the manufacturer is only stored in the IoT device or held by the manufacturer.

Because trusted firmware can achieve secure and reliable message signing and hardware-side private key confidentiality, if cheating behavior is detected in the network, such as the unauthorized generation of device private keys, it can generally be attributed to the manufacturer’s malpractice, allowing traceability back to the corresponding manufacturer.

After purchasing the device, DePHY users can obtain the activation information and then call the on-chain activation contract to associate and bind the hardware device’s DID with their own on-chain address, thereby integrating into the DePHY network protocol. After the IoT device completes the DID setting process, bidirectional data flow between the user and the device can be achieved.

When a user sends control commands to a device through their on-chain account, the process is as follows:

1. Verify that the user has access control permissions. As the device’s access control permissions are written in metadata form on the DID, permissions can be confirmed by checking the DID.

2. Allow the user and device to establish a private channel to support user control of the device. In addition to the NoStr relay, the DePHY relayer also includes peer-to-peer network nodes that can support point-to-point channels. Other nodes in the network can assist in relaying traffic. This supports users in controlling devices in real-time off-chain.

When IoT devices send data to the blockchain, the subsequent data layer reads the device’s permission status from the DID. Only devices that have been registered and permitted, such as those registered by the manufacturer, can upload data.

Another interesting feature of this DID service is the provision of functionality trait authentication for IoT devices. This authentication can identify whether IoT hardware devices possess specific functionalities, qualifying them to participate in incentive activities on specific blockchain networks. For example, a WiFi transmitter, by recognizing the LoRaWAN functionality trait, can be considered to provide wireless network connectivity and can thus participate in the Helium network. Similarly, there are GPS traits, TEE traits, and others.

In terms of expanding services, DePHY’s DID also supports participation in staking, linking to programmable wallets, and facilitating participation in on-chain activities.

peaq

peaq’s solution is quite unique, as it is divided into three levels: device-originated authentication, pattern recognition verification, and oracle-based authentication.

1. Device-Originated Authentication: peaq also provides the functionality to generate key pairs, allowing devices to sign information with private keys and bind device addresses (peaq ID) to user addresses. However, their open-source code does not include the implementation of trusted firmware functionality. peaq’s simple method of authenticating device information by signing it with private keys does not guarantee the integrity of device operation or data integrity. peaq seems more like an optimistic rollup, assuming that devices will not behave maliciously and then verifying the trustworthiness of the data in subsequent stages.

2. Pattern Recognition Verification: The second approach combines machine learning and pattern recognition. By learning from previous data to create a model, when new data is inputted, it is compared with the previous model to determine its credibility. However, statistical models can only identify anomalous data and cannot determine whether IoT devices are operating honestly. For example, a particular air quality monitor in city A may be placed in a basement, producing data different from other air quality monitors, but this does not necessarily indicate data falsification; the device may still be operating honestly. On the other hand, hackers are willing to use methods such as GANs to generate data that is difficult for machine learning models to distinguish, especially when the discriminative models are publicly shared.

3. Oracle-Based Authentication: The third approach involves selecting more trusted data sources as oracles and comparing the data collected by other DePIN devices to verify it. For example, if a project deploys a precise air quality monitor in city A, data collected by other air quality monitors that deviates significantly may be deemed untrustworthy. While this approach introduces and relies on authority in the blockchain, it may also introduce bias in the network’s data sampling due to the sampling bias of the oracle data source.

Based on current information, peaq’s infrastructure cannot guarantee the trustworthiness of devices and data on the IoT side. (Note: The author consulted peaq’s official website, development documentation, GitHub repository, and a draft whitepaper from 2018. Even after sending emails to the development team, no additional supplementary information was obtained before publication.)

Data Generation and Release (DA)

In the second stage of the DePIN workflow, the main task is to collect and validate the data transmitted by IoT devices, ensuring that the data is complete, accurate, and can be reliably delivered to specific recipients for further processing. This is known as the Data Availability Layer (DA layer).

IoT devices typically broadcast data and authentication information using protocols such as HTTP, MQTT, etc. When the data layer of the DePIN infrastructure receives information from the device side, it needs to verify the credibility of the data and aggregate the validated data for storage.

Here’s a brief introduction to MQTT (MQ Telemetry Transport): it is a lightweight, open, publish/subscribe-based messaging protocol designed for connecting constrained devices, such as sensors and embedded systems, to communicate in low-bandwidth and unreliable network environments. MQTT is particularly suitable for Internet of Things (IoT) applications.

In the process of verifying messages from IoT devices, there are two main aspects: device attestation and message authentication.

Device attestation can be achieved through Trusted Execution Environment (TEE). TEE isolates data collection code in a secure area of the device, ensuring secure data collection.

Another approach is zero-knowledge proofs (ZKPs), which allows devices to prove the accuracy of their data collection without revealing the underlying data details. This method varies depending on the device; for powerful devices, ZKPs can be generated locally, while for constrained devices, remote generation can be utilized.

After attesting the trustworthiness of the device, using Decentralized Identifiers (DIDs) to verify message signatures can confirm that the message is generated by that device.

Introduction to the Solution

IoTeX

In W3bStream, there are three main components: trusted data collection and verification, data cleansing, and data storage.

• Trusted data collection and verification utilize Trusted Execution Environment (TEE) and zero-knowledge proof methods to ensure the integrity and authenticity of the collected data.
• Data cleansing involves standardizing and unifying the format of data uploaded from different types of devices, making it easier to store and process.
• In the data storage stage, different application projects can choose different storage systems by configuring storage adapters.

In the current implementation of W3bStream, different IoT devices can either directly send data to W3bStream’s service endpoint or first collect data through a server before sending it to W3bStream’s server endpoint.

Upon receiving incoming data, W3bStream acts as a central dispatcher, distributing the data to different programs for processing. Within the W3bStream ecosystem, DePIN projects register and define event trigger logic (Event Strategy) and processing programs (Applets) on the W3bStream platform.

Each IoT device has a device account, which belongs to and can only belong to one project on W3bStream. Therefore, when messages from IoT devices are sent to the W3bStream server port, they can be redirected to a specific project based on the registered binding information, where data authenticity can be verified.

Regarding the event trigger logic mentioned earlier, it can be defined based on various event types that can be triggered, such as data received from HTTP API endpoints, MQTT topic subscriptions, detection of events recorded on the blockchain, or changes in blockchain height. Corresponding processing programs are then bound to handle these events.

In the processing programs (Applets), one or more execution functions are defined and compiled into WebAssembly (WASM) format. Data cleaning and formatting can be performed by these Applets. The processed data is then stored in the key-value database defined by the project.

DePHY

The DePHY project employs a more decentralized approach to handle and provide data, which they refer to as the DePHY Message Network.

The DePHY Message Network consists of permissionless DePHY relayer nodes. IoT devices can transmit data to any DePHY relayer node’s RPC port, where the incoming data is first processed by middleware and verified for trustworthiness using DID.

Data that passes the trust verification process needs to be synchronized across different relayer nodes to achieve consensus. The DePHY Message Network utilizes the NoStr protocol for this purpose. Originally designed for decentralized social media, NoStr’s adaptation for data synchronization in DePIN is remarkably fitting.

In the DePHY network, data fragments stored by each IoT device can be organized into a Merkle tree. Nodes synchronize the Merkle root and tree hash of this tree, enabling quick identification of missing data for retrieval from other relayers. This method efficiently achieves consensus finalization.

Node operation in the DePHY Message Network is permissionless, allowing anyone to stake assets and run DePHY network nodes. More nodes enhance network security and accessibility. DePHY nodes can receive rewards through Zero-Knowledge Contingent Payments (zkCP) when fulfilling data retrieval requests. Applications requiring data indexing pay fees to relayer nodes based on the availability of ZK proofs for data retrieval.

Anyone can access the DePHY network to monitor and read data. Project-operated nodes can set filtering rules to store only data relevant to their projects. By preserving raw data, the DePHY Message Network serves as a data availability layer for subsequent tasks.

DePHY protocol mandates relayer nodes to locally store received data for a period before transferring cold data to permanent storage platforms like Arweave. Treating all data as hot would increase storage costs and node operation barriers. By categorizing data into hot and cold, DePHY significantly reduces the operational costs of full nodes in the message network and better handles massive IoT data.

peaq

The first two approaches discussed involve off-chain data collection and storage, followed by rolling up the data onto the blockchain. This is because IoT applications generate massive amounts of data, and there are latency requirements due to communication delays. Executing DePIN transactions directly on the blockchain would face limited processing capabilities and high storage costs.

However, relying solely on node consensus introduces intolerable delays. Peaq takes a different approach by creating its own blockchain to directly handle and execute these computations and transactions. Built on Substrate, once the mainnet is launched, the increasing number of DePIN devices it supports may eventually overwhelm peaq’s performance bottleneck, making it unable to handle such a large volume of computations and transaction requests.

Due to the lack of trusted firmware functionality, peaq struggles to effectively verify the trustworthiness of data. In terms of data storage, peaq directly integrates IPFS distributed storage into its Substrate-based blockchain, as described in its development documentation.

Distributing Data to Different Applications

The third stage of the DePIN workflow involves extracting data from the data availability layer based on the requirements of blockchain applications. This data is then efficiently synchronized onto the blockchain through computation or zero-knowledge proofs.

Introduction to the Solution

IoTeX

W3bStream refers to this stage as Data Proof Aggregation. This part of the network consists of many aggregator nodes forming a computing resource pool shared by all DePIN projects.

Each aggregator node records its operational status on the blockchain, indicating whether it is busy or idle. When there is a computational demand from a DePIN project, an idle aggregator node is selected based on the status monitoring on the blockchain to handle the request.

The selected aggregator node first retrieves the required data from the storage layer, then performs computations on this data according to the requirements of the DePIN project, and generates proofs of the computation results. Finally, it sends these proof results to the blockchain for verification by smart contracts. Once the workflow is completed, the aggregator node returns to an idle state.

During the proof generation process, the aggregator node utilizes a layered aggregation circuit, which consists of four parts:

• Data compression circuit: Similar to a Merkle tree, it verifies that all collected data originates from a specific Merkle tree root.
• Signature batch verification circuit: Batch verifies the validity of data from devices, with each data associated with a signature.
• DePIN computation circuit: Proves that DePIN devices correctly executed specific instructions according to predefined computation logic. For example, verifying step counts in a healthcare project or verifying energy production in a solar power plant.
• Proof aggregation circuit: Aggregates all proofs into a single proof for final verification by Layer 1 smart contracts.

Data proof aggregation is crucial for ensuring the integrity and verifiability of computations in DePIN projects, providing a reliable and efficient method for verifying off-chain computations and data processing.

In the IoTeX ecosystem, the profit generation phase primarily occurs in this stage. Users can stake IOTX tokens to run aggregator nodes. The more aggregator nodes participate, the more computational processing power can be brought in, forming a computing layer with sufficient computational resources.

DePHY

At the data distribution level, DePHY provides a co-processor to monitor the finalized messages of the DePHY message network. After performing state changes, it compresses and packages the data before submitting it to the blockchain.

State change refers to the function of quasi-smart contracts used to process messages, customized by different DePIN project parties. This also includes computation and data processing schemes involving zkVM or TEE. The DePHY team provides project scaffolding to DePIN project parties for development and deployment, offering a high degree of freedom.

In addition to the coprocessor provided by DePHY, DePIN project parties can also use project scaffolding to integrate DA layer data into other infrastructure’s computing layers for on-chain implementation.

Comprehensive Analysis

Although the DePIN track is gaining momentum, there are still technical barriers to the widespread integration of IoT devices with blockchain. This article provides a technical review and analysis of the entire process, from trusted data generation by IoT devices to data validation, storage, proof generation through computation, and rollup to the blockchain. The aim is to support the integration of IoT devices into Web3 applications. For entrepreneurs in the DePIN track, it is hoped that this article can provide helpful insights and guidance in terms of methodology and technical design.

Among the three DePIN infrastructure projects analyzed, peaq remains somewhat reminiscent of online comments from six years ago—it’s just hype. DePHY and IoTeX have both opted for an off-chain data collection model, followed by rollup to the blockchain, allowing IoT device data to be integrated into the blockchain under conditions of low latency and ensure data integrity.

DePHY and IoTeX have their own focus areas. DePHY’s DID includes verification of hardware functionality traits, bidirectional data transmission, and other features. The DePHY message network places greater emphasis on decentralized data availability, serving more as a loosely coupled functional module combined with DePIN projects. IoTeX boasts a high level of development completeness, offering a complete development workflow and focusing more on binding processing programs to different events, leaning towards the computational layer. DePIN project parties can choose different technical solutions to suit their specific needs.

For readers involved in DePIN-related entrepreneurial projects, discussions and exchanges can be held with the author via Telegram.

References

https://www.trustedfirmware.org/

https://www.digikey.com/en/blog/three-features-every-secure-microcontroller-needs

https://medium.com/@colbyserpa/nostr-2-0-layer-2-off-chain-data-storage-b7d299078c60

https://transparency.dev

/https://github.com/Sovereign-Labs/sovereign-sdk

https://github.com/nostr-protocol/nips

https://www.youtube.com/watch?v=W9YMtTWHAdk

https://www.youtube.com/watch?v=JKKqIYNAuec

https://iotex.io/blog/w3bstream/

https://w3bstream.com/#sdks

https://docs.w3bstream.com/sending-data-to-w3bstream/introduction-1/technical-framework

https://dephy.io/https://docs.peaq.network/

https://docs.peaq.network/docs/learn/dePIN-functions/machine-data-verification/machine-data-verification-intro

https://www.reddit.com/r/Iota/comments/8ddjxq/peaq_white_paper_draft_is_here/

https://depinhub.io/https://tehranipoor.ece.ufl.edu/wp-content/uploads/2021/07/2017-DT-Probe.pdf

https://multicoin.capital/2022/04/05/proof-of-physical-work/

Statement:

1. This article is reproduced from [Geek Web3], original title “DePIN popular science article: How infrastructure such as IoTeX, DePHY and peaq works”, the copyright belongs to the original author [Long], if you have any objection to the reprint, please contact Gate Learn Team, the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team, not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.