Algorand Consensus Protocol
developer.algorand.org
developer.algorand.org
Some other group could follow this exact protocol and also call their blockchain Algorand.
Which is generally hardcoded in the client you run. So in that sense you trust the binaries you download, or the source code that you compile. The advantage of PoW consensus is that it's much easier to tell the real chain from a fake one, as the latter will not have much more work performed on it.
Even with the genesis block fixed, control of the initial keys embedded in it allows you to generate arbitrary alternative blockchain histories that without PoW are difficult to distinguish from the "real" one.
If the assumption is that downloaded binaries must be trusted, one could simply use a key embedded inside that binary to verify the identity of a centralized database. No need for proof-of-stake.
At any rate, it would be nice to see something written for a more technical user that’s not just a formal spec (although that would be okay, too.)
One salient question I have is: during the account choosing phase in which the VRF is applied to each account held in a given wallet, what is the precise mechanism by which some accounts are chosen? Is it a difficulty mechanism, where the VRF(account, some blockheader data) must be less than a given number? If so, how and why does the number change?
My understanding on how the accounts are chosen is that they have a global list of users that have opted in to validate and they pick one person at random to create the block and then 1000 people at random to validate it. If you get 501 validations back, then you have a block.
The attack I always thought about but never got an answer to was: what if you pay for the lottery winners to collude? Certainly if you offer some amount of money for the block producers only on the condition that you get 501+the block creator in a given block you could probably sign a bad block, right? It’s unclear what the consequences of that would be if the block’s signatures still have to be valid but you could maybe craft something bad.
I don’t know, all of this thinking is from when I first talked to Silvio at IACR so it’s been a long time. It’s possible all of my knowledge is way out of date or wrong.
Anyways, I wish them luck, they’ve certainly got a big thing going.
Socially if this is signing a block with a bug, miners have historically colluded to rewrite history.
If on the other hand the new blocks embed protocol changes, then we move to names: is it still ‘Bitcoin’? If not then there is a hard fork with a new community. This is the BCH, BSV and ETC story.
The answer to your question about Algorand is probably similar, unless the scheme has some novel mechanism to prune hard forks, or a way to radically include them.
It is very difficult to buy votes on the network because you don't know who the next voter will be.
If I understand correctly, the voter is chosen based on pseudo-random hash prefix?
Algorand allows more than one node to propose a block to make sure that >=1 nodes propose a block with high reliability. The distributed consensus process picks one block to be the block.
The number of validators is more like 30-50 but that's a global tunable depending on what kind of system properties you want. Fewer can be faster and more can be more secure, but there's diminishing returns and 30-50 is so far secure-enough and quite fast (5 second round times on the current global network).