Algorand releases new binaries (Algorand’s executable files) on an ongoing basis. These new binaries can contain any number of bug fixes or new features, but the key question is whether or not the consensus version changes. The consensus version can be thought of as the language that the nodes speak to each other. If the consensus version changes, then the language is changed. For example, if the nodes on a network currently talk to each other using consensus version A and then a single node on the network switches to consensus version B, this single node will no longer be able to talk with the other nodes on the network. Therefore, to keep everyone in the network talking the same language, the network must first ensure that adopting a new consensus version is “in consensus’’. Algorand’s protocol upgrade mechanism guarantees it.
Given that the Algorand network must upgrade its consensus version as some new features or bug fixes are brought in to the protocol, how do we solve this problem in a way that allows new consensus versions but also does not continually partition the network?
Algorand’s upgrade process when a consensus version change is involved is as follows:
In summary, Algorand’s consensus based protocol upgrade mechanism has an important role, making sure that everyone keeps speaking the same language when an upgrade that changes the consensus version takes place.