Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translation of Stake Credential [Un]Registration with deposit to PlutusV3 #4571

Closed
lehins opened this issue Aug 27, 2024 · 0 comments · Fixed by #4627
Closed

Translation of Stake Credential [Un]Registration with deposit to PlutusV3 #4571

lehins opened this issue Aug 27, 2024 · 0 comments · Fixed by #4627
Assignees
Labels
bug Something isn't working conway intra-era-hardfork A task that requires an intra-era hard fork

Comments

@lehins
Copy link
Collaborator

lehins commented Aug 27, 2024

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:

  1. For PlutusV3 in Conway [PV 9.0] - TxCertRegStaking and TxCertUnRegStaking certificates will always have Nothing for the deposit and refund respectively
  2. For PlutusV3 in Conway onwards [PV 10.0 ..] - TxCertRegStaking and TxCertUnRegStaking will correctly reflect the values that are supplied in the transaction.
@lehins lehins added bug Something isn't working conway intra-era-hardfork A task that requires an intra-era hard fork labels Aug 27, 2024
@lehins lehins added this to Conway Aug 27, 2024
@github-project-automation github-project-automation bot moved this to To do in Conway Aug 27, 2024
KtorZ added a commit to aiken-lang/aiken that referenced this issue Aug 27, 2024
  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).
@teodanciu teodanciu self-assigned this Sep 5, 2024
@github-project-automation github-project-automation bot moved this from To do to Done in Conway Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working conway intra-era-hardfork A task that requires an intra-era hard fork
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants