This is a joint post from Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda & Functori.
With the Kathmandu upgrade successfully activated, it’s time to look at what’s next for Tezos.
For our 12th upgrade proposal, we are leaving the Himalayan mountains behind and heading to the coastal climate of Lima, capital of Peru and one of the largest cities in the Americas.
But before we embark on that journey…
An update on optimistic rollups
Development of next-generation enshrined optimistic rollups on Tezos is progressing steadily. Functioning rollups implemented in Rust are currently running in our test suite.
These rollups will however not be part of the Lima protocol upgrade proposal, as more time needs to be spent on validation, testing, and integration with ecosystem tools before they can be activated on Mainnet.
We highly encourage ecosystem participants to start experimenting with these rollups on the Mondaynet testnet, where they are already activated. Broad testing and feedback from the ecosystem is invaluable in our efforts to minimize the risk of undetected issues upon Mainnet activation. More on this further below.
Now, let’s look at the series of improvements to Tezos functionality contained in the Lima upgrade proposal.
More pipelining for a faster blockchain
Our pipelining work continues to separate validation from application of operations and blocks in order to speed up their processing. It may not sound sexy, but this is an important part of increasing Layer 1 throughput on Tezos.
A quick distinction:
- Validating means performing basic checks, such as the cryptographic signature being valid, and that there are funds to pay fees. This is a light and quick process.
- Applying means executing the full contents of the operation, whether a simple transaction or a complex contract call. This can be much more computationally intensive and hence time consuming for the node.
The Kathmandu upgrade reduced the number of times manager operations are applied by a node before it is propagated through the network. This minimizes the delay introduced with each node, as blocks and operations are gossiped through the peer-to-peer network.
The Lima protocol proposal extends pipelined validation to all remaining classes of operations, and to blocks themselves. When receiving a new block from its peers, a node will only check the validity of the block before forwarding it to other peers, speeding up block propagation on the network. Afterwards, the node will then apply the block.
The upcoming step will be to extend pipelined validation to block production itself, reducing the effort (and hence time) required for bakers to propose new blocks. Along with further upcoming optimizations, this opens the door to reduced block times.
This one’s for the bakers: introducing consensus keys
We are happy to introduce consensus keys — a feature which has been highly requested by bakers.
Consensus keys allow bakers to designate a special key — separate from the baker address key — for signing blocks and consensus operations, such as (pre)endorsements. The proposed implementation lets bakers change their consensus key without changing the baker’s public address.
Rotating keys is generally good practice in computer security. And this feature will be of great benefit in situations where:
- There are concerns about a baker’s private key having been compromised.
- A baker using a Key Management System (KMS) or Hardware Security Module (HSM) wishes to switch to a different setup. These generally don’t allow key extraction.
- There is loss of access. E.g., if a geographically remote baking setup using KMS/HSM fails. With consensus keys, the baker can remotely deploy a new setup under the same baking address.
Hence, a baker’s delegators no longer need to actively redelegate to a new address, which was cumbersome and required off-chain coordination, reducing the chance of reaching all of the baker’s delegators.
The consensus key feature is based on contributions made by G.-B. Fefe (anonymous contributor) and Nicolas Ochem. As a reward for their involvement, invoices of respectively 15,000 and 10,000 tez are included in the Lima proposal.
Improvements to Tickets
We are deprecating creation, storage and transfer of zero-amount
tickets. This
removes a source of inconvenience and reduces the risk of bugs in
smart contracts, but introduces a breaking
change
in the TICKET instruction.
Furthermore, we added ticket ownership updates to transaction receipts. This enables indexers to maintain a table that tracks which accounts own what tickets by traversing the receipts.
The change to receipts was introduced after fruitful meetings with ecosystem actors, and we are happy to collaborate with the ecosystem in this way and implement their valuable feedback.
In Lima, receipts will include this information for ticket minting/removal within a single contract and transfers between originated contracts. In upcoming upgrades, we will cover all combinations of transactions between implicit accounts, originated accounts, and rollups. A design document can be found here.
Ghostnet fixes
During the migration from Jakarta to Kathmandu on the Ghostnet test network, two problems arose, that are fixed in Lima:
-
The VDF feature activated itself with the same difficulty as on Mainnet, but cycles on Ghostnet are ¼ of Mainnet! So it’s impossible to do the required computation within the allocated time frame. For this reason, the VDF challenge’s difficulty on Ghostnet is now set to ¼ of Mainnet’s.
-
The length of a voting period on Ghostnet was changed from two cycles to one cycle. However, due to the way a protocol upgrade is executed, a “time until next period”-counter became negative after Kathmandu was activated, leading Ghostnet to not advance through voting periods automatically. Therefore, a ‘force reset’ of the voting period is scheduled for Ghostnet’s migration to Lima, should the proposal be adopted by the community.
Other changes
- Liquidity Baking sunset removed: The liquidity baking sunset will be removed, since the subsidy can now be shut off with the moving-average toggle introduced with the Jakarta upgrade.
- Temporary Timelock deprecation: As recently
announced,
a vulnerability has been discovered in the Timelock mechanism. A
safer Timelock mechanism is currently being developed. As a
preventive measure, Octez
v14 already disabled
interaction with smart contracts using this feature. The Lima
protocol proposal complements this measure by preventing the
origination of new
contracts
using this functionality. This is achieved by temporarily
deprecating the
CHEST_OPENinstruction in Michelson.
Help us get rollups rolling!
As mentioned initially, we are looking to have our next-generation optimistic rollups tested extensively and integrated with ecosystem tools before activation on Mainnet.
Careful and incremental integration in close cooperation with the Tezos ecosystem is always desirable, but with optimistic rollups being the backbone of Tezos’ scaling strategy and possibly the largest evolutionary leap for the Tezos protocol so far, this becomes paramount.
In particular, the Webassembly (WASM) Proof-generating Virtual Machine (PVM), which is at the heart of the system, is currently considered to be in beta.
The WASM PVM included in Lima lets users originate a rollup on the Mondaynet testnet by providing a WASM program — called a kernel — which interprets any Layer 2 operations targeting the rollup.
Aside from intra-rollup operations, these Layer 2 operations may also transfer assets wrapped as tickets from Layer 1 accounts to rollups, or produce asynchronous transfers of tickets from the rollup to Layer 1 contracts. A mechanism of data revelation is also introduced, so that data from sources external to Tezos’ Layer 1 can be imported in a rollup.
There is no restriction on who can write and deploy a WASM kernel. An example of a kernel facilitating transactions is available here, and we expect such kernels to fully replace Transaction Optimistic Rollups once kernel-based rollups are activated on Mainnet.
We encourage the ecosystem to start identifying use cases for kernel-based optimistic rollups, and to prepare for building WASM kernels of their own. We are currently finalizing the necessary documentation and guides, but anyone interested in getting started with building kernels can reach out to contact@nomadic-labs.com.
More info will be released soon. Stay tuned!