Implement PlutusV3 Validators #977
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rvcas
force-pushed
the
rvcas/validators_v3
branch
2 times, most recently
from
4fa84fa
to
8615755
Compare
rvcas
force-pushed
the
rvcas/validators_v3
branch
2 times, most recently
from
b8e092d
to
8c37b37
Compare
KtorZ
force-pushed
the
rvcas/validators_v3
branch
from
8904c4a
to
e0b16de
Compare
rvcas
force-pushed
the
rvcas/validators_v3
branch
from
3879e3d
to
88aa4d9
Compare
KtorZ
force-pushed
the
rvcas/validators_v3
branch
5 times, most recently
from
fff412c
to
0753552
Compare
rvcas
force-pushed
the
rvcas/validators_v3
branch
from
f9e6fed
to
5850c74
Compare
KtorZ
force-pushed
the
rvcas/validators_v3
branch
7 times, most recently
from
0e5082e
to
896a56b
Compare
This must only happen in case all other validator succeed; otherwise we might generate invalid validators.
Probably an oversight when we reworked them.
The rationale is two folds:
1. It's more consistent with how we already separate the validator
name from its module.
2. Because `_` may be present in Aiken's validator's name, it is hard
to read and I am afraid it could potentially conflict later on. So
it's better to use a separator that cannot appear in validator
names.
Mainly to have a trivial example with just the validator boilerplate code.
Fucking hell. I got rid of the 'opaque_value_in_datum' test since it is no longer relevant (we now forbid the presence of opaque types in the ABI).
KtorZ
force-pushed
the
rvcas/validators_v3
branch
from
896a56b
to
0c9ea19
Compare
Without that, we may encounter weird error messages when writing validators without an explicit `else`. Since we automatically fill it with a `fail`; without annotation, it unifies to a generic parameter. The existing check that would look for the body being an error term is ill-advised as it doesn't work as soon as one adds tracing, or make the validator a parameterized validator. Plus, it may simply trigger the wrong behavior as one can now annotate a validator with _whatever_ and get pass the type-checker by plucking a `fail` keyword as body.
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).
Unless it is NOT bool as it deviates from the default and while wrong, we want to preserve it to provide a good error.
This is a little trick which detects record access and replace them with a simple var. The var itself is the validator handler name, though since it contains dots, it cannot be referred to by users explicitly. Yet fundamentally, it is semantically equivalent to just calling the function by its name. Note that this commit also removes the weird backdoor for allowing importing validators in modules starting with `tests`. Allowing validators handler to be used in importable module requires more work and is arguably useful; so we will wait until someone complain and reconsider the proper way to do it.
When there's no type annotation in a validator handler signature, we provide default annotation to help the type-checker. However, for spend's datum and mint policy_id, those annotations mustn't be `Data`, but rather Option<Data> and Bytearray. Without that, when no annotation are provided, the compiler infer invalid types and fails with incongruous errors.
It's fine for the argument to not be annotated; in which case we simply default back to an `Option<Data>`.
KtorZ
force-pushed
the
rvcas/validators_v3
branch
from
d44bb58
to
4853563
Compare
KtorZ
reviewed
Aug 27, 2024
Technically, we always need a fallback just because the way the UPLC is going to work. The last case in the handler pattern matching is always going to be else ... We could optimize that away and when the validator is exhaustive, make the last handler the fallback. Yet, it's really a micro optimization that saves us one extra if/else. So the sake of getting things working, we always assume that there's a fallback but, with the extra condition that when the validator is exhaustive (i.e. there's a handler covering all purposes), the fallback HAS TO BE the default fallback (i.e. (_) => fail). This allows us to gracefully format it out, and also raise an error in case where there's an extraneous custom fallback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
relates to #907
this is gonna be a big one