CIP-0081? | Tiered Pricing Protocol

[abailly-iohk]

This CIP introduces a Tiered Pricing mechanism to Cardano network as a solution to manage network congestions.
While related to the Ouroboros Leios proposal, its implementation can happen separately from it.

Here is the rendered CIP.

[L-as]

Please specify what this means precisely.

[L-as]

i.e., don't rely on the EIP

[plazos]

I can add this to the CIP.

Roughly, for every tier, we would measure how ‘full’ the input blocks where over a small time period and compare it to a target threshold T. This is slightly more complicated because input blocks can overlap, but calling S the fraction of the throughput that was actually used, the new price for tier i would be p_i^{t+1} = p_i^{t} * 2^(a(S - T)/T), for a > 0. The higher a is, the more aggressive the update.

[michaelpj]

How is the change account specified? If we're going to do this, is this something we want to allow in other cases too, e.g. this might allow wallets to not need to provide a "change output" if they could instead provide a "change account".

[plazos]

We did not get into such details for this CIP, because our plan was to involve the community with discussing the overarching principles and concepts of the tiered approach design overall. The simplest approach however would be to reimburse users according to their staking key.

[michaelpj]

It feels like most of the specific details are missing from this specification? I don't think it's "detailed enough to allow competing, interoperable implementations." Is this a work-in-progress?

[michaelpj]

it offers users a clear view of the delay expected from each tier

Is this true? Can we guarantee that the expected delays for a tier won't be exceeded under conditions of high congestion?

[plazos]

The expected delays, yes. However, it is possible (e.g. after a sharp and sustained increase in demand) that the realised delays are exceeded or that the transactions never make it on-chain without the user paying a higher fee (or selecting another tier). Unfortunately this is true of any design aiming to satisfy some notion of ease of use from, honest behaviour from SPO's and immunity to user-SPO collusion.

[michaelpj]

This makes it sound like you have a precise formulation of how the tiers work and when they change... could we include that in the CIP? :) It's impossible to know what these simulations are telling us if we don't know what they're doing!

[plazos]

Indeed, we have a precise formulation that was used for the simulations. We were concerned that it contains too many details that would be distracting in the discussion (which we thought it should focus on the merits as well as any potential downsides we haven’t thought about but the community can identify concerning the tiered pricing philosophy).

Since you think it is helpful, I will share that bit of the code, specifically how prices, delays and tier sizes are updated given the past.

[michaelpj]

We were concerned that it contains too many details that would be distracting in the discussion

I think there's a meta-point here. I tend to assume that CIPs are actual, concrete proposals, and should be expected to contain all the details. I certainly agree there's a place for higher-level discussion of ideas, but maybe that's not a CIP? Perhaps @KtorZ has thoughts?

But at any rate, if you're going to do that it's weird to include arguments like this that rest on the specific details without actually saying what they are! This argument that you're better than EIP-1559 rests on the specific proposal (which you're not telling us), and the simulation of it. I just found it very confusing.

[plazos]

I apologise for the confusion, we may have had the wrong impression about the level of detail required for a CIP. I added some pseudocode to show exactly how prices, delays and tiers would be updated under this proposal. This is the same algorithm used in the simulations.

[michaelpj]

What about:

• Realistic multi-agent simulations have been performed on a public testnet that demonstrate the expected behaviour of the pricing system under load?

[michaelpj]

I feel like this should be part of the CIP, it's very hard to assess otherwise.

[plazos]

I added this to the CIP. The algorithm contains details and corner cases which we should discuss, but let's not lose focus of our main point: is having different levels of service for different prices a better alternative than current congestion control solutions?

[michael-liesenfelt]

A governance system may collectively decide to raise the lowest price tier to accumulate more treasury spending power. To protect the end-users it may be wise to limit the lowest price tier to some reasonably small fraction of the minimum UTXO parameter.

[rphair]

@abailly-iohk our agreement at the CIP meeting today is to put this up for review... in the meantime can you please respond to some of the reviews & comments above so we have the basis for a well rounded review? 🙏

[abailly-iohk]

@abailly-iohk our agreement at the CIP meeting today is to put this up for review... in the meantime can you please respond to some of the reviews & comments above so we have the basis for a well rounded review? 🙏

I pinged @plazos who is the original author, and we'll make sure to address your comments.

[KtorZ]

Suggested change

	CIP: ????
	CIP: 81

[SebastienGllmt]

I think one of the biggest challenges that doesn't seem to be mentioned this CIP is how to implement this without hurting determinism.

Notably, in Cardano now (before this CIP), when executing a Plutus script you specify a fee for the script execution. The way Cardano is designed, if you transaction passes phase 1 validation, then the fee for the script should be deterministic and so you should never run out of gas in the real world.

However, if you have a dynamic fee, it's possible that a transaction was created when the fee was low, then the transaction runs on chain when the fee is higher, causing it to run out of gas in a phase-2 validation

Tiered fees could be a way around this issue if you define a tier as having a fixed price and if the tier disappears when the price changes, as it would allow the phase 1 validation to detect this tx was generated for a tier that no longer exists and fail-fast. However, figuring out the exact specifics of how that would work is I feel the main challenge a fee system CIP has to solve

[michaelpj]

I don't think that could even possibly happen given how things are designed. Transactions state budgets for their scripts, and the scripts are run assuming those budgets. A dynamically changing fee could make it so that a transaction can't afford it's budgets, but that would be a phase 1 failure (transaction doesn't balance).

Even more than that, there's already a fee field in transactions, so the transaction already can't fail to balance. So I assume how this would actually pan out is either:

1. The fee is too low, in which case your transaction is quickly rejected.
2. The fee is too high, in which case you just overpay.

I.e. exactly the same as today.

[SebastienGllmt]

Hmm, I think you're right that representing the Plutus redeemers as step&memory like we do now is probably enough to avoid this issue and we can make sure any future protocol changes also work similarly to avoiding any issue in the future

[L-as]

Or highest priority tier is chosen for the fee given automatically?

[michaelpj]

This is essentially why the per-script budgets are there. They act as a firewall between the script-execution part and the rest of transaction validation.

[kevinhammond]

A few quick points/questions. Some of these might arise because I haven't studied the text in enough detail? Some comparison with standard queuing solutions would be helpful. I'd expect it to be a fairly common problem for distributed systems.

1. It may be necessary to have a low-delay but low-priced tier to allow prioritisation of certain kinds of transactions (eg system-level ones). This is a fairly common requirement. The proposal mentions different types of block, but doesn't say how these are distinguished - that mechanism might work for this purpose?

2. Separating this - what are the different types of block/transaction that need to be separated and what are their properties? This will help drive the requirements. I think some of Michael's comments might be related to this - concretisation would help.

3. The proposed mechanism seems to suggest increasing tiers in a uniform way (specific gaps between the tiers) - it's not obvious to me that this is the most effective approach - you might want very low cost tiers with potentially long delays, for example, so I'd expect non-uniform gaps to be more useful. It would be useful to model these alternatives against real/potential traffic pattens.

4. The way the delay mechanism worked wasn't completely clear to me - generally, we can't guarantee specific delays (even long ones!) - you might get reasonable certainty if you know all the in-flight transactions, but there will still be some variations. This might be because I haven't read the proposal clearly enough, but is the idea that some delay is always imposed (which might lead to periods when the chain is unused), that there is a maximum guaranteed delay for each tier (which could not be promised in general), or something else?

5. Picking up on this - as defined, is it necessary to reserve some chain slots for each tier? That would lead to inefficient utilisation if the demand was low, of course. Basically, the equivalent of leaving first class seats unoccupied even if passengers are standing in second class.

6. Are you expecting the delay to be eg linked with the timeout mechanism so that transactions have some window during which they will definitely be enacted (i.e. this transaction happens no sooner than X and no later than Y) - again, hard to achieve with real confidence.

7. The speed of change may be an issue - you want the system to react sufficiently quickly to be effective as a throttling mechanism (also so that people can't block the chain with junk), but slowly enough to be predictable. One problem, though is that you can't predict transaction arrival reliably - you can only observe the current chain load and the local transaction queue [mempool], and perhaps historic usage patterns

I need to check through the pseudocode. Generally, I'd prefer a more declarative specification if that was possible - it can be hard to know how a system will behave if you need to work through timing/state concerns. I'd prefer to see something that said "under these conditions, the system will behave in the following way" - that would also make it easier to verify an implementation