Hello Dfinity Community,
This topic is to discuss an improvement in the way ICP handles nodes and node rewards. Currently, we allocate full rewards to nodes, irrespective of whether they are actively providing cycles to the network. While this approach was initially intended to foster network growth and address the absence of an alternative system, it presents certain challenges and hinders transparency in assessing network demand.
I believe we can solve this in a way that reduces latency in the network, gives Dev’s more control, and more fairly rewarding Nodes in expensive or cheaper areas.
Problem Statement:
- All nodes receive 100% rewards, regardless of their actual contribution to the network.
- This approach, though well-intentioned, obscures the true demand for network resources.
- Fails to create a relation between network demand and node availability.
- Causes confusion in the community, as seen in topics like Node Providers - Over Compensated & Under Used, with even talks about the Node Provider Inflation Spiral.
- Canister Replicas are currently attributed to nodes at random, which gives devs no control over where their node replicas are hosted.
- We can’t continue rewarding nodes that way indefinetly. The sooner we start talking about this, the better.
The Proposed Solution:
To successfully transition to a reward model based on cycles, we need to address several key aspects.
1. Rewards Based on Cycles:
Reward nodes based on the amount of cycles they contribute to the network, replacing the current flat fee system.
This should be relatively easy to implement since we are already tracking cycles. However, if this was implemented “as is”, it would cause an imbalance. Nodes that are underocupied would stop earning rewards, while other nodes might receive disproportionately high rewards.
2. Dynamic Node Allocation:
To ensure efficient resource utilization, we must enable canister replicas to be automatically relocated to nodes that are underutilized.
It also make sense to detect where most requests to a canister come from and, based on that, automatically move replicas to nodes closer to their target users.
For example: if most requests to a dApp come from New York, move one or more replicas closer to that location, to better serve those users.
This is crucial for reducing latency and enhancing the overall health of the network, especially for latency-sensitive applications such as streaming, exchanges, and gaming.
3. Prioritize the highest bidder:
The shift towards allocating nodes based on cycles and geolocation will lead to increased demand for nodes in high-density areas, while Nodes in remote areas may see less demand, causing potential imbalances.
To mitigate this, I propose a fee-based priority system, similar to how BTC prioritizes transactions from users willing to pay higher fees.
Allow developers to select their desired level of performance by choosing how much they are willing to pay for cycles (low, average, high). This empowers devs to optimize their applications for performance and cost. This flexibility means that latency-insensitive applications can naturally gravitate towards nodes in more cost-effective locations.
This would also naturaly inflate the price of Cycles during periods where there aren’t enough nodes, and have prices fall during periods of low cycle utilization.
4. Allow for Node Subsidies
The reality is that, at the moment, it still makes sense to subsidise nodes (pay out rewards even though there is no demand). If we paid out rewards based on cycles today, most nodes would abandon the network, and we might end with not enough nodes during the next crypto bull market.
This means that this system needs to allow Dfinity to pay out these Subsidies in transparent manner. For example: garantee Nodes a minimum payout.
It would be great if this was done in a transparent manner, so the community can see:
- how much was paid out for real cycles
- how much has been paid in subsidies
Why These Changes Matter:
- Price fluctuation in cycles (like BTC transaction fee fluctuation) would incentive new nodes to be created only when the network needs it, while also slowing the rate of node creation when there aren’t dApps burning cycles.
- Node location significantly impacts network latency and overall network performance.
- A priority-based fee model incentivizes nodes in high-demand locations and optimizes resource allocation. Otherwise we might end up with too many nodes in cheaper remote locations like Alaska.
- This change enhances transparency and aligns with Dfinity’s vision for a decentralized internet.
- Competing with legacy cloud services requires embracing CDN-like capabilities. ICP’s goal is to replace legacy cloud services like Amazon and Cloudflare. Their key advantage lies in Content Delivery Networks (CDNs), which allow developers to serve data from data centers nearest to end users.
If we implement a solution that automatically moves severs closer to users, we would be a better solution than Amazon or Cloudflare.
Cloudflare’s CDN nework map for reference:
Conclusion:
This proposal seeks to enhance the ICP network’s efficiency, transparency, and competitiveness. It allows us to better cater to the needs of developers and users alike, ultimately positioning Dfinity as a leader not only in the decentralized internet space, but also as a leading CDN provider.
By implementing these changes, we can provide a more robust and responsive network that benefits everyone involved.
Dfinity community, I invite you to join us in discussing and refining these ideas. Does this make sense at all and am I overlooking anything?