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

API additions for automating transaction building #2906

Merged
merged 11 commits into from
Jul 13, 2021

Conversation

dcoutts
Copy link
Contributor

@dcoutts dcoutts commented Jul 7, 2021

  • 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.

@dcoutts
Copy link
Contributor Author

dcoutts commented Jul 7, 2021

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.
@dcoutts dcoutts force-pushed the dcoutts/api-transaction-build branch from be6af05 to ead1a15 Compare July 8, 2021 09:55
@dcoutts
Copy link
Contributor Author

dcoutts commented Jul 8, 2021

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)
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.
@dcoutts dcoutts marked this pull request as ready for review July 9, 2021 17:22
Well, in this case supress since it was not helpful.
Copy link
Contributor

@Jimbo4350 Jimbo4350 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@Jimbo4350
Copy link
Contributor

bors r+

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Jul 13, 2021

@iohk-bors iohk-bors bot merged commit e71f81a into master Jul 13, 2021
@iohk-bors iohk-bors bot deleted the dcoutts/api-transaction-build branch July 13, 2021 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants