The Lima Upgrade Proposal: Fixes, Improvements, and Next-gen Rollups
On 5 October, Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda, and Functori published information about the next Tezos protocol update called Lima. Lima is the capital of Peru, so here is alpaca.
In this post, we explain in simple terms how Lima Upgrade will change the experience of using, baking, and developing on Tezos.
Kernel-Based Optimistic Rollups
In the Jakarta update, bakers have activated Transactions Optimistic Rollups (TORUs) for regular transactions. Kathmandu announced rollups for smart contracts (SCORUs). And now work is underway on Kernel-Based Optimistic Rollups.
TORUs are designed for transactions and nothing else. SCORUs enable smart contracts on Michelson. Kernel-Based Optimistic Rollups, on the other hand, are the platform for running any application at all.
Roughly speaking, a Kernel-Based Optimistic Rollup is a separate virtual computer with its own operating system (kernel) that is not limited to Michelson primitives and can run any code. Instead of having to learn Tezos languages and understand the specifics of blockchain, a developer could immediately write applications in a familiar language and treat the blockchain as a regular file system.
Operators of Kernel-Based Rollups would be able to optimise them for their tasks: simple transactions, trading, cryptography or specific applications. The most interesting case is the implementation of kernels with other virtual machines, such as EVM or Java. Nomadic Labs is currently working on a kernel with WASM.
Kernel-Based Optimistic Rollups are already activated in Mondaynet testnet. The kernel working example code is available on Trilitech’s Gitlab for testing and experiments and Nomadic Labs plans to publish guides on kernel development. See more technical details in the Nomadic Labs blog.
Consensus Keys for Bakers
Bakers now use a single address to store tez and sign consensus operations like endorsements and blockchain creation. This is dangerous as the wallet key is permanently connected to the network. Changing keys regularly is difficult, as the baker loses delegated funds when the address is changed.
Lima will have additional consensus keys for signing consensus transactions. These will be “derived”, meaning that the assignment of a new consensus key will need to be signed with a key from the wallet. Consensus keys will allow bakers to store funds more securely and make it easier to transfer operations to another machine.
For more on consensus keys, see the MIDL.dev blog.
The developers have removed the creation, storage, and transfer of tickets with zero quantity. The tickets ended up being safer to use, but the instructions for handling them changed.
In addition, ownership updates on the tickets will be recorded on the blockchain. This will allow indexers to track who owns which tickets and display balances like tokens.
In future protocol updates, the developers will specify all possible ticket transactions between different types of addresses and blockchain entities. See the design document for more details.
Block Propagation Accelerated
In our review of the Kathmandu update, we explained the first part of the Pipelining Project, the separation of checks and application operations to speed up block distribution across the network.
In Kathmandu, this separation was only used for manager operations: transactions, delegation, contract deployment, public key disclosure, etc.
In Lima, all possible transactions and even blocks will be handled according to this principle. While in Kathmandu a node would receive a block, check it, apply it, and only then propagate it, in Lima a node would send the block to other nodes immediately after checking it and apply it afterwards.
Pipelining will reduce the time it takes for bakers to offer new blocks, and in the future, it will speed up block creation.
Ghostnet Fixes and Other Improvements
Kathmandu has a permanent testnet called Ghostnet, which updates to the latest version of the protocol just like the mainnet. In the past couple of months, the developers have found and fixed two problems in it:
- When activating the Verifiable Delay Function, they did not take into account that Ghostnet’s cycle time is four times shorter than that of mainnet. Testnet participants did not have enough time to make calculations in the allotted period. The problem was solved by reducing the complexity of the VDF by four;
- because of the short voting period of one cycle, the “time until next period” counter became negative and did not allow Ghostnet to automatically go through updates. This will be fixed when migrating Ghostnet to Lima.
In addition, Liquidity Baking sunset, i.e. the timer after which the protocol will turn off the liquidity baking subsidising, has been removed from Lima. Instead, there will be a vote with the option to turn the subsidies off and on again by vote threshold.
The final change is to temporarily disable the Timelock primitive due to a discovered vulnerability. Octez v14 has disabled the interaction with smart contracts with Timelock, and Lima will not allow new contracts to be deposited with Timelock.
Subscribe to Tezos Ukraine on social media and never miss a thing from the world of Tezos!