DEPIN: Choosing Solana for scaling up token-incentivized Physical Infrastructure Networks
Public Networks as Businesses, and current limitations:
Networks are an important part of the societal structure. People, from the moment they are born, find themselves as members of networks. Family, culture, personal interests, these are networks that bind human activities, and allow the collective to thrive at scale.
As society and the economy improves, so are networks. The physical structures surrounding us are man-made networks that provide the foundation for collaboration, connectivity, and efficiency at scale. As businesses, you are required to be profitable, in order to maintain the usability of your network. This means going after your end users and extracting value, either by serving the highest bidders or utilizing user data for profits, both of which have limitations in the current social context.
So what to go from there? how do you build scale-up networks, with sufficient durability, while not getting compromised or saturated on incentives?
The answer is to create a decentralized network, where everyone who participates has a stake in its operation and success. “Show me the incentives, and I’ll show you the outcome”. By providing the opportunity for network growth to the upside, such infrastructure networks have a strong probability to thrive at scale.
As the internet and protocols change the way of the social fabric, Decentralized Physical Networks (DePIN) are changing the way we orchestrate the physical network surrounding us. On Solana, the movement is popping off, with the migration of Helium Network (hotspots/5G) and Render Network (GPU Rendering) paving the way. The vector is one of the more proper use cases of Crypto’s product-market-fit, solving the problem with its unique incentives design.
In this article, we will discuss the basics design of DePIN, challenges at scale, and why Solana is a clear candidate for DePIN to thrive
What is DePIN? and why Blockchain?
Large-scale infrastructure design usually follows a top-down approach. A centralized entity at the helm will mainly be in charge of monitoring, coordination, and updates in the network. This entity will also be in charge of growing its demand side/ customer acquisition.
The problem with this model is that you are incentivized to only serve those with the most capability to pay, and as such, resources and power dynamics got centralized, with a sub-section of end-users being underserved and holding the short end of the deal.
DePIN proposes that in order to effectively scale beyond centralized maturity, it is best to split its network incentives towards its early adopters. Instead of shouldering the responsibility as a driving force running the network, rewarding others to join and take on the workload is a great way to scale up functionalities. P2P networks, the foundational structure for most permissionless blockchains, provide the basic framework for these projects to scale.
Below here, you can see the similarities between Solana, Helium Network, and Render Network, when we compare the basic structures and usage side by side.
The table above is clearly an oversimplification of the systems implemented by both Render Network and Helium Network, but what is clearly shown is that by implementing a blockchain-like system, with a native token incentive, infrastructures for a more aligned future can scale.
The structure itself removes the need and the inefficiencies of central intermediaries and replaces them with a more robust and scalable framework, that goes far beyond the current models. Gary Gensler, the current SEC chair, also mentioned something similar in his MIT lecture back in 2018:
It could be something that has no central authority, no central intermediaries right now, and it has to just jumpstart something. I think in that circumstances more likely you need a native token.
Both Helium and Render Network are exactly this, scaled-up infrastructures for ambitious goals. Hosting/ running on a blockchain allows them to reduce the upstart cost (by splitting across the validators) while also creating better alignment among the major participants (distributed incentives for maintaining the network)
Choosing Solana
To understand the challenges of scaling these networks, it’s good to first to understand the needs and the current construction of these networks. In order to build a large-scale decentralized infra, the “ideal” criteria are as follows:
Strong and viable ecosystem and partners, to further utilize token incentives
cost for running inter-protocol functions (state access, payment distribution) should be cheap enough for public infrastructures to utilize at scale, on a daily basis.
Solana is a proper fit for both of these criteria, but the interesting thing about the stories of Helium and Render is that through multiple improvements, they both reach the destination of choosing Solana as their “new” base chain for operations.
Helium, as a LoraWan Internet-of-Things protocol, started as an L1. Each of its Hotspots runs as a mining Node on the network, providing Coverage and Data Transmission, as well as verifying Proof of Coverage for participants within the network.
As network coverage experienced exponential growth, the stability of the network came under stress, then came HIP-25 (HIP stands for Helium Improvement Proposal). HIP-25 introduced “validators” to the network, and allow the Helium network to run on stronger, more performant nodes.
Realistically, there is no alternative that allows for large network growth other than getting block production onto bigger and more secure CPUs.
Why is this design the best in the space of possible designs?:
I've added some details in the above section, but in addition to those benefits, this also leads to a very clean separation of responsibilities between spot owners and validator runners, whose jobs do not look especially similar.
Allows us to scale the network better as more light gateways and full nodes get added to the network.
What is the impact of not doing this?
More and more resources will need to be poured into the P2P aspect of the design, and we'll eventually need to add a layer of "stronger" validators in any case to keep up with transaction scaling. Since we're always going to be held back by slow/lower memory group members, we will be limited in the complexity of the features that we can add and the stability of the network will continue to suffer.
HIP-70 sees Helium Network once again making improvements to the Proof-of-Coverage by moving key responsibilities to an Oracle Model: Reliable Data Transfer and Reliable Proof of Coverage Activity.
Without the limitation of running an actual blockchain, the Helium network can now focus key resources on improving its LoraWan and IoT network, as well as better scaling and faster iteration for Proof-of-Coverage. With IoT and new use cases increasing exponentially, this is beneficial for the health and sustainability of the network.
What’s left now is to find the proper L1 for consensus rules (P2P and payment) as well as identities. The details of such selection can be found here
Render Network is the case for the second challenge/ reasoning of the “ideal” criteria, where the cost of running network payment distribution, and dynamic state access, become challenges at scale on the EVM.
Render Network is a protocol for distributed GPU rendering, in which idle GPUs without geographical restriction can be utilized to perform rendering works. Creators who want to have their work rendered, but without access to the GPU power to do so, can submit their work to the Render Network and pay in $RNDR token. The tokens will be distributed back to the GPU validators based on the work being done.
Originally, the Render Network was built on top of ETH, as the coordinating network between Creators and the GPU Providers, before making the switch to Polygon for better/cheaper payment coordination. What has been shown in the past 2 years is that the construction of the current EVM (allowing for Price-gas auction) as well as Centralized Sequencing for L2s, means that high txn fee on L1, and state access from L2 in critical points in time, will still likely be the issues at the scale that Render Network is aiming for, such as Holographic Streaming.
Even for existing use cases, certain network designs are not scalable due to transaction fees. For example, a 200-frame render job running on a network where data is written to the chain and payment sent to node operators as each frame completes would require 200 transactions. ETH gas fees trend around an average of $0.70 per tx. On ETH mainnet, this would cost $140 in fees at the current gas rate. Polygon gas fees trend around $0.025 per tx (this one is a bit more of a rough calculation - the daily tx count can be found here and the daily total network fees here). On Polygon, this would cost $5 in fees at the current rate, while on Solana it would cost under $0.001, a reduction of roughly 5000 times over Polygon. Further these same 200 transactions could cost as little as $0.00026 on Solana (19,000 less) if priority fees were not needed.
While $5 in gas fees may sound reasonable as many have been desensitized by higher prices, the Render Network is a utility where the cost of compute power used on the job could be significantly less than those fees, effectively meaning transaction fees have the ability to raise the price of compute work exponentially. In practice, adding that amount of write volume to an EVM chain would also inflate gas prices further and likely exceed those estimates while hindering user experience. As additional use-cases become available, such as holographic streaming, even moderate transaction fees could limit creators' ability to innovate.
(from Render Network’s RNP-002)
As the demand and rendering complexities continue to rise in subsequent years, having a strong foundation for coordination and incentive payments remains crucial for the high level of scaling that is required for the Render Network. Solana, as mentioned in the RNP, is the candidate for the role, with its Rust-based tech providing additional room for optimization.
There are similarities in the reasonings that both Helium and Render choose to Solana as the new base :
Both Render and Helium are looking for scale and performance, which are suitable for network activities. For both projects, the cheap cost of dynamic state access (txn fee) and high processing time are crucial drivers in the decision to migrate. With Priority Fees, multiple market activities won’t have an impact on user experience, which are crucial for these networks.
With Render Network, Solana presents itself as a “playground” for NFTs, digital assets, and the metaverse at large. Not only Solana has the culture, but also the tech and strategies to support the use case at scale. State Compression, which will play a crucial job in Holographic Streaming and Proof-of-Rendering, as well as Saga and Backpack to bring Digital Assets closer to the consumer and day-to-day use.
Saga is also part of the bullish reason why Helium chooses Solana, bringing the reality of IoT networks closer to mass adoption at scale.
Solana cultures, from the Core Devs, to the community, the hype and the product are genuine, and value driven. Solana is an underdog in the game of blockchains, and piece by piece, we are bringing crypto closer to mass adoption. Being recognizable, and user-friendly, is key to advancing the cause of Solana, and the migrating projects at scale.
With DePIN, and other use cases being developed on top, Solana is gradually becoming the Blockchain-as-a-service solution for a variety of use cases that are looking for ways to scale. We are excited to see the experimentations playing out, and as always, we are bullish on Solana!