You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a very subtle bug that was introduced in Conway in the translation of certificates to the PlutusV3 context. It was reported by @KtorZ on Slack and with a PR that implemented a potential fix: #4542
This bug depicts itself in the translation of TxCertRegStaking and TxCertUnRegStaking certificates. Regardless whether optional deposit/refund is provided or not in either of those two certificates in a transaction, PlutusV3 context will always not see the original value and will see them as Nothing.
Unfortunately we can no longer simply fix this bug due to the scheduled Chang Hard Fork (protocol version 9), therefore we will have to preserve this behavior going into Conway. Which means we are left with two choices:
either keep it like this forever for PlutusV3
fix this issue during the hard fork into Chang+1, i.e. major protocol version 10.
Having spoken to @zliu41 from the Plutus team, it seems to be the latter approach is more sensible. Any script writer that is not aware of this behavior and writing a script that would rely on presence of a deposit/refund for successful execution could lock their funds forever. For this reason we will plan to fix this bug for the next intra-era hard fork.
Expected behavior after this bug is fixed:
For PlutusV3 in Conway [PV 9.0] - TxCertRegStaking and TxCertUnRegStaking certificates will always have Nothing for the deposit and refund respectively
For PlutusV3 in Conway onwards [PV 10.0 ..] - TxCertRegStaking and TxCertUnRegStaking will correctly reflect the values that are supplied in the transaction.
The text was updated successfully, but these errors were encountered:
Unfortunately, as documented in:
IntersectMBO/cardano-ledger#4571
Some Option fields in the script context certificates are going to
remain set to None, at least until the next Hard fork. There's a risk
that people permanently lock their funds if they expect deposits on
registration credentials to ever be `Some`.
So, we introduce a special type that emulate an `Option` that can only
ever be `None`. We call it `Never` and it is the first type of this
kind (i.e. with constructors indexes not starting at 0).
There is a very subtle bug that was introduced in Conway in the translation of certificates to the PlutusV3 context. It was reported by @KtorZ on Slack and with a PR that implemented a potential fix: #4542
This bug depicts itself in the translation of
TxCertRegStaking
andTxCertUnRegStaking
certificates. Regardless whether optional deposit/refund is provided or not in either of those two certificates in a transaction,PlutusV3
context will always not see the original value and will see them asNothing
.Unfortunately we can no longer simply fix this bug due to the scheduled Chang Hard Fork (protocol version 9), therefore we will have to preserve this behavior going into Conway. Which means we are left with two choices:
Having spoken to @zliu41 from the Plutus team, it seems to be the latter approach is more sensible. Any script writer that is not aware of this behavior and writing a script that would rely on presence of a deposit/refund for successful execution could lock their funds forever. For this reason we will plan to fix this bug for the next intra-era hard fork.
Expected behavior after this bug is fixed:
PlutusV3
in Conway [PV 9.0] -TxCertRegStaking
andTxCertUnRegStaking
certificates will always haveNothing
for the deposit and refund respectivelyPlutusV3
in Conway onwards [PV 10.0 ..] -TxCertRegStaking
andTxCertUnRegStaking
will correctly reflect the values that are supplied in the transaction.The text was updated successfully, but these errors were encountered: