Probabilistic Proofs in DePIN
In my last post, I introduced the economic concepts underlying Local Protocol, a general decentralized marketplace protocol.
Local protocol aims to address key challenges for decentralized physical infrastructure networks (DePINs) where services are limited by the availability or cost of proofs. We argue that the number of services that have hard cryptographic service-proofs is especially limited in physical networks, which has reduced the surface area and design space for DePIN in general. Local aims to expand this surface area for physical services that can be both peer-to-peer and token-incentivized.
Our approach acknowledges a spectrum of verifiability and provides a path forward for networks that may not have access to hard or cost-effective service proofs.
Local Protocol is an expressive architecture whose approach to verifiability is adaptable to a wide range of DePIN projects. In the root case, the protocol assumes that services do not have access to robust service-proofs.
In this post, I discuss incorporating service-proofs and identity-proofs for network's that have access to such things. I'll share why modeling proofs in Local Protocol is more cost effective than opinionated or narrow DePIN architectures, and argue that DePIN requires Local Protocol to unlock new use cases that are limited by the availability or cost of proofs.
Local Protocol Design Recap
Local Protocol is a cryptoeconomic game where buyers and sellers develop connectivity by fulfilling transactions. As users complete transactions, the protocol creates a trustless transaction graph. The block reward for the subsequent transaction is dictated by a relative connectivity ranking (more specifically, their eigenvector centrality (EC)). Self-interested actors aim to enhance their connectivity ranking which requires cooperation with transacting parties that are transacting with similar cohorts of the network. The network incentivizes users with a large reward for developing connectivity, providing the network with a strong bootstrapping and referral mechanism that doubles as the network's security guarantee.
Difficulty in Manufacturing Connectivity
Achieving a high EC score requires not only a large number of connections but also connections to other well-connected nodes. This property makes it challenging for malicious actors to manufacture high connectivity rankings, as they would need to establish links with reputable, central nodes in the network.
Legitimate, highly-connected nodes are more likely to scrutinize and avoid suspicious or low-quality nodes. As a result, attackers face significant hurdles to manipulate their EC scores.
Proofs as Graph Attributes
In graph theory, a node is a point representing an entity (buyer, seller), and an edge is a connection between two nodes (transactions). In Local protocol, we model identity-proofs (and other trust attributes for users) as node attributes and service-proofs as edge attributes.
We can assign a degree of confidence to such proofs and propagate the trust assumptions that we derive from each proof through the graph to neighboring nodes with a dampening factor over longer path lengths from the trusted node. This allows us to reduce the requirement of capturing potentially cost-prohibitive proofs for every transaction without sacrificing the security guarantee for the network.
You can think of both identity and service proofs as injecting trust into the network. As the network becomes more trustworthy, the protocol becomes more confident in distributing rewards that are greater than the fees collected for each transaction. This unlocks a rich surface area for capital formation to bootstrap new markets. New markets can inherit the security from existing markets providing the network with a strong cross-market network effect.
For immature local networks that want to prioritize bootstrapping trust, EC rankings can help establish trust vectors through a combination of service proofs and identity proofs. As the network grows and trust is established, the reliance on expensive service-proofs can be gradually reduced with a dampening factor over time.
Trust Propagation
The boost in eigenvector centrality (EC) resulting from any proof—be it an identity proof or a service proof—doesn't just affect the individual node or transaction; it propagates through the network due to the recursive nature of the EC calculation. Nodes directly connected to the node or edge associated with the proof will also see an increase in their EC because their centrality depends on the centrality of their neighbors.
The effect of any proof diminishes exponentially over longer paths in the graph. The modified EC calculation naturally captures this phenomenon, as the solution to the inhomogeneous eigenvalue problem (more on this later) accounts for the additional trust introduced by the proofs (the doping vector for nodes or adjusted weights for edges).
You can visualize the network as a series of concentric circles centered around the node or edge that has incorporated a proof. The nodes directly connected form the first circle; these are the immediate neighbors who have direct interactions with the proof-bearing node or transaction. The second circle consists of nodes connected to those immediate neighbors, which are two steps away, and so on for subsequent circles. The influence of the proof's boost in eigenvector centrality is strongest at the center and decreases exponentially as you move outward.
Nodes that transact with those who have submitted proofs benefit more than they would have without the proofs. This results in higher rewards for both parties and increases their attractiveness as transaction partners in the network. In this way, nodes in the network might view the submission of proofs, and thus the increase in security for the network, as an investment in their EC. When self-interested actors perform actions that have positive security externalities, we achieve strong design properties.
Identity Proofs as Node Attributes
Examples of identity proofs include World ID, zkPassport, or a zkTLS authentication with a relevant Web2 provider using Opacity Network. These proofs can be assigned a score that unlocks a larger block rewards for both this node and any transacting counterparties. Specifically, we boost nodes that have evidence of realness because it provides the network with stronger sybil resistance.
Incorporating Identity Proofs into Eigenvector Centrality
We represent the network as a bipartite graph , where and are disjoint sets of nodes representing producers (sellers) and buyers, respectively, and is the set of edges representing transactions between them.
The eigenvector centrality (EC) of the nodes in the graph is calculated by solving the eigenvalue problem:
where is the adjacency matrix of the graph, and is the largest eigenvalue.
When a user provides an identity proof, we model this as adding a doping vector to the eigenvalue equation This can be captured by modifying the EC formula to become an inhomogeneous eigenvalue problem. Suppose user submits an identity proof that translates into a boost of in eigenvector centrality. We then define a "doping vector" , where the nonzero element appears in the -th position. The inhomogeneous eigenvalue problem to solve is then:
Service Proofs
While identity proofs enhance trust in individual nodes, service proofs strengthen the reliability of specific transactions (edges) between nodes. Some existing examples in the wild:
-
Wireless Networks
-
Mobility and Logistics
-
Energy
-
Compute and Storage
-
Domain Agnostic
Service Proofs in the Adjacency Matrix
Each edge in the graph has a weight representing the cumulative fees or value from transactions between producer and buyer . When a service proof is available, we adjust the edge weight to reflect the increased confidence in that transaction:
where is the boost provided by the service proof.
Alternatively, in terms of the adjacency matrix , we update the entry:
This adjustment increases the significance of the edge in the calculation of EC.
Impact on Eigenvector Centrality and Rewards
By increasing the weight of the edge , both nodes and receive a higher EC score due to their strengthened connection. This boost is again propagated through the network.
Higher EC scores translate into increased graph values and , which are used to calculate block rewards. Therefore, providing service proofs directly benefits the involved parties and indirectly enhances the trustworthiness of their neighbors.
In the next EC calculation, both and will increase more than they would have without the proof. This results in higher rewards for both parties and increases their attractiveness as transaction partners in the network; transacting with high EC nodes boosts ones own EC.
Proofs as Probabilities
Modeling proofs as increments in edge weights allows us to treat proofs as probabilistic assessments, rather than binary evidence of service. This approach acknowledges that proofs for physical services can vary in strength and reliability which is particularly useful for networks that lack hard cryptographic proofs-of-service.
By quantifying the confidence level , we can proportionally adjust the influence of each proof in the network, unlocking a wider range of evidence and increasing the applicability for networks that do not have deterministic proofs or where capturing / computing proofs is cost-prohibitive (which could break the unit economics of the service in question).
Said another way, physical networks have a spectrum of proofs. Local Protocol reduces the reliance on absolute measures of trust, which may be impractical or costly, and instead uses the aggregate trust derived from various proofs and interactions within the network.
For example, in a mobility network, a ridesharing application may contain two nodes who submit evidence of their service using a location-proof and time-proof. However, we may not have assurances that these nodes are discrete individuals; it could be a single person acting as both the driver and the rider. In such a case, these rideshare "proofs" are not robust like validity proofs are in other blockchain networks.
The graph is robust to such attacks because colluding nodes will form isolated subgraphs, disconnected from the broader network of honest participants. Nodes with low connectivity will inherently have low Eigenvector Centrality (EC). This ensures that the weight boost for a given transaction is contained to the colluding actor, is unprofitable, and a self-destructive strategy. As edge weights update dynamically, nodes that are disconnected from the main graph (or have limited interactions with genuinely trusted nodes) will find it increasingly costly to maintain their position.
Random Sampling and Slashing
To ensure that the graph doesn't lose its security guarantees as new nodes enter the game, the network can randomly sample for service-proofs or service-approximations if proofs aren't available. If a node fails to provide their proofs, the network can slash the edge weights (tokens staked in the graph), and add a inverse doping vector to the nodes that fail to provide their proofs. This localized penalty system encourages self-policing and allows the network to remain secure without necessitating costly proofs for every transaction.
Inverse Doping Vector
When the network randomly samples a transaction and requests a service proof, the involved nodes must submit the required proof. If they fail to do so, we model this as an inverse doping vector in the eigenvector centrality (EC) calculation. Specifically, we decrease the EC scores of the nodes in question and remove the edge representing the fake transaction. This slashing not only impacts the penalized nodes but also affects their neighboring nodes, with the effect diminishing exponentially over longer paths in the graph.
where is a vector with positive entries corresponding to the penalized nodes, effectively reducing their EC scores.
For example, if node fails to submit a proof, the inverse doping vector has a positive value at position and zeros elsewhere:
The impact of this penalty propagates through the network due to the nature of the EC calculation and the edge weights associated with the failed transaction are also decreased or set to zero:
Slashing Neighbors
To further encourage self-policing, we can extend the penalty to nodes directly connected to the penalized node. This is modeled by adjusting the inverse doping vector to include these neighboring nodes with scaled penalties.
Let denote the set of nodes directly connected to node . We define the inverse doping vector as:
where is the decay factor representing the reduced penalty on neighboring nodes. For each node , we can adjust the edge weights associated with the neighboring node where is a smaller slashing factor for the connected edges.
The effect of the penalty diminishes exponentially over longer paths in the network. Mathematically, this is inherent in the properties of the EC calculation. The further a node is from the penalized node, the less impact the inverse doping vector has on its EC score.
This decay can be adjusted through the choice of decay factor and slashing factors and , allowing network designers to balance between strictness and leniency based on the desired security level.
This slashing mechanism encourages nodes to maintain genuine connections and discourages malicious behavior.
Conclusion
Incorporating identity proofs and service proofs into the Local Protocol graph enhances the network's ability to verify users and transactions without relying solely on network connectivity. By modeling proofs as probabilistic boosts in eigenvector centrality (EC), we allow trust to propagate organically through the network. This approach balances the need for security with the practical limitations of obtaining proofs in various markets.
By integrating proofs into the mathematical framework of the graph, we create a system where security (trust) is directly linked to economic rewards. Nodes are incentivized to provide proofs, not just for their own benefit, but also to enhance the trustworthiness of transacting partners in their Local network.
Local Protocol supports a wide range of decentralized services, even those without hard cryptographic proofs, expanding the design space for DePIN projects. This enables more services to be both peer-to-peer and token-incentivized.