Author: Pika, Sui Chain Ambassador, DePIN Researcher

Editor: Faust, Geek web3

Preface: Although the DePIN track is currently very hot, there are still technical barriers for IoT devices related to DePIN to be massively connected to the blockchain. Generally speaking, to connect IoT hardware to the blockchain, the following three key stages need to be passed through:

1. Trusted operation of hardware devices;
2. Collecting, verifying, and providing data;
3. Distributing data to different applications.

Different attack scenarios and countermeasures exist in these three stages, requiring the introduction of various mechanism designs. From the perspective of project workflow and protocol design, this article reviews and analyzes the entire process of IoT devices from trusted data generation, verification and storage of data, proof generation 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 help your project development in terms of methodology and technical design.

In the following text, we use the scenario of air quality detection as an example, combined with the analysis of the three DePIN infrastructure, IoTeX, DePHY, and peaq, to clarify how the DePIN infrastructure works. Such infrastructure platforms can connect IoT devices with blockchain/Web3 facilities, helping project parties to quickly launch DePIN application projects.

Trusted Operation of Hardware Devices

The trustworthiness of hardware devices includes the trust of device identity and the verifiability of program execution.

Basic Operation Mode of DePIN

In the incentive schemes of most DePIN projects, the operators of hardware devices will provide services to the outside world in exchange for rewards from the incentive system. For example, in Helium, network hotspots earn HNT rewards by providing signal coverage. However, before obtaining incentives from the system, DePIN devices need to present evidence to prove that they have indeed made certain "efforts."

This type of evidence that proves that certain services have been provided or certain activities have been carried out in the real world is called Proof of Physical Work (PoPW). In the protocol design of DePIN projects, physical work proof plays a crucial role, and there are various attack scenarios and corresponding countermeasures.

DePIN projects need to rely on the blockchain to distribute incentives and allocate tokens. Similar to the public-private key system in traditional public chains, in the identity verification process of DePIN devices, public and private keys are also required. The private key is used to generate and sign "physical work proofs," while the public key is used by the outside world to verify the above proofs or as the device's identity label (Device ID).

In addition, it is not convenient to directly receive token incentives with the device's on-chain address. Therefore, DePIN project parties often deploy a smart contract on the chain, which 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 the off-chain physical device should receive can be directly sent to the on-chain account of the device holder.

Sybil Attack

In the majority of platforms that provide incentive mechanisms, they will encounter "Sybil attacks," which means that someone may control a large number of accounts or devices, or generate different identity proofs to disguise as multiple individuals and obtain multiple rewards. Taking the aforementioned air quality detection as an example, the more devices that provide this service, the more rewards the system will distribute. Through technical means, someone can quickly generate multiple air quality detection data and corresponding device signatures to create a large number of physical work proofs for profit, which would lead to high inflation of tokens in DePIN projects, so it is necessary to prevent such cheating behavior.

The so-called anti-Sybil measures, if not using privacy-destructive methods such as KYC, are most commonly implemented through POW and POS. In the Bitcoin protocol, miners need to expend a large amount of computing resources to obtain mining rewards, while in POS public chains, network participants directly stake a large amount of assets.

In the DePIN field, anti-Sybil can be attributed to "raising the cost of generating physical work proofs." Since the generation of physical work proofs depends on valid device identity information (private key), as long as the cost of obtaining identity information is raised, it can prevent cheating behavior of generating a large number of work proofs at low cost.

For the above goal, a relatively effective solution is for DePIN device manufacturers to monopolize the generation permission of identity information, customizing the devices and inputting a unique identity label for each device. This is similar to the unified recording of citizens' identity information by the public security bureau, and only those whose information can be checked in the public security bureau's database are eligible to receive government subsidies.

In the production process, DePIN device manufacturers use programs to generate root keys for a sufficient period of time, and then randomly select root keys to be written into chips using eFuse technology. It is worth noting that eFuse (electrically programmable fuse) is an electronic technology used to store information in integrated circuits, and the recorded information is usually difficult to tamper with or erase, providing strong security.

In this production process, neither the device holder nor the manufacturer can obtain the device's private key and 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, in a TEE isolated environment. People or programs outside the TEE environment cannot perceive the details of the keys.

In the above mode, if you want to obtain token incentives, you must purchase the device from an exclusive manufacturer. To bypass the device manufacturer and generate a large number of work proofs at low cost, Sybil attackers need to crack the manufacturer's security system and register their own generated key's public key in the network-permitted devices. Sybil attackers find it difficult to launch attacks at low cost, unless the device manufacturer is colluding with them.

Once suspicions arise about the device manufacturer's wrongdoing, people can expose the DePIN device manufacturer through social consensus, which often leads to the DePIN project itself being affected. However, in most cases, device manufacturers, as the core beneficiaries of the DePIN network protocol, are less likely to have malicious motives, because if they ensure the orderly operation of the network protocol, they can earn more money by selling mining machines than by mining in DePIN.

If hardware devices are not uniformly supplied by centralized manufacturers, then when any device connects to the DePIN network, the system needs to first confirm that the device has the required characteristics of the protocol. For example, the system will check whether these newly added devices have exclusive hardware modules, and devices without such modules often cannot pass the authentication. To equip devices with the above hardware modules, a certain amount of funds is required, which raises the cost of Sybil attacks and achieves the goal of anti-Sybil. In this case, it is wiser and more prudent to operate devices normally rather than to engage in Sybil attacks.

Data Tampering Attack

Let's imagine that if the fluctuation of the air quality detection data collected by a device is stronger, the system will consider the data more valuable and provide more rewards for it. Therefore, any device has sufficient motivation to forge data and deliberately show high volatility. Even devices authenticated by centralized manufacturers can "smuggle" during the data calculation process and modify the collected raw data.

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

Here's a brief introduction: TEE (Trusted Execution Environment) is usually implemented in processors or processor cores to protect sensitive data and execute sensitive operations. TEE provides a trusted execution environment where code and data are secured at the hardware level to prevent malicious software, attacks, or unauthorized access. For example, hardware wallets like Ledger and Keystone use TEE technology.

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

However, not all hardware supports Trusted Firmware, and some low-end microcontrollers, sensor chips, and custom embedded chips may lack support for TEE. For these low-cost chips, it is possible to obtain the device's identity information through probe attacks, and then forge device identity and behavior. For example, attackers could obtain the private key data stored on the chip through a probe attack, and then use the private key to sign tampered or forged data, masquerading as data generated by the device itself.

But probe attacks depend on specialized equipment and precise operations, and the cost of the attack is too high, far exceeding the cost of directly obtaining these low-cost chips from the market. Compared to profiting from cracking and forging the identity information of low-end devices through probe attacks, attackers would be more willing to directly purchase more low-cost devices.

Data Source Attack Scenarios

As mentioned earlier, TEE can ensure that hardware devices generate data results truthfully and can only prove that the data has not been maliciously processed after being input into the device. However, it cannot ensure the trustworthiness of the data source before the calculation process, which is similar to the problem faced by oracle protocols.

For example, if an air quality detector is placed near a factory emitting exhaust gases, but someone covers the air quality detector with a sealed glass jar at night, the data obtained by the air quality detector will definitely be inaccurate. However, the above attack scenario is often not profitable, and attackers mostly have no reason to do so because it is not worth the effort. For the DePIN network protocol, as long as the device undergoes an honest and trustworthy calculation process and meets the workload required by the incentive protocol, it should theoretically receive rewards.

Solution Introduction

• IoTeX

IoTeX provides the W3bStream development tool to connect IoT devices to the blockchain and Web3. The W3bStream IoT SDK includes basic components such as communication and message passing, identity and credential services, and cryptographic services.

The W3bStream IoT SDK has comprehensive development of encryption functions, including the implementation of various encryption algorithms such as PSA Crypto API, Cryptographic primitives, Cryptographic services, HAL, Tooling, and Root of Trust modules.

With these modules, data generated by various hardware devices can be signed in a secure or semi-secure manner and transmitted over the network to subsequent data layers for verification.

• DePHY

DePHY provides DID (Device ID) authentication services on the IoT side. DID is forged by the manufacturer, and each device has one and only one corresponding DID. The metadata of DID can be customized and may include device serial numbers, models, warranty information, and more.

For hardware devices that support TEE, the manufacturer initially generates key pairs and uses eFuse to write the keys into the chip. The DID service of DePHY can help the manufacturer generate DID based on the device's public key. The private key generated by the manufacturer is only held by the manufacturer.

Since Trusted Firmware can achieve secure message signing and hardware-side private key confidentiality, if cheating behavior in generating device private keys is found in the network, it can be assumed that the device manufacturer is acting maliciously, and the traceability can be linked back to the corresponding manufacturer, achieving trust traceability.

After purchasing the device, DePHY users can obtain the device's activation information, then call the on-chain activation contract to associate and bind the hardware device's DID with their on-chain address, thereby connecting to the DePHY network protocol. After the DID setup process, IoT devices can achieve bidirectional data flow between users and devices.

When users send control commands to devices through their on-chain accounts, the process is as follows:

1. Confirm that the user has access control permissions. Since the device's access control permissions are written in metadata form on the DID, permissions can be confirmed by checking the DID.
2. Allow users and devices to establish a private channel for connection 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, with other nodes in the network helping to relay traffic. This supports real-time off-chain control of devices by users.

When IoT devices send data to the blockchain, the subsequent data layer reads the device's permission status from the DID, and only devices registered by the manufacturer are allowed to upload data.

Another interesting feature of this DID service is that it provides authentication of the functional characteristics (traits) of IoT devices. This authentication can identify whether IoT hardware devices have specific functions, qualifying them to participate in incentive activities on specific blockchain networks. For example, a WiFi transmitter, by recognizing the LoRaWAN function (trait), can be considered to provide wireless network connectivity and can participate in the Helium network. Similarly, there are GPS traits, TEE traits, and more.

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, divided into three levels: device-originated authentication, pattern recognition verification, and oracle-based authentication.

1. Device-Originated Authentication. peaq also provides key pair generation, using the private key to sign information on the device, and binding the device address peaq ID to the user's address and other functional functions. However, the implementation of Trusted Firmware functionality cannot be found in their open-source code. peaq's simple method of using the private key to sign device information for authentication cannot guarantee the honest operation of the device and the integrity of the data. peaq seems more like an optimistic Rollup, assuming that devices will not act maliciously, and then verifying the trustworthiness of the data in subsequent stages.

2. Pattern Recognition Verification. The second solution combines machine learning and pattern recognition. By learning from previous data to create a model, when new data is input, it is compared to the previous model to determine its trustworthiness. However, statistical models can only identify abnormal data and cannot determine whether IoT devices are operating honestly.

For example, if an air quality detector in city A is placed in a basement and the data it collects differs from other air quality detectors, it does not necessarily mean the data is forged; the device may still be operating honestly. On the other hand, if the potential profit is high enough, hackers are willing to use methods like GAN to generate data that is difficult for machine learning to distinguish, especially when the discriminative model is publicly shared.

3. Oracle-Based Authentication. The third solution involves selecting more trusted data sources as oracles to compare and verify the data collected by other DePIN devices. For example, if a precise air quality detector is deployed by the project team in city A, data collected by other air quality detectors that deviates too much is considered untrustworthy.

This approach introduces and relies on authority to the blockchain, but it may also introduce bias in the entire network data sampling due to sampling bias in the oracle data source.

Based on the current information available, peaq's infrastructure cannot guarantee the trustworthiness of devices and data in the IoT field. (Note: The author has reviewed peaq's official website, development documents, GitHub repository, and a draft of the white paper from 2018. Even after sending an email to the development team, no additional explanatory materials were obtained before the article was published.)

Data Generation and Distribution (DA)

The second stage of the DePIN workflow mainly involves collecting and verifying data transmitted by IoT devices, storing it, and providing it to subsequent stages, ensuring that the data can be sent to specific recipients in a complete and error-free manner that can be restored, known as the Data Availability Layer (DA layer).

IoT devices often broadcast data and authentication information through protocols such as HTTP and MQTT. When the data layer of the DePIN infrastructure receives information from the device side, it needs to verify the trustworthiness of the data and aggregate and store the verified data.

Here's a brief introduction: MQTT (MQ Telemetry Transport) 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 unstable network environments, making it ideal for Internet of Things (IoT) applications.

In the process of verifying messages from IoT devices, it includes device trust execution authentication and message authentication.

Device trust execution authentication can be combined with TEE. TEE ensures secure data collection by isolating the data collection code in the device's protected area.

Another method is zero-knowledge proof, which allows devices to prove the accuracy of their data collection without revealing the details of the underlying data. This approach varies depending on the device; powerful devices can generate ZKP locally, while restricted devices can generate it remotely.

After authenticating the trust of the device, using DID to verify message signatures can confirm that the message was generated by the device.

Solution Introduction

• IoTeX

In W3bStream, it is divided into three parts: trusted data collection and verification, data cleansing, and data storage.

- Trusted data collection and verification use TEE and zero-knowledge proof methods.
- Data cleansing involves standardizing and formatting data from different types of devices for storage and processing.
- 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 directly send data to the W3bStream service terminal or collect data through a server before sending it to the W3bStream server terminal.

When receiving incoming data, W3bStream distributes the data to different programs for processing like a central dispatch scheduler. DePIN projects within the W3bStream ecosystem will apply for registration on W3bStream and define event trigger logic (Event Strategy) and processing programs (Applet) on W3bStream.

Each IoT device has a device account, belonging to and only able to belong to one project on W3bStream. Therefore, when the message from an IoT device reaches the W3bStream server port, it can be redirected to a specific project based on the registration binding information and the data's trustworthiness can be verified.

As for the previously mentioned event trigger logic, it can define the types of events that can be triggered, such as data information received from HTTP API terminals, MQTT topics, events recorded on the blockchain, and blockchain heights, and bind corresponding processing programs to handle them.

The processing program (Applet) defines one or more execution functions compiled into the WASM format. Data cleansing and formatting can be performed through the Applet. The processed data is then stored in the key-value database defined by the project.

• DePHY

The DePHY project adopts a more decentralized approach to handle and provide data, which they call the DePHY Message Network.

The DePHY Message Network consists of permissionless DePHY relayer nodes. IoT devices can transmit data through the RPC port of any DePHY relayer node, and the incoming data will first call the middleware to verify its trustworthiness in combination with DID.

The data verified through trust needs to be synchronized between different relay nodes to form a consensus. The DePHY message network uses the NoStr protocol to achieve this. The original purpose of NoStr was to build a decentralized social media platform. Do you remember when someone used NoStr as a replacement for Twitter and it became popular? It's quite clever to use it for data synchronization in the DePIN network.

In the DePHY network, each data fragment stored by IoT devices can be organized into a Merkle tree. Nodes will synchronize the root of this Merkle tree and the tree hash of the entire tree with each other. When a Relayer receives the Merkle Root and Tree hash, it can quickly identify which data is missing and easily obtain the missing data from other Relayers. This method efficiently achieves consensus confirmation (Finalize).

The operation of nodes in the DePHY message network is permissionless, allowing anyone to stake assets and run DePHY network nodes. The more nodes there are, the higher the network's security and accessibility. DePHY nodes can receive rewards through Zero-Knowledge Contingent Payments (zkCP). This means that applications with data indexing needs can decide how much to pay the relay nodes based on the ZK proof of data retrieval when requesting data from the DePHY relayer nodes.

Additionally, anyone can access the DePHY network to listen to and read data. Nodes operated by project teams can set filtering rules to only store data from DePIN devices relevant to their own projects. By storing the original data, the DePHY message network can serve as the data availability layer for subsequent tasks.

The DePHY protocol requires relayer nodes to store received data locally for a period of time during operation, and then transfer the cold data to permanent storage platforms like Arweave. Treating all data as hot data would increase the storage cost for nodes and raise the barrier for running full nodes, making it difficult for ordinary people to run full nodes.

By classifying data into cold and hot data, DePHY can significantly reduce the operating costs of full nodes in the message network and better handle massive IoT data.

• peaq

The first two solutions place data collection and storage off-chain and then roll it up to the blockchain. This is because the volume of data generated by IoT applications is extremely large, and there are also requirements for communication latency. Executing DePIN transactions directly on the blockchain would be limited by data processing capabilities and high storage costs.

The intolerable delay caused by waiting for node consensus is a significant issue. However, peaq has taken a different approach by building its own public chain to directly handle and execute these computations and transactions. It is developed based on Substrate. When the mainnet goes live and the number of DePIN devices increases, peaq's performance bottleneck may eventually prevent it from handling such a large volume of computations and transaction requests.

Due to the lack of trusted firmware functionality, peaq is unable to effectively verify the trustworthiness of the data. In terms of data storage, peaq directly introduces how to integrate IPFS distributed storage into the substrate-based blockchain in its development documentation.

Distributing Data to Different Applications

The third stage of the DePIN workflow involves extracting the data from the data availability layer according to the needs of blockchain applications, efficiently synchronizing the execution results to the blockchain through computation or zero-knowledge proofs.

Solution Introduction

• 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 working status on the blockchain, indicating whether it is busy or idle. When there is a computing demand from a DePIN project, an idle aggregator node is selected based on the status monitoring on the chain to handle the request.

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

When generating proofs, the aggregator node uses a layered aggregation circuit. The layered aggregation circuit consists of four parts:

• Data Compression Circuit: Similar to a Merkle tree, it verifies that all collected data comes from a specific Merkle tree root.
• Signature Batch Verification Circuit: It batch verifies the validity of data from devices, with each data associated with a signature.
• DePIN Computation Circuit: It proves that DePIN devices correctly executed specific instructions according to certain computation logic, such as verifying step counts in a healthcare project or verifying energy generated in a solar power plant.
• Proof Aggregation Circuit: It aggregates all proofs into a single proof for final verification by the Layer1 smart contract.

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.

The revenue aspect of IoTeX is mainly in this stage, where users can run aggregator nodes by staking IOTX tokens. The more aggregator nodes participate, the more computational processing power is available, forming a computing layer with sufficient computing power.

• DePHY

In terms of data distribution, DePHY provides a co-processor to listen to finalized messages from the DePHY message network, perform state changes, compress and submit data to the blockchain.

State change is a function of a message-handling quasi-smart contract customized by different DePIN project teams, including computation and data processing schemes using zkVM or TEE. The DePHY team provides project scaffolding to DePIN project teams for development and deployment, offering a high degree of freedom.

In addition to the co-processor provided by DePHY, DePIN project teams can use the project scaffolding to integrate DA layer data into the computing layer of other infrastructure, achieving on-chain integration.

Comprehensive Analysis

Despite the hot trend of the DePIN race, there are still technical obstacles to the large-scale integration of IoT devices into the blockchain. This article reviews and analyzes the entire process of IoT devices generating trustworthy data, verifying and storing data, generating proofs through computation, and rolling up data to the blockchain from a technical implementation perspective, in order to support the integration of IoT devices into Web3 applications. If you are an entrepreneur in the DePIN race, it is hoped that this article can provide some help in terms of methodology and technical design for project development.

In the analysis of the three DePIN infrastructures, peaq still seems to be just hype, as it was six years ago in online comments. DePHY and IoTeX both choose the off-chain data collection from IoT devices and then roll it up to the chain, enabling the integration of IoT device data into the blockchain with low latency and ensuring the trustworthiness of the device data.

DePHY and IoTeX each have their own focus. DePHY's DID includes hardware function trait verification, bidirectional data transmission, and other features. The DePHY message network focuses more on the decentralized data availability layer and serves as a loosely coupled functional module combined with DePIN projects. IoTeX has a high level of development completeness, with a complete development workflow, and focuses more on binding handlers to different events, leaning towards the computing layer. DePIN project teams can choose different technical solutions to combine according to their actual needs.

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/peaqwhitepaperdraftis_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/

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。