Why do we need the contractcode in the ledgerfootprint?
cc @feral mango @main drum @celest linden @trail frigate
#Contractcode in ledger footprint
spiral tree
trail frigate
because it's a ledger entry we access. I don't think we 'special-case' any ledger entries to not be included in the footprint
celest linden
yeah I mean we could infer it if we are certain that contractcode is 100% immutable for all time and we're willing to do an implicit read through the contractexecutable data entry but .. we don't do that now.
it would be a safe optimization to do in the future if we care, as it would strictly increase the set of legal transactions
trail frigate
if by contractcode we mean entries that contain Wasm blobs, then they're 100% immutable
spiral tree
I think anything that causes a contract upgrade that forces the invalidation of a invocation or transaction signature is something we need to remove. General users shouldn't need to redo signatures. And there could be applications where an off-chain protocol using Soroban would want their signatures to not be invalidated.
trail frigate
but I think that might complicate the metering a lot - currently the plan is to charge for the number of entries accesses and objectively we access 2 entries
spiral tree
With contractcode in the ledgerfootprint it sounds like the transaction signature would be invalidated by an upgrade.
trail frigate
yes, this is true
spiral tree
It's a good feature to be able to lock a signature to code, but should be optional.
trail frigate
well, signatures aside, this is problematic from the fees standpoint...
spiral tree
Could you expand on the impact on fees?
trail frigate
I'm a bit hesitant about special-casing any entries for the sake of fee accounting. and this would require special-casing, both on the host and on the core side
(like if the entry is not in the footprint, we either 'discount' reading it or we need to artificially add it at the time we compute fees)
maybe we should pass the number of entries accessed as a separate field, that would avoid the discrepancy between the number of entries read.
but in general the transaction invalidation is an open question
footprint discrepancy during upgrade is one case of this problem, but there are others (e.g. we charge for the number of bytes read as well, and this might change for a multitude of reasons)
btw your scenario is actually even worse, because tx will get applied, but will fail
spiral tree
Yeah that's really bad hard to reason about in offchain protocols.
trail frigate
but I think that's a general problem with the footprint... without considering the contract updates (which should be reasonably rare events), some patterns are just hard to implement with the current footprint approach, e.g. when you're trying to do some multi-party operation in a 'lazy' fashion (i.e. when stuff happens only when all the parties have approved it)