IoTeX Foundation: How to Achieve Decentralized Verification in DePIN Networks?
Original Title: 《Decentralized Verification in DePIN》
Authors: Raullen Chai, Andrew Law, IoTeX Foundation
Compiled by: Deep Tide TechFlow
Decentralized Physical Infrastructure Networks (DePIN) represent a transformative upgrade in how we plan and organize real-world systems. It spans across fields such as energy, transportation, and telecommunications. By combining blockchain, cryptocurrency, and smart contracts with smart devices, DePIN provides the capability to coordinate physical infrastructure in a decentralized and peer-to-peer manner. As Guy Woullet from a16z points out, the key to DePIN's success lies in addressing a core challenge: ensuring trustworthy verification of geographically dispersed service nodes without the need for centralized management. This article delves into the issue of decentralized verification in DePIN, critically analyzes existing solutions, and proposes innovative approaches to ensure scalability without compromising security and decentralization.
The Rise of DePIN
DePIN harnesses the power of blockchain and smart contracts to build open markets for services rooted in physical infrastructure. Imagine an energy-based DePIN: households equipped with solar panels could potentially generate electricity and supply excess power to neighbors. Facilitated by blockchain and executed through smart contracts, these energy transactions can be automatically recorded and settled. At the core of this process are IoT devices, such as batteries and other microgrid-connected hardware, which enable households to distribute energy in a trustworthy direct peer-to-peer manner, without the need for utility companies as intermediaries.
These decentralized physical infrastructure networks are gaining increasing attention across various industries in 2023. By marginalizing centralized gatekeepers, DePIN is expected to enhance efficiency, reduce costs, expand accessibility, and empower individuals with greater autonomy.
The Structure of DePIN
Decentralized physical infrastructure relies on a complex technology stack that integrates hardware, connectivity, middleware, blockchain-based smart contracts, and network or mobile applications.
Zooming in on a typical DePIN network (such as DIMO, Helium, WiFimap, or GeoDnet), they typically have three roles:
Service Nodes: A set of servers or devices providing services or utilities, such as WiFi/5G, environmental data collection, and energy production.
Middleware: A layer primarily dedicated to verifying whether service nodes are functioning correctly. It ensures the accurate expression and reporting of real-world activities and events from service nodes to smart contracts, which may be closely related to how DePIN tokens operate.
End Users: Everyday individuals or business communities that actually use the utilities provided by service nodes or devices. Here, the middleware is responsible for measuring the quality of services or utilities from nodes by tracking certain metrics, the absence of which could lead to:
Self-Transaction: Participants may exploit the network by obtaining services through the infrastructure they own, thereby accumulating fees and rewards. For example, an energy entity could simulate purchasing energy from its own reserves. Given sufficient subsidies or initial block rewards, self-transaction becomes highly profitable.
Lazy Providers: Infrastructure providers may promise to deliver services but either fail to fulfill their commitments or provide subpar services. Without a rigorous verification system, users have no recourse.
Malicious Providers: While less common than the previous two, there exists the possibility of malicious entities manipulating the infrastructure, enticing users to accept false sensor data aligned with the provider's financial interests. If left unchecked, these behaviors could undermine the economic incentives of DePIN. Trust and network efficiency decline, leading to a "tragedy of the commons," where providers seek self-interest, or result in the centralization of power. In both cases, the goal of decentralized, peer-to-peer driven infrastructure is compromised.
Verification Middleware
Designing and architecting such middleware is highly complex. Let’s look at it from different perspectives.
Perspective A: Viable Verification Technologies
Verification in DePIN is considered successful if the following two points are achieved simultaneously:
Authenticity and Integrity of Measurements: Measurements from service nodes or devices represent their operational status (e.g., they have provided some service, such as WiFi connectivity or environmental data collection) and must be authentic and untampered.
Reliability of Off-Chain Computation: Generally, measurements cannot be used directly for verification purposes. A certain amount of off-chain computation is required to process them, which needs to be trustworthy, meaning it cannot be manipulated.
Taking an energy-focused DePIN as an example: smart contracts must trust that smart meters accurately measure solar energy generation, and the middleware verifies the measurements from this smart meter over a 6-hour period before initiating cryptocurrency payments on-chain.
To achieve these two points, we can list currently viable technologies as follows:
Perspective B: Decentralized Packaging of Verification Technologies
Once we have a sufficient understanding of viable verification technologies, we need to consider how to package them into a protocol in a decentralized manner. Here are some ideas:
- The hardware layer needs to be minimized (to ensure broad accessibility and decentralization), and many functionalities should be integrated into the middleware to help avoid centralization risks in other areas of the stack. This is akin to the famous "fat protocol," where we want the hardware layer to be thin, while the middleware is fat.
The operation of middleware is similar to public blockchains in the following aspects:
Allows for anonymity and neutrality (open-source, community-operated)
Transparent and trustless, providing high security and capable of resisting complex attacks driven by financial motives
Able to execute various types of verification for different scenarios, thus requiring built-in programmability (think smart contracts)
Capable of retaining necessary functionalities from the hardware or application layer when needed.
Perspective C: Verification Methods
In different scenarios, service nodes operate differently. For example, in the case of file storage, service nodes are continuously operational (storing the promised content), so they can be sampled for checks, whereas in DIMO (automotive data collection), a service node (a device installed in a car) uploads measurements every 10 minutes, allowing for verification of all measurements. Therefore, the middleware has different verification modes to accommodate various DePIN applications:
Data Processor: This is the most common mode, where service nodes or devices essentially send all measurements to the middleware, which verifies and processes them to generate proofs for smart contracts.
Active Integrator: The middleware protocol actively selects a subset of service nodes for querying (note that if the middleware protocol is robust enough, it can "sample" all service nodes). After obtaining responses from the nodes, it enters data processor mode. The random sampling method used by Filecoin falls into this category.
Passive Observer: This is the least common approach, where the middleware simply observes the nodes in service and attempts to find evidence indicating whether they are (or are not) doing what is expected (referencing the dark forest theory).
Building W3bstream as Middleware for DePIN Verification
Integrating all the above perspectives, we advocate for a validity-proof-based approach and envision a decentralized, shared, and neutral off-chain verification protocol (as part of the IoT network) serving DePIN networks. This protocol aggregates measurements from a multitude of smaller DePIN networks and provides validity proofs for smart contracts (for example, we currently use SNARK proofs).
From a broader perspective, W3bstream is a community-operated sharded network that facilitates various DePIN projects to deploy (and subsequently update) their verification "formulas" onto the platform. These "formulas" can be written in languages such as Rust, Golang, C++, and more languages will be supported soon. They typically look like this:
Zero-knowledge proofs often come with performance trade-offs, including longer proof generation times and more computational resources, which makes their scalability poor for certain practical applications. We have conducted internal optimizations based on zk-SNARKs (including batching) to address these performance issues, aiming to provide faster proof generation while retaining the core advantages of zero-knowledge protocols.
Decentralized physical infrastructure is reshaping our world on multiple levels. However, the key to unlocking its full potential lies in addressing the challenges of decentralized verification, ensuring the sanctity and inviolability of these networks. We look forward to collaborating with top researchers and engineers in fields such as blockchain, cryptography, IoT, security/privacy, and economics to realize this shared vision.