We could consider removing the pre-caching mechanism of the shielded wallet (a.k.a. the speculative shielded context) and go back to calling shielded-sync in the client automatically before any masp-related command (balance query, shielded tx, unshielding tx). The reasons are:
Poor UX: in general both being in a speculative context or on an old confirmed context leads to a bad experience for the user who could see outdated balances or find themselves unable to produce valid transactions. The current solution based on warning messages and the need to manually call shielded-sync all the times is a bit tedious
Possible information leaks: being on a speculative (or in general, old state) can leak some information when spending a key
Performance of the shielded-sync command should be good now and should not be a concern in terms of UX
There's only one possible catch:
In the docs (https://docs.namada.net/users/fees#masp-fee-payment-gas-limit) we suggest a way to circumvent a limitation when paying fees via the MASP that would require building a batch of masp transactions. This is not currently supported by the client (since we only support batching from the SDK), but if we wanted it we'd need to apply some logic to invalidate spent notes just like we do in the speculative context: this could be done in a separate command though, without the need to have a special type of context that applies to all commands
grarco
commented
5 days ago
Follows #4019.
We could consider removing the pre-caching mechanism of the shielded wallet (a.k.a. the speculative shielded context) and go back to calling
shielded-syncin the client automatically before any masp-related command (balance query, shielded tx, unshielding tx). The reasons are:shielded-syncall the times is a bit tediousshielded-synccommand should be good now and should not be a concern in terms of UXThere's only one possible catch: