Addition of new `minFeeRefScriptCoinsPerByte` protocol parameter

[lehins]

Fee calculation need to be adjusted in Conway. It has been decided that size of reference scripts should contribute to the fee amount charged in a transaction.

• Addition of new protocol parameter: minFeeRefScripts :: NonNegativeInterval
• Adding UTxO argument to getMinFeeTx:

  getMinFeeTx :: UTxO era -> PParams era -> Tx era -> Coin

• Adding another factor to the calculation in Babbage, along the lines of:

  ...
  <+> Coin (round ((refScriptsTotalSize % 1) * unboundRational (pp ^. ppMinFeeRefScriptsL)))
  where
  refSciptsTotalSize =
    maybe 0 (toInteger . getSum) $ foldMap (fmap Sum . getPlutusScriptSize) refScripts
  txBody = tx ^. bodyTxL
  ins = (txBody ^. referenceInputsTxBodyL) `Set.union` (txBody ^. inputsTxBodyL)
  refScripts = getReferenceScripts utxo ins

  Where getPlutusScriptSize :: Script era -> Maybe Int is a function that calculates the size of a plutus script for any Script

[Quantumplation]

@lehins I see this was created before my CIP, meaning this was already in the works. Can you provide any insight into how and why this decision was made?

[michaelpj]

I thought we were just going to add it to the transaction size for the purposes of fee calculation?

[lehins]

Can you provide any insight into how and why this decision was made?

Certainly. Using reference scripts does not come for free from the point of view of SPOs. The node has to spend resources looking up the reference input (which is not being spent) in the UTxO, but most importantly a script needs to be deserialized. Therefore it is almost as much work for the node to process a script as if it was part of the transaction, but there is less incentive for SPOs to do that work. That being said, it is definitely less work, and for that reason we want to be able to tune this lever by a parameter that is different from minFeeA

I thought we were just going to add it to the transaction size for the purposes of fee calculation?

@michaelpj Yeah, that will still sort of going to be the case. As I said above, it will just be adjusted with a separate paramter. So, for example if minFeeRefScriptCoinsPerByte would be set to minFeeA value, then it would be as if the size of a reference scripts was added to the size of the transaction. The argument @WhatisRT presented in favor of a separate protocol parameter was that the user is paying for adding the transaction on chain (reaching consensus, network overhead etc.) and the work is proportional to the size of the transaction, while using a reference script is also proportional to the size, but it requires less work than for the full transaction. Thus the community might want to have some freedom in tuning that parameter separately.

[Quantumplation]

Ok thanks! Appreciate the insight.

To me, it seems like the deserialization work should logically add to the execution units rather than the tx size (so that something like partial deserialization could save on ex units), but I can understand it being easier to use the existing and much simpler tool to achieve a similar result.

[gitmachtl]

So if this is a SC execution, shouldn't that be covered by SC related "fees"? As @Quantumplation said, shouldn't this be covered by the execution units?

As we have currently the discussion about the correct minFee calculation over here https://github.com/IntersectMBO/cardano-cli/pull/534 , that would need an extra input parameter for the fee calculation function on cardano-cli to provide the size of the reference script or the script itself? But correct me if i am wrong.

[KtorZ]

Is the intention to make that parameter as high as if the script had been included in the witness? Or is the intent to rather create a new incentives, without increasing the cost as much?

[MicroProofs]

Can you provide any insight into how and why this decision was made?

Certainly. Using reference scripts does not come for free from the point of view of SPOs. The node has to spend resources looking up the reference input (which is not being spent) in the UTxO, but most importantly a script needs to be deserialized. Therefore it is almost as much work for the node to process a script as if it was part of the transaction, but there is less incentive for SPOs to do that work. That being said, it is definitely less work, and for that reason we want to be able to tune this lever by a parameter that is different from minFeeA

I thought we were just going to add it to the transaction size for the purposes of fee calculation?

@michaelpj Yeah, that will still sort of going to be the case. As I said above, it will just be adjusted with a separate paramter. So, for example if minFeeRefScriptCoinsPerByte would be set to minFeeA value, then it would be as if the size of a reference scripts was added to the size of the transaction. The argument @WhatisRT presented in favor of a separate protocol parameter was that the user is paying for adding the transaction on chain (reaching consensus, network overhead etc.) and the work is proportional to the size of the transaction, while using a reference script is also proportional to the size, but it requires less work than for the full transaction. Thus the community might want to have some freedom in tuning that parameter separately.

Do we have an idea on what minFeeRefScriptCoinsPerByte value is going to be in relation to minFeeA. I was assuming less due to the smaller tx size and less bytes being sent over the wire. But I would like to see what gets recommended.

[lehins]

Is the intention to make that parameter as high as if the script had been included in the witness? Or is the intent to rather create a new incentives, without increasing the cost as much?

Do we have an idea on what minFeeRefScriptCoinsPerByte value is going to be in relation to minFeeA

Honestly, I have no idea what the initial value for this parameter will be. The intent of this issue is to provide the functionality for making this possible.

I was assuming less due to the smaller tx size and less bytes being sent over the wire.

I'd assume so as well.

[KtorZ]

Sounds like a good first question for IntersectMBO to work on :)

[vsubhuman]

I thought we were just going to add it to the transaction size for the purposes of fee calculation?

@michaelpj , ignoring the direct topic of the issue itself, your comment is very concerning. Is it mentioned somewhere in documentation that this plan exists to add ref script size to the size of the tx that references it?

[lehins]

Is it mentioned somewhere in documentation that this plan exists to add ref script size to the size of the tx that references it?

This was discussed in a meeting as a potential solution, but instead we decided to add a new protocol parameter that will be a multiplier for the size of reference scripts. Which is what this ticket is about. It is a strictly more powerful solution since it gives fine control over how much ref scripts will contribute to the fee of a transaction.