Decentralized Verification in DePIN

In this article, we dive into the topic of decentralized verification within DePINs, critically analyze existing solutions, and suggest innovative avenues that promise scalability without compromising on security and decentralization.

Decentralized Verification in DePIN

By IoTeX Co-Founder and CEO Raullen Chai and IoTeX Researcher Andrew Law

Decentralized Physical Infrastructure Networks (DePINs) represent a transformative shift in how we envision and organize real-world systems, spanning areas such as energy, transportation, and telecommunications. By intertwining blockchains, cryptocurrencies, and smart contracts with smart devices, DePINs offer the ability to coordinate physical infrastructure in a decentralized and peer-to-peer fashion. As Guy Woullet of a16z has pointed out, the success of DePINs hinges on addressing a pivotal challenge: ensuring trusted verification of geographically dispersed service nodes without the need for central authority. In this article, we dive into the topic of decentralized verification within DePINs, critically analyze existing solutions, and suggest innovative avenues that promise scalability without compromising on security and decentralization.

The Rise of DePIN

DePINs harness the power of blockchains and smart contracts to forge open marketplaces for services rooted in physical infrastructure. Consider an energy-based DePIN: homeowners equipped with solar panels could potentially produce electricity and channel surplus energy to their neighbors. Facilitated by blockchains and executed via smart contracts, these energy transactions are autonomously documented and settled. Central to this process are IoT devices, such as batteries and other micro grid-connected hardware, which make it feasible for homes to distribute energy in a trustable, direct peer-to-peer fashion, eliminating the need for utility companies as middlemen.These decentralized physical infrastructure networks are gaining traction across diverse sectors in 2023. By sidelining centralized gatekeepers, DePINs are poised to enhance efficiency, diminish costs, amplify accessibility, and bestow greater agency to individuals.

The Anatomy of DePIN

Decentralized physical infrastructures lean on a sophisticated tech stack that melds hardware, connectivity, middleware, blockchain-based smart contracts and web or mobile apps.

Table 1 from "A Taxonomy for Blockchain-based Decentralized Physical Infrastructure Networks (DePIN)"

Zooming into a typical DEPIN network (think DIMO or Helium or WiFimap or GeoDnet), there are usually three roles:

  • Service nodes: a collection of servers or devices providing services or utilities, e.g., WiFi/5G, environmental data collection, and energy production.
  • Middleware: a layer that mostly focus on verify whether service nodes are working as expected. It ensures accurate representation and reporting of real-world activities and events from service nodes to smart contracts, which can be tightly linked to how DEPIN tokens work.
  • End users: a community of everyday people or businesses who actually use the utilities provided by the service nodes or devices.Among these, the middleware is responsible for measuring the quality of service or utility from nodes by tracking certain metrics, the lack of which could lead to, as mentioned here:
  1. Self-dealing: Participants might exploit the network by availing services from the infrastructure they own,  accruing fees and rewards. To illustrate, an energy entity could simulate purchasing energy from its own reserves. Given ample subsidies or initial block rewards, self-dealing turns lucrative.
  2. Lazy Providers: Infrastructure purveyors might pledge services but either renege on their commitments or provide sub-par services. In the absence of a rigorous verification system, users are left without recourse.
  3. Malicious Providers: Though rarer compared to the first two, there's a possibility of malevolent entities manipulating infrastructure, persuading users to accept spurious sensor data that aligns with the provider's financial interests.Unchecked behaviors can destabilize DePINs' economic incentives. Trust and network efficiency decline, leading to either a "tragedy of the commons" with providers seeking self-gain or power centralization. In both cases, the aim of a decentralized, peer-driven infrastructure is undermined.

The Middleware For Verification

Bitcoin's proof-of-work is an early form of DEPIN verification. It leverages vast amounts of hash power to ensure security, with every node in the global Bitcoin network playing a part in verification. DEPIN verification nowadays employs a similar ethos. Here, service nodes produce utility, and another distinct set of nodes (as a middleware protocol) step in to endorse this utility, ensuring the validity and authenticity of work that has been done in the physical world. This can be characterized as "proof-of-useful-work" or "proof-of-physical-work". Both systems underscore the importance of decentralized consensus in fostering trust and security.

Designing and architecting such a middleware is nontrivial. Let's look at it from different perspectives.

Perspective A: Feasible Technology for Verification

A successful verification in a DePIN is achieved if both below are achieved at the same time:

  1. Authenticity and Integrity of Measurements: The measurements from service nodes or devices represent their work status (e.g., they have delivered a certain service, such as providing WiFi connectivity or collecting environmental data) and must be authentic and non-tampered.
  2. Trustworthiness of Off-chain Computation: Usually, the measurements cannot be directly used for verification purposes. A certain amount of off-chain computation is needed to process them, which needs to be trustworthy, e.g., no cheating.Take the case of an energy-focused DePIN: it's crucial for the smart contract to trust that a smart meter measures solar energy generation correctly AS WELL AS the middleware verifies maybe 6 hours of measurements from this smart meter, in order to initiate on-chain payments in crypto.

To achieve both, we can map out the current technology that is feasible, as below.

Perspective B: Pack Verification Technology in a Decentralized Way

After enough understanding of the feasible verification technology, we need to think how we can pack it into a decentralized protocol. Here are some thoughts:

  • Hardware layer needs to be minimized (to ensure widespread accessibility and decentralization) and many features should be enshrined in middleware to help avoid centralization risks in other areas of the stack. This is analogous to the famous "Fat Protocol" such that we want to the hardware layer to be thin while the middleware to be fat.
Fat Protocol (in terms of how value is distributed) from USV
  • Middleware runs like a public blockchain in the following regards
  • be permission-less and neutral (open-source, community-operated)
  • be transparent and trustless, offers high security, capable of withstanding sophisticated attacks driven by financial motives.
  • be able to execute various types of verification for different scenarios, therefore needs programmability (think about smart contract) embedded.
  • Be able to enshrine necessary features from hardware or application layers when needed.

Perspective C: Modes of Verification

In different scenarios, the service nodes work differently. For example, in the context of file storage, the service nodes are always working (to store what has promised) so spot-check on them is natural, while in the context of DIMO (car data collection), a services node (device mounting on the car) upload measurement says every 10 minutes, so verification can be applied to all measurements. Therefore, the middleware has different modes for verification adapting to distinct DEPIN applications:

  • Data processor: this is the most common mode that service nodes or devices basically send all measurements to the middleware, which verifies and processes them to produce proofs for smart contracts.
  • Proactive Integrator: the middleware protocol actively selects a subset of service nodes to challenge (note that if the middleware protocol is strong enough, it can "sample" all service nodes). After getting the responses from nodes, it goes into the data processor mode. The random sampling approach as used in Filecoin falls into this category.
  • Passive watcher: this is the least common way that the middleware just silently watch the nodes in service and try to find evidence that they are (not) doing what expected (Think Dark forest theory).

Building W3bstream as the Middleware for DePIN Verification

Putting together all the perspectives aforementioned, we champion the validity-proof-based approach and envision a decentralized, shared, and neutral off-chain verification protocol (as part of IoTeX Network) to serve DEPIN networks. This protocol assimilates measurements from a multitude of smaller DEPIN networks and furnishes validity proofs (e.g., we use SNARK proof for now) to smart contracts. We launched the developer preview version of W3bstream in July and we are now full-speed on delivering the Mainnet Sprout version as planned on our roadmap, which allows community use staked IOTX to participate in the cold start of the network in late 2023Q4 or early 2024Q1.

On a broader scale, W3bstream is a community-operated shard network that facilitates various DEPIN projects in deploying (and subsequently updating) their verification "formulas" onto the platform. These "formulas" can be crafted in Rust, Golang, C++, with more languages to be supported soon. Here's what they typically look like:

Zero knowledge proofs often come with performance trade-offs including longer proof generation times and increased computational resources, making them less scalable for some real-world applications. We have done in-house optimizations (including batch) on top of zk-SNARKs to address these performance issues, aiming to provide faster proof generation while retaining the core benefits of zero-knowledge protocols. Below is the benchmarketing result to run the batched proof generation from 1000 simulated devices using the "formulas" above, with and without GPU acceleration.


zk-SNARKs Generation
(on regular machine)
zk-SNARKs Generation
(GPU-accelerated)
Amortized time
0.75 second

0.06 second

Benchmark of Proof-of-drive-range

Notes: regular machines - 12 threads CPU + 64GB RAM

Pioneering Trust in Tomorrow's Decentralized World

Decentralized physical infrastructure is on the cusp of reshaping multiple dimensions of our world. However, unlocking its full potential hinges on addressing the challenges of decentralized verification, ensuring the sanctity and invulnerability of these networks. To address these intricate challenges, we're organizing the world first academic conference this October, welcoming top researchers and engineers from domains like web3, cryptography, IoT, security/privacy, and economics, all aligned towards a shared vision. We invite everyone passionate about advancing the DEPIN verification layer to collaborate with us in diverse capacities. Reach out to us at [email protected].