@john-tri1lium
Thanks for your suggestions. First I thought I discuss them in the meeting. But then I started answering some (see below), and now I’m not so sure whether they are meeting material. But please get back to me (before the meeting) if I misunderstood you:
- Reward timeliness: boost for 80% fast-path, reduced if only 60%.
I don’t understand this. Who gets the reward? The leader? Everybody? In Alpenglow, in any slot, some validators finish on the 80% path, some others finish on the 2x60% path. Whatever is faster for them. Every validator is the only one who knows how they finished. So as a validator I just claim that I finished on the 80% path to get the higher reward? Or is this reward actually for the leader? Do we have an additional vote to figure out (democratically) how many finished on the 80% path and how many on the 2x60%? If I don’t like the leader, why would I not simply lie and claim that I finished on the 2x60% path?
- Late vote decay: linear down to zero after ~150 ms.
Who is measuring? The vote goes to everybody, so who is deciding this? Do we again vote on votes and take the median? Why would I not lie about the delay of others just to make sure that they don’t get a reward? Also, screw the validator in Australia who might not be able to vote as quickly as the others. In the paper we claim 150ms median delay. However, this is the median over all leaders, relays, and validators. 150ms is not achievable for a validator who is geographically disadvantaged. On earth, the maximum possible delay from any node to any other node is roughly 100ms, roundtrip 200ms. An incentive like this would kill our global blockchain immediately. Now 60% of stake is in (close to) Europe. After this 100% of the stake is going to be in FRA and AMS, perfectly located to have the EU regime kill Solana.
- Conflicting votes = full epoch reward forfeiture.
Okay, this one is actually rather slashing than rewards. We discussed this among ourselves months ago, and some Anza people even started writing tables of provable offenses and how they can be punished. This one was usually on the top of the list. So I’m totally okay with this. We probably will propose these slashing (or no rewards for you) proposals in a separate SIMD.
- ≥2 aggregators per window (primary + backup).
Maybe I don’t quite understand what this means. So far in Alpenglow we only have one leader per block, and that leader is decides what goes into the block. So the backup aggregator sends its aggregate to the leader, and the leader then does not include that (or steals all votes from it, and publishes themselves)? Or is the idea that we have aggregations for slot s in slots s+4, s+8, s+12, s+16 to make sure that every vote is accounted for? This would be close to a suggestion we once discussed among ourselves. In the end we decided it’s not worth it, because it adds 10x complexity for almost no real-world improvement. Simplicity is very dear to us. If we ever want to implement MCP, then we need to start out with the simplest possible protocol. Otherwise MCP is doomed to fail (and we are basically back to a very messy protocol … cough … TowerBFT … cough).
- Validators deliver votes to ≥2 upcoming aggregators.
What do you mean? Validators already deliver their votes to ALL validators.
- Aggregator rewards require ≥95% inclusion of timely votes.
So far, the aggregator/leader gets rewards for every vote they include. So they have a clear incentive to include as many votes as possible. You suggest instead that they only get a flat reward if they include 95%, and nothing if they don’t have 95%?! How is that any better than just incentivizing every single vote? Why would a byzantine (just 5% byzantine needed) not simply not send their vote just to let you lose your reward completely? We don’t want a protocol where 5% can mess with everybody, do we?
BTW (“story time”): We currently split the rewards 50/50 between leader and voters. You might think that we decided this ratio on a whim. But Max Resnick wrote a whole 6 page document just to compute the lowest possible split that is still incentive compatible with the leader. We discussed about this for a long time. In the end we went for 50/50, also because of simplicity. (Yes, I told this story because I can’t shake the feeling that some validators seem to believe that Alpenglow was written in two days and a lot of “let’s just do this” and “sounds about right.”)
- Validators must always cast notarize/skip; >5% missing = reward loss.
Is this the same as above? Or do you now argue that a validator will lose their rewards for the whole epoch if they didn’t vote for 95% of all slots? Who is counting? Do we again take the aggregates? If so, 5% bad stake is enough to mess with everything, i.e. 5% can make it happen that we have no rewards for anybody? Alpenglow has 20+20 security. With this we are essentially back to 2+2 security.
- On-chain metadata records per-slot vote arrival quintiles.
Sorry, but I don’t know what you mean here. We have all the votes (in the aggregates) on-chain, not just quintiles.
- Leader aggregate rewards fixed per slot, not dependent on who voted.
Okay, this is similar to above. I hope you agree that fixed thresholds are always worse. If you have binary thresholds, it’s an invitation for those that like to play games.
Please tell me if I misunderstood something. I appreciate a lot that you sent this to me before the meeting, because it’s a lot more difficult to address new proposals in a 100 people meeting.
Brace for a big autistic rant.
