CIP-0081? | Tiered Pricing Protocol #381
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,125 @@ | ||
| --- | ||
| CIP: ???? | ||
| Title: Dealing with traffic congestion by implementing Tiered Pricing | ||
| Status: Draft | ||
| Category: Fees | ||
| Authors: | ||
| - Giorgos Panagiotakos <[email protected]> | ||
| - Philip Lazos <[email protected]> | ||
| Implementors: N/A | ||
| Discussions: | ||
| - https://github.com/cardano-foundation/cips/pulls/1 | ||
| Created: 2022-11-17 | ||
| License: CC-BY-4.0 | ||
| --- | ||
|
|
||
| # Dealing with traffic congestion by implementing Tiered Pricing | ||
|
|
||
| ## Abstract <!-- A short (~200 word) description of the technical issue being addressed and the proposed solution --> | ||
| As Cardano adoption widens the system is bound to face traffic congestion. During such a situation the system should have predictable behavior, handling gracefully the unavoidable delays users are going to experience. Tiered Pricing deals with this issue by offering users a number of service options to select from when the system is under congestion. Each possible choice consists of a price/delay trade-off, covering a wide spectrum of use-cases. The exact mechanism is described as an extension of the recently introduced [Ouroboros Leios](https://iohk.io/en/research/library/papers/ouroboros-leios-design-goals-and-concepts/) proposal. | ||
|
|
||
|
|
||
| ## Motivation <!-- A clear and short explanation introducing the reason behind a proposal. When changing an established design, it must outlines issues in the design that motivates a rework. --> | ||
|
|
||
| Fees in the current system are fixed and transactions are included in blocks in a FIFO order. | ||
| Unfortunately such an approach is ill-suited to handle traffic congestion, as it does not provide any means for users to signify their urgency and accommodate them based on their needs. Throughput scaling solutions, e.g., Ouroboros Leios, may only temporarily solve the problem, until peak traffic grows larger than the available throughput. Traffic congestion is also a possible attack vector that malicious actors may try to exploit to increase the average delay of the system at a moderate cost. Thus, Cardano needs a better way to handle traffic congestion. | ||
|
|
||
| Ideally, we would like the system to offer a multitude of options, and have users decide the price/delay trafe-off that suits them. These options should change dynamically to reflect current traffic levels. We would like to have a mechanism that informs users of the current congestion status, and takes into account their preferences in prioritizing transactions. | ||
|
|
||
|
|
||
| ## Specification <!-- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations. --> | ||
|
There was a problem hiding this comment. 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? There was a problem hiding this comment. 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 There was a problem hiding this comment. 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:
I.e. exactly the same as today. There was a problem hiding this comment. 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 There was a problem hiding this comment. Or highest priority tier is chosen for the fee given automatically? There was a problem hiding this comment. 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. |
||
|
|
||
| ### Tiered Pricing | ||
| Tiered pricing works by dynamically separating the available throughput into multiple tiers that offer different price/delay trade-offs. Users are given the choice of selecting which tier better accommodates their needs. | ||
|
|
||
| In more detail, the price and delay associated with each tier as well as the number and size of different tiers are determined dynamically based on the demand observed in the ledger; the fuller the space allocated to a certain tier looks, the higher the demand. When the system is not congested, a single high speed/low price/small size tier remains available, with the system optimizing its resource use and behaving more or less as having fixed low fees and no extra delays. On the other hand, when congestion is detected, tier parameters are selected in such a way that a multitude of price/delay options become available to users. | ||
|
|
||
| More specifically, tiers are introduced and modified to achieve at minimum a target ratio between consecutive prices and delays; moving from tier `i` to tier `i+1` both the price must be substantially lower and the delay higher than that of the previous tier. The first tier is always available and its delay is set to the minimum level. | ||
| Additional tiers are introduced, if the demand on the last (slowest) tier increases, i.e., its price becomes high enough. Similarly, if the demand of the last tier falls below a certain level, the tier gets deleted and other tiers are resized accordingly, to avoid leaving the allocated space unused. | ||
|
|
||
| The price of each tier is updated in similar fashion to [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md), disregarding other tier prices. | ||
|
There was a problem hiding this comment. Please specify what this means precisely. There was a problem hiding this comment. 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. |
||
| On the other hand, delays are updated much less frequently than prices and depend on them. In particular, delays observe the average prices between each update and adjust up or down in small steps accordingly, to ensure that prices of consequent tiers are separated enough. Finally, tier additions and deletions happen even less frequently. | ||
|
|
||
| Transactions are allowed to specify higher fees than those determined by the tier selected. In the end, they are only going to pay the actual tier price, and get back the change as a reward at the end of the epoch. The reward mechanism should be adjusted accordingly. | ||
|
There was a problem hiding this comment. 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". There was a problem hiding this comment. 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. |
||
|
|
||
|
|
||
| ### Integration with Ouroboros Leios | ||
| Tiered pricing naturally integrates with Ouroboros Leios by assigning to each input block (IB) a single tier type, and restricting its contents to only transactions of this type. The VRF output used to determine whether an SPO is eligible to create a new IB is also used to determine its tier type. The rate at which IBs of a certain type are produced is determined by the tier's size. | ||
|
|
||
| Demand for different tiers is tracked by observing the level of fullness of the IBs that were recently added to the main chain in a large enough interval. As specified earlier, tier parameters are adjusted based on the observed demand. IBs are expected to uphold the relevant parameters derived by the ranking block (RB) they reference, otherwise they are deemed invalid. | ||
|
|
||
| IBs are prioritized for inclusion in the main chain based on their respective tier delay; IBs are only allowed to be included in an endorsement block (EB), and subsequently to the main chain, after time proportional to their tier delay has passed. | ||
|
|
||
|
|
||
|
|
||
|
|
||
| ## Rationale <!-- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. When applicable, it must also explain how the proposal affects backward-compatibility of existing solutions. --> | ||
|
|
||
| The key idea of this proposal is that the fee system should be able to target multiple use cases at once, whenever this is possible. This is done through the use of tiers with varying delays and cannot be achieved by different prices alone. If a tier offers a specific quality of service, its price cannot be reduced to capture every user, because costs can be misreported and off-chain agreements can override the prescribed transaction order. By ensuring that the delay of every tier must be waited out, each tier is only useful to certain users, resulting in lower prices. | ||
|
|
||
|
|
||
| ### Are we departing from a low-cost system? | ||
| While this proposal departs from the low fixed fees approach for the reasons explained earlier, by appropriately setting the relevant parameters it can be guaranteed that a relatively low-cost service option will always be available to users. | ||
| This option may come with a high expected delay when the system is congested. Note, that this is also the case in the current system. Moreover, tiered pricing improves in that it offers users a clear view of the delay expected from each tier, compared to the current system where the expected delay can only be estimated by off-chain channels. | ||
|
There was a problem hiding this comment.
Is this true? Can we guarantee that the expected delays for a tier won't be exceeded under conditions of high congestion? There was a problem hiding this comment. 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. |
||
|
|
||
|
|
||
|
|
||
| ### Why not EIP-1559? | ||
| While our approach bares similarities to that of EIP-1559 regarding the way prices are updated, our design is a lot more diverse in that it allows different types of use-cases to be served by the system in a satisfactory manner. We highlight this point further through simulation. | ||
|
There was a problem hiding this comment. 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! There was a problem hiding this comment. 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. There was a problem hiding this comment.
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. There was a problem hiding this comment. 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. |
||
|
|
||
| In the following figures we present the evolution of the price, delay and size of each tier of a simplified blockchain with three tiers of equal size. The demand starts low, then changes to 3 clusters with different levels of urgency, then uniform urgency and finally becomes lower than the available throughput. During the low-demand periods, only tier 1 is available and its price and delay are minimal. Moreover, the size of tier 1 periodically fluctuates, in an effort to detect increased traffic. Next, in the 3 cluster period, all 3 tiers become available as the system detects increased traffic. Note, that the delays of Tiers 2 and 3 increase to maintain the price invariant; here the price of subsequent tiers must be at least half of the previous ones. Finally, during the uniform urgency segment, the delays of Tiers 2 and 3 again adjust to maintain the price invariant, as the price of Tier 1 decreases. | ||
|
|
||
|
|
||
| <p float="left"> | ||
| <img src="https://github.com/abailly-iohk/CIPs/blob/tiered-pricing-protocol/CIP-XXXX/blob/image2.png" alt="Tiered pricing - prices" width="33%"> | ||
| <img src="https://github.com/abailly-iohk/CIPs/blob/tiered-pricing-protocol/CIP-XXXX/blob/image4.png" alt="Tiered pricing - delays" width="33%"> | ||
| <img src="https://github.com/abailly-iohk/CIPs/blob/tiered-pricing-protocol/CIP-XXXX/blob/image1.png" alt="Tiered pricing - sizes" width="33%"> | ||
| </p> | ||
|
|
||
|
|
||
| In the last figure we show how the Ethereum transaction fee mechanism would have fared against the same traffic. Notice that in periods of low demand the results are similar, while during high congestion the Ethereum price is slightly lower than our Tier 1 price. However, Ethereum is priced in such a way that only transactions with the highest value can make it through. In our proposal, the increased delays of different tiers could make them unattractive for certain applications (such as DeFi), reducing their prices and allowing a more diverse set of users to participate. | ||
|
|
||
|
|
||
| <p float="left"> | ||
| <img src="https://github.com/abailly-iohk/CIPs/blob/tiered-pricing-protocol/CIP-XXXX/blob/image3.png" alt="Ethereum - prices" width="33%"> | ||
| </p> | ||
|
|
||
|
|
||
| <!-- | ||
|  | ||
|  | ||
|  | ||
|  | ||
| --> | ||
|
|
||
| ### Fee overshooting | ||
| Allowing users to allocate more funds than the observed tier price for fee payment serves as a way of reducing the risk of price fluctuations. This comes without additional costs to users, as change will come back to them in the form of reward at the end of the epoch. | ||
|
|
||
| ### Tracking demand | ||
| Tracking demand is necessary to properly adjust prices (and consequently delays and tiers). Given that malicious parties may try to artificially inflate or deflate prices by creating IBs that do not reflect the actual demand, we take advantage of the fact that IBs are created at a high rate, and make use of a “large” enough sample from which we can robustly deduce the actual demand for each tier. | ||
|
|
||
| ### IB-Tier correspondence | ||
| Assigning a single tier type to each IB at a random and verifiable way through the VRF mechanism, is an efficient way of avoiding meddling of malicious actors in the tier selection process. It also easily allows us to regulate the expected rate at which IBs of a certain tier type are produced by adjusting the relevant target threshold. | ||
|
|
||
| ## Path to Active | ||
|
|
||
| ### Acceptance Criteria <!-- Describes what are the acceptance criteria whereby a proposal becomes 'Active' --> | ||
|
|
||
| * Tiered Pricing is available on Cardano mainnet | ||
|
There was a problem hiding this comment. What about:
|
||
|
|
||
| ### Implementation Plan <!-- A plan to meet those criteria. Or `N/A` if not applicable. --> | ||
|
|
||
| While Tiered Pricing will have a deeper impact when deployed on top of Ouroboros Leios, due to the high level of throughput that can be directed to different use-cases, Cardano running Ouroboros Praos could still benefit from it during high congestion periods. A Tiered Pricing implementation should thus be as much as possible agnostic of the actual protocol run. | ||
|
|
||
| Should this CIP be accepted, the high-level implementation plan would be: | ||
| 1. Publish a detailed pricing algorithm | ||
|
There was a problem hiding this comment. I feel like this should be part of the CIP, it's very hard to assess otherwise. There was a problem hiding this comment. 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? |
||
| **NOTE**: This includes fees calculation and distribution | ||
| 2. Prototype executable implementation suitable for running simulations and formal analysis | ||
| 3. Simulate the impact of Tiered Pricing on Cardano. This simulation should be able to demonstrate how this proposal impacts the distribution of fees under various conditions of the system, possibly using historical data | ||
| 4. Implement and deploy on top of Ouroboros Praos (or whatever version of consensus is current on Cardano at that time) | ||
| **NOTE**: From this point on, the proposal will be _Active_ | ||
| 5. Adapt as part of Ouroboros Leios deployment | ||
|
|
||
| ## Copyright | ||
|
|
||
| This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.