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.
This proposal aims at introducing an on-chain revenue share mechanism between RPC endpoint/full node providers and Pocket Network validators.
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.
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.
For this type of reward scheme to be enabled on Pocket we will need the following:
- A metering service to count units of useful work (data relays from full nodes to consumers of data)
- 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 email@example.com for his instrumental input in this section
What is the scope of work in implementing the proposed network upgrade?
Will the cadence of payouts to operators take place on a block-by-block basis? firstname.lastname@example.org feedback: if using the above Reward Address solution, rewards would be block-by-block
Will the payout to operators be relayed automatically or will it accrue and disbursed when called? email@example.com: relayed automatically if using the above solution
- Discuss the perceived benefits of the proposal and weigh them vs drawbacks.
- Come to consensus with regards to feasibility and desireability.
- Discuss roadmapping, assuming the sentiment is largely in favour.
Looking forward to hearing from you all !
Copyright and related rights waived via CC0.