Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda & Functori
published a joint post
on what to expect in the Tezos protocol upgrade so without further ado, here are the awesome features being prepared for the next proposal.
An update on optimistic rollups
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 Mondaynettestnet
, 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
work continues to separate validation
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
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
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.
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_OPEN instruction in Michelson.