Clarification on MinFeeRefScriptCostPerByte
Quantumplation opened this issue · 4 comments
Hello!
Can we get some clarification on the final value for MinFeeRefScriptCostPerByte? If there is not yet a final value for this parameter, can we get clarification on how that final value will be decided?
I believe the current value of 44 was arrived at "by default" because that is the cost per byte of a transaction, and I can understand that seeming like a reasonable starting point.
However, this value is a very steep cost as an initial value for DeFi applications, sometimes doubling or tripling the cost to the end user. For point of reference, the protocol fee for a Sundae v3 transaction would need to jump by around 1.5 ADA, effectively negating most of the benefit of lowered fees that reference scripts provided.
Additionally, 44 was chosen as a per-byte cost for the transaction because you're paying for transmitting, parsing, loading, and long term storage of the bytes in the transaction; But in the case of reference scripts, the transmission and long term storage has already been paid for in the initial publishing transaction. In this case, MinFeeRefScriptCostPerByte is really only paying for the cost to load / parse the script, and so arguably should be much much cheaper.
Proceeding with Conway without a discussion with SPOs, dApp developers, and end users on what this parameter should be set to seems really ill advised. If we don't have time to solicit that feedback because of the aggressive timeline for the Chang hardfork, I believe (and I imagine others would support me on this) that we should set it to 0 initially, as that is what the de-facto value for this parameter is today, and then leverage the new governance processes to raise it if its deemed a significant risk.
Yes please, clarification very much needed, slipping in this game-changing parameter without public discussion/announcement looks very bad.
Can we get some clarification on the final value for MinFeeRefScriptCostPerByte? If there is not yet a final value for this parameter, can we get clarification on how that final value will be decided?
Unfortunately, ledger repository is not the correct place to ask those questions. It is the implementation for the parameter that lives here, but the actual value that it will be set to is not up to the ledger team. In the matter of fact, I personally have no idea what the final value for it will be when we enter Conway. That being said, the value will be amendable once we are in Conway and the community will be able to propose a different value for this parameter through a proposal.
slipping in this game-changing parameter without public discussion/announcement looks very bad.
Nothing is being slipped in. There have been plenty of discussions about it, it's been months since the parameter has been implemented and all of the code is open source.
My personal and professional opinion is that this parameter is really necessary and should be initially set to something between 1 and minFeeA. The community later on will decide what the correct value should be, but if they want stability it should not be set to 0. The value for the parameter, however is still to be decided. That being said this is not the place for such discussion, because the audience for this issue tracker is not the same that controls protocol parameter values. I can suggest raising any concerns regarding protocol parameter values on IntersectMBO Discord channel.
No worries; I wasn't sure where else to create it, nor was I trying to blame anyone here, just trying to head off some drama and figure out who to talk to; Sam has reached out to me and we had a very productive conversation because of this ticket, so mission accomplished I think!
With regards to my "slipping it in" comment, my point is this: the parameter may have been discussed in lots of github issues, or among the ledger team, and the code may be open source, but I don't think there's ever been any explicit outreach to those of us building on top of the chain that will be impacted by it. I only know about it because I stumbled on it in a different issue I raised. And I only opened this ticket because many other builders I know were surprised recently when they learned of the existence of this parameter.
Similarly, I don't object to the parameter existing, I think it makes a lot of sense to have it. But last I heard about it the plan was to set it very low, and then was surprised to see it set to 44 in all environments:
https://book.world.dev.cardano.org/environments-pre/preprod/conway-genesis.json
Again, without any outreach or discussion with the actual people who it will impact. Not to say that it's you specifically that should be doing that outreach, or to place blame anywhere, I know there's a lot going on!
nor was I trying to blame anyone here
No worries. I wasn't trying to imply you are.
Sam has reached out to me and we had a very productive conversation because of this ticket, so mission accomplished I think!
Very nice.
But last I heard about it the plan was to set it very low, and then was surprised to see it set to 44 in all environments:
Current genesis files is far from final. So, I believe it is just a placeholder.
This actually made me realize, that I can direct all future issues about initial values that go into genesis files into the cardano-node issue tracker, since that is where they are defined, eg: https://github.com/IntersectMBO/cardano-node/blob/43149909fc4942e93e14a2686826543a2d9432bf/configuration/cardano/mainnet-conway-genesis.json#L27
Again, without any outreach or discussion with the actual people who it will impact. Not to say that it's you specifically that should be doing that outreach, or to place blame anywhere, I know there's a lot going on!
💯 agree with you. My team and I have too much on our plate to be also proactively reaching out to the community members about every issue we encounter and fix, especially since we don't really know that many members of the community and we are totally oblivious to many things that people actually do on Cardano, like what sort of scripts people write on Cardano for example 🙈 😄
That doesn't mean that there shouldn't be some group of people responsible for this sort of stuff. I wholeheartedly hope that IntersectMBO will be the solution to this problem. For examlpe, I know that we will have a Ledger working group in some not so distant future where members of Intersect interested in Ledger can join in and participate in the discussions about the future of Ledger.