PIP-6.2: Settlers of New Chains

Attributes

Summary

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 Foundation’s Pocket Dashboard, 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:

  • SupportedBlockchains
  • MaxApplications

Background

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.

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.
  • 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 Dashboard, 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 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.

Motivation

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 Dashboard 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

Specification

Chain Bootstrapping Process

  1. 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.
  2. Whitelisting: Once the notice period is over, the chain will be whitelisted and start generating revenue for nodes.
  3. 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 dictated by this calculator.
  4. Onboarding New Applications: Having a pre-existing network of nodes that has been load-tested will make it easier for us to confidently 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.
  5. Ending Relay Bootstrapping: The Foundation’s bootstrap relays would exist until we onboard new applications (meaning we no longer need to cover node costs), or after 3 months, whichever comes soonest.

Limiting App Access

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 Dashboard stakes so that apps can only access the network through the Dashboard.

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.

Governance Upgrades Required to Facilitate the Above Processes

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.

Rationale

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 Dashboard represents operational centralization in the sense that apps will need to either:

  • Use the Dashboard
  • 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 Dashboard, 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 Dashboard 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.

Providing Minimum Viable Relays (MVR) Should Bootstrap Chains with Minimal Impact on Inflation

Baseline Inflation

The MVR is dependent on the number of node runners required to ensure a new chain has reliable service, accounting for the cost of running the nodes, which will vary from chain to chain. We feel that we should aim for at least 10-15 RelayChain nodes to ensure reliable service and we estimate that the average node runner will connect 10-20 Pocket nodes to every RelayChain node. This means there will be 100-300 servicers for the new RelayChainID and, to ensure that the long tail of nodes (who may connect only 1 Pocket node to their RelayChain node) is still statistically likely to break even on the cost of their RelayChain node, we will need the MVR to cover the costs of an average of 200 nodes. Otherwise, let’s say we assume a 1:1 ratio and only fund 10-15 Pocket nodes, we could end up in a situation where the 10-15 Pocket nodes are all pointing to the same RelayChain node.

Aside: Ideally, every node runner would just connect 1 Pocket node to their RelayChain node, which would ensure every node runner breaks even in the perfectly cooperative scenario, but we recognize that there is a prisoner’s dilemma because we can’t guarantee that a rogue node runner won’t seek to maximize the odds that they’re selected for sessions.

If it costs conservatively $100/mo to run a standard RelayChain node on a cloud provider, and we expect there to be an average of 200 Pocket nodes serving a RelayChain, that’s a total of $20,000 to be covered in monthly POKT rewards. Using a $0.30 price, that would need to be 66,666.67 POKT minted in total throughout the month, or 249,687.89 relays per day.

Total Network inflation

Assuming 6 months of Minimum Viable Relays for 15 chains, using the above numbers, this would result in:

For a total of 6M POKT minted over 6 months.

At a supply of nearly 660M POKT, this is only 0.91% inflation, which 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.

Dissenting Opinions

We should wait until native on-chain QoS is implemented

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.

The inflation will hurt all holders of POKT, especially small node runners

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.

Implementation

  • If this proposal is approved, the Foundation would be given the permission to change the following parameters without the DAO’s approval:
    • SupportedBlockchains
    • MaxApplications
  • 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.
  • MVR will be activated within the constraints of our ecosystem engineering team’s bandwidth. The Foundation will attempt to align the whitelisting of RelayChainIDs with the launching of MVR.
  • 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.
  • As soon as this proposal passes, we would immediately whitelist the RelayChainIDs that already have organic traffic: Ethereum Mainnet Archival, Ethereum Mainnet Archival with traces, Ethereum Rinkeby Testnet. If this proposal passes, this proposal serves as notice for node runners that these chains will be whitelisted immediately.

Copyright

Copyright and related rights waived via CC0.

2 Likes