compress tx bytes with zlib compression #28
Conversation
SEQ-161 Compress incoming transactions using zlib compression
op-translator assumes that the transactions will be gzip-compressed, so we should handle that here too AC
|
daniilrrr
force-pushed
the
daniil/SEQ-161-brotli-for-txn-list
branch
2 times, most recently
from
458aafc to
b180601
Compare
metabased-sequencer/interceptor/src/infrastructure/zlib_compression.rs
Outdated
Show resolved
Hide resolved
metabased-sequencer/interceptor/src/infrastructure/zlib_compression.rs
Outdated
Show resolved
Hide resolved
|
|
||
| async fn process_bulk_transactions_compressed(&self, tx: Vec<Bytes>) -> Result<(), Self::Error> { | ||
| // Note: Compression starts being beneficial at ~5 transactions | ||
| let compressed_txs = compress_transactions(&tx)?; |
There was a problem hiding this comment.
I wouldn't do this here, because the Chain should just pass in whatever bytes it gets, it should not be reponsible for doing the compression - it already is responsible for writing into the smart contract.
There was a problem hiding this comment.
ok that makes sense, we should do it at the endpoint level.
currently we only have the send_raw_transaction endpoint which maps -> process_transaction contract call.
We have no endpoint to map to the process_bulk_transactions or process_bulk_transactions_compressed, which makes sense because those will only become relevant once we have load balancing and Mempooler, which will be after private testnet
There was a problem hiding this comment.
Created SEQ-248 to track this throughout PR. I don't like pushing commented code but I think here it's the best thing to do, since we will work on bulk txns relatively soon
daniilrrr
force-pushed
the
daniil/SEQ-161-brotli-for-txn-list
branch
from
b5f6357 to
4ad869d
Compare
daniilrrr
force-pushed
the
daniil/SEQ-161-brotli-for-txn-list
branch
from
4ad869d to
2748e6a
Compare
Ticket
What does this PR do?
zlib, which matches op-node's internal implementation.zlibsupport for de/compression of txn/sIntroducedprocess_bulk_transactions_compressedto compress inputDoes this PR introduce any breaking changes (API/schema)?
It depends on the existence of a new function in the contract in the form of
function processBulkTransactionsCompressed(bytes calldata compressedTxns) public;Do any environment variables need to be updated or added before deployment?
How can this PR be tested?