Handle MASP Transactions Across Epoch Boundaries

[murisi]

Right now in the client, the epoch can change during the construction of a MASP transaction. And when this happens, the ledger simply rejects the submitted transaction, and then the client prints out an error. The client ought to detect when an epoch boundary is near enough to invalidate a transaction it would create, sleep till after the epoch changed, and then attempt to construct and submit a transaction.

@tzemanovic had suggested the following:

The client could wait for the new epoch and then continue, but we’ll need to add a new RPC path for this, probably something that exposes storage.last_height, next_epoch_min_start_height and next_epoch_min_start_time from the shell.

If there are any unexpected problems with the above approach, the client could instead attempt resubmitting the transaction at most once. This trick would work under the assumption that two consecutively submitted transactions cannot both be on epoch boundaries (for otherwise the epoch length for the network would be too short).

[cwgoes]

@karbyshev can you take this on as part of the wallet work?

[murisi]

@karbyshev Looking at namada/main, an attempt to solve this issue has been made. The approach taken is to resubmit (transparent -> shielded) transactions if the epoch changes during construction, while at the same time weakening the MASP VP to allow (shielded -> transparent) transactions for assets belonging to older epochs. But the implementation has some possible shortcomings:

1. The client only tests if the epoch changes during the construction of a shielded transaction (and repeats the construction if this is the case). However, theoretically it's possible for the epoch to change only after transaction creation, but before submission. In this (unlikely) case, the client would fail. Also, if a transaction is somehow rejected due to a epoch boundary crossing (caused for example by E2E epochs being too short), the cause is still obscure to the user.
2. The code for reconstructing a transaction in the case where the epoch did change is essentially duplicated from the code that initially attempts to create a transaction. This could end up being a maintenance burden if the two codes for constructing a transaction fall out of sync.
3. The vp_masp code for checking that the value balance is legal assumes that the MASP value balance has at least one component (i.e. it is non-zero) and that the asset type of the first component of the value balance is constructed from the token of the wrapper transparent Transfer. The first assumption not being met could crash the VP, the second assumption not being met could lead to validation bugs down the line.

Issue (1) could be solved by checking after a transaction has been rejected whether the cause was due to the epoch having changed. If the epoch did change, then an informative error message could be printed (or maybe a retry could be attempted).

Issue (3) could be solved by just computing the transparent value balance by adding net transparent input to the MASP value balance and checking that the result is more than or equal to zero. Applied in conjunction with the conditions at https://github.com/anoma/namada/blob/main/documentation/specs/src/masp/ledger-integration.md#boundary-conditions , this would eliminate the need to inspect the components of shielded_tx.value_balance (if there are any).

[karbyshev]

@murisi Can this be closed now?