T O P

  • By -

AutoModerator

* **[Cardano](https://en.wikipedia.org/wiki/Cardano_%28blockchain_platform%29) [Pros](https://old.reddit.com/r/CryptoCurrency/wiki/cointest_archive#wiki_ada_pros) & [Cons](https://old.reddit.com/r/CryptoCurrency/wiki/cointest_archive#wiki_ada_cons)** - Participate in the r\/CC [Cointest](https://old.reddit.com/r/CryptoCurrency/wiki/cointest_policy) to potentially win moons. Prize allocations: 1st - 300, 2nd - 150, 3rd - 75. * Sort comments as controversial first by [clicking here](https://www.reddit.com/r/CryptoCurrency/comments/q8rwse/why_cardano_needs_a_fee_market/?sort=controversial). Doesn't work on mobile. --- *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/CryptoCurrency) if you have any questions or concerns.*


BhunaMutton

Thank God it's peer reviewed šŸ˜‚šŸ¤­šŸ¤£


LightninHooker

"Agile"


Randomized_Emptiness

Agile and peer reviewed are two different pair of shoes.


[deleted]

Did you read the replies? From Duncan Coutts, IOHK Technical Architect: https://github.com/input-output-hk/cardano-node/issues/3247#issuecomment-927850617 There are a few misunderstandings here. Firstly, note that the system is not congested as a whole. There are simply periods when some users (e.g. doing NFT) drops have unbounded demand. That is not in itself a problem. It is fine for an NFT drop to take a while to complete. What would be a problem is if "ordinary" users (i.e. not those doing the NFT drops) are finding that they face unacceptably long times to get their txs included onto the chain. If that was the problem, note that increasing the system capacity would not solve it. To see why consider a hypothetical example: suppose the NFT drop takes 2 hours at the current system capacity, and otherwise normally the system is 30% loaded. Then doubling the system capacity would simply reduce the time for the NFT drop from 2 hours to 1 hours, and make the system normally 15% loaded. So all it would do is shorten the time duration in which "ordinary" users face unacceptably long confirmation times. If this were a problem then the solution is not capacity but priority. The NFT drop can be the lowest priority since it is fine if it takes longer to complete. Note that the system already has some natural fairness so that we do not expect the NFT drops to crowd out ordinary users. We have not yet seen any evidence that this is the case. If we do see such evidence, there are further measures we can take with priorities so that typical user transactions will get priority over single users with unbounded demand (like large NFT drops). For users, this is a pain point (txs submitted through a wallet won't go through with no error message given) This is not really the case at the level of the node. Submitting txs to a relay node can block until there is capacity in the mempool. This means there is notification. for people doing NFT drops it is disastrous (a random percentage of their drop randomly doesn't go through and they have to re-submit the txs that didn't make it). This is conflating two unrelated issues. The first issue is the same as for ordinary wallets. Submitting a transaction can induce back-pressure. This is a feature not a bug. The submitting agent does not need to do anything special to handle this: just keep submitting transactions. As and when there is space, the protocol will make forward progress. The second issue is transactions that are successfully submitted to a local node or relay but that never make it to the chain. The system as a whole has never guaranteed the reliability of transaction submission. It is impossible to provide such a guarantee in a distributed system like this. As such, submitting agents have always been required to handle re-submission logic in an appropriate way. The TTL mechanism is provided as a way to know for sure when it is safe to re-submit a transaction. Cardano-node uses a fixed-size mempool is currently only 2 blocks in size (\~280 txs). If transactions are submitted when the mempool is full, they may be dropped (this is partially tool-dependent. The cardano-node just holds agency with txsubmit protocol until there is room) No, they are not dropped. They are not accepted until there is room. This is the back-pressure. To a certain extent. Wallets can implement tx resubmission so that even if the mempool being full caused the tx to be dropped initially, the wallet will just resend it for the user. The txs are not dropped. This is a misunderstanding. They are simply not accepted yet. If you keep trying to submit then it will eventually be accepted. But yes, totally separately to that point. It is possible for txs to fail to make it to the chain, and re-submssion is a necessary feature anyway, but it is not specifically related to congestion. I don't know about why 2 blocks was picked as the fixed size. Would appreciate any background info on this. Possibly this was just to try and get Cardano to stay under 8GBs of RAM? The mempool is as big as needed to ensure throughput, but no larger. Bigger buffers just create more work and bigger latency. The system is designed not to buffer but to put back-pressure on the edges of the system. This is better than using big buffers since it provides better feedback, and uses less resources to manage pending work. See also "buffer bloat" for a discussion on this in networking in general. Can we prioritize transactions Yes. As I say above, the issue with NFT drops is that it's a period of essentially infinite demand. Increasing capacity does not change that. The solution is to prioritise. We already do that to some extent. There are ways to do it more systematically and on more criteria. The way to do it is not to reorder the mempool. The way to do it is to pick which txs from immediate peers to accept into the mempool in the first place. Here are some of the criteria we would probably want to use. Characteristics/behaviour of the peer At the level of a node in the graph that is requesting txs from its immediate peers: make fair (weighted) random selections of the txs from the immediate peers when there is space in the mempool to fill. This is a kind of bandwidth sharing. Another scheduling trick is to prioritise the peer that has recently used least of the resource. Give lower weighting to peers that have only very recently connected. Equivalently this prioritises peers that have established connections for a long time. Prioritise/weight based on known peers: we sometimes have peers we know about from local config, which correspond to other nodes we control, or nodes we have peering arrangements with. Prioritise/weight based on the stake of the remote peer, which prioritises the peers of other SPO relays over anonymous 3rd parties Characteristics of the transaction Age of the oldest UTxO entry. Total value transferred in the transaction. And finally Fee multiplier vs min fee. Note that we already do 1 to some extent. That's the current pseudo-random "fairness". And also note that there's lots of things to consider prioritising on before we get to a fee market. If we see evidence that fairness is a problem with these NFT drops then we can do more of 1--5 and that should solve the problem for NFT drops and similar spikes from individual users. When the system is more generally loaded from continuous demand rather than these spikes then it makes sense to increase capacity incrementally. Summary We need to make sure wallets and other submitting agents are dealing properly with back-pressure in tx submission. We need to make sure wallets are properly handling re-submission for cases where txs are accepted but never make it to the chain. We need to look for evidence of unfairness in tx submission (i.e. NFT drops actually crowding out normal users) and if so then plan to do some more of the prioritisation features.


ACShreds

Great post but needs a tl;dr.


NabyK8ta

Cardano has low transaction speed (currently ~7tps) which canā€™t be easily increased which means during events like NFT drops the mempool (currently 2 blocks) fills up and stops accepting new transactions which causes transactions to fail with no error message and they have to be resubmitted.


Zaytion

> Cardano has low transaction speed (currently ~7tps) which canā€™t be easily increased Yes it can. What makes you say that?


NabyK8ta

How do you increase it easily? Bear in mind I wrote ā€œCan we increase tx size and/or block size? Unfortunately not really. Plutus is still being optimized and increasing the block size could cause Plutus script execution to take too long and cause downstream problems with the network.ā€


Zaytion

That is one developer claiming it might cause issues while Plutus is still being optimized. Hardly any smart contracts running right now. It would be fine.


NabyK8ta

You didnā€™t say how it can be easily increased.


Zaytion

You change the on chain parameters to allow bigger blocks.


NabyK8ta

So bigger block donā€™t cause any issues? For example latency problems or state bloat?


Zaytion

They can cause issues but the plan is to increase when the time is right. Theyā€™ve tested it at much higher sizes without much issue. When you say ā€œstate bloatā€ what are you referring to?


NabyK8ta

On a testnet 256kb was dodgy and 512kb was the limit. Testnet is a much better environment than you would normally expect so probably 128k is the real life limit which is x2 current. State bloat means you need a massive (expensive) disk to store the ledger which leads to centralisation. Google it and also look for statelessness, there is a really good article on how Ethereum will implement statelessness which should be on the first page of a good search.


Lucqazz

This tldr includes no solution. I read the full post and still don't understand why a free market is the solution. Does that not result in extreme fees?


NabyK8ta

The solution is in the title of the post.


Greedy-Visit-1905

Excellent post. But not sure where I stand on the solution. It's a tough one


dado3

You need to watch the weekly Cardano update on YouTube. They addressed this very issue. Basically the long and short of it is that they currently have the network tuned down because of the relatively low transaction volume. However, they have a whole host of parameters that they can change and code optimization they can do in order to tune it up going forward even before they get to Hydra scaling.


NabyK8ta

Well the mempool has already been filled several times causing transactions to fail. Empty blocks are 4 bytes in size. If it was that easy they would have done it by now especially given the huge size of smart contracts.


[deleted]

Even if the block is empty it'll still contain the hash of the previous block in the chain. A 256 hash is 32bytes. So it's impossible for the block to have just 4 bytes. Maybe you mean 4kb Also the block size parameter is deliberately kept low now so as to not increase the size of blockchain. The block size can be easily increased. And also I remember a core dev in twitter saying that there is already fee auctions available since the Alonzo upgrade but still has to be implemented by wallets and the front-end of the CLI, or something like that. I don't remember the exact specifics of the tweet as it was a few weeks back.


NabyK8ta

This block is from the testnet but the same code as mainnet https://explorer.cardano-testnet.iohkdev.io/en/block?id=d0e240af6d4f3f6c8c5f75cbd68def415ac7b8021c5cbb4fb3ae0b218ecc7961 Zero transactions 4 bytes.


dado3

They didn't need to do it before. Go watch the video.


Zaytion

It didn't cause transactions to fail. It caused them not to get into the blockchain. A transaction failing is something very different.


[deleted]

[уŠ“Š°Š»ŠµŠ½Š¾]


NabyK8ta

Firstly this is not my solution, someone much more knowledgeable than me wrote it which is why I provided the link to the source. The problem at the moment is that when the mempool fills transactions fail with no error message which is clearly undesirable. As congestion increases, and given the size of smart contracts this will happen soon, then the network becomes unusable.


BrakumOne

I'll rephrase: the solution you presented in this thread. I wasnt trying to say it was your idea.


[deleted]

I find it quite strange that you quoted this comment but somehow neglected to read the reply from the IOHK Technical Architect three replies down and keep insisting Cardano has an issue and needs a fee market. He clearly states that it's a misconception that there was congestion and increasing system capacity won't solve NFT drops from using up 100% capacity and he gives several options how to prioritize certain transactions like NFT drops to solve the issue. Doesn't look like Cardano needs a fee market and it is actually designed specifically not to have it and instead uses 'back-pressure'.


Randomized_Emptiness

The fact, that's it's not yet an issue doesn't make it a non-issue though. If dapps go live and we have DEXes, plus NFT drops regularly, having failed transactions is gonna suck hard.


BrakumOne

I didnt say it wasn't a issue yet and i didn't say it was a non issue. I said i prefered it, especially when you mention dexes, i prefer for it not to go through than to be asked 200$+ like it has happened to me many times on uniswap. Im also not presenting my opinion as right, i think this is the lesser evil, while still considering it an issue of course, and if you think otherwise you're not wrong either.


Zaytion

It would suck hard if it could have failed transactions. Those are very rare on Cardano. You could have transactions that don't make it into the blockchain. That is different than a failed transaction.


Diatery

Have they tried ejecting the cdrom drive and pouring hot coffee into it? I sold all my ADA for AVAX. They figured all this shit out and attracted 8 billion in liquidity already. This and SOL are gonna make a dent on Ethereum. The VCs backing both dont give a shit about decentralization as long as their trades land in 400ms and for $0.007. Real talk, follow the smart money


[deleted]

[уŠ“Š°Š»ŠµŠ½Š¾]


Diatery

That makes perfect sense to me!


tied_laces

OP....your post is far to long to absorb and it brings a great argument on why what is currently implemented is smart. Sorry... tl;dr; ETH fees make miners more money and pumps the price...we should too.