Fractal Upgrades

Abstract

As future versions of protocols add new features, fixes and performance improvements, consensus among stakeholders is required to migrate from the current version to the proposed improved version. Many other blockchains have adopted a voting-based system, where all proposals have to pass with a quorum requirement to be enacted for a binary switchover. Anoma instead uses a “fractal upgrade” approach, which allows anyone to propose a new version of the protocol which can be used immediately, and allows multiple versions to be tested in parallel, with a canonical version switchover taking place after extensive testing has been conducted.

Introduction

A protocol dictates how transactions are made and the processes within, essentially defining the set of rules that allow data to be shared between computers and forming the structure behind it. In Anoma, those components in the ledger protocol need an upgrade system. These upgradeable components are defined by a need to evolve and iterate over time in accordance with usage patterns, and being part of consensus so they cannot be changed unilaterally¹. Other features such as the matchmaker and ledger are not part of the consensus state machine and accordingly can be changed voluntarily by individual participants. By not using a voting-based upgrade system, Anoma’s fractal upgrade approach is a unique system in the blockchain industry whereas others require unanimity (or majority approval) from stakeholders. Additionally, multiple iterations of proposed candidate versions can be used in parallel to the canonical versions, with stakeholders voting for their preferred version of Anoma through intents.

As time goes on, these rules can evolve, someone can develop new features, depending on the objectives behind the design considerations of each protocol, or even the evolution of technology and the varying adoption of these innovations in protocols². An example of the adoption of innovations in protocols is zk-SNARKs as an advancement in zero-knowledge proofs, playing a prominent role in the construction of ZCash, which allowed the upgrade from Sprout to Sapling³. Anoma can, for example, use the upgrade system to add new curves for zero-knowledge protocols, adopting more complex logic in the validity predicates system for different forms of private trade. Protocol upgrades allow networks to stay up-to-date with the latest technology and also develop unique new features. This article will explore this concept of protocol upgrades and describe Anoma’s fractal upgrade approach.

Protocol upgrades on Anoma

For all blockchains, the challenge is not in writing code for upcoming software changes, but to achieve a good balance between the upgrade system and the stakeholders using it. Once a particular instantiation of the ledger protocol is live, node operators do not automatically pull the changes that are, for example, released on GitHub. Node operators are running a consensus algorithm to operate the state machine and agree on the results of applying transactions to the state – meaning that a single node cannot decide, by itself, to change the rules when it comes to determine the validity of transactions and the state of the ledger. Nodes in a diverged fork, as a result of this action, have a different view of the global state of the consensus protocol, and are unable to validate blocks in the previous blockchain.

When designing protocols, it is difficult to anticipate all future possible bugs and exploitations within the design itself and through the implementation. By having an upgrade system in place, Anoma has the ability to change the protocol over time. An upgrade system also offers flexibility for the release of innovative features, such as updated cryptographic primitives and revised consensus algorithms, which still require development and time to mature. Aside from new features, having an upgrade system in place helps integrate user and network agents’ feedback to bring immediate attention to issues or bugs.
While requiring consensus from validators to make changes brings many advantages such as stability and decentralization to the blockchain, for Anoma, the initial upgrade system must be flexible to allow changes of the system itself, as it is expected to adapt to future developments. While new features, fixes and performance upgrades can bring many exciting changes, a poorly established protocol upgrade system may bring disadvantages, such as malicious agents co-opting an upgrade mechanism. A well-designed and implemented upgrade system where two thirds of the stakeholders have signalled a binding acceptance can provide a relatively high degree of minority protection and protection against malicious or buggy upgrades, due to a gradual transition between protocol versions.

Possible approaches to protocol upgrade mechanisms on Anoma

In the space, one could identify two ends or extremes, when it comes to possible approaches, defined by technical restrictions:

On one end, this can be for those running the protocol “to do nothing” with regards to the upgrade system and the basis point remains. This could mean simply releasing upgrades and new versions of the protocol to the Anoma Github repository. If everyone running a current version of Anoma wants to upgrade, they would have to coordinate among themselves to do it all at once, otherwise participants will diverge in consensus, meaning that they can no longer agree on the state of the blockchain. This method will simply require users to stop their nodes and restart them with the new code, but without a mechanism in place to discover what users might want for the network to implement in the next upgrade, it is not a given that users would approve of or favor the new changes. Without a structured method for discussion between stakeholders for the network’s direction, such as one with stake-weighting associated with consensus voting power, agreeing on additional features and fixes can be an ambitious task.

However, the difficulty of this coordination can also be an advantage. Once the rules are set, it requires extreme coordination to change them, which allows users to be fully aware of what they are using at all times. With an agreed upon consensus of the state of the ledger, this mechanism ensures that few changes allow the system to be reviewed by many over time, achieving reasonable security. Despite the difficulty involved, this approach comes with the advantage of simplicity and security.

The other side of this protocol upgrade design spectrum is the “public key” solution. A person or an entity in charge, for example Alice, would have a public and private key. The private key would be kept secure in her home or a secure facility. Alice, in this situation, would be responsible for signing the code updates that the Anoma blockchain nodes would then automatically download. Alice would also be the person responsible for deciding whether the new version of Anoma looks good, publish the signature for users to decide whether they want to use the new version or not. The same basic model applies in an example where the public key can also be a threshold M of N, where the signature is only possible if enough shares of the key are gathered.

On one hand, this approach brings fantastic advantages in the form of being able to fix bugs in the protocol almost immediately. All Alice would need to do is to use her private key to sign over the code update and publish it to the blockchain. Unfortunately, this approach comes with the disadvantage of centralization of control. This approach depends on Alice’s motivations, meaning that the network is not protected from any kind of malicious behavior that Alice may engage in. She could, for example, use her private key to sign over an update which transfers all the tokens to herself. Aside from malicious behavior from the key holder themselves,the private key could be obtained by another party to perform similar heists, which could be achieved by a simple break-in to Alice’s apartment. All things considered, this approach makes protocol upgrades extremely simple, but at the cost of network security.

Analysis of voting-based systems

Voting-based systems in the blockchain space have been tested and established with a degree of success, such as the Stargate Upgrade Proposal #37 on Cosmos⁴, with newly enabled IBC, Tezos Florence bringing intuitive smart contract development and Polkadot launching nominated proof-of-stake. Certain disadvantages come with these methods, primarily due to the lack of testing involved, especially in a way that incentivizes users to report issues, ensuring that the network runs smoothly. Tezos and Cosmos both share majority systems and an all-or-nothing quality for upgrades, which is disadvantageous in a way that there is no intermediate ramp up for testing. If bugs can be found before deployment, it is in a user’s best interest to not inform the network and to exploit it after it goes live on the mainnet. This atomic switch of the upgrade system not only has security implications once a bug is exploited, but that consequent code updates may not be released as regularly because of the risks that stand in the way.

Another disadvantage with regards to testing is that Tezos, Cosmos and Polkadot’s upgrade systems do not allow the testing of multiple versions with value at stake. If two versions were proposed, only one could be chosen, unless a new proposal was made with the best features of both, which is a problem that Anoma also has. While testnets are supposed to serve this role of allowing developers to test new protocol versions before they are live, they do not allow “real” usage in a way that is generally interoperable with the current main ledger. There is little reason for someone who is not a developer to run a testnet and see whether these protocols are good enough. Simply put, testnets tend to have no value at stake, therefore there is no reason for someone to exploit bugs on them.

Nevertheless, the importance of testnets and technical audits should not be understated in the context of protocol upgrades. Testnets serve the role of allowing developers to test code before going live, but it is also important to recognise that alternate versions of the protocol on the mainnet where users are incentivized to find bugs and notice bad features may benefit a network in the long-run. The key is to pick out good practices from existing systems that can be replicated, and perhaps having both testnets and alternate versions that can be used for different purposes, ultimately for greater functionality of the network.

Fractal Upgrades: The Anoma Approach

Anoma’s fractal approach to protocol upgrades aims to reconstrue what it means to upgrade. A staking token demarcates the canonicality of a particular instance of the Anoma ledger, therefore Anoma will loosen the tie between the staking token and the instance of the ledger in such a way that there can be multiple instances of the ledger – but only one managing the canonical staking token. For upgrades to happen, a process involving multiple stages is necessary. The Anoma protocol will be written in a way that allows for the following: Users can take the current ledger, change the code and launch a new version with whatever they want - perhaps with a subset of the validators and less security. The new protocol version will connect to the main or previous protocol version over IBC. Users can then try out the new version as if it were a different fractal scaling instance – running in parallel to the canonical version. For example, the first running version of Anoma is launched, which is the current mainnet. Thereafter, Alice launches her version of Anoma with performance upgrades, codebase of which is a variation from the mainnet’s version. This is followed by Bob, who also comes up with a new version, which offers support for the latest Juvix features. In parallel, Charlie can decide that these new features are not particularly important, and come up with a new version that is a variation from Alice’s codebase with an updated database layer, because he finds that Alice’s performance improvements were not fast enough.

With four existing versions in the same space (𝗧₀), users can start moving their assets to whichever version they wish, and interact with them, seeing what features they like (𝗧₁). While most users will likely not move to the other versions, they are still free to be early adopters of them, validators are encouraged and may be rewarded to run new versions before they become canonical. Early adopters may also receive extra rewards in the form of tokens if the version they test early on ends up being adopted as the canonical version. Additionally, users who move to parallel versions can choose to stay, or move back to the canonical version.

After some time, when users have tested and tried using the new versions of Anoma and there is clearly a superior version, for example Charlie’s, which at this point, 66.67% have agreed, using intents, on becoming the new canonical version. (𝗧₂). Rather than having a staking token always associated with one version of the ledger and having it all switch at the same time, it will be switched on Anoma separately. Stakeholders will have a special kind of account, and a special kind of order intent they can publish. Now that ⅔ are in favour of switching control of the token to Charlie’s version, the logical transfer can happen over IBC, resulting in Charlie’s chain receiving the ability to mint the token to send it elsewhere. This will be recorded in the logs, and the old version can keep running during a sunset period where users are encouraged to migrate to the new canonical version.

As mentioned previously, the canonical version of the ledger is defined by its ability to mint the staking token and send it across chains. This version would then control the supply, while other chains connected to this chain monitor the supply that comes in and out. The canonical version also controls the staking token and everything else related to consensus, primarily to prevent inflation of the native token by risky new versions until the switchover happens, i.e. preventing anyone from sending back more than they received. Anoma’s upgrade system differs in a way from existing protocols that leverage voting-based mechanisms in that no vote happens when a proposal is launched. The only “vote” that takes place is to switch control of the canonicality of the ledger to a new version that has already been running for a period of time, but this is done using intents, while assets can already be independently moved to whichever versions users wish. There can be many new versions in parallel, and users can be incentivized to test and find bugs in new versions to increase security for the rest of the users who follow. This lowers the risk in comparison to existing approaches in the space, stabilizing new versions before the switch, which is then also not immediate for every participant. In Anoma’s instance, a proposal period is also not needed. This upgrade system allows not only higher security, as new versions can be tested by users and validators prior to voting and switching, but flexibility. Stakeholders can decide which version works best for the network, and skip versions in between.

Conclusion: The future of the Anoma protocol upgrade system

Upgrades can be expected to slow down as new versions are created that exist in parallel, filling different niches of users of the network – a good sign that the protocol is stabilizing. As the protocol matures, it will converge to a particular point in the design space where upgrades will be less necessary. Users remain free to create new versions of Anoma with features and improvements they desire, propose them for stakeholders to vote on, and use an instance that is the best version Anoma offers. This upgrade system is expected to be phased out over time as the protocol converges to a stable point.

Bibliography