Kathmandu: Technical Features of the New Update Proposal Explained
On June 28, Tezos will migrate to the Jakarta protocol update with the built-in L2 solution Transaction Optimistic Rollups. For now, L2 only supports tez transactions, but that will change with the introduction of the Kathmandu update.
On June 23, Nomadic Labs released information about Tezos’ next update, Kathmandu. It includes Smart Contract Optimistic Rollups (SCORUs), faster block validation, integration of verifiable delay function and a permanent testnet called Ghostnet. Here’s an overview of all the new features.
SCORUs: L2 Supporting Third-Party VMs
Previously, we’ve looked at how Optimistic Rollups work. In short, users send tokens to the repository and get their representation on L2. Rollups routinely summarise transactions on L2 and publish them to L1. As a result:
- The load on the baker nodes is reduced;
- The maximum throughput of Tezos increases;
- It becomes more profitable for users to work with DeFi as transaction fees in L2 will be ten times less than in L1.
Tezos is about to activate Jakarta and TORUs, the rollups for tez transactions. And Kathmandu will have SCORUs, i.e. rollups supporting smart contracts.
The main feature of SCORUs implementation in Tezos is the ability to implement any computing device as long as its semantics can be described as a Proof-producing Virtual Machine (PVM).
So, to put it simply, it is theoretically possible to implement an Ethereum virtual machine (EVM) or Java right in Tezos’ L2.
Core developers, as a proof-of-concept, plan to launch a stack-based PVM with support for WebAssembly (Wasm) instructions on a testnet. Wasm itself supports compilation from C++, Rust, Go, TypeScript, and other high-level languages.
It’s essential to keep in mind that SCORUs will appear on the mainnet in half a year or maybe even later. Tezos developers previously complained about the too rapid introduction of new features into the protocol: they didn’t have time to try them out and use them in applications. For example, tickets appeared more than a year ago, but the community still hasn’t worked out standards for them. That’s why SCORUs will only be available on Mondaynet and Dailynet for the next six months so that developers could have more time to experiment and find bugs.
Validation Pipelining Project: Faster Work with Blocks
When validating a block, the validator checks the validity of each operation one by one and then applies (executes) them. Validation and application take turns, and there may be several such checks in a single operation. In the end, the validator checks the validity of the final state, recognizes the block as valid, and distributes it over the network.
The process can be made more efficient by separating validation and application of operations. In this case, the validator first checks the validity of all the operations, then it starts to propagate the block, and only then applies all the operations. As a result, we get bigger throughput.
In Kathmandu, only the first part of the project, i.e. separating validation and application operations into different modules, will be implemented. And only for manager operations, which spend fees: transaction, delegation, origination and reveal. In the next protocol update, the developers will adapt the network mempool for the work with modules. Read more in the Nomadic Labs documentation.
Verifiable Delay Function: Randomicity Enhanced
Tezos chooses a baker to create the next block using a protocol similar to RANDAO. Bakers publish random numbers, the protocol hashes them together with the hash of the previous result, and stores the result, i.e. a seed or entropy. At the beginning of each cycle, the network uses the current seed to generate pseudo-random numbers, which determine the lucky bakers.
This method works as long as at least one baker publishes a really random number and doesn’t try to tweak the pseudo-random number generator in their favour.
Kathmandu still uses RANDAO, only the potentially biased seed is used as a challenge for a verifiable delay function (VDF) to generate a really random seed. This solution improves security. Find out more on Tezos Gitlab.
Event Logging for Work With Outside Apps
A new feature for bridges and other applications that have an off-chain part. Event logging will allow contracts to create on-chain messages that can be read quickly by external applications. The event publishing instruction, EMIT, does not call external contracts and saves gas by doing so.
In addition to the EMIT instruction, there are special addresses “ev1…” and several commands for working with event logs. Read more in the Event Logging documentation.
Ghostnet: a Permanent Testnet
Nicholas Ochem and Oxhead Alpha proposed to make a testnet that will be continuously updated to the latest version of the protocol. To do this, the creator of the testnet assigns a special address, which can forcibly update the entire network to the new version. Such a network is called Ghostnet.
Ghostnet is a great innovation for developers who have just switched to Tezos and have not yet understood the principles of naming networks. Many of our hackathon participants published contracts in Hangzhounet, which is no longer supported. In addition, when switching to a new testnet, developers have to get the address and publish their contracts all over again. It’s nice to get rid of this routine.
Subscribe and never miss updates from the world of Tezos:
- Telegram channel
- Twitter in Russian and Ukrainian
- Twitter in English
- YouTube channel
- hub at ForkLog
