I don’t like this reliance on assumptions about honesty. We’ve clearly seen that validators are incentive-driven, including modified voting behaviours and malicious behaviours.
I would much prefer that if we change the consensus system this sort of incentive (to vote properly) is baked in. Perhaps some threshold of skips is allowable, or skips earn lower credits always, this also penalized validators who have below average block production in general.
We’ve seen regularly in the past that validators will trend to behaviour that maximizes their rewards, regardless of honesty or ethics. If we’re completely revamping consensus it is critical that we get the incentives right from the start, this should include some sort of incentive for timely voting to ensure quick finality as well as an incentive for best-effort honest voting
I agree. I think that it is imperative that vote credits be rewarded only for votes which agree with supermajority. And once this is implemented, a timely vote credits like mechanism then becomes necessary to prevent validators from delaying vote in order to more frequently vote with supermajority. So votes should also receive credits based on the slot in which they are cast; although how this will be calculated when votes are not on-chain is an issue that will require some significant design work.
You guys had too much “TowerBFT cool-aid” (if that ever existed). Let me try to explain again: Why would you be dishonest if you can gain nothing? You can also not harm anybody by sending a skip, unless an absolute majority of stake is dishonest. If the majority of stake is dishonest, we have much bigger problems, and no blockchain protocol can work. In Alpenglow, your most profitable course of action is to simply be honest.
In contrast, in TowerBFT we have a problem because it pays to be dishonest! In TowerBFT you don’t want to vote for a block that sits on the wrong side of a fork, so you wait and strategize to see which branch of a fork is going to win. And because of this, Solana had to introduce the crutch of “timely vote credits” so that you cannot strategize “too long”. You can of course still strategize, just not very long. Timely vote credits is not without problems because it potentially disadvantages validators which reside in the wrong part of the world. So we need another crutch to fix that problem (well, luckily Alpenglow is coming, so we don’t have to go there).
In Alpenglow, being honest is a Nash equilibrium. Voting wrongly might happen naturally, as you (maybe as the only validator) didn’t get a block in time because you were really unlucky with dropped packets. We certainly don’t want to go back to the world where you would want to lie and strategize whether others might have gotten the block and hence you still wait with voting until you see what others are voting and then we have to introduce timely vote credits again.
Sorry for the rant. Believe me, your intuition is misleading here. There is a long history in game theory that assumes that you will not deviate from the standard answer if you cannot gain anything from deviating. And this is what we are building on.
(But, as said earlier: if we ever find that validators start lying, we will be very quick to fix it – we know how to fix it, but it will have overhead, and essentially will be worse for everybody than just assuming the 20+20 model for now.)
We removed that before starting the discussion. We try to simplify as much as possible, and after some discussion we felt that this is not worth it for anybody.
This is not changing the economics in a way that is meaningful…you already have an intrinsic cap on max validator (and if you set it to be > than current number of active validator you are not doing much) and 1 SOL is already burn. Further, the question was
so probably you meant something different when saying “preserve as much as possible”
Let me try to understand, Umberto. Are you going to vote “no” because of 0.3 SOL per day knowing that we will discuss VAT economics again once the basic Alpenglow SIMD is approved?
Maybe, let me clarify. Here I’m talking on behalf of myself, as Solana community member. I want to share my ideas and if something doesn’t resonate with me, I express that.
Chorus One is going to vote yes because it’s the right thing to do.
Thanks for the answer/rant, and it’s a fair response, but on the argument that there is nothing to gain from dishonesty, the counterpoint is that there is nothing to gain from honesty. The use case for dishonesty here might be much simpler and bland than might appear at first glance. We’ve previously speculated and been somewhat sure that we have observed instances of standalone “voters” that simply mimick a high performing node and copy their votes, where this may have been more profitable than trying to evaluate fork choices and vote yourself, or to offload the compute and have a heavily modded block producing validator that is separate from the voting logic.
My point is that there are combinations of motivation and use cases that may still make dishonest voting the best option for a validator’s particular flavour of optimization. Of course the risk that over 40% of validators do this is low, but then again we do also know that there are large gorups of sybils thart are ostensibly run by a single cabal (or multiple groups run by multiple cabals) that run modified code and act in unison, we know from the SIMD-228 vote as well that at least one of these groups ostensibly controls as much as 10% of total stake.
Perhaps despite all this the risk is, justifiably, insignificant, I’m not sure how to quantify it, but I do think it’s worth debating and trying to quantify and disprove this possibility.
I agree, the debate is a good one, and you and @zantetsu are not the first to raise this exact point.
The mimicking in TowerBFT you describe is very plausible because you do gain something from not behaving correctly. If anything, this totally proves my point!
Maybe I underestimate what length validators will go to change the code for absolutely no gain, but rest assured: if anyone ever does it, we will suggest and implement a punishing mechanism right away. Until then I trust 75 years of game theory.
BTW: It is not really easy to come up with a rule/punishment that cannot be abused. In particular we cannot say that we only reward those voting with the majority because with that it absolutely makes sense to delay your vote, and then we are back with patches on top of patches.
Unfortunately, I think you have little insight into or experience with real world behavior of validators on a proof of stake network. Your voting rewards mechanism will be gamed and it will drive stake towards dishonest actors. TowerBFT set out to create an incentive system that rewards validators for participating in the network, but it was imperfect, as you have noted. Its imperfections were later corrected, which you noted. Your “solution” is to say that incentives were never needed to begin with. This is fantastically naive.
If you believe that “honest participants” will always act in the way that is most beneficial to the network, then why have voting based incentives at all? You are already arguing that validators don’t need incentive because “80% will always do the right thing”. In that case, no extra incentives are needed. Just simplify your rewards scheme and pay out inflationary rewards according to stake, regardless of performance. You could vastly simplify your rewards mechanism this way. And since your most basic premise is “80% will always do what I think is right (even if it’s not rewarded by protocol)”, then you must agree that this will work fine.
Another issue you fail to consider is that there is a difference between being honest and being hard-working. The advantage to being dishonest in Alpenglow is in saving system resources; don’t bother validating if nobody requires it, because it’s extra work. The flip side of this is not bothering to dedicate better resources to performing better because performing better has no clear value in Alpenglow. We used to have tons of validators (and about 1/3 of stake) running really slowly because the protocol did not reward them for running faster. They voted after 2 or 3 slots had already passed because their systems could barely keep up, but they didn’t care, because they still got full credits. The same thing will happen with Alpenglow. If you don’t mind validators voting late and slowing consensus down, then by all means, don’t have performance based incentives.
Also I find it kind of amazing that you are being given real-world experience based feedback from validators who have been working on Solana for years, and you are shitting on it; preferring to say “if there’s a problem we’ll address it later”. Hey – experience shows you will have a problem and you can address it now rather than waiting until it has caused problems that you have to deal with later. Why would you not want to address the issue now instead of waiting until later?
Voting spam prevention. Since fees aren’t directly tied to votes anymore, this doesn’t matter anymore
Validator set size gating. Somewhat informally, voting fees made it tougher for the validator set to balloon in size and also made it more expensive for riff raff to run validators on chain. Since the validator set will have a fixed limit of 2k (?) this is less of an issue though since there’s actually a bound to the validator set.
Given that the two concerns that voting fees addressed are basically non-existent anymore, there doesn’t seem to be much of a point of having a fee anymore, though to some extent it could help keep riff raff off from running a validator – though they would probably have very little stake anyway.
Also, as a side note, what would make a lot more sense would be for validators to have a stakeweighted bond of some sort to participate in an epoch, then have that bond value decremented severely if they have outlier levels of poor performance (see why “Loss Aversion” is better for motivating behavior Loss aversion - Wikipedia ). Marinade stakepool does something like this with their PSR bonds Protected Staking Rewards | Marinade Documentation
The fee is there to not be overrun by free-loading validators. The 2k limit is only there as a last resort. We don’t want to actually reach it. Reaching it would bring many other problems, e.g., you would have validators which constantly fall in and out of the 2k set. I’m sure they wouldn’t be happy about not being included every second epoch, also it is also not good for the health of the system.
Your poor performance = loss proposal is well intended but we might see problems very soon. For instance, validators which are sitting in more remote areas of the world (Oceania, South America, Africa, to some extent also East Asia, etc.) might naturally perform poorer than those sitting in the center of the current action. If you start to punish those with “poorer performance” you actively push for centralization. Just always punish the 10% worst, and over time all validators sit in the same data center, and Solana goes down as soon as that data center has issues.
Having a decentralized system is paramount for the security of the system. And a decentralized system must be geographically decentralized as well. I would rather just have 10 validators highly decentralized than 10,000 validators on the same continent.
I think this is exactly what @zantetsu meant: there might be incentives in voting skip. As you mention @Roger there is the possibility that some validators may poorly perform, and this is related to voting. Since rewards are based on vote being casted, I can implement an “only skip mod” mechanism and I don’t even need to wait for the block. Is that a fair interpretation?
However, I think that this is something may have sense only once we’ll implement single slot finality (if time to finality << block time). The proposal is targeting finality in 8 slots (if I understand correctly), and I think this is why Roger said that there are no incentives in voting skip - since you have 8 slots to vote (~3s). Is that right?
On a side note, @Roger what is the fallback mechanism if leader of slot s+8 is offline? I was reading again the SIMD and it doesn’t seem to be mentioned.
Yes, if the leader is offline, we won’t have rewards for that slot.
Your general comment: Yes, I understand well what @zantetsu is saying. It’s not that complicated. The truth is that every blockchain we have today needs voluntary participation. While in principle (“academically”) it may be possible to build a blockchain where every blip is accounted and rewarded for, the network and computation overhead would be absolutely bonkers (when discussing this we called it “crypto delirium” for a reason). So it’s a trade-off between performance and protection against selfishness. Compared to some other nefarious behavior we could have today, wrong skip votes are not a problem. Voting behavior is completely public (in the aggregates). It’s a bit like Will Smith slapping Chris Rock at the Oscars: Visible for everybody, no benefit for the perp.
@Roger among my other feedback, which I hope doesn’t get lost here, I’d suggest forming a validator advisory committee. There are many of us who have been here since before the beginning or close enough to it to have gained very valuable, practical experience.
One thing at least I’ve learned having operated on PoS networks for nearly 8 years is that the gap between theory and practice can be quite significant and if that gap presents a perceived advantage, will be exploited. It seems to me that merging this real-world experience with theoretical research can only help Alpenglow succeed in the long run and as such, should be embraced.
@Roger emphasizing what Zantetsu states here and many, if not most operators of validators on PoS networks can attest to, relying on altruistic behavior once real money is at stake is a losing proposition.
