I have a question about network partitioning. I read the white paper but I couldn’t understand how Algorand resists on Network partitioning .
Imagine after Bn the network become totally partitioned. Then probably we will have two different committees for both partitions and that might result to a fork.
Whitepaper talks bout it at section 7.4 under “Getting stuck”. The whitepaper assumes that: “Neither group is large enough to gather enough votes on their own”
Could you please explain more about this assumption. Considering that some offline accounts might become online and start doing Sortition in both partitions.
That is a very good question.
The short answer is that there is no risk of forking in that case. The only thing that may happen is that the blockchain stalls until the network recovers.
Here are some more details.
To participate in consensus, an account needs to be marked online.
This is done by sending a special transaction, called a key registration transaction - Algorand Developer Docs).
The account is marked online 320 rounds after the key registration transaction is sent to the blockchain.
The sortition algorithm randomly selects a committee of online accounts.
To understand how things work, let’s make the following simplifying assumptions
the committee is composed of 1,000 parties
a block is committed if at least 700 of these parties vote for it
each account on the blockchain has exactly 1 Algo. (Accounts with more Algos can be selected multiple times in a committee, as if each Algo of the account was selected individually.)
there are X online Algos
Each online account (with 1 Algo) will be selected in the committee with probability 1,000 / X.
Note that the blockchain knows X because it knows the list of online accounts.
Now, if the network is partitioned, say 50% / 50%, with high probability, each group in the partition will have 500 selected parties in the committee. This is not enough to get 700 votes for the same block. Thus the blockchain stalls.
Note that since no blocks can be committed, in particular no key registration can be made, so no new party can vote in the consensus.
This really means that the blockchain just stalls until the network recovers.
A few remarks:
The fact that the blockchain stalls in case of a 50/50 partition is unavoidable. It is essentially a consequence of the CAP theorem: Algorand is network tolerant and consistent, so it cannot be available in case of some network partitions.
One great feature is that after the network recovers, the Algorand blockchain commits new blocks almost immediately. There is no long process to fix the network recovery.
If the network is partitioned 90/10, then the largest group will grow the blockchain while the smaller group will just not see the new blocks. This is perfectly fine. There will still be no fork: the smallest group cannot commit to new block by itself.
In that case, the blockchain would stall and not produce any block.
Since the only way for an account to be marked online or offline is to commit a key registration in a block and since no blocks are generated, the set of online accounts remain the same and there is no risk of fork.
As @fabrice suggested, once the networks get partitioned, there is no further progress on the network ( for good or bad - depending on your position ). ( you might be able to convince me that a given participant is online or not), but if the participant’s votes could not reach the rest of the network, that participant would be effectively offline.
The network would recover once there are enough online voting participants.
but if it’s the actual algos that form the committee and not the accounts is that decentralized and secure? going with the 1000 committee/algo assumption, if there were only 3 accounts controlling it, two might collude at the expense of the other/ how does algorand mitigate this? same for 2 accounts controlling the 1000. Even if the algos are randomly selected to make up the 1000 committee, the colluding accounts would have their way most of the time. This is exacerbated when the colluding accounts have their other algos in X subsequently and frequently selected in the other steps.
The nature of selecting the Algos instead of the account eliminate any gains/losses by merging/splitting account balances to get more control over the network.
If we’ll go to the extreme case - let’s say that there is only a single account voting : this account would be in contol of the network. The colluding scenario you’ve mention above is real - but is normally used for good. I.e. protocol upgrades, etc.
There is an assumption, that if someone has enough stake in the platform, it would be in his best interest to participate in the consensus as a way to protect his investment. I don’t have the numbers, but it’s the Algorand foundation that keep monitoring the participation levels and adjusts their participation nodes balances to ensure the network is secured.
yes it’ll be in his interest to protect his investment at the expense of another. That someone or colluding accounts may not include the other’s tx, ignore the other’s vote, even create empty blocks to get ahead in a trade , an auction etc. What happens if the algos get concentrated again assuming it was initially evenly distributed until 2030. i think out of the 10b 1/3 should be locked up and participating forever
I think that what you’re trying to say is “1/3 of the online stake (i.e. eventually 10b algos) should always be allocated to a honest participant”.
I completely agree with that. Furthermore, I think that one of the core principals behind the Algorand security model is that “more than 66% of the stake would always belong to a honest players, since those have too much to loose”.
One thing that we can clearly improve upon, is to develop additional methods for people to vote in the consensus, even if they don’t have a participating node. This isn’t an “urgent” thing, but once all the Algos are distributed, the network would benefit from having a trustworthy voting service.