From Jakarta to Kathmandu non-stop: What to expect in the 'K' proposal

While the Jakarta upgrade nears activation, developer teams at Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda, Functori and Tweag have been busy preparing the next step :technologist:

Introducing the the 11th protocol Tezos upgrade proposal: ‘Kathmandu’ :mountain_snow:

This proposal is expected to include the following features:

:game_die: Improved randomness for distribution of baking rights
:bell: Event-logging, enabling off-chain systems to react to smart contract execution
:package: Validation pipelining:ongoing block validation tweaks to improve Tezos Layer 1 throughput
:scientist: Support for ‘Ghostnet’, a permanent testnet that upgrades with Mainnet

The next step in the scaling strategy, Smart Contract Optimistic Rollups (SCORUs), will not be activated for Mainnet in this proposal, but will be available on ‘Mondaynet’ and ‘Dailynet’ testnets. This is part of a new approach to protocol development meant to ensure better coordination with ecosystem builders around major feature releases.

A blog post with a more in-depth introduction to SCORUs is coming soon!


Will the “The validation Pipelining project” affect block times?

Hey @NomadicLabs the reduction of blocktime to 20s was first in J and then postponed to K and now again postponed. I am sure that you have very valid reasons to do so but I think many people are curious about the “why” because this in fact would be a big UX improvement! Would be cool to give insights in this matter here or as an article… what the plans are in regards to blocktime on L1 etc.


Hey @NomadicLabs, can you please respond to @Britcoin and myself?

1 Like

Sorry about that :frowning:

1 Like

Quoting a response to a similar question:

Reducing block time is a priority, but we want to be confident that we can do this safely on Mainnet. We have ongoing projects, both on the Tezos protocol side – like the validation pipelining work that has (partly) been rolled with Kathmandu – and other ongoing work on the Octez node, which target to reduce block validation and propagation time. These are a prerequisite to reducing block time safely, otherwise we risk having cascading effects with higher congestion and slower blocks.

1 Like

@noodlestomatojuice the pipelined validation project is a pipelined project in itself, whose target is to make validation of blocks and operation more lightweight, in order to reduce the validation and propagation time. This does not reduce the block-time on Tezos Layer 1 at the moment but, as mentioned in our reply above, it is an absolute requirement for being able to do so safely.