Popular science about DePIN: How infrastructure such as IoTeX, DePHY and peaq works

Author: Pika, Sui public chain ambassador, DePIN researcher

Introduction:

Although the DePIN track is very hot at the moment, DePIN-related There are still technical obstacles for 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 need to go through the following three key stages:

1. Trustworthy operation of the hardware device;

2 . Collect verification and provide data;

3. Distribute data to different applications.

There are different attack scenarios and countermeasures in these three stages, and various mechanism designs need to be introduced. From the perspective of project workflow and protocol design, this article reviews and analyzes the entire process of IoT devices generating data from trustworthiness, verifying stored data, generating proof through calculation, and rolling up data to the blockchain. If you are an entrepreneur in the DePIN track, I hope this article can help your project development in terms of methodology and technical design.

In the following,we take the air quality detection scenario as an example and analyze it based on the three DePIN infrastructures: IoTeX, DePHY, and peaq, to ​​explain how the DePIN infrastructure works. This type of infrastructure platform can connect IoT devices and blockchain/Web3 facilities to help project parties quickly launch DePIN application projects.

Trustworthy operation of hardware devices

Trustworthiness of hardware devices, including trust in device identity and trust in program execution that can be verified without tampering.

DePIN’s basic working model

In the incentive schemes of most DePIN projects, the operators of hardware devices will provide services to the outside world as a bargaining chip. Ask for rewards from the incentive system. For example, in Helium, network hotspot devices obtain HNT rewards by providing signal coverage. But before obtaining incentives from the system, the DePIN device needs to provide evidence to prove that it has indeed put in a certain amount of "effort" as required.

This type of proof used to prove that one has provided certain types of services and performed certain activities in the real world is called proof of physical work(Proof of Physical Work, PoPW). In the protocol design of the DePIN project, physical proof of work plays a decisive role, and accordingly there are various attack scenarios and corresponding countermeasures.

The DePIN project relies on the blockchain to complete incentive distribution and token distribution. Similar to the public and private key system in traditional public chains, the identity verification process of DePIN devices also requires the use of public and private keys. The private key is used to generate and sign the "physical proof of work", and the public key is used by the outside world to verify the above. Proof, or as the identity tag (Device ID) of the hardware device.

In addition, it is inconvenient to directly use the device’s on-chain address to receive token incentives. Therefore, the DePIN project team often deploys a smart contract on the chain, which records different devices. The holder’s on-chain account address is similar to a one-to-one or many-to-one relationship in a database. In this way, the token rewards that should be received by off-chain physical devices can be directly transferred to the device holder's on-chain account.

Witch Attack

Most platforms that provide incentive mechanisms will encounter "Witch attacks", which means that someone may control a large number of accounts or devices, or generate different identity certificates, pretend to be multiple people, and receive multiple rewards. Take the air quality detection we mentioned earlier as an example. The more devices that provide this service, the more rewards the system will distribute. Someone can use technical means to quickly generate multiple copies of air detection data and corresponding device signatures, and create a large amount of physical proof of work to make a profit. This will cause the tokens of the DePIN project to suffer high inflation, so this type of cheating must be stopped.

The so-called anti-witches, if KYC and other privacy-destroying methods are not used, the most common measures are POW and POS. In the Bitcoin protocol, miners have to spend a lot of computing resources to obtain mining Mining rewards, POS public chain directly allows network participants to pledge a large amount of assets.

In the field of DePIN, anti-witch can be attributed to "raising the cost of generating physical proof of work". Since the generation of physical proof of work relies on valid device identity information (private key), Therefore, as long as the cost of obtaining identity information is raised, certain cheating behaviors that generate large amounts of proof of work at low cost can be prevented.

To achieve the above goals, a relatively effective solution is to let DePIN device manufacturers monopolize the generation authority of identity information, customize the devices, < strong>Enter a unique identity tag for each device. This is like having the Public Security Bureau uniformly record the identity information of all citizens, and only those who can be found in the Public Security Bureau database are eligible to receive government subsidies.

(Image source: DigKey)

In the production process, DePIN device manufacturers will use programs to generate root keys for a long enough time, and then randomly The selected root key is written into the chip using eFuse technology. To popularize science here, eFuse (programmable electronic fuse) is an electronic technology that stores information in integrated circuits. The entered information usually cannot be tampered with or erased, and has strong security guarantees.

Under this production process, neither the device holder nor the manufacturer can know the device’s private key and root key. Hardware devices can derive and use working keys from the root key in the isolation environment of TEE, including the private key used to sign information and the public key used to verify the identity of the device to the outside world. No one or program outside the TEE environment can perceive the details of the key.

Under the above model, if you want to obtain token incentives, you must purchase equipment from exclusive manufacturers. If a Sybil attacker wants to bypass the device manufacturer and generate a large number of proofs of work at low cost, he or she needs to crack the manufacturer's security system and register the public key for generating the key himself into a network-licensed device.It is difficult for a Sybil attacker Attacks can be launched at low cost, unless the equipment manufacturer is on guard.

Once people find that the equipment manufacturer has suspicious signs of doing evil, the DePIN equipment manufacturer can be exposed through social consensus, which will often cause the DePIN project itself to suffer. But in most cases, as the core beneficiary of the DePIN network protocol, equipment manufacturers mostly have no evil motives, because if the network protocol is allowed to operate in an orderly manner, the money earned from selling mining machines will be greater than that of DePIN Mining makes more money, so they are more inclined not to do evil.

(Picture source: Pintu Academy)

If the hardware equipment is not uniformly supplied by a centralized manufacturer, then when any device is connected When dePINing a network, the system must first confirm that the device has the characteristics required by the protocol. For example, the system will check whether these newly added devices have exclusive hardware modules. Devices without such modules often fail to pass certification. In order for the device to have the above-mentioned hardware modules, it will cost a certain amount of money, which will increase the cost of witch attacks, thereby achieving the purpose of anti-witch attacks. In this case, it is wiser and safer to run the device normally rather than create a Sybil attack.

Data tampering attack

Let us imagine that if the air quality detection data collected by a certain device becomes more volatile, If the data is strong, the system will consider the data to be more valuable and provide more rewards for it. Then any device will have sufficient motivation to falsify the data and deliberately show high volatility. Even devices used for identity authentication by centralized manufacturers can "include private goods" in the data calculation process and rewrite the original data collected.

How to ensure that the DePIN device is honest and trustworthy and has not arbitrarily modified the collected data? This requires the use of Trusted Firmware technology, the more famous of which are TEE (Trusted Execution Environment) and SPE (Secure Processing Environment). These hardware-level technologies can ensure that data is executed on the device according to pre-verified procedures, and there is no "private goods" in the calculation process.

(Picture source: Trustonic)

Here is a brief introduction, TEE (Trusted Execution Environment) is usually in the processor or processor core Implemented to protect sensitive data and perform sensitive operations. TEE provides a trusted execution environment where code and data are protected by hardware-level security to prevent malware, malicious attacks, or unauthorized access. For example, hardware wallets such as Leger and Keystone all use TEE technology.

Most modern chips support TEE, especially those targeting mobile devices, IoT devices, and cloud services. Normally, high-performance processors, security chips, smartphone SoCs (System-on-Chip) and cloud server chips will integrate TEE technology, because the application scenarios involved in these hardware often have a high pursuit of security.

However, not all hardware supports trusted firmware, and some lower-end microcontrollers, sensor chips, and custom embedded chips may lack support for TEE. For these low-cost chips, probe attacks and other means can be used to obtain the identity information retained in the chip, and then forge the identity and behavior of the device. For example, the attack obtains the private key data saved on the chip, and then uses the private key to sign the tampered or forged data, disguising it as data generated by the device itself.

However, probe attacks rely on specialized equipment and precise operations and data analysis processes. The cost of the attack is too high, much higher than the cost of directly obtaining such low-cost chips from the market. Rather than making money by cracking the identity information of forged low-end devices through probe attacks and other means, attackers would be more willing to directly purchase more low-cost devices.

Data source attack scenario

The TEE mentioned above can ensure that the hardware device faithfully generates data results, and can only prove that the data is input After entering the device, it has not been maliciously processed, but there is no way to ensure that the input source of the data is trustworthy before calculation and processing. This is actually similar to the problem faced by the oracle protocol.

For example, if an air quality detector is placed near a factory that emits exhaust gas, but someone covers the air quality detector with a sealed glass jar at night, then the air quality detector obtains The data must be untrue. However, the above attack scenarios are often unprofitable, and attackers do not need to do this most of the time because it is thankless. For the DePIN network protocol, as long as the device meets the honest and trustworthy computing process and puts in the workload required by the incentive protocol, it should theoretically be rewarded.

Project Introduction

IoTeX

IoTeX provides W3bStream development Tools to connect IoT devices to blockchain and Web3. The W3bStream IoT SDK includes basic components such as communication and messaging, identity and credential services, and cryptography services.

W3bStream's IoT SDK has very complete development of encryption functions and includes a variety of encryption Algorithm implementation, such as PSA Crypto API, Cryptographic primitives, Cryptographic services, HAL, Tooling, Root of Trust and other modules.

With these modules, the data generated by the device can be signed on various hardware devices in a safe or unsafe way, and passed to the subsequent data layer through the network for verification.

DePHY

DePHY provides DID (Device ID) authentication services on the IoT side. DID is cast by the manufacturer, and each device has only one corresponding DID. DID metadata can be customized and can include device serial number, model, warranty information, etc.

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 help manufacturers generate key pairs based on the device publicity. Key to generate DID. In addition to being written to the IoT device, the private key generated by the manufacturer is only held by the manufacturer.

Since trusted firmware can achieve safe and reliable message signatures and hardware-side private key confidentiality, if people find that there is cheating in the network to generate device private keys, they can basically be considered to be the device manufacturer. When doing evil,it can be traced back to the corresponding manufacturer, achieving trustful traceability.

After purchasing a device, DePHY users can obtain the activation information of the device, then call the activation contract on the chain, associate and bind the DID of the hardware device with their own address on the chain, and then access the DePHY network protocol. After the IoT device goes through the DID setting process, it can realize two-way data flow between the user and the device.

When the user sends control instructions to the device through the account on the chain, The process is as follows:

1. Confirm that the user has access control permissions. Since the access control permissions of the device are written on the DID in the form of metadata, the permissions can be confirmed by checking the DID;

2. Allow the user to open a private channel with the device to establish a connection to support the user to control the device. In addition to NoStr relay, DePHY relayer also contains peer-to-peer network nodes, which can support point-to-point channels and allow other nodes in the network to help relay traffic. It can support users to control devices in real time off the chain.

When an IoT device sends data to the blockchain, the subsequent data layer will read the permission status of the device from the DID. Only devices that are permitted through registration can upload data. For example, equipment registered by the manufacturer.

Another interesting feature of this DID service It provides functional feature (trait) certification of IoT devices. This certification can identify whether an IoT hardware device has certain functions that qualify it to participate in the incentive activities of a specific blockchain network. For example, if a WiFi transmitter is recognized as having the LoRaWAN function (trait), it can be considered to have the function of providing wireless network connection, and it can participate in the Helium network. Similarly, there are GPS traits, TEE traits, etc.

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

peaq

Peaq’s solution is rather unique. Its solution is divided into three levels, namely authentication from the device and pattern recognition. Verification, oracle-based authentication.

1. Authentication originating from the device. peaq also provides functions such as generating a key pair, using the private key to sign information on the device, and binding the device address peaq ID to the user address. However, the functional implementation of trusted firmware cannot be found in their open source code. peaq's simple authentication method of using a private key to sign device information cannot guarantee the integrity of the device and that the data has not been tampered with. peaq is more like an optimistic rollup, which defaults to a device that will not do evil, and then verifies the trustworthiness of the data in subsequent stages.

2. Pattern recognition verification. The second solution is to combine machine learning and pattern recognition. The model is obtained by learning the previous data. When new data is input, it is compared with the previous model to determine whether it is credible. However, statistical models can only identify abnormal data and cannot determine whether IoT devices are operating honestly.

For example, an air quality detector in city A is placed in the basement. The data collected and generated are different from other air quality detectors, but this does not mean that the data is forged and the equipment is still operating honestly. . On the other hand, as long as the benefits are large enough, hackers are also willing to use methods such as GAN to generate data that is difficult to identify by machine learning, especially when the discriminant model is publicly shared.

3. Oracle-based authentication. The third option is that they will select some more trusted data sources as oracles and compare and verify them with the data collected by other DePIN devices. For example, the project team deployed an accurate air quality detector in city A. If the data collected by other air quality detectors deviates too much, it will be considered unreliable.

On the one hand, this method introduces and relies on authority to the blockchain. On the other hand, it may also cause deviations in the entire network data sampling due to the sampling deviation of the oracle data source.

Based on the current information, peaq’s infrastructure cannot guarantee the trust of equipment and data on the Internet of Things side. (Note: The author checked peaq’s official website, development documents, Github repository, and only a draft of the 2018 white paper. Even after sending an email to the development team, I could not get more supplementary information before publishing. )

Data generation and release (DA)

The second stage in the DePIN workflow is mainly to collect and verify the data passed by the Internet of Things devices. , save it to provide data to subsequent stages,to ensure that the data can be sent to the specific recipient in a complete and recoverable manner. This is called the data availability layer (DA layer).

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

Introduced here, MQTT (MQ Telemetry Transport) is a lightweight, open, publish/subscribe model-based message transmission protocol, designed to be used to connect restricted devices, such as sensors and embedded systems that communicate in low-bandwidth and unstable network environments, making them ideal for Internet of Things (IoT) applications.

In the process of verifying the message of the IoT device, it will include the trusted execution of the device. Authentication and message authentication.

Authentication of device trusted execution can be combined with TEE. TEE ensures the secure collection of data by isolating the data collection code within a protected area of ​​the device.

Another approach is zero-knowledge proofs, which allow devices to prove the accuracy of their data collection without revealing the details of the underlying data. This scheme varies by device. For powerful devices, ZKP can be generated locally, and for restricted devices, it can be generated remotely.

After authenticating the trust of the device, using the DID to verify the message signature, you can determine that the message was generated by the device.

Solution introduction

IoTeX

In W3bStream, it is divided into trusted data Collection, verification, data cleaning, and data storageThese three parts.

• The collection and verification of trusted data use TEE and zero-knowledge proof methods.

• Data cleaning refers to unifying and standardizing the format of data uploaded from different types of devices to facilitate storage and processing.

• The data storage link allows different application projects to choose different storage systems by configuring storage adapters.

In the current W3bStream implementation, different Internet of Things devices can directly send data to the W3bStream service terminal, or they can first collect the data through the server and then send it to the W3bStream server terminal.

When receiving incoming data, W3bStream will act like a central distribution scheduler and distribute the incoming data to different programs for processing. The DePIN project in the W3bStream ecosystem, Will apply for registration on W3bStream and define event triggering logic (Event Strategy) and handler (Applet).

Each IoT device will have a device account, which belongs to one and only one project on W3bStream. Therefore, when a message from an IoT device is delivered to the W3bStream service port, it can first be redirected to a project based on the registered binding information, and the authenticity of the data can be verified.

As for the event triggering logic mentioned earlier, you can define the data information received from the HTTP API terminal, MQTT topic, as well as detect the event record on the blockchain, detect the blockchain height, etc. The type of event (Event triggers) being triggered, and binding the corresponding handler to handle it.

One or more execution functions are defined in the handler (Applet) and are compiled into WASM format. Data cleaning and formatting can be performed through Applet. The processed data is stored in the key-value database defined by the project.

DePHY

DePHY The project adopts a more decentralized way to process and provide data, which they call DePHY Message network.

The DePHY message network consists of unlicensed DePHY relay nodes (relayers). IoT devices can pass data in through the RPC port of any DePHY relay node. The incoming data will first call the middleware and combine it with DID to verify that the data is trustworthy.

Data verified by trust needs to be synchronized between different relay nodes to form a consensus. TheDePHY message network is implemented using the NoStr protocol. NoStr was originally used to build decentralized social media. Remember when someone used NoStr to replace Twitter and it became popular. It is also cleverly suitable to be used in the synchronization of DePIN data.

In the DePHY network, the data fragments stored by each IoT device can be organized into a Merkle tree. The nodes will synchronize the root of the Merkle tree with each other, as well as the tree of the entire tree. hope. When a Relayer obtains the above-mentioned Merkle Root and Tree hashes, it can quickly locate the missing data and easily obtain it from other Relayers. This method can achieve consensus confirmation (Finalize) extremely efficiently.

The node operation of the DePHY message network is permissionless. Anyone can stake assets and run DePHY network nodes. The more nodes there are, the more secure and accessible the network is. DePHY nodes can receive rewards through zk conditional payments (Zero-Knowledge Contingent Payments). In other words, when an application with data indexing requirements requests data from a DePHY relay node, it will decide how much to pay to the relay node based on the ZK certificate of whether the data can be retrieved.

At the same time, anyone can access the DePHY network to monitor and read data. Nodes operated by project parties can set filtering rules to only store DePIN device data related to their own projects. Due to the precipitation of raw data, the DePHY message network can serve as a data availability layer for other subsequent tasks.

The DePHY protocol requires the relay node to store the received data locally for at least a period of time during operation, and then transfer the cold data to a permanent storage platform such as Arweave. If all data is treated as hot data, it will eventually increase the storage cost of the node, thereby raising the threshold for running a full node, making it difficult for ordinary people to run a full node.

Through the design of hot and cold data classification processing, DePHY can greatly reduce the operating costs of all nodes in the message network, and can better cope with massive IoT data.

peaq

The previous two solutions are to collect and store data on the chain for execution, and then roll it up to the blockchain. This is because the amount of data generated by IoT applications is huge and also requires communication delay. If you directly execute DePIN transactions on the blockchain, the data processing capacity is limited and the storage cost is high.

Just waiting for node consensus will cause intolerable delay problems. Peaq took a different approach and built a public chain to directly carry and execute these calculations and transactions. It is developed based on Substrate. When the main network is actually online and the number of DePIN devices it carries increases, it will eventually be unable to carry such a large number of calculation and transaction requests due to peaq's performance bottleneck.

Since peaq does not have the function of trustworthy firmware, it is basically unable to effectively verify the trustworthiness of the data. In terms of data storage, peaq directly introduced in the development documentation how to connect IPFS distributed storage to the blockchain based on substrate.

Distribute data to different applications

The third stage in the DePIN workflow is to distribute the data according to the needs of the blockchain application. The data of the available layer is extracted, and the execution results are efficiently synchronized to the blockchain through execution of operations or zero-knowledge proofs.

Project Introduction

IoTeX

W3bStream calls this stage data Data Proof Aggregation. This part of the network consists of many aggregator nodes (Aggregator Nodes) forming a computing resource pool (computing resource pool), which is shared and called by all DePIN projects.

Each aggregator node will record its working status on the blockchain, whether it is busy or idle. When the computing requirements of the DePIN project come over, idle aggregator nodes are selected to process them based on the status monitoring (monitor) on the chain.

The selected aggregator node will first be retrieved from the storage layer Required data; then perform operations on these data according to the needs of the DePIN project, and generate proof of the operation results; finally, send the proof results to the blockchain for smart contracts to verify. After completing the workflow, the aggregator node returns to the idle state.

The aggregator node uses a layered aggregation circuit when generating proofs. The hierarchical aggregation circuit consists of four parts:

• Data compression circuit: Similar to a Merkle tree, verify that all collected data comes from a specific Merkle tree root.

• Signature batch verification circuit: Batch verification of the validity of data coming from the device, each data is associated with a signature.

• DePIN calculation circuit: Prove that the DePIN device correctly executes some instructions according to specific calculation logic, such as verifying the number of steps in a medical health project, or in Verification of the energy produced in a solar power plant.

• Proof aggregation circuit: Aggregates all proofs into a single proof for final verification by Layer1 smart contracts.

Data proof aggregation is essential to ensure that the DePIN project The integrity and verifiability of calculations are crucial, providing a reliable and efficient method for verifying off-chain calculations and data processing.

The revenue link of IoTeX is also mainly at this stage. Users can run aggregator nodes by pledging IOTX tokens. The more aggregators participate, the more computing processing power will be brought and a computing layer with sufficient computing power will be formed.

DePHY

At the data distribution level, DePHY provides a coprocessor to monitor the finalized messages of the DePHY message network and perform state migration (State After change), the data is packaged, compressed and submitted to the blockchain.

State migration is a smart contract-like function used to process messages. It is customized by different DePIN project parties and also includes zkVM or TEE computing packaged data processing solutions. This part is developed and deployed by the DePHY team to provide project scaffolding (Scaffold) to the DePIN project, with a high degree of freedom.

In addition to the co-processor provided by DePHY, the DePIN project party can also connect the DA layer data to the computing layer of other infrastructure according to the project scaffolding to achieve on-chain implementation.

Comprehensive analysis

Although the DePIN track is hot, there are still technical obstacles for IoT devices to be connected to the blockchain on a large scale. From the perspective of technical implementation, this article reviews and analyzes the entire process of IoT devices generating data from trustworthiness, verifying stored data, generating proof through calculation and rolling data to the blockchain, thereby supporting the integration of IoT devices into Web3 applications. If you are an entrepreneur in the DePIN track, I also hope that this article can be helpful to project development in terms of methodology and technical design.

Among the three DePIN infrastructures selected for analysis, peaq is still just hype like the online comments six years ago. Both DePHY and IoTeX chose to collect IoT device data off-chain. , and then rolled up to the working mode on the chain, which can connect IoT device data to the blockchain with low latency and ensuring the credibility of the device data.

DePHY and IoTeX have their own focuses. DePHY’s DID includes verification of hardware function traits, two-way data transmission and other features. DePHY message network focuses more on the decentralized data availability layer and is more of a Low-coupling functional modules are combined with the DePIN project; IoTeX has a high degree of development integrity and a complete development workflow. It focuses more on binding handlers to different events and is biased toward the computing layer. DePIN project parties can choose different technical solutions to combine according to actual needs.