Announcing Oxford 2: a revised 15th protocol upgrade proposal

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

After the Oxford protocol upgrade proposal did not gather the required supermajority of affirmative votes in its promotion period vote, we presented an action plan centered around improving staking UX for bakers and furthering the continuous development of Smart Rollups and other features of the Tezos protocol, e.g. Timelocks.

We thank bakers, infrastructure and application developers, and the Tezos ecosystem at large for their feedback, in particular towards the proposed changes in slashing and automated staked funds management for bakers.

Today, we are pleased to announce that this revised Oxford 2 protocol proposal is ready to be submitted to the Tezos governance mechanism. The proposal’s hash is ProxfordYmVfjWnRcgjWH36fW6PArwqykTFzotUxRs6gmTcZDuH.

In a nutshell, the proposed changes in Oxford 2 can be summarized as follows:

• Adaptive Issuance and the new Staking mechanism are disabled: Oxford 2 would not allow the activation of Adaptive Issuance nor extend the Staking mechanism to delegators in its lifetime. The feature vote mechanism inherited from Oxford remains available, but the result of the vote is ignored by the Oxford 2 protocol.
• Refinement of Tezos PoS: the Oxford 2 proposal introduces changes to slashing and an automated auto-staking mechanism for bakers. The latter aims to smooth the transition towards the new staked funds management API and avoids manual bookkeeping to counter over-delegation.
• Timelocks are re-enabled: a new design and implementation of Timelocks addresses security concerns that led to their temporary deactivation in a previous protocol upgrade.
• Smart Rollups keep evolving: Oxford 2 introduces private Smart Rollups, allowing developers to choose between permissionned or permissionless deployments. Oxford 2 also simplifies the deployment of rollups both on protocol and periodic test networks, as well as on ad-hoc dedicated ones.

In the sequel, we provide further detail on the main features of the Oxford 2 protocol upgrade proposal, and highlight key changes with respect to its predecessor, Oxford.

A complete summary of changes is available in Oxford 2’s Changelog.

From Oxford to Oxford 2: Adaptive Issuance and Staking

First and foremost, the Oxford 2 proposal does not enable the activation of Adaptive Issuance, nor allows delegators to become stakers. A disabled feature flag has been introduced, which would prevent these features from activating in the protocol’s lifetime.

The disabled feature flags signal our position that the feature is not yet mature enough to be activated on Tezos Mainnet, and we will continue working together with infrastructure builders to ensure that both the feature and the required ecosystem tooling support are ready soon.

However, the feature activation vote introduced in the original Oxford proposal is still available to bakers: participation is still recorded by the Tezos protocol, but it does not take effect and can never activate the feature. We will reset the associated EMA to 0 in any future protocol proposal developed by us that enables the feature flag.

The rationale behind this choice is twofold: first, bakers can manifest their attitude towards Adaptive Issuance and the new Staking mechanism in an informal manner, which is a useful signal. Second, this is a conservative approach which causes less friction to ongoing efforts to develop and test support for these features.

Automated Staking

The Oxford 2 proposal introduces an automated staking mechanism for bakers aiming to smooth the transition between the current frozen deposits management system in Tezos Mainnet, and the staked funds management mechanism originally proposed in Oxford.

The rationale is that the resulting mechanism should not entail noticeable changes for baker operations. In a nutshell,

• The set_deposit_limit operation is preserved – to enable bakers to continue capping their deposit limit further than the default value of 10% of their staking balance
• The manual staked funds management API implemented in Oxford is disabled, and the protocol automatically adjusts frozen deposits to match the chosen deposit limit at the end of each cycle.

See this design document for further technical details of the proposed mechanism – and don’t hesitate to reach out to us on this Tezos Agora thread with questions or feedback.

Refined slashing

In Oxford 2, there are also a few changes to slashing penalties for double signing – that is, for behaviors that might threaten the safety and liveness of the Tezos ledger. As originally proposed in Oxford, the penalties for double baking are made proportional to the baker’s staking balance. However, Oxford 2 sets the penalty at 5% of the stake, instead of 10% as set in Oxford – or the 640 tez as it is currently the case on Tezos Mainnet.

Oxford 2 also implements changes to how and when slashing penalties are applied by the Tezos economic protocol:

• Slashing penalties take effect at the end of a blockchain cycle instead of immediately after the inclusion of the corresponding denunciation operation. They are applied after the distribution of the cycle’s attestation rewards and before the computation of new voting and baking rights.
• Balance updates from slashing penalties are published in the block ending the cycle, including burned tez and denunciation rewards.
• Repeated offending bakers (those who got 51% of their stakes slashed over 2 cycles), will be marked as forbidden at the inclusion of the triggering denunciation, immediately preventing them from participating in consensus for the rest of the cycle — when their status would be reassessed using the same criteria.

See Slashing and you: a primer for further detail, including the effect of slashing on frozen deposits. Again, don’t hesitate to give feedback or ask questions on Tezos Agora.

Further reading(s)

Oxford 2 introduces further minor changes that might impact bakers and indexers. They are summarized in this document.

Timelocks are re-enabled

As originally planned for Oxford, the Michelson instructions providing support for cryptographic Timelocks are re-enabled in Oxford 2.

Timelocks were disabled in the Lima protocol upgrade, following the discovery of a security flaw at the application level. This error could plausibly allow an adversary to play two roles at the same time in the Timelock protocol to bypass the security of the system, acquiring the secret. As a result, the attacker would be able to create and post false proofs and unlock the Timelock chest.

The feature has since been redesigned¹, and after thorough testing, including an external audit performed by Inference AG, we are ready to re-activate this feature in the Tezos protocol.

Additionally, the new version of Timelock features new client CLI commands allowing users to create, open, and verify time-locked chests, as well as to execute the pre-computations required for fast chest generation.

Introducing private rollups — and other improvements to Smart Rollups

Oxford 2 introduces a new complementary feature for Smart Rollups: the ability to deploy private rollups. They allow for defining a whitelist of allowed rollup operators, which is maintained by the rollup kernel and enforced by the Tezos protocol.

Note that this new feature does not affect the existing permissionless approach — which will continue to be the default rollup behavior. It is rather a complementary choice for operators, broadening the spectrum of potential adopters of Tezos Layer 2 solutions.

Indeed, this feature was developed in response to requests by potential adopters of Tezos Smart Rollups, whose data privacy needs are incompatible with permissionless fraud proofs, typically where user data cannot be shared openly. By restricting the participation in refutation games to whitelisted operators, private rollups prevent potentially sensitive data from being leaked in the generation of fraud proofs.

We will provide further insights into this new feature in an upcoming blog post.

Oxford 2 also includes several quality-of-life improvements for Smart Rollup developers, inherited from the Oxford proposal:

• The rollup origination operation has been simplified, and no longer requires a so-called_ “origination proof”_ as an argument. This should benefit projects building on top of the Smart Rollups infrastructure stack.
• Similarly to what was already possible for smart contracts, it is now possible to hard-code the origination of Smart Rollups in a chain’s genesis block. This is used, for example, in the deployment of EVM rollups on test networks.
• A new WASM PVM revision is released (2.0.0-r3). It enriches the set of host functions available for querying the durable storage of a Smart Rollup, and introduces new capabilities aimed at integrating with the upcoming Tezos’ DAL. Existing rollups will see their PVM automatically upgrade, and newly originated Smart Rollups will use this version directly.

Looking ahead to 2024

Oxford 2 comes at the end of an exciting year for Tezos:

• Smart Rollups went live on Mainnet when Mumbai activated, a crucial milestone in our roadmap for scalability.
• We demonstrated that Tezos can support – and surpass – the 1M TPS throughput benchmark.
• Mumbai also halved blocktime from 30s to 15s, after the Pipelining project completed its full-revamp of the internal block and (operation) validation logic.
• Nairobi increased overall performance on Tezos Layer 1, reducing gas costs for common operations and enabling faster propagation of consensus operations.
• Data-availability solutions continued their development, with DACs being finalized, and the DAL getting closer and closer to Tezos Mainnet.
• Etherlink, an EVM-compatible rollup, is available on Tezos Ghostnet as it gets ready for Mainnet deployment.

In 2024, we look forward to continuing to work closely with the Tezos community to cement Tezos’ position as a technical leader in the blockchain space. Stay tuned for more updates!