Open MonsieurNicolas opened 1 year ago
Would transactions be compressed just at the overlay layer, or would they be compressed at the transaction layer itself? Would they remain compressed in archives?
It's a bunch of tradeoffs:
TransactionFrame
layer, it's compressed everywhere. Which means that we can charge fees for the compressed size in archives(we also have to evaluate this of course to make sure it's worth it - it probably is)
WASM is .. already a fairly dense code. XDR is not -- it's quite compressible. binary hashes are pure noise so typically not compressible. repeated constants I'm going to be working fairly hard on making less of a thing before we finalize, but they still might be a bit of a thing. I wouldn't rush to do this but if we find once all the low-hanging-fruit attempts to size minimize are done that we're still uncomfortably large, I wouldn't be opposed to running an experiment.
XDR is not
Could we gain more by using a more compact form of XDR and indicating that in some frame that the XDR within is a custom form? That's actually what issue https://github.com/stellar/rs-soroban-sdk/issues/415 was supposed to refer to. For example, Horizon uses what it calls a "compressed form" for an XDR type to reduce memory usage, where the compressed form has enums reduced to 1 byte instead of 4 bytes.
Soroban transactions can grow to be fairly large:
In both cases, compression might really help.
Tangentially related to https://github.com/stellar/rs-soroban-sdk/issues/415
We may be able to add this later, and special consideration should be taken as this means that in some situations (bridges, etc) - contracts will have to decompress transactions.