PIP-31: Unleashing the potential of POKT

Proposals Improvements
21

Thanks for putting up an easy to understand example. Two thoughts:

  1. What about adding an additional constant that addresses under/over provision of chains? So: RTTM * RTTMM (ex. ‘2’ for archival) * CP (Chain Provision, for0028 it would be something like 0.3)

So you could automatically adjust rewards to both fairly compensate more computationally expensive work AND incentivize efficient chain provision?

  1. As a layman - Adding ‘AI’, in any capacity to Pocket has to be a good thing and a major marketing tool. If Pocket can in theory service LLMs and then do a press release that we now service AI, even if the true situation is more complicated, I think this helps with both retail + institutional investor interest and can be considered as a much a marketing expense as a building or tokenomics expense.
1 Like
22

Governance Transactions Formatting

With the new RTTMmap parameter, it’s not clear to me how transactions would be submitted to update the parameter value.

For example, the way that the SupportedBlockchains parameter is updated is as follows:

pocket gov change_param a83172b67b5ffbfcb8acb95acc0fd0466a9d4bc4 mainnet pocketcore/SupportedBlockchains “[“0001”,“0003”,“0004”,“0005”,“0006”,“0009”,“000A”,“000B”,“000C”,“000F”,“0010”,“0012”,“0021”,“0022”,“0024”,“0025”,“0026”,“0027”,“0028”,“0040”,“0044”,“0046”,“0047”,“0048”,“0049”,“0050”,“0051”,“0052”,“0053”,“0054”,“0056”,“0057”,“0058”,“0059”,“0060”,“0061”,“0063”,“0065”,“0066”,“0067”,“0068”,“0069”,“0070”,“0071”,“0072”,“0074”,“0075”,“0076”,“0077”,“0078”,“0079”,“0080”,“0081”,“03DF”]”

The new RTTMmap parameter should work similarly, in that PNF only has to submit one transaction in order to modify an array of values.

Could you indicate how such a governance transaction would be formatted for the RTTMmap?

Has your local devnet testing included submitting governance transactions to update the parameter?

ARR Considerations

The per-chain RelaysToTokensMultiplier (RTTM) significantly complicates emission control policies, like the currently active ARR.

ARR operates on the assumption that there is a single RTTM that generates a given mint for a given relay count. Since we know that the same multiplier was applied to all relays, we can make weekly adjustments that will average out to the target daily minting. See this spreadsheet to see this in action.

Introducing chain-specific multipliers means that we can no longer assume that every relay will be multiplied by the same value. We can’t predict how many relays each chain will process either, since it’s an emergent product of demand. Since each chain may have different multipliers, and we can’t predict relays-per-chain, this seems to break the existing methodology for emission controls.

I’m basing this analysis on this logic outlined in the proposal:

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.

ARR modifies the RTTM, not the RTTMmap, and since the RTTMmap overrides the RTTM if a value is set, ARR is no longer controlling emissions for those chains.

That said, this proposal does not suggest any parameter values for the new RTTMmap, so it will not break ARR until a PUP is approved to modify the multiplier for a specific chain. We could therefore think of this PIP as a decision to grant ourselves the option to activate this feature, rather than an implicit approval of any RTTMmap values, as msa alludes to:

This PIP can proceed without answering the ARR question if we’re considering it under this framing. However, any subsequent PUP to set a RTTMmap value should be coupled with a plan to adapt or replace ARR.

The proposal authors have suggested this could be addressed by increasing the GatewayFeePerRelay for specific chains in the same proportion. However, it should be noted that GatewayFeePerRelay is not yet offsetting today’s mint rate (i.e. burn ≠ mint), so scaling the burn in proportion is not a solution by itself. This would have to be part of a broader strategy to set mint = burn, which is not viable yet at current daily relay counts.

Implementation Details and Moving to a Vote

Before moving to a vote, the Implementation section should be filled out as follows, to follow the standard for previous protocol upgrades (note: I’m assuming we’ll adopt RC-0.11.0 as the version number for this potential upgrade):

  • 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 upgrade transaction.
  • 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 enable txs 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 RelaysToTokensMultiplierMap parameter, which means the global RelaysToTokensMultiplier will continue to apply to all chains until a subsequent PUP is approved modifying the new RelaysToTokensMultiplierMap parameter.
2 Likes
23

Thank you for your questions and comments!

Could you indicate how such a governance transaction would be formatted for the RTTMmap?

Here’s an example command to submit a tx.

$ export POKT=<path to pocket>
$ 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"
}

Has your local devnet testing included submitting governance transactions to update the parameter?

Yes, we conducted E2E testing on our devnet that includes:

  • 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

Before moving to a vote, the Implementation section should be filled out as follows, to follow the standard for previous protocol upgrades (note: I’m assuming we’ll adopt RC-0.11.0 as the version number for this potential upgrade):

We’ll update the post.

2 Likes
24

This was a helpful example, thanks. It seems easy enough to format and submit changes to multiple chains at once.

1 Like
25

This proposal is now available for voting at Snapshot

1 Like
26

In the future, I’d like to ask that proposals be labeled in factual terms, instead of subjective framing. The DAO voting page shouldn’t be used to frame the proposal itself IMO.

image
image1792×1143 231 KB

3 Likes
27

This current proposal feels like déjà vu – as if we’ve seen this movie before, Stake Weighting 2.0.

I might be a bit late to the party, but I believe this was a golden opportunity to make necessary changes for GANDALF. I fully support the idea of having higher RTTM for different chain IDs and regions, something I’ve always advocated for. However, I can only see two viable ways to implement this while preventing abuse. Definitely not in the current protocol’s form.

  1. Independent staking for each chain ID.
    or
  2. One staked Pocket node for one Chain.

I don’t believe the DAO should vote on a feature without first assessing its potential impact on the network. This statement appears counterintuitive. I see the potential here for a provider, like c0d3r or any other, to run archival nodes and stake only trace/archival nodes to maximize rewards. Indies won’t run archival nodes due to resource constraints.

1 Like
28

This is a very valid and interesting point.

The biggest challenge against moving to one staked POKT node for each chain pre the Shannon upgrade is the high coordination costs involved. It would be great to get more input from the various node runner groups about how willing they would be to implement such a change.

2 Likes
29

I will note that the migration challenge and high coordination costs will exists regardless of if happens pre-Shannon or at the Shannon upgrade. Waiting for Shannon is putting more coordination cost on the upgrade.

The benefits of doing it pre-Shannon, which was laid out in GANDALF, is it can be done in a progressive way, dropping the MaxChains in steps (say start with 5, then 3, then 1). If you wait till Shannon, then it will be an immediate transition (from 15 to 1)… on top of all the other transitions that Shannon is already bringing.

I also believe that balancing the network now has it’s merits, which I laid in GANDALF, but won’t get into on this thread. Just wanted to point out pre-Shannon allows progressive changes, possibly reducing coordination cost, instead of stacking all network changes on Shannon.

3 Likes
30

I would like to remind everyone that solving any of the problems of original stake weighting or supposed network imbalance problems or any of what Gandalf wants to achieve are NOT goals of this proposal. We did mention briefly that there might be benefits for Gandalf, which I believe is true, but honestly, we regret even mentioning it, because it seems like it derailed the conversation.

The goals of this proposal are:

  • For RTTM: The goal is enabling equal pay for equal work. And the main motivator is enabling scenarios that won’t be otherwise available until v1/Shannon ships. Biggest example is allowing LLM (see here for an example that is currently running end to end on Pocket Testnet) and other generative AI end points to be served. This will help us get to ready for what the future can offer.
    • Ask yourself if you want to enable Pocket Network for offering anything more complex (e.g. LLMs) than what it can do now. Ask yourself if you want to have a chance to participate in AI ecosystem.
    • This proposal brings new capabilities but doesn’t change anything by itself. Any further parameter changes will require DAO action. So, if you like the direction but worried about the exact implementation, don’t.
  • For Built-in Rewards Share: Enabling a wider set of non-custodial node running scenarios.
    • Ask yourself if you want to make the network more secure (by allowing more non-custodial nodes), more transparent (rewards rates being in the chain) and more efficient (no more reward sweep needed).
5 Likes
31

The two parameter changes have vastly different implications should be separated, not lumped into one vote, full stop.

3 Likes
32

Is this some kind of closed source service to be launched on POKT? Folks have asked for more technical details, and no answer has been given. Why should we change the protocol to make it possible to release closed services? This is all so confusing.

I already laid out here, how these kind of LLMs can’t be launched without a fully dynamic GatewayFeePerRelay. You said :point_down:

… but now it is up to vote without including any changes. Why wasn’t it added to this proposal? Again, this is all very confusing, because as it now stands, your LLM service would take a huge portion of everyone else’ rewards. I appreciate that you acknowledged the issue, but that doesn’t change the fact of where this is currently heading with this proposal with no plan to address the very serious oversight.

3 Likes
33

TLDR: I’m going to vote no, but (sadly) for thing not related to what this will bring to the ecosystem.

I’ve been thinking in this proposal and even though I like it, it seems that we need to properly discuss some points in it before accepting it.

Feature 2: Built-in Reward Share feature

I think that this was not discussed properly. Maybe none has an issue with it or @ethen 's GANDALF took over the the thread. Either way, I think that this deserves its own voting and discussion thread to be sure. I agree with @iannn here.

Feature 1: Per-chain Relays To Token Multiplier

I like this because it enables Pocket to do something new and also to properly reward more costly requests, such as archival requests. However much is left to discuss. The focus that the authors give around LLMs seems to be weak, as its implementation does not seem so straight forward. The real initial implementation of this feature would be for archival chains (or heavy chains in general). I’m starting to lean towards @Breezytm and others in the community in this aspect. We have the code ready (we appreciate it), maybe we should establish what chains are going to have a different multiplier, why and how that will affect minting (this last part is relatively easy, just project to base relay counts, as we do for PIP22). Once this is settled we can go ahead and merge the PR and implement it.

The Morse (V0) consensus break

Until the recent announcements of moving towards Celestia, I was thinking that keeping status-quo until Shannon (V1) was the best way to do it. This meant that things like GANDALF would only create a distraction to the Shannon development. In today’s builders call I asked if everything in the Shannon utility layer was going to be included in Q1 2024 release, and they (PNF) told that they will publish a new roadmap soon, but it was not guarantied that all the utility layer will be there for the update. This make me change my mind, as the “clean cut” that I was expecting is not going to happen.
So, given that GANDALF entered this thread, and that it also requires a consensus break for being implemented, I’m thinking that we should do it all at the same time. This means, discuss the three subjects:

  • Per chain rewards: Decide which and how this will happen. Do not talk about GANDALF, the per-chain price has to do with hardware costs not minting strategies or network balancing.
  • Rev-share changes: Discuss and explicitly agree on this single topic.
  • Discuss GANDALF, code the checking for maximum staked chains (not really hard IIRC).

Once that we agreed (and voted) on all this, we can update the mainnet and try to steal the less time that we can from the Shannon team.

4 Likes
34

Is this some kind of closed source service to be launched on POKT?

This is not closed source service. It is using Llama v2, which is open source Llama 2 - Meta AI. If allowlisted as a chain, anyone could offer it. Our link is a proof of concept and simply shows that it is possible to do it over pocket, and how the very basic experience would look like. It is easy to think that it takes ChatGPT and endless resources of Microsoft etc. to achieve such cool tricks. No. Pocket can, too, if this proposal passes.

A fully dynamic GatewayFeePerRelay.

We decided against it because

  • a fully on-chain burn mechanism is way beyond the scope of this proposal, it is a feature all by itself, a large one at that.
  • and you also thought yourself that it wasn’t necessary by saying: “GatewayFeePerRelay is currently off-chain, and was universally set by ARR. It may not need to be on-chain, but it would need to be in ARR (with a method/system to adjust) or in an ARR replacement.”
1 Like
35

Just because it is off chain, that doesn’t mean it can be ignored. You are mistaken on the meaning of my comment. IMO, dynamic relay cost needs to be addressed prior to this proposal, so we know how this new lever will operate in a ARR world. Ignoring the economic changes needed is put the cart before the horse IMO.

1 Like
36

Thank for sharing your thoughts. I have one comment.

The focus that the authors give around LLMs seems to be weak, as its implementation does not seem so straight forward.

Implementation IS truly straightforward. What we would need is:

  • Allowlist a LLM chain and set some reasonable RTTM so running it is economically feasible. Offset that with larger burns on that chain with zero impact on ARR.
  • Node runners who wants to participate use open-source Llama v2 from Meta Llama 2 - Meta AI. It is free for commercial use.

This is really all there is to it. We can publish a doc explaining Llama setup, but I doubt it would be needed.

Imagine: A few weeks from now, Pocket could be the world’s first serious decentralized LLM provider.

1 Like
37

I really like a lot of these ideas and I’ve learned of some new stuff. I am not sure where to go with this proposal though because if nothing is done the market will sort it out. If it’s too costly to run chains then don’t run them and instead go out and seek them. The real issue I think is ARR and we should be working on ways to fix that price per relay for higher yield APR to make it more attractive to stake POKT. Some have proposed solutions that can be complicated to implement, like what I’m reading here, needing consensus changes and lots of dev work having to wait when we can simply scale back some of the inflationary tokenemics that caused people to unstake and sell. Seems so simple to me and can practically be done now.

In addressing that ARR or (price per relays to continually decrease in a forever spiral as we get more relay traffic load over time) will also reduce the amount of sell offs because nothing has been addressed to resolve that which causes a lot of resistance when we do actually get new investors and the amount of relays has not gone up high enough making it continuously losing value unless we get a lot of investment. A higher yield APR would could resolve a lot of resistance which would then help the issue with the cost of chains bring the price back up to where it belongs. It is the more simpler thing to do and would not only make some noise but help fix all these issues with cost.

I am just saying this could be a simpler way to achieve the goal of reducing the out of pocket cost to maintain infrastructure and revive POKT at the same time and it can practically be done now without too much wait if we all agreed to do it. Look forward to the automated reward sharing and other new features. Thanks for the great work.

1 Like
38

I agree that implementation of the RPC part is really easy, that’s not the problem… The problem is QoS, chains and pricing.

  • How do you know if you have a fp16 or an int2.3 LLama-2 on the other side? they are both the same model but they will provide different answers to the exact same queries (even at temperature=0).
  • Setting up a single chain for each flavor of llama-2 model (7-14-70 B parameters) and other Llama-2 based models is insane. And this is not all the granularity that we will observe (a chain for quantization level and method? :exploding_head: ).
  • Pricing IA RPC workloads on a RPC count basis is not correct, as the request difficulty can vary wildly (just think in prices per token for chatGPT).

Believe me, I love this:

In @Adrienne 's words:

Pokt is your API to the open web

But the subject of IA RPCs is not correctly addressed here and that’s why I considered it a weak justification for this proposal.

1 Like
39

Thanks for your thoughts! Just one comment:

I am not sure where to go with this proposal though because if nothing is done the market will sort it out. If it’s too costly to run chains then don’t run them and instead go out and seek them.

Pure cost of running each LLM query is 100x to 1000x more than blockchain relays (their value on the demand side is also 100x to 1000x more). Without a proper rewards multiplier, it is simply not feasible to run them. “Then don’t run them” would cause Pocket to miss the opportunity of being one of the leaders in the AI ecosystem. Pocket can be the first decentralized AI provider. LLM is the next generation API, and it is very versatile. It can be used to summarize text, proofread docs, annotate song lyrics, polish up corporate letters… sooo many uses. Instead of trying to sell blockchain relays (we are at lowest relay points in last 6 months), we would bring a new variety, a new energy.

This proposal doesn’t change any parameters whatsoever. It just lays the groundwork for allowing node runners of all backgrounds to run cutting edge AI solutions feasibly. With a path forward, node runners can start experimenting in the testnet. Actual mainnet number changes, if at all, will happen with another vote in the future.

4 Likes