-
Notifications
You must be signed in to change notification settings - Fork 724
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
API additions for automating transaction building #2906
Conversation
Currently based on #2881, can be rebased on master once that is merged. More patches to follow. |
Make them more regular by having both take an era param, fix the names and make them both clearly general in the era.
Conversion functions within the API. We'll need both.
Compute the total balance of the proposed transaction. Ultimately a valid transaction must be fully balanced: that is have a total value of zero. Finding the (non-zero) balance of partially constructed transaction is useful for adjusting a transaction to be fully balanced.
Compute the transaction fee for a proposed transaction, with the assumption that there will be the given number of key witnesses (i.e. signatures).
Give an approximate count of the number of key witnesses (i.e. signatures) a transaction will need.
be6af05
to
ead1a15
Compare
Now rebased on master. Still more patches to follow. |
This more-or-less mirrors the RdmrPtr, which we generally want to hide, but for some kinds of tx manipulation it is inevitable. In particular we will need it to be able to provide the execution units for each script use, and to perform substitutions.
The collectTxBodyScriptWitnesses helper function was previously only being used within makeShelleyTransactionBody, but with the addition of the public ScriptWitnessIndex type, it now makes sense to have it use that and to expose the function. It also makes it clearer what the types ScriptWitnessIndex and AnyScriptWitness are for.
Compute the ExecutionUnits needed for each script in the transaction. This works by running all the scripts and counting how many execution units are actually used.
-- | The 'ScriptDatum' provided does not match the one from the 'UTxO'. | ||
-- This means the wrong 'ScriptDatum' value has been provided. | ||
-- | ||
| ScriptErrorWrongDatum (Hash ScriptData) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be worth including the incorrect and correct datum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, but I don't think we have that immediately available. We'd probably need to change the ledger functions too.
| ScriptErrorEvaluationFailed Plutus.EvaluationError | ||
|
||
-- | The execution units overflowed a 64bit word. Congratulations if | ||
-- you encounter this error. With the current style of cost model this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤣
That we will use for the auto-balancing tx construction.
This is much like 'makeTransactionBody' but with greater automation to calculate suitable values for several things. In particular: * It calculates the correct script 'ExecutionUnits' (ignoring the provided values, which can thus be zero). * It calculates the transaction fees, based on the script 'ExecutionUnits', the current 'ProtocolParameters', and an estimate of the number of key witnesses (i.e. signatures). There is an override for the number of key witnesses. * It accepts a change address, calculates the balance of the transaction and puts the excess change into the change output. * It also checks that the balance is positive and the change is above the minimum threshold. To do this it needs more information than 'makeTransactionBody', all of which can be queried from a local node.
Well, in this case supress since it was not helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
bors r+ |
Build succeeded: |
Add API evaluateTransactionBalance
Compute the total balance of the proposed transaction. Ultimately a
valid transaction must be fully balanced: that is have a total value
of zero.
Finding the (non-zero) balance of partially constructed transaction
is useful for adjusting a transaction to be fully balanced.