Dear everyone,
The Parameter Committee wants to thank PCP 002 - utxoCostPerByte author ShawnMcMurdo (@shawnim) for his parameter change proposal and hereby states its official recommendation and rationale as communicated to and approved by the PC members in the tri-weekly meeting on the 1st of February.
PCP 002 Rationale.pdf (182.7 KB)
Recommendation and Summary:
The recommendation of the committee is not to change utxoCostPerByte at this time.
The role of this parameter is to reflect the cost of storage of the UTxO in nodes participating in the Cardano protocol. The parameterâs intended operation is, by associating an Ada cost to UTxO size, to reduce Ada liquidity as the overall UTxO size increases. The expectation is that such a reduction of liquid Ada would raise the overall Ada value, thus compensating SPOs for their additional storage costs through the fees that are earned in block production.
The UTxO (and other associated state) is currently stored in RAM, which is acquired in specific amounts. In cloud environments it is common for the next memory threshold to be twice the RAM at approximately twice the cost.
There is ongoing work to refactor the storage of UTxO (and other associated state) so that it is stored on solid state disk. Once deployed, this will substantially change the incremental storage costs, at which time it is appropriate to revisit the utxoCostPerByte parameter values.
Inputs to the Rationale from the PCP
- âDesired outputâ
- âA specified value, or range of values, for utxoCostPerByte that enables more applications on Cardano while maintaining sufficient security and efficiency with justifications and evidence.â
No investigation towards which value (range) is optimal has been made due to the deferral to a point where sufficient experience with solid state disk UTxO storage is available.
- âPCP Questionsâ
- At what point does the size of the UTxO set become problematic for SPOs? What about wallets and other applications?
The undesired outcome is to have substantial UTxO growth that requires all nodes to increase the RAM associated with their nodes several times without an associated increase in Ada value
When UTxO on disk is available we expect that wallets and other applications would make use of it. There will remain the option to store UTxO in RAM which is likely to be more suitable for those nodes involved in block production and relaying.
- Is there a point where network congestion becomes an issue?
The issue of UTxO growth is driven by the nature of transactions - do they consume as much UTxO space as they create or do they require a net increase in UTxO size?
The issue is more around the transaction mix than the overall transaction load.
- At what point do blockchain bloat attacks become feasible or likely?
utxoCostPerByteâs value is related to the arming of the hazard of SPOs having to incur substantial uncovered costs.
There are so many potential factors that would require specific quantification, including whether actors are non-myopic etc, that any attempt at a quantified answer would be pure speculation.
Note: It is unlikely that the committee would make a quantified response to questions relating to the arming of attack vectors.
- How much reduction is necessary to enable or expand the various types of applications listed above?
Since no investigation towards a specific value (range) has occurred, this question is deferred.
PCP Result Rationale
Technical and Networking considerations
The vast majority (if not all) of the parameters ensuring Cardanoâs operations primarily serve to mitigate risks, whether ensuring long-term economic stability or deterring adversarial actions by imposing costs or time requirements for potential and inherent threats to âget armedâ well enough to materialise. These measures aim to safeguard against this arming of risks, fostering a secure and resilient network environment.
One of those measures is associated with storing UTxOs within the system, which are collectively borne by all nodes. Clearly, there are inherent costs associated with storing, and those storage costs, whether in ROM or RAM, do not exhibit a linearly projectable relationship with scale, but are rather characterised by being:
- threshold-based, necessitating a sufficient quantity to accommodate the collective data set, and,
- quantized, requiring fixed increments to add upon reaching storage thresholds.
UTxO data is currently stored in RAM across all nodes, imposing a significant demand on the allocated memory needed for node operations. The threshold nature of RAM plays a pivotal role in managing this demand. It is important to acknowledge that not all SPOs or other participants in the Cardano ecosystem utilize cloud-based resources; some opt for alternative hardware setups, such as running their own virtual machines or dedicated hardware. Regardless, the increase in memory usage presents a trade-off for all users, either requiring more memory allocation to their VM, which may limit other operations, or necessitating hardware upgrades or migration to larger memory cloud instances, both of which incur additional costs.
In certain cloud computing instances, it may be possible to incrementally allocate additional disk space; however, this approach is typically limited to slower storage options. While such storage suffices for logging and historical data storage, it fails to meet the real-time access demands crucial for UTxO operations.
The time-critical nature of UTxO storage access stems from its role in representing the current state of the chain, reflecting the cumulative history. Low-latency access is essential for validating transactions in transit towards potential block producers and for verifying new blocks. Delays in block validation can impact the overall network diffusion budget, designed to meet security requirements within the consensus mechanism. While transaction validation is not directly part of the diffusion budget, it consumes CPU resources, particularly for block producers and relays as part of forwarding blocks. Thus competition arises for resources like CPU, memory, and disk access, incurring competitive costs on the way.
In addition to, and likely even more relevant than, time criticality, the risks associated with unchecked UTxO growth is the correlated need for a substantial increase in memory requirements across all Cardano instances, potentially leading to adverse consequences.
Apart from impacting standalone wallet users who may face operational constraints, the sudden spike in costs could prompt many marginal participants to disengage from active involvement in block production or the Cardano network at large.
It is worth noting that the issue of UTxO growth was anticipated during the initial design phase of Cardano. The decision to store UTxO in RAM was driven by the need for expedited time-to-market considerations, while recognizing the complexity of the issue. Efforts to address this challenge include the ongoing development of an âon-diskâ UTxO version with reduced RAM requirements, currently in the testing phase.
Given those ongoing development efforts, there is a strong incentive to avoid changes that could trigger a sudden surge in UTxO size or UTxO storage behaviour.
Economic considerations
The Parameter Committee asked the question of âWhat if there was a surge, driven by external factors in todayâs environmentâ?
An approximate, âupper boundâ quantification, assuming:
Large UTxO transactions with maxTxSize = 16kB
RAM growth = 1.5 times UTxO growth (1.5 is an âupper bound engineering judgementâ)
Current max rate of RAM growth: 1.5 * 16kB * 4 (tx per block) * 3 (blocks per min) * 60 * 24) = 414 MB per day
utxoCostPerByte = 0.004310 ADA
It would require 1.79m ada (16000 * 4 * 3 * 60 * 24 * 1.5 * 0.004310) to be expended, to be tied up in UTxOs daily. When extrapolated to an epoch this represents around 9m ada per epoch - for comparison, recent epochs are taking, around 150k ada per epoch in fees.
A lower value of utxoCostPerByte, say, as suggested by the PCP author, of 431 (adjusted from his original 400 for a simpler 10:1 ratio in this approximation) would result, with the same maximum daily growth, in 180â000 ada or around 900k ada per epoch to be tied up.
Replacing that ada requires fiat and tied up ada reduce liquidity, an increase in ADAUSD, should be observed, which, in turn, would increase real world cost (and revenue). When assuming that, as projected, lowering utxoCostPerByte would be coupled or the cause of a surge in UTxO size/growth, the increase in fiat value of ada by tying up substantial ada - arguably dampens ârampantâ growth and would go a long way to mitigating the non-monetary damage potential of causing upgrades of to the infrastructure.
This relation couples utxoCostPerByte to the price of ada, at which point the question arises whether there is evidence that the current value is indeed pricing Dapps out and whether the potentially generated value of lowering doesnât outweigh the costs of the network.
Further observations
Lastly, there are secondary effects of reducing utxoCostPerByte in relation to the overall fees per transaction which need separate analysis before any action is taken, given minFeeB would then make up to 20% of the transaction value, which would make all mentioned use cases financially inconvenient.
Conclusion
All expert groups of the parameter committee are in general agreement that utxoCostPerByte needs to come down, but given the developments of on-disk UTxOs and the relation between network costs, ada fiat price and projected value, it would be more beneficial to lower it when ADA reaches higher prices and on-disk UTxO is ready for production, both of which are anticipatable in the near future.