The introduction of the Babbage era comes with some minor (albeit possibly breaking) changes and deprecations:
-
⚠️ datums
, redeemerData
and plutus:v1
scripts are no longer encoded as base64
strings, but are encoded as base16
strings. The data payload remains however identical.
This change is meant for more compatibility across the API since those data-types can now also be submitted to the server when evaluating execution units for transactions. Using
base64
for input data here is a bit awkward since most existing interfaces in the ecosystem favor base16
;
-
⚠️ When passing transaction outputs to the server (e.g. when providing an additional UTxO for script evaluation), datum hashes in output must now be specified as datumHash
(instead of datum
). However, the server does a best-effort for the sake of backward compatibility and should still work if provided with a valid hash under datum
. However, after the Vasil hard-fork, it'll be possible to also pass inline-datums using datum
, while datum hash digest are expected to be specified as datumHash
. Said differently, existing applications relying on this functionality will keep working without a change on this release, but applications willing to make use of the new inline-datum functionality coming in Vasil must abide by the new notation;
-
⚠️ Similarly, Alonzo transaction outputs will now contain a datumHash
field, carrying the datum hash digest. However, they will also contain a datum
field with the exact same value for backward compatibility reason. In Babbage however, transaction outputs will carry either datum
or datumHash
depending on the case; and datum
will only contain inline datums;
-
⚠️ The outputTooSmall
errors from transaction submission will slightly change format for transactions submitted during the Babbage era. Instead of an array of outputs, it is an array of objects with output
and minimumRequiredValue
fields;
-
⚠️ A slightly modified block header: leaderValue
and nounce
fields are gone and replaced by a single inputVrf
field;
-
⚠️ Few protocol parameters changes:
-
A new protocol parameter coinsPerUTxOByte
comes to replace coinsPerUtxoWord
with a slightly different semantic. coinsPerUTxOByte
is meant to compute the minimum Lovelace requirement on transaction outputs, and is simply a coefficient in a linear function of the serialized (CBOR) output:
minUTxOValue(output) = |serialise(output)| * coinsPerUTxOByte
-
The decentralizationParameter
no longer exists.<br/>
The block production is forever decentralized :tada:!
-
The extraEntropy
no longer exists.