PCP_utxoCostPerByte_ShawnMcMurdo

This proposal aims to enable more applications on Cardano by reducing the utxoCostPerByte parameter.
I propose lowering utxoCostPerByte from 4310 to 400.
For reference, there was an earlier discussion related to this topic at: Reduce Min UTxO

I could not figure out how to get the PCP template doc to show up correctly in this post so I have attached a PDF.

PCP_utxoCostPerByte_ShawnMcMurdo.pdf (135.6 KB)

2 Likes

For anyone who does not want to open the PDF, here is the unformatted text.

PCP-002 Reduce utxoCostPerByte

Description

This proposal aims to enable more applications on Cardano by reducing the utxoCostPerByte parameter.
I propose lowering utxoCostPerByte from 4310 to 400.
For reference, there was an earlier discussion related to this topic at: Reduce Min UTxO

What is utxoCostPerByte?

The utxoCostPerByte parameter establishes the minimum amount of ADA required per Unspent Transaction Output (UTxO). The parameter is specified as an amount of Lovelace per byte in the UTxO. The current value of utxoCostPerByte is 4310 Lovelace. This gives an approximate minimum of 1.5 ADA per UTxO for transaction outputs containing native tokens.

Why do we need utxoCostPerByte?

The use of this minimum amount of ADA per UTxO ensures that the blockchain remains efficient by preventing the creation of large numbers of extremely small UTxOs that could lead to excessive data storage and processing requirements. It also incentivizes compact and efficient data storage.

What are the pros and cons of lowering utxoCostPerByte?

Lowering the utxoCostPerByte parameter can have both pros and cons. The impact of such a change depends on the specific context, use cases, and the overall goals of Cardano. Here are some potential advantages and disadvantages:

Pros:

Increased Flexibility: Lowering the utxoCostPerByte allows for more flexibility in creating UTxOs with smaller values. This can be advantageous for microtransactions and use cases where smaller denominations of ADA are needed.

Improved Accessibility: It can make the Cardano network more accessible to a wider range of users, particularly those in regions with lower economic resources, by enabling them to transact with smaller amounts of ADA.

Enhanced Token Functionality: Lowering the utxoCostPerByte can also facilitate the creation and management of custom tokens and assets on the Cardano blockchain. It allows for greater granularity in defining token values.

Encouraging Adoption: Smaller UTxOs can encourage broader adoption by making it easier for people to experiment with and use Cardano.

Cons:

Blockchain Bloat: A potentially significant drawback of lowering the utxoCostPerByte is that it could lead to blockchain bloat. Smaller UTxOs result in more data being stored on the blockchain, which can increase the overall size of the blockchain. This may require more storage resources and can slow down network synchronization.

Increased Storage Costs: Lowering utxoCostPerByte can lead to higher storage costs for network participants who run Cardano nodes. Storing and maintaining a larger blockchain can be expensive, which may discourage some users from participating in the network.

Network Congestion: If utxoCostPerByte is set too low, it could result in an increased number of transactions and UTxOs, potentially causing network congestion and slower transaction processing times.

In summary, lowering the utxoCostPerByte can have several benefits, such as increased flexibility and accessibility. However, it also carries significant challenges, such as the risk of blockchain bloat and higher storage costs. Any decision regarding lowering utxoCostPerByte should consider the trade-offs and align with Cardano’s overall goals. It is important to strike a balance between accessibility and network efficiency.

What kinds of applications can be enabled by lowering utxoCostPerByte?

Lowering these costs can open the door to a wide range of applications by making it more affordable and accessible for users to interact with the blockchain. Reduced costs can be particularly advantageous in various use cases, including:

Microtransactions: Lower transaction costs enable microtransactions, where users can transfer very small amounts of ADA. This is valuable in applications like content monetization, pay-per-use services, and tipping content creators.

Tokenization: Reduced costs make it more feasible to create and transfer tokens. This eases the way for various tokenized assets, including real estate, art, stocks, and other financial instruments.

Supply Chain Management: Supply chain applications can benefit from lower costs when tracking goods and verifying their origin or authenticity. This is especially relevant in industries like agriculture, pharmaceuticals, and luxury goods.

Decentralized Finance (DeFi): In the DeFi sector, lower costs can encourage more users to participate in lending, borrowing, yield farming, and trading. This can lead to increased liquidity and adoption.

Gaming: Blockchain gaming can benefit from lower costs, increasing the ability to trade in-game assets and currency. Gamers can have true ownership of their assets, and developers can create play-to-earn games.

Digital Identity: Implementing digital identity solutions on the blockchain can become more cost-effective. Users can have greater control over their personal data and selectively share it with trusted parties.

Social Networks: Cardano based social networks could reward content creators and users with cryptocurrency for their contributions. Lower costs make this reward system economically viable.

Internet of Things (IoT): Devices in the IoT ecosystem can interact with the blockchain for data verification and value exchange. Lower costs can make this practical for various IoT applications.

Charitable Giving: Donations and philanthropic efforts can benefit from reduced costs, ensuring that a higher percentage of donated funds goes to the intended recipients.

Voting Systems: Secure and transparent blockchain-based voting systems can be more accessible, enabling secure and tamper-resistant digital voting. In the era of Voltaire, it is crucial to ensure affordable access to voting on Cardano.

Smart Contracts: Lower costs can drive the adoption of smart contracts in various industries, including legal, insurance, and real estate.

Decentralized Autonomous Organizations (DAOs): DAOs can benefit from lower transaction costs by making it affordable for members to participate in decision-making and governance processes.

Overall, lowering transaction related costs by lowering utxoCostPerByte expands the potential applications of Cardano, making it more accessible for a broader range of use cases and encouraging innovation. However, it is important to strike a balance between low costs and network security and scalability to ensure that Cardano remains reliable and efficient.

Questions

At what point does the size of the UTxO set become problematic for SPOs? What about wallets and other applications?
Is there a point where network congestion becomes an issue?
At what point do blockchain bloat attacks become feasible or likely?
How much reduction is necessary to enable or expand the various types of applications listed above?

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.

1 Like

I would be interested to see some additional rationale for why 400 Lovelace was chosen including graphs of projected impact this could potentially have (i.e. what does max utxo state look like?) prior to endorsing or really providing more thoughtful feedback. I agree that we can probably stand to decrease the minUTxO at this point as, iirc, the intent of the original setting was to “cap” the ledger state at approximately 45B discrete UTxO. Obviously this is already impossible due to the presence (and higher minUTxO) of Native Assets on the ledger which introduce their own storage impact.

5 Likes

there is probably no specific point over time from which it becomes problematic. Rather there are specific values such as the currently valid or a reduced utxoCostPerByte, and then more or less activities, implementations and behaviors that leads to an (extended) increase of the UTXO set (or not). This all currently has to be loaded and held in a node’s RAM. There is already a workstream to store this entire UTXO set on hard disk. This would provide much more leeway on this point. Nevertheless, it is important to consider whether a significantly inflated UTXO set does not bring further challenges with it, for example the calculation of the rewards per epoch.

Not directly, but indirectly it could lead to larger transactions and thus space requirements in the blocks, once the UTXO set has become very large, and it then often needs several inputs to feed a transaction.

It depends on several factors: the price of Ada, and the specific goal the attacker wants to achieve. It has already existed on other blockchains with obviously insufficient cost barriers. So it is not a purely theoretical threat.

2 Likes

The first question the parameter commit will likely ask is: What evidence is there that the current parameter value has prevented groups, companies, individuals from building the apps, dapps, or tools they want?

Given we have over 8m native assets on Cardano, the current cost doesn’t seem to be that big of a hurdle.

It does make sense to review this parameter and set a more “thoughtful” level. The current value is an artifact of the early days when minUtxo was hardcoded to 1 ada. Once this parameter was introduced, it was set to a level so minUtxo would be very close, but still under 1 ada. That way, people who had built code using the hardcoded values could continue to work.

As long as this parameter is moved to a lower value, there is no risk to any app/dapp still using the 1 ada hardcoded value. The only risks I see are network security-related which you’ve also already outlined in your PCP. I look forward to discussing this proposal with the rest of the parameter committee.

Can you give a rationale of why you’ve chosen to suggest the value of 400?

4 Likes

Homework problem for the team:

Using {the total bytes added to the ledger, the total reserves distributed, and total fees} during the previous year calculate a new utxoCostPerByte if the reserve distributions drop to 0 (rho=0).

4 Likes

Thanks for taking the time to put this PCP together.

From a financial PoV we need to take in account that if “micro payments” is the main rationale of this proposal, we need to think that we are trying to optimise for transfers where the tx fees might make up 40% or more of the value of the transferred amount.
Simply put a donation of 20 cents of ada, should cost at least 15 cents of ada. Similar for native assets.

Despite that, I think that, especially with the hope of ada price going up, it might make sense to periodically review utxoCostPerByte.

Most of the questions I wanted to ask have anyway been already asked.

An additional question for me would be: you’re suggesting a 90% drop in value for this parameter, this feels quite excessive. I think it’s a good practice to gradually update parameters, observe the impact and take further actions.

Under these circumstances, what would be, if any, an intermediate value of the utxoCostPerByte param that could make sense as a first step?

Thanks

1 Like

The parameter committee is currently reviewing this proposal. We’ve received initial feedback from economic sub-committee and are awaiting feedback from other sub committees before forming a formal recommendation. We will provide a further update in the coming weeks.

Thanks,

Sam

Thanks for the update Sam!
As for the question of why I chose 400. It was to get the cost of sending an NFT, FTs, or small payments down to about the same as a transaction fee.
This would allow people to send something worth $1 for a cost of about $0.20 instead of the current $0.70.
Choosing a value for the parameter in between the current and my suggested value needs to be low enough that the use cases are actually enabled.
Otherwise, there is no way to evaluate the success of the change.
Thanks for considering the proposal!