Update ManagedLedger implementations
Clarification and motivation
There are a couple of things we can improve in ManagedLedger:
- For some reason in
transfer
we considerfrom == to
case as no-op. That probably contradicts FA1.2 and just does not make sense. It also slightly increases gas consumption in the normal case (from ≠ to
). - We currently have this
type LedgerValue = ("balance" :! Natural, "approvals" :! Map Address Natural)
which can be made arbitrarily large. Only the owner of an address can make itsLedgerValue
large (by callingapprove
many times). It's not a big problem in ManagedLedger (normally there is no incentive to break your own account), but it may break/spoil additional functionality in ManagedLedger-based contracts and it's just inefficient. Fortunately, since Carthagenet we can use pairs as keys in big_maps, so we can store approvals inbig_map (pair address address) nat
.
Acceptance criteria
-
ManagedLedger
(both implementations) does not treatfrom == to
case as a special one. In particular, it consumes allowance whenfrom ≠ SENDER
and fails iffrom
does not have enough tokens. - Approvals are stored separately, each big_map key is mapped to constant-sized data (
nat
).