Ithaca (PsiThaCaT)

DEPRECATED
Ithaca proposal did not pass, and core developer teams are planning to offer a different proposal to inject for Ithaca going forward. Read more here: Proposal plans

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

We were proud to see Hangzhou go live on chain on December 4th, 2021. In keeping with our policy of proposing upgrades on a regularly scheduled basis, we’re happy to announce our latest Tezos protocol proposal, Ithaca.

(As is usual, Ithaca’s “true name” is its hash, which is PsiThaCaT47Zboaw71QWScM8sXeMM7bbQFncK9FLqYc6EKdpjVP).

Ithaca contains two major updates to the protocol, as well as numerous minor improvements. Below we discuss some of the most interesting and important changes.

Tenderbake

Tenderbake is a major update to the Tezos consensus algorithm. Like Tendermint, Tenderbake brings fast deterministic finality to the Tezos protocol.

Tenderbake comes with a set of important changes:

  1. The protocol moves away from a roll-based model to an optimized stake-based model to allocate rewards: bakers will receive rewards depending on their current stake instead of the number of rolls they own.
  2. A reduction in the minimal number of tokens required to be selected as a validator would be implemented: from 8,000 tez to 6,000 tez. This minimal stake of 6,000 tez remains necessary for performance reasons.
  3. The baking and endorsement rewards mechanism has been reworked (c.f. rewards documentation). In particular, baking rewards will be credited instantaneously, and not frozen for 5 cycles as is the case with Emmy*. Furthermore, there will no longer be a variance for endorsement rewards. The total sum of endorsement rewards for a cycle will be fully distributed at the end of the same cycle, provided delegates have at least 2/3 of their endorsement slots included in blocks.
  4. A new security deposit mechanism is introduced: delegates are required to freeze, at minimum, 10% of their stake in advance in order to obtain baking and endorsement rights. A new operation Set_deposit_limit is also introduced to manually manage this limit.
  5. The number of endorsement slots per block has been bumped from 256 to 7,000: this means that a delegate with the minimum amount of tokens will participate every 10 blocks on average. The node’s storage layer and prevalidator have been optimized to handle the charge, with the precheck feature also contributing to the increase in performance. The number of endorsement operations, which will continue to endorse multiple slots, will be proportional to the number of validators in the network, i.e. around 500.
  6. Since Tenderbake is modeled after classical BFT consensus algorithms, it favors safety over liveness and requires active participation of validators holding 2/3 of the stake in order for the chain to progress.

This consensus algorithm also offers the possibility to easily reduce the minimal time between blocks, which may be proposed in future Tezos protocol amendments.

Precheck of operations

The new version of the protocol will enable the prechecking of operations. This is not a feature of the Ithaca protocol proposal per se, but it rather consists of a new set of functions which are exposed by the economic protocol, and which can be used by any Tezos shell (e.g., Octez and TezEdge) to avoid fully executing manager operations before gossiping them through the network.

The feature serves mainly one purpose: increasing the number of operations gossiped over the Tezos network. It is a prequel to further optimizations that should increase the transaction throughput over the Tezos network.

Liquidity Baking

Ithaca includes an increase to the liquidity baking sunset level of 819,200
blocks, or twenty voting periods, roughly an additional ten months.
This bigger increase will avoid needing to worry about the sunset level for the next few protocol amendments.
Also, to balance this increase, the threshold for activating the escape hatch is lowered from 50% to 33%.


We invite you to look at the changelog for a full description of the contents of the proposal.

Ithaca is the biggest update to Tezos to date, and testing is critical. A testnet for Ithaca protocol named Ithacanet will launch in the coming days. It is critical to have as many bakers as possible participating in this testnet, by running nodes, producing blocks and deploying apps. We are looking for more bootstrap bakers to participate from day one. If you are interested, please join the baking slack and make yourselves known in the test-networks channel.

Furthermore, we strongly encourage you to test your own Tezos-based applications to check for compatibility problems with Ithaca. Ithaca, and the configuration for its test network Ithacanet, will be included in the version 12 of Octez.

Should the Ithaca protocol proposal be accepted by the community, the following minimal version of Tezos node (shell) software will be necessary to participate in the consensus, due to necessary changes introduced to the protocol environment: v12 of Octez, or v2 of TezEdge.

If Ithaca is adopted, the next proposal (which likely will have a name starting with the letter “J”) should be proposed and enter the Tezos amendment process next year.

Over the course of the coming months, our teams also intend to continue to develop and propose amendments to increase performance, lower gas consumption, reduce block times, and increase the overall Tezos network’s throughput – as measured, for example, in transactions per seconds, or smart contract invocations per second. We are all excited to continue developing the future of Tezos.

1 Like

CALL TO BAKERS TO BOYCOTT PROPOSAL ITHACA.

This new proposal by Nomadic Labs et al seeks to extend Liquidity Baking (tzBTC) by 10 months. Despite knowing that a large portion of bakers (approx 15% have activated the escape hatch) and the community are against it, they have NOT introduced a non-LB choice for us to vote on.

Such behavior actively works against the governance process as there is no reason the core-devs should be gate-keeping what is essentially a economic on-chain proposal that should be decided by the community. It is trivial for the core-devs to introduce a competing proposal for us to inject and the fact that they do not is very telling about their intentions and disrespect to the community. Sure, the community can inject our own proposal but there will always be some who question the fitness of the code, asking if it is audited by the core devs. The debate should be on whether LB shall be extended, not fitness of code.

Bakers, whether or not you agree with extending LB, you should agree that the community should have a voice and have a say in the vote. I call upon you to boycott this vote - the effect will be that the proposal does not reach the required quorum and give Nomadic Labs and the other core devs a black eye. They must learn that the community governs Tezos and must be listened to and hopefully they will propose competing proposals once this one fails.

Further discussion can be found here: Announcing Tezos’ 9th protocol upgrade proposal “Ithaca”

Some numbers for everyone on whether 33% is a reasonable percentage to require.

In the last vote (Promotion for PTHangzhou), we saw 67.14% participation. However, 47% of those who actually participated had voted for pass (some for legal or other reasons) which means they either cannot vote or don’t even care about the proposal much.

This means that the % of bakers who actually voted (yes, no) is 35.59% of the total baking population. In essence, asking for 33% to flag an escape is asking for almost 100% participation of those who care to vote and can vote.

1 Like

Id rather Call Bakers to build and fund their own Dev Teams to make Counter-proposals.

This is the way.

3 Likes

Agree, who is going to build the treasury for that?

Wouldn’t be a solution as well, that everything was funded privately, even LB?