Migrate to Plutus V3 #7
Conversation
The `collective_output` validation is now removed to avoid the additional list reversal. Now the validation is only provided with the number of outputs for each input.
It is less costly to look up a given withdrawal script than looking up a spend's script hash.
They both now look into `redeemers` and their corresponding fields (i.e. `mint` for tx-level pattern, and `withdrawals` staking pattern). This gives users access to minted tokens and withdrawal amounts.
For supporting GitHub Pages.
| use cardano/address.{Script} | ||
| use cardano/transaction.{Redeemer, ScriptPurpose, Withdraw} | ||
|
|
||
| /// Datatype for redeemer of the "computation stake validator," to represent |
There was a problem hiding this comment.
| /// Datatype for redeemer of the "computation stake validator," to represent | |
| /// Datatype for redeemer of the "computation stake validator" to represent |
| ) | ||
| } | ||
|
|
||
| pub fn no_datum_wrapper_validator_3( |
There was a problem hiding this comment.
Would it make sense to create a generalized version as well?
e.g.
pub fn no_datum_wrapper_validator_3(
hashed_parameters: List<...>,
parameter_serializaer: List<...>,
...
)
There was a problem hiding this comment.
I think that would limit the parameters to be of the same type... Unless there is a better way to model this?
pub type ParameterisedRedeemer<p, r> {
params: List<p>,
redeemer: r,
}| /// | ||
| /// For validation functions, corresponding indices of inputs/outputs are also | ||
| /// provided in these functions. | ||
| pub fn withdraw_no_redeemer( |
There was a problem hiding this comment.
Can this function be split to aid readability? (Only if it does not make performance worse...)
There was a problem hiding this comment.
By splitting, do you mean having different variants, each of which perform one of the 3 validation functions?
| /// Under the hood, one other difference is that here, instead of traversing all | ||
| /// the inputs, there are two traversals: one over the `redeemers`, and another | ||
| /// over the indices. | ||
| pub fn withdraw_with_redeemer( |
There was a problem hiding this comment.
Maybe split this as well? (Same caveats as above...)
| /// > This function has no protection against | ||
| /// > [double satisfaction](https://github.com/Plutonomicon/plutonomicon/blob/b6906173c3f98fb5d7b40fd206f9d6fe14d0b03b/vulnerabilities.md#double-satisfaction) | ||
| /// > vulnerability, as this can be done in multiple ways depending on the | ||
| /// > contract. If you can tolerate some extra overhead, consider using the |
There was a problem hiding this comment.
I do not think that there is any protocol that might not want to avoid a double satisfaction attack. Maybe we could implement a countermeasure for it in this module?
There was a problem hiding this comment.
I can think of 4 ways to prevent double satisfaction:
- Equality of input index and output index (not applicable everywhere)
- Datum tagging (would require an additional function for extracting the tag field from the output datum)
- Filtering the inputs and expecting one to remain (a bit costly)
- Expecting the continuing output at index 0, such that it holds only 1 NFT (works for contracts that only hold multiple beacon UTxOs)
Picking one over the others might make the interface somewhat opinionated. What do you think?
Thank you for taking the time @mpetruska 🙏 |
In favor of a more consistent interface.
No description provided.