- Author(s): @o_rourke @JackALaing @richCL @adam
- Implementer(s): Pocket Network Foundation
- Category: Governance Upgrade
- Related: PIP-4
- Fulfills: PUP-2
Based on the feedback provided on previous proposals, and new functionality that comes with RC-0.6.3, we are proposing a new method of bootstrapping chains.
The Pocket Network Foundation would provide a minimum number of relays (revenue) on each new RelayChainID to attract enough nodes to provide quality service to new apps. The MaxApplications parameter would be lowered and filled up by the Pocket Portal, reinforcing the economic security of bootstrapped chains and thus allowing us to whitelist chains more quickly. To facilitate this, the Foundation would be delegated the power to control the MaxApplications parameter without DAO approval.
When there is demand for Pocket to support a new chain, all that needs to happen is the Foundation provides node runners with enough notice to spin up nodes for the chain, then the Foundation whitelists the new chains and provides node runners with bootstrapping revenue.
The changes that this proposal seeks to approve are:
Delegate to the Foundation the power to control the following parameters:
Whitelisting new chains in the SupportedBlockchains parameter has so far been a complex chicken-and-egg problem, because whitelisting the chain for rewards before it is adopted by a significant number of nodes/apps would leave the network vulnerable to targeted servicing, wherein apps can unfairly favor specific nodes when choosing who to send relays to, but without the incentives that come with whitelisting we would struggle to reach the required threshold of nodes.
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.
- 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 Portal, 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.
The governance process for whitelisting new RelayChainIDs was originally:
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 was deemed to be ineffective when the DAO is small: at the current count of 12 voters, 5% of voters is only 1 node runner.
Therefore, in PIP-1, the process was simplified to just be a majority vote lasting 7 days, like most other parameters.
However, this may be a bottleneck on the chain bootstrapping process described below.
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 this new proposal.
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. The Portal is designed to test the quality of nodes it gets matched to in sessions and make use of fallback “altruist nodes” (unmonetized nodes that provide a backup to bad nodes in sessions) if needed to ensure quality service to apps. Since it is likely that node runners who are running new chains for the first time may make mistakes in configuration/maintenance of their nodes, this will be an important quality assurance mechanism that should minimize the churn of new apps in new chain ecosystems.
This proposed process should:
- Give node runners enough time to spin up nodes for new chains before a chain is whitelisted, to ensure a level playing field
- Give the Pocket Foundation a live testing environment for new chains to ensure smooth onboarding of new applications
- Eliminate the demand/supply problem of onboarding new chains
- Notice: The new UpdateStake functionality that RC-0.6.3 brings means that it will no longer take 21 days to add a new RelayChainID to a node’s stake. However, it will still take time for node runners to spin up nodes for new chains. Therefore, to ensure a level playing field and prevent inside knowledge from giving privileged node runners the lion’s share of early revenue, a notice period will be given depending on how long it takes to spin up a node for the chain in question. We will provide notice in reply to this proposal thread and in the announcements Discord channel.
- Whitelisting: Once the notice period is over, the chain will be whitelisted and start generating revenue for nodes.
- Relay Bootstrapping: The Foundation will provide a Minimum Viable Relay (MVR) count by staking the Foundation’s POKT as an application and sending relays. This will ensure minimum viable revenue to node runners, while simultaneously load testing the new chain with a variety of relay types. Since different chains have different costs associated with running nodes, this will vary from chain to chain as demonstrated by this model.
- Onboarding New Applications: Before endpoints for the new chain are provided to applications, we’ll test the quality of the nodes who are settling the chain and coordinate on any enhancements that need to be made. When we’re comfortable with the quality of the service, we’ll expose the chain through the Pocket Portal. While this testing process happens, the developers of ecosystem tools such as Node Pilot will also be able to integrate the new chains natively.
- Ending Relay Bootstrapping: The Foundation’s bootstrap relays would exist until we onboard enough new applications to organically achieve the MVR count, or after 3 months, whichever comes soonest.
To reinforce the economic security of the protocol for smaller chains while they’re being bootstrapped, the Foundation would lower the MaxApplications parameter value, lowering the number of app stakes that the protocol permits, then fill these slots up with Pocket Portal stakes so that apps can only access the network through the Portal.
To ensure a smooth UX for end-users, and allow the Foundation to adjust the MaxApplications parameters as needed, we should delegate the permission to change the MaxApplications parameter to the Foundation. See Governance below for details.
Once the protocol has native quality-of-service mechanisms that are capable of countering/punishing targeted servicing, the original parameter value (9223372036854775807) would be reinstated and the Foundation would give up its delegated permission.
Add the following clauses to the Constitution:
The SupportedBlockchains parameter will be governed by the Foundation in order to facilitate a frictionless onboarding experience for new chains. Before whitelisting, the Foundation will provide node runners with sufficient notice to deploy nodes for the new blockchain prior to whitelisting.
The MaxApplications parameter will be governed by the Foundation to ensure economic security while bootstrapping new chains, per ‘PIP-6.2: Settlers of New Chains’, until Pocket Core has been upgraded to address targeted servicing.
Filling Out MaxApplications Stakes Minimizes Friction Without Undermining the Integrity of the Protocol
Allowing the Foundation to make discretionary adjustments to the MaxApplications parameter and fill out the slots for the Portal represents operational centralization in the sense that apps will need to either:
- Use the Portal
- Ask the Foundation to raise MaxApplications parameter so that they can stake directly with PocketJS
This temporarily strays from our long-term goals of permissionless access, however, all apps so far have opted to use the Portal, so we don’t anticipate this being unpopular with apps as their user experience will remain unaffected.
Ultimately, this is the lowest friction method for bootstrapping new chains. Since we’ll have enough insight into the apps using the Portal to know whether targeted servicing is occurring, filling out MaxApplications gives us complete freedom to whitelist new chains rapidly without worrying about whether both sides of the market are large enough to uphold economic security.
It does this without undermining the integrity of the protocol since it makes use of the existing mechanisms and parameters that have been there from the beginning. When we no longer need these temporary measures (once native quality-of-service mechanisms exist on-chain), the DAO can simply vote to resume control of the MaxApplications parameter and increase the value.
Delegating Control of the SupportedBlockchains Whitelist Doesn’t Stop Community Members Deploying New Chains
While this proposal seeks to delegate control of the SupportedBlockchains whitelist to the Foundation, for operational efficiency, this does not stop any community members from deploying new chains and rallying support to whitelist them.
The MVR is the baseline number of relays required to ensure that enough RelayChain nodes are breaking even on the cost of their operation, to ensure a baseline quality of service to applications. As described above, the settling process will involve providing this baseline from the Pocket Network Foundation’s stakes until enough apps have adopted the service to achieve the MVR organically.
For illustrative purposes, we created a model that calculates the expected impact on overall inflation of settling new chains, with the following assumptions:
- OTC price of POKT is $0.30 as of 06/2021
- We want a minimum of 15 RelayChain nodes to ensure a baseline quality of service
- The average node runner will connect 10 Pocket nodes to their RelayChain node to maximize the odds of being selected in sessions, and there will be no overlap between each RelayChain’s Pocket nodes
- We only need to provide MVR for the following chains: Fuse, xDAI, Avalanche, ETH-Tracing, BSC, BSC-Archival
Assuming 3 months of Minimum Viable Relays under these assumptions, this would result in 0.19% inflation overall. This seems like a worthwhile cost for the outcome of growing Pocket’s multi-chain ecosystem, especially when those least diluted will be those who are most engaged.
A future upgrade will remove many of these risks by using on-chain data to automatically remove targeted servicing. However, we would argue that the market demand for these new chains is high enough, and the risks of this particular solution low enough, that moving forward with this proposal would still be worth doing.
While the MVR inflation may affect the value of the POKT held by all POKT holders, it is a relatively small price to pay for the potential increase in the growth of the network. All holders of POKT will be affected equally, from small to large node runners.
It could be argued that larger holders of POKT have more opportunity to outpace this inflation by running extra nodes. But it could be also argued that smaller node runners will be more agile and have a better opportunity to claim the revenue of new chains before they get saturated.
This proposal creates yet another reason to participate as a node in the network – especially the new chains – to outpace any inflation that may be incurred from this proposal.
- If this proposal is approved, the Foundation would be given the permission to change the following parameters without the DAO’s approval:
- We would use this permission to ensure a steady pipeline of new chains, based on our inbound relationships, with fair notice to all node runners to profit from this growth. Before whitelisting new chains, the Foundation would give the community enough time to spin up nodes for the chain.
- To both test and incentivize support for new chains, the Foundation will stake POKT and send relays on the new RelayChainID, for 3 months or until the Minimum Viable Relay count is reached organically, whichever comes first. The relay counts on all chains will be monitored and PNF stakes adjusted to ensure MVR is met as a baseline during the 3 month settling period.
- If this proposal passes, we would whitelist the following RelayChainIDs on July 5th. This proposal serves as notice for node runners that they should prepare for the whitelisting of these chains:
- Avalanche Mainnet (0003)
- BSC (0004)
- BSC Archival (0010)
- Fuse (0005)
- xDAI (0027)
- Ethereum Archival Trace (0028)
- Ethereum Ropsten (0023)
- Ethereum Rinkeby (0025)
- Ethereum Goerli (0026)
- Ethereum Kovan (0024)
- Ethereum Archival (0022) – no MVR expected to be provided by PNF, because Archival seems to have organic MVR already
- Any time a new chain is being whitelisted or the settling status changes, we’ll provide notice as a reply to this proposal and in the announcements Discord channel.
Copyright and related rights waived via CC0.