Algorand's Latest Upgrade: Dynamic Round Times & AVM v10
The latest Algorand upgrade to v3.21 introduces a new, more refined, timing strategy to produce blocks that is based on dynamic parameters.
This strategy allows the network to adapt its performance based on how fast the messages spread across nodes. The average round time decreased from 3,4 to 2,8 seconds!
Also, we have a new release of the Algorand Virtual Machine (AVM) which now includes useful opcodes for math on pairing-friendly Elliptic Curves; box manipulation; pooled opcode budget for Logic Signatures; and new global fields.
Table of Content
Dynamic Round Time
Any blockchain network faces the important problem of allowing as many people as possible to participate and yet to not allow bad actors to stall or degrade performance.
A single round in Algorand is made up of multiple steps in which a lot of nodes are involved in the exchange of messages through the Internet.
These nodes form committees and vote on what the next block should be.
However, nodes may be slow or fail entirely, so timeouts must be chosen that allow the consensus protocol to move forward, rather than wait for every node. Until now, Algorand has chosen these timeouts statically, based on worst case estimates of Internet connectivity.
Dynamic Round Time is a new feature of the Algorand node that allows this timer to be changed dynamically by taking the network conditions into consideration. Meaning that if the nodes can process messages at a high speed and also have favorable network connectivity that allows for fast communication, this timer can be decreased resulting in faster block production time.
When you do this for Algorand nodes, which already run an efficient consensus protocol, the block time reduces on average to 2,8 seconds (with instant finality)!
This is not at all in contrast with the goal of allowing maximum participation because this adjustment can go both directions. The parameters that make up the time out are based on the average performance of the network and therefore would also adjust to allow communication with nodes that don’t enjoy the same internet speed (or machine performance).
The network still defined maximum time outs that prevent stalling.
For more information on this feature, check out chapter “Timing Parameters” of this document and also this.
EC Math on Pairing Curves
Pairings of Elliptic Curves are an interesting mathematical object. In essence, there are some pairs (G1, G2) of related elliptic curves for which there exists a transformation that takes two points (g1, g2) and maps them to the a target curve (GT).
These transformations also preserve the structure of the original elliptic curve which means that the arithmetic that you can do on the first curve corresponds in an elegant way to the same kind of arithmetic on the second curve (bilinearity property).
Pairing friendly Elliptic Curves allow for many interesting cryptographic schemes such as: Zero Knowledge Proof Schemes; Vector Commitment Schemes; and Digital Signature Schemes.
We will give an example of Digital Signature Scheme by offering a minimal implementation of the BLS Digital Signature verification algorithm.
This verification algorithm bases its correctness on a very important reduction in computational difficulty that happens when a bilinear mapping exists.
The Decisional Diffie-Hellman Problem is believed to be impossible to solve on the original pair of curves (G1, G2) but becomes trivial on the target curve (GT).
It’s thanks to this asymmetry that it becomes possible to produce signatures that are hard to reverse but easy to verify.
We give an example of this algorithm using TEALScript and Algokit at this Github link.
Disclaimer: This minimal implementation is to be considered for learning and demonstrative purposes only. It is not audited and not fit for production. Don’t use it anywhere it’s important.
Other AVM Upgrades
The new box opcodes in AVM v10 are box_splice and box_resize. These two opcodes simplify some common box operation that previously had to be composed of many opcodes and looping constructs.
Splice lets you replace a substring in a box with another arbitrary string (up to the size of the box), even if the replacement is a different size.
Without this opcode, you’d have to extract the box content, manually replace and potentially move all the old information.
Resize lets you change the size of a box in a single instruction instead of saving the content, deleting a box, re-creating it with the correct size, and re-populating it.
You can find TEALScript examples for both these opcodes at this Github link.
LogicSig opcode pooling is a new feature that follows the more general trend of pooling resources in an Atomic Group. Each LogicSig gets an opcode budget of 20.000 units. Before this change, if two LogicSigs were using 10.000 budget units and 25.000 units, the group used to fail.
With this new feature, your budget is tracked across all LogicSigs. In the previous example this means that the group succeeds because the total budget used (35.000) is less than the total allowed (40.000).
It is now also possible to query three new fields from the global opcode.
AssetCreateMinBalance and AssetOptInMinBalance will return the change in Minimum Balance Requirements (MBR) when creating or opting into an ASA.
GenesisHash can be used to check which network your TEAL code is running on. This is especially useful for LogicSig because those programs, once signed, are valid for all Algorand networks and special care should be taken to make sure that it’s only running in the expected network.