New Values: 0002 (Bitcoin Mainnet), 0003 (Avalanche Mainnet), 0023 (Ethereum Ropsten Full Node), 0024 (Ethereum Kovan Full Node), 0025 (Ethereum Rinkeby Full Node), 0026 (Ethereum Gorli Full Node), 0027 (xDAI Full Node), 0011 (Fuse Mainnet), 0041 (Binance Smart Chain Mainnet), 0051 (Solana Mainnet), 0061 (Energy Web mainnet), 0071 (Shyft Network Mainnet)
Summary
I propose to add the following chains to the SupportedBlockchains parameter:
Bitcoin Mainnet
Avalanche Mainnet
Ethereum Ropsten Full Node
Ethereum Kovan Full Node
Ethereum Rinkeby Full Node
Ethereum Gorli Full Node
xDAI Full Node
Fuse Mainnet
Binance Smart Chain Mainnet
Solana Mainnet
Energy Web mainnet
Shyft Network Mainnet
because these chains would help to drive the growth of relays on the network.
Abstract
I am proposing to whitelist the above chains for revenue generation. Each of these networks are either currently in use on Pocket Mainnet without monetization, or have been widely requested by our application partners. It is crucial to the growth of Pocket’s ecosystem that we incentivize our node community to further support these networks.
Motivation
Many of Pocket’s partners have needs that extend beyond Ethereum Mainnet. Being a blockchain agnostic solution, Pocket needs to provide increased support for other networks. The best way to do this is by incentivizing Pocket Validator Nodes to run nodes for the ecosystems our users are desiring. By monetizing these chains, we create this incentive and have a robust infrastructure to service our application partners.
Rationale
We believe that there is sufficient demand for these chains to support the costs to Pocket nodes of running these nodes.
Bitcoin Mainnet: Supported by most wallets
Avalanche Mainnet: A top tier layer 1 blockchain and DApp platform
Ethereum Ropsten Full Node: Important testnet used by Ethereum projects
Ethereum Kovan Full Node: Important testnet used by Ethereum projects
Ethereum Rinkeby Full Node: Important testnet used by Ethereum projects
Ethereum Gorli Full Node: Important testnet used by Ethereum projects
xDAI Full Node: Platform for running cheaper ETH contracts, growing due to high gas fees on layer 1.
Fuse Mainnet: Payment and DeFi platform wanting to use Pocket as their default service provider. There are parties lined up to provide node support and parties lined up to provide relays.
Binance Smart Chain Mainnet: Ethereum alternative that is rapidly expanding. Many Pocket users have asked for BSC support as there is a real need for BSC infra.
Solana Mainnet - Solana is a growing smart contract platform. There are parties lined up to provide node support and parties lined up to provide relays
Energy Web mainnet - An Ethereum fork that is focused on bringing blockchain technology to the energy sector. There are parties lined up to provide node support and parties lined up to provide relays
Shyft Network - Payment and DeFi platform wanting to use Pocket as their default service provider. There are parties lined up to provide node support and parties lined up to provide relays.
Dissenting Opinions
TBD
Analysts
Shane Burgett - Solutions Lead, Pocket Network Inc.
Upgrading the param before a significant # of nodes support each chain is a recipe for a ‘self dealing’ attack.
The original vision to modify this parameter is to not only have a significant number of nodes pre -committed to the new blockchain, but also some significant number of nodes actually running the blockchain before the DAO changes the param.
I would strongly advise the following:
Create an official governance accepted protocol that addresses the security concerns of supporting blockchains before the protocol ‘actually’ supports the new blockchains. The protocol proposal would include an acceptable threshold of committed vs pre-running node operators that balances both growth and security
The hypothesis is 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.
You touch on a valid point about the vulnerability of this process to scale. 5% of the DAO is not many people while the DAO is still small (though that is why we have such a strict qualification process). And when a chain is brand new (still scaling) it may be vulnerable to self-dealing, which is especially true due to the lack of an Update Stake command which means most nodes would take a few weeks to get set up, as @AlexF touches on.
However, what you’re ignoring is that there’s a chicken and egg / free rider problem. Who will be willing to run nodes at a loss for several weeks in order to whitelist a chain, when they could just let other nodes do it while they profit? This incentive problem is compounded by the stake editing delay that @AlexF describes. In short, we lack sufficient bootstrapping incentives for new chains, which was the idea that the (abandoned afaik) CampaignNet project planned to address.
I’m open to discussions on how we can resolve these trade-offs.
and possibly affecting network quality due to nodes going offline
…
stake new nodes, exacerbating the # of validators issue
Unstaking is currently the graceful way to exit the network, node runners (who have some liquidity) can unstake and stake (a new node) simultaneously to not ‘lose their income stream for 3 weeks’ and avoid the # of Validators issue.
The update stake function is going to rollout with 7.0 (we are just now releasing 6.0). The timeline isn’t finalized
It is important to highlight the attack vector still stands regardless of the UX of the switch
(I do hear your point about the process though and how this can hinder the proposal)
It would be helpful if you could clarify what you view to be a significant number, because your perception of significant may differ from the perception of those doing biz dev on new chains.
Edit to add: beyond what threshold of apps/nodes does self-dealing become unlikely?
The reason the Validators are not signaling now, is the naming scheme was just finalized late last week and the chains were given their RelayChainIDs last night
Validators have been lined up for a few weeks, but they didn’t have a RelayChainID to add to their Validators. I like the idea of having them signal early for all future integrations, it just didn’t pan out this time due to the ID being a blocker.
Now that we have our ID process down, we won’t have the same bottleneck for other integrations. We have plans to announce intentions prior, and then give nodes a chance to spin up infra.
Right now we have users waiting on integrations, so we didn’t want to naming scheme the push plans down the road and have us miss existing opportunities.
Am I missing something here? Do we have no data on current usage, number of nodes, amount of backend support, distribution of node ownership? And we are pushing to white list these chains for paid relays?
I’m sorry if I haven’t stayed current on the new chain developments, I’m in the channel where providers like me are spinning up backend for these chains, but I haven’t seen any chatter about most of these. I think I am the only AVA full node on the entire network. Pretty sure the gateway emergency AVA backup is just my node on a different path. I run xDai and BTC full nodes also so I know the gateway has some data on these chains.
Good callout, the “specialized testnet” refers to the CampaignNet project that didn’t take off. The purpose of that was to bootstrap the incentives of node running by providing rewards to early nodes on a chain.
Many of these chains are opportunities that are coming through our business development pipeline. Nodes haven’t been run on the network for them yet, but there is varying evidence (dependent on chain) to suggest that they would bring significant relays to the network.
PUP4 will modify the economic incentives (or lack thereof).
And now a massive change to the supported networks.
I am all for moving fast, but Pocket is mainly a critical infra provider. We want to deliver high performance, high reliability and high quality. Doing right is more important than doing more.
Also, as NachoNodes said, unstake/stake is very undesirable for most investors, and staking new nodes is not what we want these days.
My recommendation is slowing down a little bit. Can I suggest perhaps choosing a smaller subset of these? That’s still a positive growth, but also giving everyone a chance to fully bake everything.
Thank-you everyone for all the feedback. We are withdrawing this proposal to introduce a new proposal in the near future that will address the issue raised in this version.
ALSO, the RelayChainIDs are NOT official and NOT to use them with Validators. For ALL official RelayChainIDs, always refer to: List of Supported Blockchains
