Soroban: should we support compressed transactions?

stellar / stellar-core

Reference implementation for the peer-to-peer agent that manages the Stellar network.

https://www.stellar.org

Other

3.11k stars 962 forks source link

Soroban: should we support compressed transactions? #3645

Open MonsieurNicolas opened 1 year ago

MonsieurNicolas commented 1 year ago

Soroban transactions can grow to be fairly large:

they may contain raw WASM blobs
they reference certain keys multiple times over (contract ID is repeated in footprints and other places)

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.

leighmcculloch commented 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?

MonsieurNicolas commented 1 year ago

It's a bunch of tradeoffs:

If we compress them at the TransactionFrame layer, it's compressed everywhere. Which means that we can charge fees for the compressed size in archives
all systems have to decompress, meaning more complexity (even though this is probably less of a pain than the xdr decoder dependency for example)

(we also have to evaluate this of course to make sure it's worth it - it probably is)

graydon commented 1 year ago

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.

leighmcculloch commented 1 year ago

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.