For blockchain systems, a typical source of changes are enhancements at the consensus protocol level. There might be changes to the values of specific parameters (e.g., the maximum block size, or the maximum transaction size), changes to the validation rules at any level (transaction, block, or blockchain), or even changes to the consensus protocol itself. Usually, the reason for such changes is the reinforcement of the protocol against adversarial attacks, or the optimization of some aspect of the system like the transaction throughput or the storage cost.
An oxymoron: Centrally governed decentralized systems
Traditionally, software updates for blockchain systems have been handled in an ad hoc, centralized manner. Somebody, often a trusted authority or the original author of the software, provides a new version of the software which users download and install from that authority's website. Even if the system follows an open-source software development model, and therefore an update can potentially be implemented by anyone, the final decision of accepting or rejecting a new piece of code is always made by the main maintainer(s) of the system, essentially constituting a central authority.
Even in cases where the community has initially reached consensus about an update proposal (in the form of an Improvement Proposal document) through discussion in various discussion forums, it still remains an informal “social” consensus. Such a social consensus is not recorded as an immutable historical event in the blockchain, and the final decision is always up to the code maintainer. Moreover, the authenticity and safety of the downloaded software is usually verified by the digital signature of a trusted authority, such as the original author of the software.
What does it take to decentralize software updates?
A decentralized mechanism for software updates should be open to the community. Software update proposals indicate the direction that the blockchain system should follow, and this direction steering should not be the privilege of the few. Ideally, anyone who can submit a common transaction to the blockchain should be able to submit an update proposal.Decentralized decision making
It is true that in the life cycle of a software update there exist several important decision points, some of which require significant expertise and thus traditionally have been restricted to a small group of “experts” (usually called the code maintainers). Examples of such significant decision points include:
● the approval or rejection of an update proposal,
● the appropriateness of a submitted piece of code that implements an update,
● when an approved software update will be activated.
In a decentralized setting, the responsibility for all these decisions should be handed over to the community (i.e., the participants) of the blockchain system. This transfers the ownership of the blockchain to the community, which in blockchain parlance is called decentralized governance. But, what does it mean to hand over decision making to the community?
Voting is the main vehicle for driving democracy and is also the main mechanism for decision making in a decentralized setting for software updates. The community is called to vote for approval of update proposals. Then when an approved proposal is submitted as code, the the community is called again to vote on the correctness of the implementation. Finally, at the last stage, the community is called to synchronize on the activation of the update by a voting mechanism called signaling.
In the following figure, we depict the life cycle of a typical decentralized software update. This consists of four phases:
- the Ideation Phase, where a software update (SU) proposal is submitted to the blockchain in the form of a System Improvement Proposal (SIP) and is approved or rejected
- the Implementation Phase, where an approved proposal is implemented and submitted for review
- the Approval Phase, where the submitted implementation of an update proposal (UP) is reviewed and is either approved or rejected and
- the Activation Phase, where the activation of a change takes place in a synchronized manner.
Note that all the critical decision points mentioned above are supported by a voting process. Moreover, the strong requirement for technical expertise in assessing software updates could be fulfilled by enabling the delegation of the voting rights to some expert pool (an analog to stake pools that we see in proof-of-stake-based systems) on a per software update basis. Of course, a participant in the software updates protocol could request help from an expert without delegating their participation rights (i.e., expert assistance could very well be just an out of band solution).
Figure 1: The life cycle of a decentralized software update.
A protocol-driven process
A decentralized mechanism for software updates should not be just an informal discussion-based process that utilizes social media in order to reach consensus on a proposed update. On the contrary, the whole process should be part of an update protocol that offers specific security guarantees and that leaves behind an immutable on-chain trace of what has happened.
Transparent and auditable
Such a mechanism for updates should also be transparent to everyone regarding the evolutionary history of the system. Who submitted which proposal and when; when it was approved or rejected and with what percentage vote and when it was activated. All these comprise critical questions whose answers should be available (transparent) to every participant of the blockchain system. Moreover, all the generated update events, such as the submission of proposals, the votes, and the activation signals, should be recorded on-chain and form a fully auditable historical record of the system’s evolution.
Safe, Secure and Resilient to Chain Splits
Last but not least are the requirements for safety and security. The activation of an update should take place in a safe manner such that the system is guarded against chain splits. For example, one has to guarantee that enough nodes have upgraded before the activation takes place. Moreover, the update protocol must ensure security against malicious attacks, where an adversary might attempt to take over an updated chain or block the activation of an approved software update.
Clearly, properly decentralizing the process of software updates is not that simple and is one of the problems that we try to tackle in one of the four industry-oriented use cases of the Priviledge research project. Follow the Priviledge project on Twitter to hear the latest about decentralized software updates and other developments in distributed ledger technology and privacy!
Illustrative photo by Pixabay