Attributes
- Author(s): @toshi @conkleris @bulutcambazi in C0D3R
- Implementer(s): The proposal authors
- Category: Protocol Upgrade
GitHub:
[v0.11 feature] Per-chain Relays To Token Multiplier by msmania · Pull Request #1580 · pokt-network/pocket-core · GitHub 3
Abstract
The calculation of relay rewards is determined by the following formula [1]
Number of relays * Relays To Tokens Multiplier * Reward Multiplier
where Reward Multiplier is determined by the node’s stake amount, and Relays To Tokens Multiplier (= RTTM) is the value of the network parameter pos/RelaysToTokensMultiplier [2].
We propose a new parameter pos/RelaysToTokensMultiplierMap so that we can set RTTM per chain.
[1] Node Economics - Pocket Network
[2] Protocol Parameters - Pocket Network
Motivation / Rationale
The operational costs of running a node can differ significantly across various blockchain networks. For instance, maintaining an archival node is considerably more expensive than operating a pruned node, and enabling debug/trace calls on a node incurs additional computational costs. That’s why Pocket Network provides separated chain IDs for an archival network and a non-archival network for some blockchains. For example, there are three chain IDs for Ethereum Mainnet, Ethereum Mainnet (0021), Ethereum Mainnet Archival (0022), and Ethereum Mainnet Archival with trace calls (0028). It’s intuitive to expect that relay rewards for 0028 should be higher than relay rewards for 0022, and rewards for 0022 should be higher than rewards for 0021. With the introduction of our new parameter, pos/RelaysToTokensMultiplierMap, we can now implement this flexible reward structure by adjusting the network parameter.
Perhaps more importantly, Pocket is an RPC infrastructure, and RPC is not limited to blockchain calls. We envision that Pocket can be used to make calls into more complex API endpoints. A good example is newly emerging generative AI interfaces such as LLMs. These endpoints cost 100 to 1000 times more per call. Proper rewarding is needed if we will make these new non-blockchain RPC chains feasible.
Finally, this also helps keeping “quiet” chains feasible. Currently, node operators are incentivized to host “busy” and established chains because performing more relays is the way to get more rewards. With pos/RelaysToTokensMultiplierMap, we can incentivize node operators to host brand new chains / quiet chains with little traffic by setting higher RTTMs for such chains.
Specification
The new parameter is added in the pos module side by side with the existing pos/RelaysToTokensMultiplier. Its parameter defines a mapping from a chain ID to a custom multiplier as follows.
{
"relays_to_tokens_multiplier": "181",
"relays_to_tokens_multiplier_map": { // <--- New
"0028": "12345"
},
...
}
When a node mints relay rewards, it looks up the pos/RelaysToTokensMultiplierMap, and the relayed chain is defined there, it adopts a custom multiplier for that chain to calculate the amount of relay rewards, otherwise it adopts the default multiplier of pos/RelaysToTokensMultiplier.
Discussion
Q: Are we turning our backs to our trusted traditional chains?
No. This is not a new slice in the pie, at the expense of other less computationally expensive chains. This is growing the pie, opening up new markets, new applications, new possibilities. If anything, we are growing our pie at the expense of other centralized and decentralized players who are already making progress in this direction.
Q: This is all good in theory, but who will actually use this?
Grove, currently the largest portal operator confirmed their support and demand at all levels of their company.
Q: Won’t more rewards result in more inflation?
Yes. But no. Although it is not part of this proposal, and will be decided by independent PUPs in the future, we believe that the new chains with higher-than-normal RTTM values should be non-inflationary. This can be achived by making mint equivalent to burns. If a node runner earned X POKT for a relay, the portal who brought that traffic should be charged exactly X POKT.
- The cost to run them will be compensated entirely by the portal operators which, in turn, will be compensated by their customers. Compare this to today, where node runners are compensated partly by inflation out of nowhere.
- Since these custom chains are non-inflationary, they can be excluded from ARR calculations.
- Although they are not part of ARR calculations, they still serve the purpose of proving the world that Pocket Ecosystem cares about the inflation, and they are taking concrete steps towards non-inflationary models.
Q: Won’t more rewards result into more sell pressure?
Again, yes, but no if custom-RTTM chains are non-inflationary. More sell pressure, yes, but also at least the equivalent buy pressure, because portals will need to buy the tokens to burn them. Since it is non-inflationary, they will have to buy them from node runners.
We say “at least” because there is a distinct possibility faith in the future value of POKT can improve due to these exciting developments, and node runners might save some of the emission to themselves for future use, therefore increasing the buy pressure, improving the token price.
Q: Wasn’t this discussed and voted recently?
PIP-31 was voted recently, but that PIP was for 2 independent features put together and had missing details. Based on the feedback we got from the forum and the recommendations from v0 maintainers conference call on 10/10, we decided to split up the proposals, implement the feedback and repropose.
Q: I see the proposers are from a professional node runner company. Was is in it for them? Is there a hidden agenda?
There is nothing in it for them nor is there any hidden agenda. The only agenda here is making the Pocket ecosystem larger, more profitable and more competitive against other similar platforms.
Q: Is it true that only a few node runners has the resources to run gen-AI chains because gen AI is so complex?
No, it is not true. Creating gen-AI models can indeed be very difficult and R&D heavy, but by and large, running trained models is not more difficult than running a docker image. Anyone with basic container knowledge can do it. Check all these models that Pocket could run: Models - Hugging Face
Viability
- New unit tests to verify the new features are included in the PRs we implemented.
- We perform end-to-end testing, where we submit relays and verify the rewards are distributed correctly, on Pocket Testnet before upgrading Mainnet.
- We prepare upgrade plan after this proposal is approved.
Implementation
This proposal includes two working implementations as GitHub PRs above. They’ve been verified on our private devnet:
- submit gov transactions
- keep sending relays throughout a test (before/after gov transactions) and wait until relay rewards are minted
- verify the amount of rewards
Deployment:
- If this proposal is approved, and after testing has taken place for BETA-0.11.0 on Testnet, RC-0.11.0 will be published for node runner adoption. Anyone can monitor node runner adoption of RC-0.11.0 using the Servicers and Validators version pie charts displayed here or the equivalent “Staked Tokens by Node Version” chart displayed here .
- Once ≥67% of validator power has updated to this version, an upgrade height will be selected by the Foundation Directors based on the preferences expressed by node runners (e.g. through Discord polls) and they will pass this height to the chain through the
pocket gov upgradetransaction. - The upgrade height chosen by the Foundation Directors will be communicated in advance to ensure node runners are prepared to react if necessary. A time will be targeted that maximizes the availability of node runners, accounting for all time zones and working hours.
- Once the network is upgraded, each of the new features will be enabled by the Foundation submitting the
pocket gov enabletxs and working with the protocol developers to ensure there are no issues. - For avoidance of doubt, this PIP does not approve any values for the new
RelaysToTokensMultiplierMapparameter, which means the globalRelaysToTokensMultiplierwill continue to apply to all chains until a subsequent PUP is approved modifying the newRelaysToTokensMultiplierMapparameter.
Example
Here’s an example command to change per-chain RTTMs.
export DAO=<DAO address>
export NETWORK=mainnet
$POKT gov change_param $DAO $NETWORK pos/RelaysToTokensMultiplierMap '{"0001":"12345","03DF":"42","0028":"3141592"}' 10000
Once it’s accepted by the network, the new parameter looks like this.
$POKT query node-params
2023/09/19 11:30:20 Initializing Pocket Datadir
2023/09/19 11:30:20 datadir = /home/john/.pocket
http://localhost:8082/v1/query/nodeparams
{
"dao_allocation": "10",
"downtime_jail_duration": "3600000000000",
"max_evidence_age": "120000000000",
"max_jailed_blocks": "37960",
"max_validators": "5",
"maximum_chains": "20",
"min_signed_per_window": "0.600000000000000000",
"proposer_allocation": "1",
"relays_to_tokens_multiplier": "8461",
"relays_to_tokens_multiplier_map": {
"0001": "12345",
"0028": "3141592",
"03DF": "42"
},
"servicer_stake_floor_multipler": "15000000000",
"servicer_stake_floor_multiplier_exponent": "1.000000000000000000",
"servicer_stake_weight_ceiling": "15000000000",
"servicer_stake_weight_multipler": "1.000000000000000000",
"session_block_frequency": "4",
"signed_blocks_window": "10",
"slash_fraction_double_sign": "0.000001000000000000",
"slash_fraction_downtime": "0.000001000000000000",
"stake_denom": "upokt",
"stake_minimum": "15000000000",
"unstaking_time": "300000000000"
}
Audit
There will be no external audit, refer to Viability.
Copyright
Copyright and related rights waived via CC0.
Edits
This proposal is not available for voting:
https://gov.pokt.network/#/proposal/0x7793ba565324c35b28ad39934f70e3b18ab534738fa83ceab9162d03ef6baada
I fully support and back this proposal 
s to increasing Pocket Network’s Total Addressable Market, and will also show the 
a use-case where blockchains can provide real value in the Web2 landscape.