From Jakarta to Kathmandu non-stop

This is a joint post from Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda, Functori & Tweag.

The Tezos community is preparing for exciting new developments in the coming days: the activation of the Jakarta protocol upgrade will be the first step towards massive scalability, with the introduction of the first Tezos Layer 2 solution: Transaction Optimistic Rollups, or TORUs.

Today we look a bit further ahead. However beautiful and lively a port Jakarta is, the Tezos protocol’s path to scalability doesn’t stop there. After mending our sails and reloading our batteries, we are eager to present to the community what’s next in our pipeline. We hope you brought your mountain gear with you – next stop is Kathmandu.

In this article we give you a preview of the different projects that have kept us busy in the last months. We will describe the features which, after some stabilization in the coming weeks, are likely to be part of Kathmandu, Tezos’ 11th protocol upgrade proposal. But, first we will focus on Smart Contract Optimistic RollUps (aka SCORUs), our next Layer 2 scalability solution, and how big new features like this one require us to rethink the development process for protocol upgrades.

SCORUs are rolling into testsnets

As we hinted in an earlier scalability preview, SCORUs provide a generic infrastructure to implement any computational device, as long as its semantics can be described as a Proof-producing Virtual Machine (PVM), in the Tezos protocol.

This design allows us to continuously develop and deploy new supported PVMs, and thereby new execution environments, via protocol amendments. In our upcoming protocol proposal, we plan to introduce a first PVM supporting WebAssembly (WASM) — although only available via bleeding-edge test networks.

WebAssembly-based rollups come with a native token bridge based on Tickets, similar to the one used for TORUs, and with a bare-bones execution environment supporting token exchanges between Layer 1 and Layer 2, gas monitoring, and self-governance. On top of this infrastructure, users can write custom rollup kernels, ranging from application-specific rollups to full-scale “parachains”.

Finally, a proof-of-concept rollup kernel will be also provided with the proposal: a token exchange with BLS signature verification. We aim to integrate this with the in-development Data Availability Layer to demonstrate scaling up to higher throughput values.

Start building with SCORUs on Mondaynet

Starting with the Kathmandu protocol proposal, we want to take a new approach to the protocol development process. Taking in feedback from the recent protocol proposal periods, Kathmandu marks a move towards a “continuous development” process that reduces friction and enables ecosystem developers to build support for new features incrementally in close collaboration with the core protocol developers.

We observe that the current development rhythm does not always provide sufficient time for infrastructure and application developers to embrace and support the new protocol features, including experimenting with them on test networks.

We are therefore changing the process of integrating major new features into Tezos protocol proposals so as to:

• make sure that together with ecosystems builders, we can provide end-to-end support for new features of the Tezos protocol;
• enable the community to provide valuable feedback to protocol developers before features are locked by the governance process;
• increase the chance of discovering bugs before proposals are injected and avoiding re-injections and protocol overrides.

The SCORU core business logic and the Wasm PVM are in a mature enough state for the community to start developing and testing applications and infrastructure on testnets. But, given the new approach outlined above, we want to provide the community with extra time to develop and test infrastructure and Layer 2 applications. As a result, SCORUs will not be enabled on Tezos Mainnet by the Kathmandu protocol proposal.

Given that the “Kathmandunet” test network is meant to mirror the protocol proposal subject to on-chain governance, it will not be spawned with support for SCORUs enabled either. Instead, we encourage the community to start building and testing support for SCORUs on the bleeding edge Mondaynet and Dailynet testnets.

What’s coming in Kathmandu

In the following, we focus on the features we are confident will be enabled in the upcoming Kathmandu protocol proposal.

First steps towards pipelined block validation

The validation Pipelining project aims to streamline the block validation process, in order to reduce the number of times they need to be applied (that is, executed) across the Tezos Layer 1 network. It also aims to propagate blocks before fully applying them, but after having fastly validated a set of preconditions on the block and its operation payload which guarantees their correctness. These goals combine to pursue increasing throughput for Tezos’ Layer 1, without compromising the network’s safety.

The Kathmandu protocol proposal will implement first steps in this direction by focusing on disentangling validation and application for manager operations¹ inside the Tezos protocol. That is, we separate the business logic of addressing the question of whether an operation can be safely included in a block, from its actual inclusion in a block.

The second part of the project is planned for future protocol proposals, and it will consist of integrating the remaining parts necessary for a complete pipelined validation of blocks and operations to be fully operational inside the Tezos protocol.

Improved randomness using Verifiable Delay Functions

All Tezos protocols versions so far — including Jakarta — rely on a simple RANDAO-like scheme to generate a random seed at each cycle, which in turn feeds a Pseudo-Random Number Generator (PRNG). Sound randomness is paramount for enabling the Tezos protocol to fairly decide the attribution of consensus rights, which ultimately affect participation rewards.

In order to strengthen the Tezos protocol’s distributed randomness generation mechanism, we propose integrating Verifiable Delay Functions (VDFs). These are novel cryptographic primitives that allow a verifier to quickly assert that a value was computed as a result of an expensive computation. Appending a VDF phase after our current RANDAO scheme adds an extra layer of security to the protocol’s random seeds.

Event logging in Tezos smart contracts

The Kathmandu protocol proposal will provide support for Tezos smart contracts to cheaply emit on-chain events via statically typed event data attachments. This new feature will enable DApp developers to send publicly visible on-chain messages in order to trigger effects in off-chain applications. For instance, events can be notifications of changes in contract states, be it explicit or implicit. We aim to provide a uniform interface with existing token transfer facilities to allow event logging without origination of any extra contracts.

Further details on the motivation behind this feature can be found in Contract event logging.

Support for permanent test networks

The Kathmandu protocol proposal will also include a new testnet-specific governance mechanism necessary to support a permanent test network, Ghostnet.

For any chain other than Tezos Mainnet, this mechanism lets the chain originator designate a special account, that can upgrade the protocol unilaterally with a new protocol proposal. Instead of going through the normal governance election cycles, the chain will upgrade straight away to the new protocol. This will allow for the creation of a long-running testnet, Ghostnet, where protocol upgrades will be centrally managed by Oxhead Alpha and which will closely follow Tezos mainnet upgrades.

Further details are available in the TZIP advocating for this feature. The implementation is a contribution of G.-B. Fefe, a community member not affiliated with the core developing teams behind this protocol proposal.

Looking ahead

The contents of the Kathmandu proposal will be finalized shortly, after the last stages of stabilization are completed. As customary with recent proposals, a dedicated test network Kathmandunet will be spawned shortly after the protocol is announced. Moreover, and as we mentioned above, we invite the community to start testing the upcoming SCORU functionality in the Mondaynet test network, and we will provide more details shortly.

We set out to make 2022 a year of ground-breaking advances in the Tezos technology stack, and we believe Kathmandu follows naturally the path set out with Ithaca and Jakarta protocol upgrades. We look forward to sharing these new exciting features with you all!