This is a joint post from Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda, Functori & Tweag.
We were proud to see Jakarta go live on June 28th, 2022. In keeping with our policy of proposing upgrades on a regular schedule, we’re happy to announce our next Tezos protocol proposal, Kathmandu. As usual, Kathmandu’s true name is its hash, which is
The main features are:
- Smart contract optimistic rollups enabled on bleeding edge testnets
- Pipelined validation of manager operations (ongoing)
- Improved randomness with integration of Verifiable Delay Functions
- Support for tailored governance for permanent testnets (
- Event logging in Michelson smart contracts
- New operation for increasing paid storage of a smart contract
For more details, see our Kathmandu preview post. A deeper technical description can be found in the protocol proposal’s technical documentation, and a complete list of changes is provided in the changelog.
As always, we encourage the community to participate in Tezos testnets, which is of great help in the protocol development process. There are different options:
We are happy to see Beacon and Taquito having already added support for
Kathmandunet. It is critical to have as many bakers and builders as possible participating in this testnet, by running nodes, producing blocks and deploying apps and infrastructure.
Nomadic Labs will publish a release candidate for a new Octez suite version,
v14.0~rc1, within a few days. It will include the daemon binaries that enable participation in the
Kathmandunet test network.
Should the Kathmandu protocol proposal be accepted by the community, v14 of Octez (or later) will be required to participate in consensus due to necessary changes introduced to the protocol environment.
The smart contract optimistic rollups core business logic and Wasm PVM are in a mature enough state for the community to start developing and testing applications and infrastructure on testnets.
As mentioned in our Kathmandu preview post, smart contract rollups will not be enabled on Tezos mainnet by the Kathmandu protocol proposal. This is to give the community extra time to develop and test infrastructure and Layer 2 applications.
Kathmandunet is meant to mirror the current protocol proposal, it will not have support for smart contract rollups enabled. Instead, we encourage the community to start building and testing on the bleeding edge
Ghostnet is live! It’s a permanent testnet that follows Mainnet upgrades, meaning dApp developers will no longer have to redeploy to a new testnet after each upgrade. It was activated with a User Activated Upgrade (Ithacanet -> Jakarta), and another UAU will be necessary to migrate to Kathamandu. After that, further evolution of
Ghostnet will happen via a new upgrade mechanism managed by Oxhead Alpha.
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. For this work, an invoice of 3000 XTZ is included in the proposal.
We are interested in the communty’s input on the optimal date for testing migration of
Ghostnet to the next Mainnet protocol. The migration from Ithaca to Jakarta was performed a few hours before Mainnet activation. For Kathmandu, we are considering to do
Ghostnet migration 72 hours prior to Mainnet activation, should the proposal be adopted.
However, we would like to empirically figure out the best time (during the Adoption period) to perform the migration. The community’s participation in the test network and feedback will be most welcome in this process.