This is a joint post from Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda, Functori & Tweag.
Update: A revised prootocol proposal, Jakarta 2, has been released. Jakarta 2 adresses two critical bugs in the implementation of Transaction Optimistic Rollups.
We were proud to see Ithaca 2 go live on April 1st. In keeping with our policy of proposing upgrades on a regularly scheduled basis, we are happy to announce our latest Tezos protocol proposal, Jakarta.
Jakarta’s “true name” is its hash,
PtJakartaiDz69SfDDLXJSiuZqTSeSKRDbKVZC8MNzJnvRjvnGw.
The Jakarta protocol proposal contains major updates to the Tezos economic protocol, as well as numerous minor improvements. In this article, we preview its most relevant features. A more thorough description can be read in the protocol proposal’s technical documentation entry, and a complete list of changes is provided in its changelog.
Transaction optimistic rollups
We are pleased to announce that Transaction Optimistic Rollups (or TORUs) have found their way into this protocol proposal, as a first and experimental implementation of optimistic rollups on Tezos. As the name implies, TORUs allow for exchanges of assets, but not execution of smart contracts.
Optimistic rollups enable higher throughput (TPS) by moving the validation of transactions away from the main chain, to ‘Layer 2’. They are called optimistic, because they work on the assumption that this validation is correct until explicitly proven otherwise. One consequence of this approach is longer finality when withdrawing from the rollup, currently set to 40,000 blocks (about 2 weeks).
Optimistic rollups have a number of desirable properties:
- Trust minimized: You don’t have to trust that a majority of the rollup nodes are honest to always be able to withdraw your funds from the rollup. One honest node is enough.
- Permissionless: Anyone can submit operations to a rollup since all the rollup block data is posted on the main chain.
- Capital efficient: Unlike with state channels (e.g., Lightning Network), rollup users are not required to lock up a bond upfront. Only rollup node providers are.
With our proposal, Tezos rollups will not be implemented as smart contracts (like, e.g., Arbitrum on Ethereum), but rather natively in the economic protocol — making them enshrined rollups. Leveraging Tezos’ unique self-amendment feature this way allows us to implement more efficient, expressive, and scalable solutions.
For a broader understanding of optimistic rollups, and the rationale behind them, we recommend checking out our blog post outlining a scaling strategy for Tezos.
Note that TORUs should be considered an experimental feature, and they are introduced with a sunset of 1 year. This sunset can be extended, or removed altogether, in future proposals, depending on community adoption.
A safer Sapling integration
We recently reported a design flaw of the existing integration of Sapling transactions into Michelson smart contracts, which makes unshielding tez from certain smart contracts vulnerable to manipulation.
The Jakarta protocol addresses this situation by implementing a new, safer design.
Jakarta also deprecates the previous format of the Michelson integration for Sapling transactions, and if Jakarta is adopted, it will only be possible to originate Sapling smart contracts which conform to the new version.
Further details on the vulnerability and the new integration design can be found here.
Liquidity Baking toggle vote
The Liquidity Baking Escape Hatch mechanism has been redesigned and renamed to the “Liquidity Baking Toggle Vote”.
The options are now “On”, to vote for the Liquidity Baking subsidy being turned on, and “Off”, to vote for the subsidy to be turned off, and a new “Pass” option to abstain.
Another change is that if the threshold for deactivation is reached, the deactivation of the subsidy is no longer permanent. If the proportion of bakers voting “On” later increases back over the threshold, the subsidy can be restarted.
More information can be found in the feature’s TZIP.
Note that the future Tezos Octez v13 baking daemon for Jakarta,
tezos-baker-013-PtJakart, will impose the use of a mandatory
command-line flag --liquidity-baking-toggle-vote to set up the
delegate’s default Liquidity Baking toggle vote preference, and will
also provide an optional --votefile flag intended to be used to
declare the path for a JSON file encoding the delegate’s toggle
vote. When provided, the latter file takes precedence over the former
mandatory flag.
Michelson interpreter improvements
We have implemented various improvements to type safety and performance of the Michelson interpreter. The majority of these changes do not impact the semantics of Michelson other than decreasing gas costs for parsing and unparsing scripts.
The single semantic change is ignoring annotations. With Jakarta, annotations are only used by the type-checker and the interpreter to identify smart contract entry-points. Additional annotations still remain valid but they no longer carry any semantic meaning.
Moreover, the protocol proposal upgrades a few smart contracts which relied on legacy features which are no longer available since the Babylon protocol upgrade. They are now compliant with the modern Michelson specification. The list of patched contracts, the patches themselves, and a detailed description of the process can be found at the merge request.
Tickets hardening
Tickets provide a first-class notion of ownership in the Tezos Protocol. They can be used to implement fungible as well as non-fungible tokens.
We introduce a mechanism for explicitly tracking ownership of tickets in the protocol. Whenever a ticket is created or its ownership changes — for instance by sending it to a different contract — it is explicitly recorded and validated against a balance table. This extension does not impact the Michelson API.
The feature serves two purposes:
-
Extra protection against attempts to forge tickets
-
Facilitate Layer 2 solutions that use tickets to represent assets that can be exchanged with the main chain (e.g., TORUs)
Rolls are no more
The Jakarta protocol proposal redefines the computation of delegates’ voting power in the self-amendment process. Instead of being measured in terms of rolls, it is now defined directly by delegate’s stake (expressed in mutez). The minimal stake required to be assigned voting rights is kept at 6000 tez.
This change complements those introduced with the Ithaca2 protocol, in order to unify voting and baking power. As result the notion of rolls is no longer relevant, and has been deprecated.
Testing, testing…
A testnet for the Jakarta protocol named Jakartanet will launch in the coming days. It is critical to have as many bakers, tool builders, indexers, wallets, etc. as possible participating in this testnet.
We are looking for more bootstrap bakers to participate from day
one. If you are interested, please join the Tezos baking
slack and reach out in the
#test-networks channel.
Furthermore, we strongly encourage you to test your own Tezos-based applications for compatibility problems with Jakarta. Jakarta, and the configuration for its test network Jakartanet, will be included in version 13 of Octez.
Should the Jakarta protocol proposal be accepted by the community, v13 of Octez or v3 of TezEdge will be necessary to participate in consensus due to necessary changes introduced to the protocol environment.
Over the coming months, our teams will continue to work on increasing performance, lowering gas consumption, reducing block times, and increasing the overall throughput — as measured, for example, in transactions per seconds or smart contract invocations per second. We are excited to be part of this continued development of Tezos.