Parameter Signaling

TZIP
1

Request for comments on the TZIP draft for Parameter Signaling.

This proposal describes a mechanism by which bakers can signal to change protocol parameters, independent of and faster than protocol upgrades, by inserting values in block headers. This is similar to how bakers can signal to activate the liquidity baking escape hatch. The hard_gas_limit_per_block is proposed as an initial parameter to change through this mechanism.

11 Likes
2

I think this is a really good proposal.

1 Like
3

I like the idea but would like to emphasize the importance of having parameter boundaries or valid set of values to be bound with the parameter, enforced by the protocol and not be subject to signaling.

5 Likes
4

Would be cool to choose Pass / Decrease / Increase about the liquidity baking subsidy (now 2.5 tez).

5

I think this would address all my concerns with this idea. As long as those bounds have been tested at each possible extreme to prove that it wouldn’t crash the network, this could be a very good idea overall.

Although, the power given to bakers who may have no idea what updating the values would do with this change is still of concern to me.

6

This proposal already includes a hardcoded lower bound set to the hard_gas_limit_per_operation. Decreases short of that won’t break anything.

It’s an increase that could stop the chain, but my argument against including an upper bound on that end is that:

  1. The limit is no easier to change with block signaling than through a protocol amendment. I think one could argue the threshold I proposed would actually be too difficult to reach since I based it on recent promotion periods and dissent tends to present earlier on in the governance process.
  2. We can control how quickly the limit can be raised through the delta and window length, which is the equivalent of setting a maximum change in the amount of time it takes to activate a new protocol.
  3. The limit would increase gradually because the delta is very small. In the case where it’s raised slightly too high you’d expect to see minor performance regressions in nodes that would be a sign to revert the increase. It would take numerous increases of this delta to reach a point where performance could regress to a point where block creation slows enough to stop consensus.

I think this is the real issue and inherent in this proposal. It’s also exactly the opposite of claims made about liquidity baking (except liquidity baking is more about economics than software development, although I would argue bakers on average understand the effects of gas usage on node performance much more so than they understand economics).

Ironically, as I’m a full-time protocol developer, I’m in favor of developers holding as little of a privileged role in protocol changes as possible. One of the lessons I’ve learned from working on Tezos is how high a barrier it is for users to make a very simple change to an existing protocol (e.g. a one-liner or reverting git commits), snapshot, and hash it and how this ends up centralizing protocol development efforts. Ideally concerned parties would be able to hire people with this baseline level of technical knowledge so protocol expertise and skin in the game are more aligned. But I think arguments that developer expertise is an additional security measure against unsafe protocol changes on top of the design of governance processes are ultimately the same as arguments against on-chain governance entirely like those made in the Ethereum community.

7

The TZIP name suggests it’s a generic TZIP to specify how parameters can be set, but it turns out to be specifically about gas parameters. This is potentially confusing.

The mechanism provided seems to have extra steps whose purpose is not clear: why vote on whether to increase the gas limit by some amount as opposed to voting directly on the amount? It’s quite possible to set the gas limit at, say, the 20% lowest percentile of signals.

The mechanism doesn’t seem safe absent clear bounds on the parameters.

The tzip lacks a discussion of the issue with signaling for gas increases, which is that the slowest x% of machines may progressively drop out of the network, which can recursively lead to a situation when only the fastest machines run baking nodes.

8

So if 80% of participating bakers want an increase and 20% want to decrease it all the way to the lower bound, it would be decreased to the lower bound? Sure, minority rule is not catastrophic if it’s on the conservative side, but this doesn’t seem ideal to me. Unless I’m misunderstanding this, a percentile with no sort of smoothing allows it to be set at a value all but one baker maximally disagrees with.

I do discuss not signaling arbitrary values to some degree at the end of section on the rationale for the delta. This would also require something like a participation threshold rather than just not including pass signals like in the symmetric escape hatch.

Good point. This is also a risk when changing it through a protocol amendment, but seems more insidious when compounded between small window lengths.