Implementer(s): Pocket Network Foundation
Category: Governance Upgrade
Based on the feedback provided on previous proposals, we’re proposing a new method of bootstrapping chains by providing a minimum level of relays (revenue) on each new RelayChainID that will attract a minimum viable number of nodes while new RelayChainIDs are in their infancy. This would be accomplished by signaling the intention to whitelist a new RelayChainID and creating temporary, Pocket Network Foundation staked applications that produce on-chain rewards encouraging node runners to participate through predictable rewards. This technique effectively balances the needs for incentives and the inflation cost to users.
We would like to get feedback from the node community about how you feel with the timeline, proposed incentives and the chains the market is signaling us to support.
Whitelisting new chains in the SupportedBlockchains parameter is a complex chicken-and-egg problem, because whitelisting the chain for rewards before it is adopted by a significant number of nodes/apps leaves the ChainID vulnerable to targeted servicing, wherein apps can unfairly favor specific nodes when choosing who to send relays to, but without incentives we would struggle to bootstrap the two-sided market.
Incentive Bootstrapping Process
We have explored a few solutions to this problem but none were intuitive enough to take off.
- CampaignNet: Initially, the plan was to run “CampaignNet”s, which would essentially be isolated incentivized testnets run exclusively for specific RelayChainIDs. However, this introduces another operational challenge of bootstrapping entirely new chains. This is assumed to be our solution in How to Whitelist New RelayChainIDs.
- Centrally-administered Funding Program: We have also contemplated running a centrally-administered incentive program funded by the DAO and administered by the Foundation. Node performance would be recorded through the Pocket Gateway, which most apps use to connect to the network, and rewards would be manually distributed in a manner similar to the protocol’s automated block rewards. However, this also introduces an operational burden and would deplete the DAO’s treasury over time. It was deemed unsustainable from a time and cost perspective.
Governance of the SupportedBlockchains Parameter (Block Rewards Whitelist)
The governance process for whitelisting new RelayChainIDs is also imperfect in hindsight.
Currently new RelayChainIDs are to be whitelisted according to the following section in the Pocket DAO Constitution:
6.10. The SupportedBlockchains parameter will not be governed through voting, but instead according to the Network ID configuration choices of Voters. The Foundation will add Network IDs to the whitelist if 5% of Voters have configured their App or Node to include the Network ID. PUPs can still be submitted for this parameter to draw attention to new eligible Network IDs.
The hypothesis was that, since the Voters are proven non-sybils who have also been qualified as among the most knowledgeable in the community, they would make sensible decisions about which chains are worth whitelisting. It was also assumed that voters would probably represent a slice of the network as a whole, meaning if they support a RelayChainID the wider community of node runners probably does too.
However, this has two key problems:
- Ineffective when the DAO is small: at the current count of 11 voters, 5% of voters is only 1 node runner.
- Prevents voters from participating in incentive bootstrapping programs: the purpose of these programs is to help bootstrap the number of node runners, then whitelist a RelayChainID only once a certain threshold (resistant to targeted servicing) has been reached, but if any DAO voter participates in one of these programs before the threshold has been reached, they will satisfy the criteria to whitelist before the threshold has been reached.
Therefore, this proposal also aims to adopt a more sensible governance process for whitelisting new chains, which is also more compatible with the incentive bootstrapping process.
Previously, we have not adequately addressed ensuring that the whitelisting process is fair, transparent and reliable for all node runners who are currently staked, as demonstrated by concerns raised by node runners in response to PUP-5. We aim to resolve these concerns with the proposed incentive bootstrapping process.
We have also not given enough attention to how to embed testing and quality assurance into chain onboarding. This proposed process should allow us to test and debug any issues concerning the quality of requests in a controlled environment. This is an alternative to testing quality standards on new production users who are still on the fence about using the protocol which has demonstrated to be a contributing factor for churn.
This proposed process WILL:
- Give node runners enough time to decide which chains they want to stake for
- Provide fair playing field for nodes of all levels to join new chains
- Guarantee an incentive for node runners to unstake and add new chains
- Give the Pocket team a live testing environment for new chains to ensure smooth onboarding of new applications
- Eliminate the demand/supply problem of onboarding new chains
This proposed process WILL NOT:
- Impact existing incentives for node runners on existing blockchains
- Initiate a new chain with no relays deployed on Day 1
Incentive Bootstrapping Process
- 30-days Notice: The Pocket Network Foundation will provide node runners with 30-days notice prior to incentive activation for a new RelayChainID, providing ample time for node runners to both unstake and spin up new nodes. This notice will include a mandate for a Minimum Node Threshold that will need to be met before the RelayChainID can be whitelisted in the SupportedBlockchains parameter.
- Unstaking & Restaking: Following this signal from the Foundation, node runners will be able to unstake and restake their nodes with a buffer of 9 days in addition to the 21-day unstaking period.
- Day 27 Node Count: 3 days prior to whitelisting the RelayChainID, the node stake count will be performed on the RelayChainID. If the Minimum Node Threshold hasn’t been met, the timeline will be extended to accommodate the entry of additional nodes.
- Whitelisting: If the Minimum Node Threshold is reached by the indicated date, the Foundation will activate the allotted chain.
- Relay Bootstrapping: Once the incentives are activated, the Foundation will provide a Baseline Relay Count, ensuring minimum viable revenue to node runners, while simultaneously load testing the new chain with a variety of relay types. This Baseline Relay Count will be whatever is needed to economically support the Minimum Node Threshold, including the cost of running the nodes as well as the opportunity cost of being unpaid while unstaking for 21 days. Since different chains have different costs associated with running nodes, this will vary from chain to chain. These relays sent by us would exist until we onboard new applications for these given RelayChainIDs and no longer need to subsidize nodes.
- Onboarding New Applications: Having a pre-existing network of nodes that has been load-tested will make it easier for us to onboard new applications. While our solutions team works on outreach, the developers of tools such as the Pocket Dashboard and Node Pilot will also be able to integrate the new chains natively.
- Ending Relay Bootstrapping: Once we have reached enough organic relays to match the Baseline Relay Count, we will stop submitting relays from the Foundation’s stake. If it becomes clear that the chain will not sustain an organic relay count to prevent targeted servicing, e.g. due to abandonment of the chain by applications, the DAO may vote to (blacklist) remove the RelayChainID from the SupportedBlockchains parameter.
Update 6.10 in the Constitution to:
6.10. RelayChainIDs will be added to the SupportedBlockchains parameter (whitelisted) by the Pocket Network Foundation according to the process outlined in ‘PIP-5: Settlers of New Chains’. The Foundation will give node operators 30-days notice prior to whitelisting new RelayChainIDs. If it becomes clear that the chain will not sustain an organic relay count to prevent targeted servicing, e.g. due to abandonment of the chain by applications, the DAO may vote to (blacklist) remove the RelayChainID from the SupportedBlockchains parameter.
Baseline Relay Count to Provide Minimum Viable Revenue to Nodes
The minimum amount of relays is dependent on the cost of running the nodes, the expected rewards and the estimated amount of nodes needed to prevent self dealing. For example, if it costs conservatively $100/mo to run a standard full node on a cloud provider, and we want to guarantee that there are 200 Pocket Nodes serving a given full node, that’s a total of $20,000 in monthly costs (if not running multiple pocket nodes to one bitcoin node) that needs to be covered in POKT rewards. Using a $0.80 OTC price, that would need to be 25,000 POKT minted in total throughout the month, or 93,632.95 relays a day.
$20,000 / $0.80 = 25,000 POKT a month
28,571 / 0.0089 = 2,808,988.76 relays a month
2,808,988.76 / 30 = 93,632.95 relays a day
|Costs to run a Bitcoin Node|
|Number of months||1|
|Number of nodes||200|
|Cost to operate Node||20,000|
|Break Even Point to Cover Node Costs|
|Number of POKT/month||28571.43|
|~relays per day||95,238.10|
Instead of one single application stake, we would advocate having 10 application stakes to spread the sessions to avoid RNG of not being chosen to participate in sessions. This Baseline inflation would continue until we onboard applications for these given chains or the community decides it is no longer viable to continue supporting that RelayChainID.
Opportunity cost offset
Additionally, to cover the opportunity cost of switching over, if nodes are on average, earning 20 POKT a day and the aim is to have 200 Pocket nodes, that is about 4,000 POKT a day, or 84,000 POKT in earnings missed out by nodes over 21 days. This would be an additional ~400,000 relays a day totalling to 84,000 POKT minted over 21 days.
|Opportunity cost to switching to a new Chain|
|# of Pocket Nodes||200|
|# of days/period||21|
We propose that this opportunity cost inflation happen just once, for a single chain for the initial group of nodes. This will give everyone ample time to unstake once, and set up their RelayChainIDs for the new chains ahead of time. Given enough time, as new node runners come in or others are staking their POKT for new RelayChainIDs, there is no need to continue the opportunity cost offset program.
Total Network inflation
Assuming 6 months of baseline inflation for 15 chains this would result in:
- 2,571,426 POKT minted to service nodes
- 28,892 POKT minted to block producers
- 288,924 POKT minted to the DAO
With an additional 84,000 POKT for the opportunity cost offset proposed for Ethereum Archival Mainnet trace enabled.
For a total of 2,973,242 POKT minted over 6 months. At a supply of nearly 660M POKT, this would result in 0.4% inflation over 6 months.
Purpose of Gateway relays
The applications that provide the initial relays will be designed, built, and staked by the Foundation. Providing this baseline creates an important function for the entire protocol.
Today, nearly all relays come through the gateway. It allows us to perform critical quality assurance of the service balancing and debug any issues with a given service.
Using an average baseline of 100,000 relays per month, per chain (depending on the node network) marginally increases the current inflation while seeding a robust initial set of nodes profitably.
Altruistic spam relays
There has been, and always will be, the challenge of altruistic spam relays. This would be individuals using the Gateway’s free tier to send requests to the network for everyone’s benefit. Just like targeted servicing, the effectiveness of this on an individual level becomes muted the more nodes there are for a RelayChainID.
Monitoring the gateway applications for legitimate applications that have been built as opposed to fake applications just using the endpoint for these altruistic spam relays will help avoid this.
We should wait until 0.7.0 QoS is implemented
The 0.7.0 upgrade, slated for later this year will remove many of these risks, using on chain data to automatically remove any targeted servicing. I would argue that the market demand for these new chains is high enough that moving forward with this proposal would still be worth doing.
This might adversely affect the node counts with large node providers
In light of the concerns regarding the amount of nodes on the network, this may result in a significant increase of Pocket Nodes from larger node providers. The largest node providers need to be cognisant of how they manage this with their customers, and should be replacing 1 for 1 with the new RelayChainIDs they plan on supporting to avoid overloading the network with nodes unnecessarily.
To conclude, we propose to split up the order of RelayChainIDs based on market demand and urgency versus more speculative, yet potentially interesting RelayChainIDs. Feedback on timing of these for node runners is crucial, as we want to make sure you have time for syncing and connecting these new nodes to your existing infrastructure setups.
To give time for feedback, we propose to begin the initial 30 day timer for implementation on May 9th. This would mean that we will begin making the first chain paid on June 9th, with each one successive RelayChainID paid on the date indicated below.
Node runners would need to have staked for these RelayChainIDs ahead of time and have the full nodes available on the given dates.
Schedule for paid chains
Edit: We originally had estimated dates for whitelisting these chains but now we are planning to wait on the 0.6.3 release, which will allow us to move more quickly. Without a clear date for 0.6.3, it doesn’t make sense to estimate dates for individual RelayChainIDs.
|0028||Ethereum Mainnet Archival Tracing (Opportunity cost chain)|
|0023||Ethereum Ropsten testnet|
|0025||Ethereum Rinkeby testnet|
|0026||Ethereum Goerli testnet|
|0024||Ethereum Kovan testnet|
|0009||Polygon (Prev Matic)|
More speculative, yet interesting RelayChainIDs:
|0007||Energy Web Token Mainnet|
|0008||Shyft Network Mainnet|
We propose Ethereum Mainnet Archival with traces enabled to be the opportunity cost chain. As many solutions today need traces enabled for Ethereum, we would like to seed this network with as many Archival nodes as possible.
We propose a delayed daily activation of all supported chains using the forums as the source of truth.
Copyright and related rights waived via CC0.