Simulate: report minimum balance requirements

[jasonpaulos]

Problem

When called by a user, some applications may create resources that increase the MBR (minimum balance requirement) of the app account, e.g. boxes, assets, and apps all increase MBR. In order to successfully call such an application, the user needs to know the MBR increase that their call will have so that they can send this amount to the app account prior to the app call.

Minimal Solution

Simulate could report the MBR change that a transaction has on accounts. Then users could simulate their transaction group with a larger-than-necessary payment to the app account and they'd see exactly how much the app account's MBR increases.

Questions/concerns for this approach:

• How should MBR change be reported, and at what granularity? Our REST API and downstream client generation doesn't have support for negative numbers, so perhaps reporting initial MBR for all relevant accounts and updated MBR later on (either at the txn or txn group level) would make the most sense.
• This solution may be completely satisfied by just returning the ledger StateDeltas for each transaction (or txn group). If that's the case, it may make more sense to do that instead, since there would be many other benefits.

Better Solution

There are a few problems with the minimal solution:

1. It requires the user to know which account(s) can have an MBR increase. When interacting with many apps, sometimes this may not be clear.
2. The user has to guess the maximum MBR increase the app can have with their initial payment, and has to have the algos available to perform the payment.

Because of this, it may be preferred to add an option to allow simulate to execute transactions and ignore any MBR violations. As long as simulate reports the violating accounts and the amount of each violation, it should be clear to the user what needs to be done to make their transaction group valid.

[joe-p]

It requires the user to know which account(s) can have an MBR increase. When interacting with many apps, sometimes this may not be clear.

There is an upper bound on "available" accounts, so couldn't simulate just check all the available accounts before and after the txn/group and report any changes?

[jasonpaulos]

@joe-p that limitation is important because in the minimal solution, the user has to fund the target app with an amount that's greater than any possible MBR increase it expects. Therefore the user needs to know which apps might need MBR payments.

Simulate only tells you the actual MBR changes after the fact, so you can minimize your payments on the real network.