PIP-11: Implementing an On-chain Rev Share Mechanism

About the Author

Elias Simos is a Protocol Specialist at Coinbase Cloud (fka Bison Trails). Elias led Decentral Park Capital’s investment in Pocket c.a. February 2020 during his time there, and has been a friend of Pocket ever since.

Context

This proposal aims at introducing an on-chain revenue share mechanism between RPC endpoint/full node providers and Pocket Network validators.

Motivation

In June 2021, Coinbase Cloud and the Pocket Network Foundation engaged in a business relationship under which Coinbase Cloud is providing RPC endpoint access to Pocket Network validator nodes, on a series of networks that Pocket Network supports. We are proud to have enabled Pocket to scale its access to high quality read/write bandwidth and to have contributed a small part in the runaway success of Pocket in H2 2021, as the network scaled its relay count to over 16x what it was in the beginning of H2.

This proposal is inspired by the successful experiment we have been running over the past 6 months and seeks to operationalize and scale some of the tangible benefits the experiment has brought to Pocket Network.

Rationale

As the network is currently structured, rewards for relays in POKT tokens are reserved for Pocket validator nodes and operators. This structure implicitly assumes that Pocket validators are the sole entities operating full nodes of the chains the data is being relayed from. Alas, within a validator cluster there are two tracks of work being performed; (i) relaying data and (ii) performing validation services.

By optionally separating the two tracks of work in terms of rewards earned, we can achieve the following benefits for the network:

  • Grow and further decentralise the network; by enabling on-chain revenue sharing between Pocket validators and full node suppliers, we enable operators from various networks to become Pocket stakeholders by providing useful work to Pocket, but without requiring them to necessarily make the investment to also run validators. As these operators earn POKT tokens and build a balance, they can then elect to become validators themselves.

  • More optionality for Pocket validators; running a Pocket validator and running multiple full nodes require somewhat overlapping skill sets, albeit not perfectly. By enabling Pocket validators to reward the suppliers of RPC endpoint access with POKT tokens, Pocket validators can draw read/write capacity from specialists, thus increasing the available capacity and quality of the source of relays.

  • Harden the network and increase redundancy; by introducing an optional mechanism that incentivizes partial participation on the work side of the network, we allow for operators to specialize in either of the two distinct categories of work nodes provide to the network. With more specialization and less overhead at the network level, we edge closer to a more performant whole that is harder to break.

  • More economic optionality for operators; with this solution in place, Pocket validator operators can use their network earnings to directly offset costs of running full nodes, if they choose to delegate this to a third party.

Operationalizing the proposed solution

For this type of reward scheme to be enabled on Pocket we will need the following:

  1. A metering service to count units of useful work (data relays from full nodes to consumers of data)
  2. A periodic and programmatic on-chain POKT transfer mechanism, with tunable parameters conditional to the metering service. The Cosmos SDK already has templates for payouts to delegators; these could be repurposed to power the proposed solution.

The metering service already exists and it’s a core feature of the protocol. A Pocket node already earns POKT proportional to the data relayed by the full node it is communicating with. Assuming there is a 1:1 relationship between the Pocket node and external full nodes provided by CC (i.e. the Pocket node is not using any other service providers), this means the units of work processed by the Pocket node equal the units of work processed by CC’s full node.

Thus, the pre-existing “metering service” applies and on-chain rev share could be as easy as the Pocket node specifying a Reward Address to divert a % of their block rewards to. This would require upgrading the protocol to enable Reward Addresses to be specified when staking. There is already a feature in the works that enables 1:1 non-custodial staking, by separating the “Operator Address” from an “Output Address”.

The Output Address could be further separated into a Custodial Address (the owner of the POKT stake) and multiple Reward Addresses (the recipients of the POKT revenue).

This solution wouldn’t be perfectly trustless because in theory the Custodial Address could unstake their node and restake without the revenue share. But the network of participants in Pocket could easily monitor this, flag it and automatically shut off service if anything is changed.

h/t jack@pokt.network for his instrumental input in this section

Open questions

  1. What is the scope of work in implementing the proposed network upgrade?

  2. Will the cadence of payouts to operators take place on a block-by-block basis? jack@pokt.network feedback: if using the above Reward Address solution, rewards would be block-by-block

  3. Will the payout to operators be relayed automatically or will it accrue and disbursed when called? jack@pokt.networkfeedback: relayed automatically if using the above solution

Goals

  1. Discuss the perceived benefits of the proposal and weigh them vs drawbacks.
  2. Come to consensus with regards to feasibility and desireability.
  3. Discuss roadmapping, assuming the sentiment is largely in favour.

Looking forward to hearing from you all !

Copyright

Copyright and related rights waived via CC0.

8 Likes

From my perspective, reducing the friction for onboarding high-quality full node providers, like Coinbase Cloud, makes a lot of sense for all of the good reasons outlined by Elias above.

We know from the previous posts from @AlexPocket - Increasing Hardware Requirements for Pocket Nodes - that the most rewards go to the “fittest nodes”. Not every staked Pocket node - whether staked as a servicer or validator - will be able to run full nodes for new blockchains as well as specialist node providers for that particular chain.

I see this proposal as a way to potentially democratise access to the highest performing nodes in a given network, while also increasing performance for end-user applications.

Some of the immediate questions that come to mind for me (in no particular order) are:

  1. How could Pocket node runners signal that they want to leverage full nodes from providers like Coinbase Cloud?

  2. How will providers like Coinbase Cloud make their decisions? Do they want to work with one or two providers? Or many?

  3. What are the centralising risks we should be aware of? And how to mitigate such?

  4. What is a fair revenue split between a staked Pocket relay node and a full node? Could potential power imbalances be exploited here? Similarly, how can we prevent too much friction in negotiations, which may ward off node providers in other networks? Other specialist node providers are unlikely to be as deeply integrated as Elias in the Pocket Network community already, so they will need to be given comfort about what they are getting themselves into.

I’d love more people to jump in with potential drawbacks - from both a technical, commercial and perhaps strategic standpoint.

2 Likes

This is important to investigate.

Given the large number of third-party chains supported by Pocket with the work that implies for node operators, and the amount of relays and rewards brought by some of the long-tail chains, there could be heavy incentives to delegate full node operations to full node providers such as Coinbase Cloud, especially for smaller node runners who don’t have the scale and capacity to start and support full nodes for 20+ chains.

This is a great thing if Pocket Network validators can easily access full nodes from a range of reputable providers such as Coinbase Cloud but that should also include many other operators such as Figment, Blockdaemon and the other usual suspects so that there isn’t a unique setup being built in terms of full-node infrastructure (which would miss PN’s point).

Currently and given pseudo-randomness in validator selection, the number of Pocket validators running is a close estimate of the network decentralisation degree. It would be important to have a similar metric to measure full node decentralisation to ensure we do not end up with Pocket Network being a mere front-end to a couple of full node providers.

especially for smaller node runners who don’t have the scale and capacity to start and support full nodes for 20+ chains.

Circling back on this point: this would be a great argument for large Pocket Network validators such as Blockspaces that they’re actually contributing to the network decentralisation if their scale give them the opportunity to run their own full node infrastructure across all chains supported by Pocket, rather than running on third-party full nodes (like I’d expect individual node runners to do).

this was my main concern about this proposal. if nodes end up delegating to just two or three centralized providers

If you want to pay by relayChain serviced (as opposed to fixed % of all rewards) this may be impossible. Definitely very tricky even if possible.

And… From my experience, If you don’t host the backend on the same local network as the frontend, you won’t be competitive.

2 Likes

Thank you all for your comments so far. From a quick scan of the section, I can see the following main questions and concerns arising. Let me offer my perspective on each one:

1. Centralization risk at the full node layer

In the short-to-medium term I don’t think this is a high probability outcome. In fact, when considering the variance in outcomes, I think it’s probably > 2σ. There are quite a few providers out there (CC included) from which Pocket validators could source read/write bandwidth from, with loose overlap of offerings–especially in the longer tail of chains that Pocket supports. Opening up the marketplace in the way PIP-11 suggests actually creates more competition, which should altogether improve the network’s output.

Perhaps there even is a co-location vs full-node quality tradeoff scale at play here that could help further balance things out.

Over the long term, I feel I am poorly equipped to make a definitive judgment, although I my gut tells me it’s equally unlikely. The long-term is a series of short-term intervals strung together by path dependency after all.

Let’s for a moment, however, entertain the idea that full node bandwidth supply would centralize in 2-3 providers. This doesn’t mean that the network topology will tend to centralize in one location. For example, through the Coinbase Cloud platform you can spin up dedicated nodes in virtually all locations available in the major cloud providers.

So the only real concern here is cenrsorship resistance; a fair and very valid concern. Let’s unpack a couple of scenarios here.

If the steady state long-term is an oligopoly of full-node providers, then if any single entity decided to censor access to full-nodes, it would give up all its share of the market to its competitors. There are strong disincentives to pursue that course of action.If the steady state is a monopoly (or equivalently we see a state level censorship of the oligopoly that forces them to act in unison) then the threat becomes a little more real.

To mitigate this, the DAO or Foundation could incentivize a critical mass of failover full nodes to exist profitably through subsidies to guarantee continuity in the event of large scale censorship action, until validators spin up their own full nodes or plug into alternatives. This is akin to the Ethereum Foundation subsidizing the development of minority eth2 clients.

2. Fair revenue sharing, demand signalling, provider screening

Imo this whole bundle is better left to the market to decide. Initially there will most likely be a lot of overhead in sourcing, screening, agreeing, troubleshooting etc on both sides of the marketplace. So be it I say.

Over time things will get increasingly more streamlined and possibly a lot of the complexity can be automated and abstracted away.

I don’t think we can know all the potential inflexibilities to streamline pre-flop. As more cards open on the table, we can adjust, course-correct and improve.

Ultimately, integration and pricing decisions should be left to the humans behind the machines to decide, but the machines should allow for humans to express maximal optionality.

3. Revenue share mechanism

Again, not the best equipped to answer the question here as I don’t know the full scope of Pocket’s limitations. I can, however, perhaps offer a comment about an ideal world–which might or might not be possible.

Some of the aims of the proposal, as stated earlier are to (i) increase optionality for validators, (ii) increase network-wide redundancy, and ultimately (iii) offer better data access to end users.

If these aims are to be fulfilled, and allowing for market forces to shape ultimate pricing, the mechanism would have to maximize for simplicity and flexibility, subject to specificity constraints.

By the above, a Pocket validator should be able to plug into multiple different providers (via endpoints), and have the option to set different rev-share parameters with each provider and potentially on each endpoint. Ideally these would be somehow governed by units of useful work produced for the network.

Would love to hear other technical folks weight in on this. I would think that a solution is still tenable with heuristics (fixed % of all rewards that periodically changes) if closer metering is not possible.

2 Likes

A well written post, I’m very encouraged to see PIPs like this coming forward :slight_smile: .

On the other hand, I currently disagree with this proposal and do not think it should be passed by the DAO.

My disagreement is best summarized in PIP-9 dissenting opinions:

Anything that can be moved to L2 to assist the network should be. Adding a revenue share % field for rewards not only increases the complexity of development - it also grows the blockchain size by an entire other field per Service Node. This is an unacceptable trade off considering the position Pocket Network is currently in with state size and data duplication. As this feature was considered when Non-Custodial was specified, it was realized that it’s quite unrealistic to optimize for a single use-case revenue share model. If the feature optimizes for one - it must optimize for others (fee scheduling - stake splitting etc) it’s a very slippery slope.

To further the point, Pocket Network Mainnet is currently supporting 18K+ validators and a sync from scratch can take days. As the core team alleviates the scalability issues with a persistence overhaul, feature requests like this can counter the efforts. At this stage in the project, the protocol is optimizing for security and scalability, not specific business use-cases. Though admittedly there is value in revenue sharing and it could be done L1 within the core Pocket protocol, at this time I’d highly discourage attempting to make a change that doesn’t support technical longevity of the blockchain. I would encourage the community to revisit this proposal at a later phase closer to maturity.

Thank you for the detailed thoughts and ideas, @eliasimos. I learnt a few things myself by reading through the proposal and comments!

Though a lot of the ideas and suggestions resonate with me and arguably help both the growth and resilience of the network, I would personally like to push against it for the time being. I will defer the decision to the DAO.

1. Centralization risk at the full node layer

You mentioned this is not a risk in the short-medium term. However, I wanted to strengthen the point that Pocket is quite decentralized for a nascent network that is still being bootstrapped:

Image from poktscan.com

As the community grows, documentation & infrastructure improve, it will be easier for individuals to run their own nodes. For example, nodepilot.tech is moving fast, and I wouldn’t be surprised if they introduce some sort of node pooling (but that is outside the scope of this discussion).

2. Multiple Reward Addresses

As @Andrew, this is a great addition to a business use-case, though it still doesn’t solve all the problems so it is hard to determine where a line should be drawn. PIP-9 helps increase the security of the network, which is a large improvement in the short-term.

We are still learning around various business use cases as the market evolves, so it may be premature to implement some of those solutions in L1. For example, some node runners allow the stakeholders to configure a parameter to withdraw their POKT when earnings pass a certain threshold. It is still too early to say if business logic like this should be implemented in L1 today.

Final thoughts

Overall, my vote is to keep discussing but defer this PIP until the network is more mature.

I think this mechanism would be nice, but may come with other complications. The chain is already growing very rapidly, and I would imagine that this would increase blocksizes dramatically. Chain halts also seem to be fairly common, and modifying consensus would make those more likely.

I do think this mechanism would be useful though. Currently, revshare node providers do not worry about getting paid from the rewards since they have the keys, but once pokt switches to non-custodial, node providers will now have to trust their clients to pay them the revshare. This could end up bloating the chain more, for node providers might require their clients to send them their share of rewards daily. The issue with doing onchain revshare for coinbase cloud full nodes, is that the reliability of coinbase cloud nodes is not onchain. The full node provider could pull the service, and would still earn rewards if the pokt validator changed their chains.json.

This service outside of onchain revshare would be very beneficial though. I made a post offering to help people set up their nodes, and out of the handful that reached out, all them had no idea that they needed to run blockchain nodes to earn rewards for their pokt validator. They all wanted to run one pokt node, but it is not economical to run a blockchain cluster for just one node. A full node provider would allow small guys to participate. But, depends what metric you’re using for decentralization (number of full nodes v. distribution of pokt validators.) If it’s the former, then not sure that making it easier to rely on another party for their blockchain data is a good thing.

1 Like

Bringing in an on-chain rev share mechanism as outlined by @eliasimos, at the highest level, appears to address the issue for onboarding high-quality full node providers (CC). Though, this is clearly a complex proposal that deserves to be drawn out as much as possible. Some thoughts to add:

I do not believe the topology would be affected even in the worst case of only 3 providers dominating over the network as @eliasimos highlights. If the problem is that of censorship resistance - a more pressing question would be: what incentive does CC and others have to act this way?

With this in mind, it may be valuable to take a leaf out of API3’s first-party framework - API redundancy, security, and accuracy are all reliant on the reputation of the data providers themselves. The thesis being an overall more efficient, effective oracle network where the DAO can oversee all operations from both sides of the market. We should, therefore, equally explore at what point the benefit of Pocket Network becoming more performant and streamlined outweighs the level of risk introduced at the node layer.

Note - API3 partnered with Pocket Network and performed a token swap in February 2021.

This brings me to risk mitigation. It strikes me that having Pocket Network dynamically react to external ‘pressures’ such as concentration around few providers is an worthy exploration.

One approach could be to have rewards asymptotically decline on a pre-defined function based on some metric (e.g. #of total supply delegated). But I defer to the technical to understand how this can be done.

If Pocket become more decentralized at the node layer, wouldn’t this directionally counter risks introduced by the likes of CC and other providers?

If Pocket become more decentralized at the node layer, wouldn’t this directionally counter risks introduced by the likes of CC and other providers?

My main questions would be:

  1. What is a ‘fair distribution’ and how can this be dynamic based on certain inputs into a calculation What are the inputs?
  2. Can rewards be split by relayChain serviced? If not, how can we reconcile this based on the actually underlying work carried out by providers and their associated costs?
  3. How are we to define decentralisation within the scope of this proposal?