regarding block time target of 6s, i’m familiar with how the “blocks per year” are part of the token emissions rate calculation in the Cosmos SDK, but my understanding is that Namada’s emissions rates depend upon epochs. i’ve chatted with the engineering team, and my understanding is that we shouldn’t see variance in emissions unless we have variance in epoch times
we chatted about the 10k NAM minimum in the June 27 Namada Validator Circle and discussed lowering it. why do you think many validators won’t have at least 10k NAM in total staked (including delegations)?
all “inflation” parameters, including PGF, are based on the total supply. regarding the steward role, i agree! we should define our expectations for the role, as well as vision, since currently there’s currently only the on-chain mechanism. i’d be up for starting a forum topic about that
regarding the shielded set, i agree; we should begin a dedicated discussion about goals and asset targets to bootstrap data protection
imo the goal is to be useful, ie. provide data protection for assets in ways that people find useful, and the objectives are to a) identify which assets will be useful to shield and b) get enough deposits & deposit size of each of these assets to provide the strength of data protection needed by those who use them
Let’s kick off discussions on asset designation now so we’re ready when rewards activate. Getting stakeholders involved early means we can gather a range of inputs and put together a solid plan.
@OVDuck Just wanted to answer your question about slashing types.
Essentially, a duplicate vote occurs when a validator signs a block more than once, while a light client attack involves signing an invalid block. These terms and evidences for misbehavior actually come from CometBFT. You can read more details in the CometBFT documentation here: CometBFT Documentation - Evidence - v0.38.
I’ll add some details on these slashing types to the Namada docs, which are actively being upgraded, soon.
Namada protects user information through its shield mechanism, which offers several benefits:
-By shielding transactions, Namada ensures that user data remains confidential and secure from unauthorized access.
-Shielded information is less vulnerable to attacks, reducing the risk of data breaches and theft.
-Robust privacy and security measures build trust among users, encouraging broader adoption and engagement with the platform.
I know many people have been wondering,
If Namada can do all this above and more, how are you planing to deal or handle the hackers and money launderers in the space?
Security is the main thing that need to take more serious and that can be done by reducing the validators.
In this case, the staking rewards/inflation will be 5% maximum but the PGF inflation could be 10%. If we look at the Cosmos Hub for example, the inflation to the community pool used to be 2% of the total staking inflation and then it was raised to 10% of the total staking inflation. Using an example, if there is 100 token/year from inflation, 10 of these would go to community pool and 90 to stakers/validators. In the case of Namada, it seems it would be 100 for stakers/validators and 200 for PGF funding? This would mean in the Cosmos hub the inflation to the community pool is 10% of the staking inflation, while in Namada it would be 2x more inflation for PGF than stakers/validators rewards, and 20x more funding for PGF than the Cosmos hub community pool? Is this correct? If yes, I would suggest more rewards for validators/stakers initially to get high staking ratio, and less PGF funding. We already see in other projects that community pools have a lot of funds accumulated and it is difficult to manage those funds or find where to invest so much
Eventually maybe, but initially we see when new networks launch the minimum to join the active set even with 50-100 spots is near 0, maybe 1 or 2 tokens, so for Namada the same is expected. Meaning that it could be a long time until all 255 have at least 10k NAM, unless we see many sybils creating many 10k validators
The thing that stands out for me in the proposal is the ratio between various inflation types. It is outlined as 5.5% → 11% for PGF (the funding itself + the stewardship), 5% max for staking and TBD for shielded pool rewards, with the example pointing out a 0.4% inflation dedicated to two assets. PGF will take up a large share of the emissions in this scenario.
While I agree with the positive effect that the PGF program should have on Namada (a unique feature and a testament to the project’s ideals, a channel for community and strategic partnership building etc.), I believe that we should focus on incentivising shielded pools while keeping the total inflation rate reasonable. The shielded pool is Namada’s core feature, and we have to make sure it is bootstrapped properly, especially given the chicken-and-egg problem you’ve mentioned and that “privacy loves company”. It seems like large PGF allocations can wait a bit compared to the need to ensure the success of the protocol’s key value proposition. Besides, a successful take off of the shielded pool benefits PGF long-term, as it should ensure a higher appreciation of NAM => better PGF opportunities in the long run.
To sum up, I suggest the PGF inflation is reduced to make more room for shielded pool incentives while keeping the same total emission rate.
Other parameters make sense to me. I believe 255 slots in the validator set should have a positive impact on the ecosystem. While this measure itself will not affect decentralisation in a significant way, it will decrease the chances of a passionate, contributing validator being pushed out of the set and losing a link with the project.
Another thought on shielded pool rewards - I believe Namada should not limit the incentives to Cosmos-native tokens, such as ATOM and OSMO. The protocol is being built as asset-agnostic and (further along the road) multi-chain, so I’d love to see incentives for widely adopted stablecoins (e.g. USDC), wrapped versions of ETH/BTC etc. The aforementioned idea of integrating LSTs also has a lot of merit.
Thanks for proposal, i think if we have 250 slots we need make the best information channel for emergency updates,
and 0% inflation at first block is not motivating validators to join to the network at Start
But if Anoma give additional stake to first validators thats sounds good
@Gavin thanks for taking the time to put this up for conversation. I think everything looks generally great!
I would echo concerns about 255 validators, and recommend a smaller number due to experience. It’s mostly due to coordination efforts for upgrades, votes, quality of peers, etc. The reality of validating is that it’s not extremely profitable all the way down the set, and when there’s little incentive to participate people don’t. Some that do use very unreliable hardware. This causes issues. More open testnets have been a nightmare simply due to bad peers. I would also suggest something like 150 which is still a huge set size in comparison to most cosmos sdk built chains. Though it I mentioned that 255 is only the CAP.
PGF funding seems way high at 10% in Phase 5, but without knowing more about what actual contributions will be made I can’t comment knowledgeably. To be honest the whole steward thing and the chain being more decentralized scares me when thinking about longer term vision/success. Decentralization is great, but lack of coordination/accountability has been seen in instances and other communities where experiments like this have been attempted. Will just have to evaluate over time and as things get moving!
Isnt that the goal of a decentralized network? To learn to coordinate effortlessly (big brackets - with scalability in mind?) =)
Humor aside. I honestly think that if there is (near) 0 technical risk, then the fear of coordination should not be the reason not to proceed, but should be the motivation to try =)
After some concerns and a bit of Validator Circle discussion, I’ve updated our proposed validator_stake_threshold parameter such that it would take at least 1000 NAM (instead of 10k NAM) in delegations to qualify for the active set.
After our testnets have struggled to handle large blocks, I also noted that there’s a “mempool size” node setting recommendation that we should consider.
Hi, I noticed that there might be some confusion regarding what the block_proposer_reward and the block_vote_reward, understandably, and wanted to provide some information on what these are.
The parameters dictate the distribution of proof-of-stake block rewards to validators for proposing blocks, signing blocks (voting in consensus), and for simply being in the consensus set. The details are described in the specs here.
In the link above, the block_proposer_reward is r_p, and the block_vote_reward is r_v. With the proposed values of r_p = 0.125 and r_v = 0.1, we can describe how the staking rewards for a given block will get distributed:
Between 1% and 5.1% will be given to the block proposer. As of now, the lower bound of 1% is hard-coded, but we could make it a parameter that governance can set in the future.
10% will be distributed among all validators who signed the block, weighted linearly by relative signing stake
The remaining rewards are distributed among all validators in the consensus set, weighted linearly by relative consensus stake.
A block proposer is incentivized with higher rewards to include more validator signatures/voting power in the block over the necessary 2/3. The fraction of the signing stake to the total consensus stake determines what the exact proposer rewards is.
Consider an example where validator A has 20% of the network stake, and a block is made in which 80% of the network stake, including validator A, signs the block.
if A proposed the block, they would get 2.67% for doing so
for signing, A will get 0.1*(20/80) = 2.5% for doing so
for being in the consensus set, A will get 0.8733*(20/100) = 17.47%
So at minimum, validator A will get 17.47% of the block rewards. If they sign the block, they get an extra 2.5%. If they also propose the block, they will get an additional 2.67% on top of that.
I want to leave a couple remarks about inflation parameters.
Shielded set rewards
For shielded set rewards, I think @Gavin’s example involving a 0.2% inflation rate for ATOM and OSMO locked shielded tokens accidentally gave the impression that this is around the rate that the Namada team thinks the inflation should be. At one point we did also discuss the possibility of trying to ensure that shielded set rewards in total (for all incentivized shielded assets) be larger than the inflation for Proof-of-Stake and PGF. As a member of the community and interested user of Namada, this would be my personal preference and something I think we should aim to do through governance. In this case, I imagine something like 7-8% total inflation over all incentivized tokens. For example, if we offer rewards for shielding ATOM and OSMO only, then maybe 3-4% inflation for each of them.
I would like to encourage everyone here to participate in further conversations on shielded set rewards in this dedicated thread.
PGF inflation
I’ve also noticed some comments regarding the final 10% inflation for PGF that @Gavin mentioned being high. As a member of the community, I think it is less important to discuss this number now and more important to discuss what the initial non-zero PGF inflation will be. It is suggested that 5% be this initial number, and I think that works.
But beyond the possible initial 5% inflation (which would be enacted in transitioning to Phase 2), I think it is more important to gauge how well the PGF tokens are being allocated in the first several months of mainnet and then determine if the inflation rate should be changed rather than make some kind of a priori commitment to some next number. If there are lots of public goods that the community wants to fund and it feels that there is not enough inflation to go around, then it might be nice to increase the inflation. On the flipside, if for some reason that funds were not being allocated efficiently and tokens are just sitting in the PGF account, then maybe it could be wise to do nothing or even decrease the inflation.
Correct! The shielded set rewards max inflation parameter values that I provided were (confusingly) just examples, not actually meant to be proposed. I don’t have a well-formed opinion about these values–I suspect that it will take some experimentation to find what works, but it would be great to model some different scenarios with different parameter values: Preparing to kick off shielded set rewards - #4 by Gavin
PGF inflation
gauge how well the PGF tokens are being allocated in the first several months of mainnet and then determine if the inflation rate should be changed rather than make some kind of a priori commitment to some next number
The idea of proposing a plan to escalate to 10% now is so that we have some alignment in signalling that our goal is to allocate a relatively strong backing to reward contributors with meaningful Namada network ownership, and thus there should be a bit more onus to justify deciding against raising from 5% to 10% when the time comes.
If there’s a good reason to agree that tokens aren’t being allocated according to expectations, or that there isn’t a need for additional allocation, personally I think that either should be enough justification for changing the plan (and also to consider decreasing below 5%).