PEP-33: Triforce Shard Income Proposal

This is a good thought, but onboarding new chains will help expand the ecosystem and further expand the utility of POKT.

Infrastructure costs are not that high, they are high for certain organizations that pay cloud providers a premium + profit margin for running nodes. I think the focus should be placed on optimization(direct hires, thin client, bare metal, pruned chain, tuned caches …etc) into these organizations that heavily inflated the node count. They could have hired in house talent and built everything out on their own for at least a 75% decrease in node costs per day w/staffing paid for the year after running a month.

I think we should propose a chain sharing mech, with % rewards payout goes to the sharing node. If the Service node wants to support a certain chain but not necessarily run a full backend chain.

Example:

Node A wants to support Harmony(0040) but doesn’t want to stand up their own infrastructure yet until they sees how it performs in the market.

  • Node Runner B has Harmony(0040) staked and is offering stake_sharing to its peers , advertises this service to any node that connects as a peer. NodeRunner B would have to provide an additional parameter to the stake command : something like shared_chains which could be a dictionary indicating the chain ,to backend_ur mapping.

  • Node Runner B has staked shared_chains for certain chain_ids , allowing NRB to only share specific chains they have extra bandwidth, load …etc to handle and penalizing them if they do not have the actual bandwidth to support extra traffic(via cherry picker checks, other QoS measures.) Either directly via the cherrypicker or indirectly via the cherrypicker and the middleman Node A.

  • Node A has stake shared [‘0004’, ‘0005’] and regular stake [‘03DF’, ‘03CB’,‘0003’]
    Node A services relay for 0040 and there is a stake_split percentage for using Node Runner B’s Harmony as a relay chain; likely larger % split to Node Runner B for running and servicing the chain and the rest to Frontend relay provider Node A.

  • Node A will still receive full relay rewards for the chains they are regularly staked for, but when staked with chains in shared_stake the provider (Node Runner B). who is footing the bulk of the work for the shared_chains gets the larger percentage of those rewards (not entirely sure on the split).

This will allow for demand to scale with chain infra and allow smaller node runners experimentation with chains before they are able to build and service relays themselves. It will also allow chain_providers to utilize their idle-ish infrastructure and expand their backend availability for supplemental income.

Crypto is a fast paced moving entity, disregarding emerging technologies will not bode well.

POKTBlade edited his comment after I typed this, so I also agree with something along the lines of BenVans original proposal here: Incentivized decentralization - Idea - seeking discussion - #2 by Garandor

1 Like