I am conducting MEV research on Algorand and, to get more informed about the sortition algorithm (proposer selection + committee selection), I went through the whitepaper and various resources. The one thing I couldn’t wrap my head around is the use of subUser (i.e., winning ticket count) in the committee selection. I understand that it should be greater than 0 s.t. the account can vote, but does the vote actually have a weight? In proposer selection, the subUser count enables you to produce more hashes (and pick the lowest valued one) but I am not sure about the effect it has in committee selection. Any clarification would be appreciated.
1 Like
Note that GitHub - onplanetnowhere/AlgorandConsensusProtocolMD: A Technical Guide to the Algorand Consensus Protocol is not an official resource. In particular, it does not seem to describe the protocol as implemented: the expected number of seats in committee are off and there is no notion of tentative block in the current Algorand implementation (there were though in some white papers but MainNet never had tentative blocks).
The official Algorand specs, as implemented, are in GitHub - algorandfoundation/specs: Algorand Specifications.
From what I see, the value subUser described there seems to correspond to the number of seats/votes the user has in the committee. Or in other words, the weight of the user in the committee.
The way it is computed seems to match the way it is done in the current protocol.
1 Like
Thanks for your answer. This means that it is probable for an account to have multiple votes in a single round, right?
And just to clarify, does the sortition algo pseudocode in Gilad et al. match the actual implementation? I couldn’t make it out from the overview document in the specs repo you shared.
1 Like
I believe this part is correct in essence. (There may be little tweaks about what the exact input to the VRF is and things like that, but in essence, it looks correct to me.) The exact code is: go-algorand/sortition.go at master · algorand/go-algorand · GitHub & go-algorand/sortition.cpp at master · algorand/go-algorand · GitHub
2 Likes
I have a followup question regarding the block proposer selection. After running VRF, if I have any winning tickets, I calculate a priority for them through hashing and propose the lowest valued one to the network (and everyone else repeats this and propose their lowest value if they have any).
Some resources state that there is a threshold that the values proposed must be below but from what I understand this is just an abstraction. Is there actually a threshold and the number of valid proposals is approx. 26 (as stated in the whitepaper) or does 26 correspond to total number of blocks proposed by anyone (i.e., anyone who has >0 winning tickets)?
The winning tickets are computed similarly as the number of seats in committees above.
In average, there will be 20 of them (according to current parameters at the end of the PDF specs/Algorand_v1_spec-2.pdf at master · algorandfoundation/specs · GitHub).