CIP-0055? | Babbage Era Protocol Parameters

[JaredCorduan]

This informational CIP extends CIP-0028 to introduce a change to one of the Alonzo protocol parameters in the Babbage era, namely lovelacePerUTxOWord. We propose to have this updateable parameter be based on bytes instead of words (eight bytes).

[gitmachtl]

@JaredCorduan , question, i am calculating the current value discrete in my stakepool operator scripts, based on mary/alonzo values. (https://github.com/gitmachtl/scripts/blob/f84ed987ab0dcdcba7caee758a9f723853735899/cardano/mainnet/00_common.sh#L669-L752)

After the HF event, can i still use the same calculation method but just multiplying the value of the coinsPerUTxOByte value by 8 and use this as the new "word" amount?

[JaredCorduan]

@JaredCorduan , question, i am calculating the current value discrete in my stakepool operator scripts, based on mary/alonzo values. (https://github.com/gitmachtl/scripts/blob/f84ed987ab0dcdcba7caee758a9f723853735899/cardano/mainnet/00_common.sh#L669-L752)

After the HF event, can i still use the same calculation method but just multiplying the value of the coinsPerUTxOByte value by 8 and use this as the new "word" amount?

No, that is not guaranteed to work. The old formula was based on an upper bound to the memory usage, and the new formula is based on the size on the wire.

[KtorZ]

@JaredCorduan I do expect the new formula to always yield values that are less or equal to what they used to be with the current formula, as the approximation was 'over-estimating' sizes generally speaking. Right?

[JaredCorduan]

[JaredCorduan]

@JaredCorduan I do expect the new formula to always yield values that are less or equal to what they used to be with the current formula, as the approximation was 'over-estimating' sizes generally speaking. Right?

(clicked the wrong button, sorry to close/open the PR) That is probably true, but we have not tested it or made that promise.

[JaredCorduan]

as the approximation was 'over-estimating' sizes generally speaking. Right?

just to be clear, the old formula was over-estimating the size in memory. the new methods is an exact measurement of the size on the wire. in other words, we are measuring something slightly different in Babbage, though obviously they are correlated.

[gitmachtl]

as the approximation was 'over-estimating' sizes generally speaking. Right?

just to be clear, the old formula was over-estimating the size in memory. the new methods is an exact measurement of the size on the wire. in other words, we are measuring something slightly different in Babbage, though obviously they are correlated.

can the size be calculated from the "build-raw transaction" output we do already to produce a "dummy-tx" for later usage with the "transaction calculate-min-fee" command? like just using the cBor hex content of the unwitnessed-tx-file, size is length of that cbor string / 2 (because hex uses 2 chars for 1 byte). i want to have an external 2nd option to calculate the minAda. if it is necessary to do the signing too, that would be a nightmare with hw wallets or multisig operations.

currently we can calculate the minRequiredUTxO externally by the formular or via the internal "calculate-min-required-utxo" command. but the external formular method does not require any cBor conversion just pure "bash" commands.

[JaredCorduan]

can the size be calculated from the "build-raw transaction" output we do already to produce a "dummy-tx" for later usage with the "transaction calculate-min-fee" command? like just using the cBor hex content of the unwitnessed-tx-file, size is length of that cbor string / 2 (because hex uses 2 chars for 1 byte). i want to have an external 2nd option to calculate the minAda. if it is necessary to do the signing too, that would be a nightmare with hw wallets or multisig operations.

almost! it's not the size of the cbor tx that matters, but the size of each cbor txout inside the output of build-raw transaction. for each such output hex, after you have divided by two (to account for the hex), all you have to is multiply by the protocol parameter coinsPerUTxOByte.

[gitmachtl]

can the size be calculated from the "build-raw transaction" output we do already to produce a "dummy-tx" for later usage with the "transaction calculate-min-fee" command? like just using the cBor hex content of the unwitnessed-tx-file, size is length of that cbor string / 2 (because hex uses 2 chars for 1 byte). i want to have an external 2nd option to calculate the minAda. if it is necessary to do the signing too, that would be a nightmare with hw wallets or multisig operations.

almost! it's not the size of the cbor tx that matters, but the size of each cbor txout inside the output of build-raw transaction. for each such output hex, after you have divided by two (to account for the hex), all you have to is multiply by the protocol parameter coinsPerUTxOByte.

hmm ok, but this is not trivial because it would need to redo the whole cbor conversion... hmm.

[JaredCorduan]

hmm ok, but this is not trivial because it would need to redo the whole cbor conversion... hmm.

what cbor conversion are you referring to?

[gitmachtl]

hmm ok, but this is not trivial because it would need to redo the whole cbor conversion... hmm.

what cbor conversion are you referring to?

to bring any kind of txOut into the used cBor format for calculating the minAda. there is no native solution to do this in pure bash without 3rd party tools. but lets see how it differs. currently running testnodes in the vasil-qa testchain. any plans to bring this new parameter into this testchain anytime soon?

[JaredCorduan]

currently running testnodes in the vasil-qa testchain. any plans to bring this new parameter into this testchain anytime soon?

it's already using the new calculation on vasil-qa.

[KtorZ]

@JaredCorduan what about the 'extra entropy' and the 'decentralization parameter' which are now gone in Babbage/Vasil? Do you think you could add two lines of rationale as for why those parameters have now been removed so that we have a complete overview of the updatable parameters changes.

[JaredCorduan]

@JaredCorduan what about the 'extra entropy' and the 'decentralization parameter' which are now gone in Babbage/Vasil? Do you think you could add two lines of rationale as for why those parameters have now been removed so that we have a complete overview of the updatable parameters changes.

yes, that's a great idea.

[JaredCorduan]

@KtorZ I've added some prose about the removal of d and extraEntropy.

[SebastienGllmt]

LGTM

[gitmachtl]

@JaredCorduan

hi, i have troubles to get the math right. so i have a simple transaction to a testnet base address. sending lovelaces and 10x ATADAcoin. this results in a minADA value of 1168010 lovelaces. according to the utxoCostPerByte value of 4310 this should be 271 bytes. but when i only take the CBOR part of this txout

{0: h'00897789A996EC52F93668D18DD4DBE5F00036A0406F6DA37185C641CAF695C35024868C4DD6F694E16B88BDF6986E31A074F790D75241C44B', 1: [1168010, {h'34250EDD1E9836F5378702FBF9416B709BC140E04F668CC355208518': {h'4154414441636F696E': 10}}]}

cbor-hex:
A200583900897789A996EC52F93668D18DD4DBE5F00036A0406F6DA37185C641CAF695C35024868C4DD6F694E16B88BDF6986E31A074F790D75241C44B01821A0011D28AA1581C34250EDD1E9836F5378702FBF9416B709BC140E04F668CC355208518A1494154414441636F696E0A

thats only 111 bytes and not 271 bytes? what am i missing here? 160 bytes as a fixed addition?

EDIT: ah... the overhead ...
https://github.com/input-output-hk/cardano-ledger/blob/2505b7f103c78ee5a230b3e302e31d9607fffbd5/eras/babbage/impl/src/Cardano/Ledger/Babbage/Rules/Utxo.hs#L251-L264

[JaredCorduan]

@gitmachtl great catch, I forgot that we ended up adding the constant overhead, that should definitely be a part of this CIP!

[gitmachtl]

@JaredCorduan i figured out, that for a mary/alonzo transaction in babbage era you get along with an overhead of only 158 bytes. what is causing the 2 extra bytes for a babbage formated transaction? is it the change in the legacy/babbage transaction output (https://github.com/input-output-hk/cardano-ledger/blob/2505b7f103c78ee5a230b3e302e31d9607fffbd5/eras/babbage/test-suite/cddl-files/babbage.cddl#L77-L88) ?

[JaredCorduan]

@gitmachtl -

Note that the purpose of the minimum UTxO value is to constrain how much memory someone can take up in the UTxO map, relative to how many lovelace they control. And we are now (starting in the Babbage era) using the number of bytes of a given transaction output on the wire to approximate the impact in memory to the UTxO.

In Haskell, a Word (eight bytes) is the smallest unit of space that you can take up. The twenty words in the overhead exist to account for some of the difference between the size of an output on the wire, and the size in memory of the unspent transaction output which it creates. Recall that an unspent transaction output is an entry in a map, mapping a transaction input to a transaction output. So, at the very least, the overhead needs to include the size in memory of the transaction input and also the impact of the map data structure. Let's first dig into that.

---

The UTxO map looks like:

newtype UTxO era = UTxO (Map (TxIn (Crypto era)) (TxOut era))

type Size     = Int

data Map k a  = Bin {-# UNPACK #-} !Size !k a !(Map k a) !(Map k a)
              | Tip

So each element of the map, ie each Bin, uses:

• 1 Word for for the type constructor
• 1 Word for Size
• 1 Word for the pointer to k
• 1 Word for the pointer to a
• 2 Words for the two pointers, left and right, that the map uses for the binary tree structure

Total: 6 Words + the size of k + the size of a
(ie 6 Words + the size of the transaction input + the size of the transaction output.)

Remember that we are approximating the size of a by the number of bytes on the wire of the transaction output (and that this number is not a part of the overhead).

---

The transaction inputs look like:

data TxIn crypto = TxIn !(TxId crypto) {-# UNPACK #-} !TxIx

So each TxIn uses:

• 1 Word for the type constructor
• 1 Word for the pointer to TxId (the transaction ID)
• 1 Word for TxIx (the transaction index).

Total: 3 Words + the size of TxId

---

The transaction IDs look like:

newtype TxId crypto = TxId {_unTxId :: SafeHash crypto EraIndependentTxBody}
newtype SafeHash crypto index = SafeHash (Hash.Hash (CC.HASH crypto) index)
-- Resolves to:
newtype Hash Blake2b_256 EraIndependentTxBody = UnsafeHashRep (PackedBytes (SizeHash Blake2b_256))
-- Which is this case:
data PackedBytes (n :: Nat) where
  ...
  PackedBytes32 :: {-# UNPACK #-} !Word64
                -> {-# UNPACK #-} !Word64
                -> {-# UNPACK #-} !Word64
                -> {-# UNPACK #-} !Word64
                -> PackedBytes 32
  ...

So each TxId uses:

• 1 Word for the type constructor
• 4 Words for the data

Total: 5 Words

---

This brings us to 14 words of overhead.

The remaining 6 words account for the space taken up by the transaction output which is not accounted for in the bytes on the wire. Since outputs can vary a lot (Babbage era outputs have a lot of options, such as inline datums, reference scripts, etc), we did not do accounting as above, but rather chose 6 because that was the value which made the minimum lovelace of an lovelace-only output have a minimum of 1 ADA (using the current Alonzo protocol parameters). Though the minimum utxo calculation has changed each era, ever since the Shelley era we have kept the minimum value for a lovelace-only outputs as close to 1 ADA as we can.

[gitmachtl]

thx 🙏