Hmm I’m a bit confused. In the discussion yesterday and in the whitepaper it was mentioned that voting could be done once a block is fully received and “checked” rather than fully executed. Is the voting on the blockhash or the bankhash?
There would not be an on-chain cost, but participation is definitely not free; hardware and bandwidth-wise, Solana is the most expensive chain we operate at Chorus One. Access to good hardware in a good location is a significant barrier to entry. Hopefully Alpenglow will relax those requirements a bit, but more likely, the freed-up capacity would instead go to processing more transactions per second.
Yes, “lazy” execution could be done, but it’s currently not done. Alpenglow is in principle compatible with both, but if you execute lazily, then extra steps need to be taken. Also long as we execute eagerly, we can vote on blockhash, bankhash, or even both.
1 Like
That’s a good thing, right? 
Critical point here:
“we can vote on blockhash, bankhash, or even both.”
Votes should continue to include the bankhash to form a consensus of the correct account state. When the vote certificates, inclusive of the bankhash, land on chain, they should be included within the blockhash. This means that when reconstructing point-in-time state from a snapshot (or dealing with a restart?), a blockhash can be used to verify votes, and the bankhash from the votes can be used to verify the account state.
TODO: Illustrate a chain restart procedure under Alpenglow
FWIW, I’m generally comfortable with the voting incentives. The simplified “1 vote = 1 vote” + all-to-all delivery removes the incentive for some poor behavior. Those of us running validator dashboards will need to reconsider the metrics we show. For example, vote latency precision may be less important.
I’m with you here. Assuming the votes include the bankhash, votes can only be cast after the validator calculates the latest bankhash.
1 Like
Yes, some metrics will need a new flavor. In particular everything that was measuring delays in slot (or block) times does not make much sense anymore, since Alpenglow’s delays are sub-slot.
Back about possible abuse: the main risk for me is to make the creation of Sibyls still a bit easier than now. From a cheap VPS, you copy the votes of a nearby validator (simpler with AlpenGlow since the votes are broadcasted directly to all other validators, no TVC, no lockout risk), and possibly delegate block creation to your master validator. If this allow you to gather some stakes from stake pools, you will soon cover the VAT cost.
Is there an opportunity with AppleGlow to disincentive that ?
As epoch 839 has now begun the stake weights have been captured and published here for verification: solgov-distributor/votes/simd0326 at master · laine-sa/solgov-distributor · GitHub
The simd326-proposal.csv captures each validator’s identity and the number of tokens they would receive which correlatest to the number of lamports of active stake.
If using the check_stake_weights script the github notes expected discrepancies due to a bug in jq relating to Helius, Binance and Kiln of 1 lamport, the CSV file that will be used to mint the token has the correct number. Another discrepancy relates to a validators with two vote accounts, again the CSV file has the correct value.
Should any other discrepancies be noted please share here or on Discord. Stake weights can only be verified during epoch 839. The voting token will be minted at the start of epoch 840 and claimable via the CLI as with previous votes.
We discussed this issue, which is somewhat outside/adjacent to consensus. Let’s say that the bankhash is included in the block footer, and then voting is only on the blockhash. We can change this in the future when (if) we go for lazy execution.
We could have something like TVC. TVC is not impossible in Alpenglow.
However, the benefit of copying someone else’s vote escapes me. You still have to sign the vote and send it out. Why not just gather (the additional) stake at your master validator instead? You also save the additional VAT that way.
To collect more total stakes from stake pools. This is common today. But you can argue that this is a problem with delegation strategies that should be sibyl-proof.
Yea, I would argue exactly that. 
Also if we re-introduce some form of TVC so that validators are incentivized to validate better, copying the best performer votes may be beneficial. To prevent this we can split the vote message in 2 parts: one broadcasted so that the block can be finalized ASAP, and one only sent to S+8 leader and containing the bankhash if voting for, or the precise reason of the skip, if voting against.
I’ve been able to -
1 - Generate a new merkle tree with the same sha256sum 9849052712c231da2f2e82b34f50b493b7cefb460d6bc0b1843894c1a5650f8f as published here solgov-distributor/votes/simd0326 at master · laine-sa/solgov-distributor · GitHub
(Note: This time I had to use the cli from the solgov-distributor repo. I believe in the past I was able to use the cli from the original Jito repo.)
2 - Run the diff using check_stake_weights.sh. The results are generally consistent with the explanations for the differences mentioned in the repo.
ERROR: Stake weights do not match; diff follows
185c185
< 5pPRHniefFjkiaArbGX3Y8NUysJmQ9tMZg3FrFGwHzSm,9021922795828987
---
> 5pPRHniefFjkiaArbGX3Y8NUysJmQ9tMZg3FrFGwHzSm,9021922795828988
628c628
< DRpbCBMxVnDK7maPM5tGv6MvB3v1sRMC86PZ8okm21hy,13131645166110409
---
> DRpbCBMxVnDK7maPM5tGv6MvB3v1sRMC86PZ8okm21hy,13131645166110408
733a734
> FttTBmXi5tmGJtiRcbVLwfMnY3ngrxw8DNSWRWMrr1WS,0
815c816
< HEL1USMZKAL2odpNBj2oCjffnFGaYwmbGmyewGv1e2TU,12471016241459883
---
> HEL1USMZKAL2odpNBj2oCjffnFGaYwmbGmyewGv1e2TU,12471016241459884
867c868
< JupRhwjrF5fAcs6dFhLH59r3TJFvbcyLP2NRM8UGH9H,6439863211056214
---
> JupmVLmA8RoyTUbTMMuTtoPWHEiNQobxgTeGTrPNkzT,6439863211056214
874a876
> kyzzzgRymGpePUsLyr48kQHt53kh5CSfRH1qfvz1xgj,0
947a950
> prt1st4RSxAt32ams4zsXCe1kavzmKeoR7eh1sdYRXW,0
1031a1035
> TxtxXzLTDQ9W4ya3xgwyaqVa6Tky6Yqhi5BLpPCc9tZ,0
I don’t understand your first sentence.
We established the following:
- TVC does not help against nodes copying votes from others (because 800 ms is enough time to still do that).
- With Alpenglow there is no reason to delay votes (because you get the same credit), so there is no reason for TVC.
So what are you proposing and why?
The question is: will it be beneficial for the chain if the validators do their best to validate better, that is:
- vote FOR “good” blocks and AGAINST “bad” blocks.
- do it quickly
or do we just need from validators a bare minimal service (counting on the fact enough of the total stakes actually looks at the block before voting, and does it quickly enough) ?
If the answer is yes, then they must be incentivized to validate always better. That’s why we have TVC today. You mentioned above that we could have “something like TVC” in AG, wasn’t it for this purpose ?
If there is “something like TVC”, there might be nodes trying to collect the reward for good validation without doing the job by copying good validator votes. I agree that TVC doesn’t protect against vote copying. That’s why I suggested to split the votes in two ballots: one public ballot allowing to finalize fast and one secret ballot containing the proof the validating job has been done (bank hash or precise skip reason). Copying the public ballot without providing the secret one won’t earn you any reward.
Maybe we should discuss this in a call.
But briefly: My “we could” comment was meant as “it’s not impossible”. However, I don’t see any reason why we should have it. This is the question we need to solve. When we agree on the “why” we can talk about the “how”.
The first part of my last post tried to formulate the “why”: will it be beneficial for the community if validators compete for doing an always better job in terms of speed AND relevance of their votes ?
EDIT: this is a different that what you already pointed you several times: that there is no reason to deviate since there is nothing to gain from deviating. Here it’s about pushing validators to do their best, not to prevent deviation.