Announcing Tezos’ 9th protocol upgrade proposal “Ithaca”

Research and Development
1

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.

7 Likes
2

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.

9 Likes
3

Obviously, I join the boycott. It is a matter of principles that they inject competing proposals. Some integrity as core devs please.

And the worst of it, is that when USDC comes to tezos ecosystem, they won’t give us a competing proposal without tzBTC, the only proposal to choose will be USDC sharing the subsidy with tzBTC.

So hard to defund a gang once it is established. Public money attracts the worst and corrupts the best.

3 Likes
4

PosDog,
the largest public baker, will join the boycott,
unless a no-LB proposal is also available.

8 Likes
5

Kryptstar will also be abstaining. We would accept a liquidity baking program for a project that is more involved in the community. At this point TZBTC just seems like a useless tax, preferably a decentralized projects where all countries can participate freely. Also, the elusive Tenderbake being thrown in with a 10 month liquidity baking contract, seems a bit like a honeypot.

No liquidity baking is fine as well.

5 Likes
6

TezosRus will also be boycotting this vote. We have been against LB from the very beginning and still are

4 Likes
7

They want to put a 10-month tax extension inside an awesome tech update, so you can’t say no. Not playing that game, enough is enough.

1 Like
8

Don’t get the negativity here. If you don’t like LB, there is an escape hatch for that. Use it! Ask your baker to use it! Devs don’t need to introduce a non-LB proposal for the community to discontinue it. Boycotting this proposal shoots past your goal to get rid of LB.

Now if you want LB for a different coin than tzBTC, that I understand. Instead of lobbying for another single coin I’d rather like to see a discussion on how we can create a more flexible way to subsidize DeFi in general. A DAO endowed with XTZ on a protocol level that is then responsible to distribute subsidies to different DeFi projects would be a starting point.

edit: Thank you for educating me @Swarles. Now I think the negativity is justified

1 Like
9

basically the hatch is an illusion, you can’t use it because you need either TF or the exchanges to support you
and it’s not about LB only, it’s more about the way that decisions are made and the governance process works.
personally I’m not against LB (nor am I a baker) but I’d love to see the community gets a say in what’s happening and not only ratifies everything the devs proposed.

8 Likes
10

Unfortunately, as this is a very important proposal for Tezos, I tend to agree for the reasons I have stated in this thread.

Andreas: the escape hatch is no substitute for proper governance. It is a relatively complicated procedure that presents high barriers to entry. The proposal’s part to lower the threshold from 50% to 33% in a way acknowledges this. What voting system would approve changes based on a 1/3 minority voting in favour? It is also a red herring: between exchanges and the foundation, more than 1/3 of XTZ is in the hands of actors that respectively will not participate in governance (to their credit) and will not vote against liquidity baking. So the escape hatch 33% threshold still requires effectively more than half of bakers to activate it, which is inconceivable.

The truth is that we now have sufficient data to come to the honest conclusion that liquidity baking in its current implementation has been an abject failure. The idea is sound, and I’m sure we’ll get it at some point (I’m on team USDC, if and when it becomes available). But we should not be flippant about raising inflation by ~ 0.3 percentage points against no discernible benefit.

Lastly, I frankly haven’t liked the dismissive attitude of some leading voices of this community towards the legitimate concerns raised by liquidity baking and the choice of supported asset. Whether you are in favour of liquidity baking or not, all sides should be encouraged to share their views and we should welcome different points of view. An open and fair democratic process includes the ability of naysayers to formally express their disagreement simply and effectively. In this case, that means injecting two proposals: one including liquidity baking and one without it. I’m not even sure which I would like my baker to vote for in that case. But the option should be there. It will create a proper consensus in the community either way.

7 Likes
11

I respect your right to boycott the vote, but if you and other bakers simply choose not to vote then you will only cause quorum to be lowered. Why not just vote Nay?

12

I do think that there should be at least a discussion about the goals and current state of LB.

What are the steps that are underway and planned to rectify the problems?

2 Likes
13

Exactly! communication regarding this would be great. I’m as excited as everyone else for Tenderbake :heart_eyes: :star_struck:

3 Likes
14

This Reddit post was censored, people can’t see it when they scroll down, is totally hidden. Unbelievable that mods always resort to censorship.

2 Likes
15

A possibility would be to inject a different proposal with just the escape hatch changed to 15% or 20%.
This parameter is already being changed so the proposals would be very easy to compare and safe.

2 Likes
16

Advice to proposal devs - not extend LB with each proposal and let instead 33% of bakers signal with “continue” LB hatch to extend the sunset level.

LB lovers will be able to continue LB by doing some hatchflag work, if they don’t want LB to stop (which will happen by default), all satisfied.

Pros:

  1. No need to push LB sunset level extension in each proposal. It either fade of by default or will be continued by 33% of bakers signalling to continue the experiment.
  2. If 33% escape hatch considered easy, 33% continue hatch should be absolutely same, isn’t it?
  3. You will see the real community support of LB instead feeding it as present with must have tech features.
2 Likes
17

Let me put an analogy here for you guys to think about why this economically doesn’t make sense to fund and also why gangs form:

Imagine we want to fund a school with public money…

Is like hiring teachers (LP’s) with public money, for opening a public school (LB), but no students (traders) are attending the school because there is no interest in their educational program (tzBTC), so why keep funding the teachers with public money, if the educational program clearly sucks and no one wants to learn (trade) there? Why not halt the funding of the school, until tzBTC.io improves their educational program? Which could take years.

But since the teachers (LPs) are a gang, pretty much functioning like a syndicate, they will always fight to keep the subsidy, even if that means sacrificing all taxpayers (tezos hodlers) for eternity without delivering results.

How we know that core DEVs are not part of that gang? Or TF? or DLS? Or even some bakers that might also be providing useless liquidity for tzBTC/XTZ pair? Obviously, if they are benefiting from it, they will want to keep the subsidy, even tho there is no benefit for the public good… the only benefit is for them right? LB was supposed to benefit the public good, including all XTZ hodlers who pay that tax, but this is far to be the truth.

1 Like
18

And we have proposed multiple times some kind of regulation to the public money, so it would be harder for a bad actor to take the money.

For example, setting up some kind of logic check so if an asset is not delivering decent volume/burning in 6 months, the subsidy gets cut or reduced.

We can’t just launch a subsidy out in the open without some kind of logic check or milestones steps to get the subsidy, public money needs heavy regulation so we can make it harder for bad actors, so they can’t just take all the money like that. Don’t make it easy for them!

But again, these suggestions have been ignored, and obviously they want to keep it for them regulation free.

1 Like
19

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.

3 Likes
20

I am not against Liquidity Baking, but I certainly understand the anger and frustration of those who are.

@NomadicLabs @Marigold What more must people do to be given a voice in the matter? Why do you continue to disenfranchise those who are against LB?

People who were against LB were told “We thought there was consensus on this feature! You should have been part of the conversation here 6 months ago!” Now it has been 6 months since a number of people have expressed their dislike of LB, and still their desire for a way to vote against it in a meaningful way without delaying other technical upgrades has been ignored.

One of the ways proponents of LB assuaged the concerns of those who dislike LB was to say something along the lines of “it has a natural sunset in 6 months if people don’t like it.” But every subsequent proposal has extended the sunset period and we have not been allowed the choice between extending it or letting it expire naturally.

A really simple solution to the problem is to have a proposal that extends the sunset of LB, and one that allows it to expire. This way the people who have expressed their dissent socially (as you requested they do) can formally dissent on-chain without having to vote against much-desired features such as Tenderbake. Additionally, with these two proposals there is no need for using the escape hatch, which the nomenclature suggests was meant to be used in case of an emergency.

I have voted nay a few times, or voted for other proposals, where the majority have voted differently from me, but the fact that I have been able to vote according to my conscience makes it easier for me to accept an outcome that is different from what I would personally desire.

Please give those who are against LB the same opportunity to feel that they are being heard.

9 Likes