For most of the software that we use in our life, e.g. word processors, the company that produces it decides what updates are required, sometimes in accordance with user opinions, and then releases the new software. At this point, each user can install and enjoy the updated software.
The case of Blockchain software is significantly different, as it is typically run by many users, and all the nice properties of Blockchain systems hold as long as a significant fraction of the users run the same Blockchain software honestly.
This creates two critical issues:
1) The honest users should all agree on how the Blockchain should be updated and on what code each user will run. If different users started running different versions of the Blockchain software, then the security of the Blockchain would be completely compromised. For example, it is natural to require that the updated Blockchain will preserve the history of the transactions of the old Blockchain. If the switch from one version of the software to another is not done carefully then we might lose part of this history or, even worse, adversarial users might alter this history.
2) Once an agreement is reached on the update of the new Blockchain software, it should be established when and how the users should install this software.
In PRIViLEDGE we have studied exactly these problems and proposed solutions that do not require to rely on trusted third parties. In particular, we show how to construct a Blockchain software that tolerates updates. To do that, we start from any Blockchain software that has some specific properties and show that this can handle a large class of updates.
Our protocol is pretty intuitive. We rely on the Blockchain system to reach a consensus on what features the new software should have, its new code, and on when and how the new code should be installed. Once that the new Blockchain code (let's call it B2) has been accepted by sufficiently many users, we handle the switch in the following way. We transform one of the most recent blocks into a block that is valid for the rules of B2, and we start extending this block using the rules of B2.
Even if the above approach is based on a simple idea, there are many aspects that need to be treated with care. For example, if B2 is a Blockchain software that works securely under the assumption that its genesis block is generated correctly, what can we say about the security of B2 when the genesis block is the output of another Blockchain software? To capture this, and other aspects of an update process, we have provided a formal treatment of the problem proving under which condition it is safe to do an update. For more details, we refer to our paper "Updatable Blockchains" that will be presented to the 25th European Symposium on Research in Computer Security (ESORICS) 2020.
Written by Michele Ciampi, University of Edinburgh.
Photo by Markus Winkler, Unsplash.