You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Convert descriptions could point to older anchors (just like spend descriptions do). This requires keeping in storage old versions of the tree anchor, updating the validation in the validity predicate and the way we build transactions.
The text was updated successfully, but these errors were encountered:
I'm not sure this is really needed nor necessarily nice to have. For the commitment tree we need to keep older versions of the tree's root in storage because this can be possibly update with every block and we cannot expect clients to keep up the pace. For the conversions though, we only expect one update per MASP epoch, which is planned to be quite slow (approx. 1 per day). Moreover, clients have an interest in querying and utilizing the latest conversions to extract more values out of their notes.
I'd say that storing older anchors would only help in one case: when a transaction involving conversions is submitted close to the masp epoch change. In this case there's a chance that, by the time the transaction is included in a block, the conversions have been updated and the tx will fail. This can be prevented by a smart client and, on top of that, since conversions are only used for shielded and unshielding operations, which most likely will rely on masp fee payment, there's a good chance that the transaction will not pass the fee check and won't even get included in a block, preventing the submitter from paying the gas fee.
Convert descriptions could point to older anchors (just like spend descriptions do). This requires keeping in storage old versions of the tree anchor, updating the validation in the validity predicate and the way we build transactions.
The text was updated successfully, but these errors were encountered: