The following is @hashkode idea on how to handle both transactions and bundles at the sequencer:
- two separate sub pools at the sequencer for bundles (now) and transactions (later)
- the sub pools are synced via retransmission for a defined number of elements in a defined period to the bundlemerger
- the bundlemerger can then replicate the sub pools up until the defined depth/N; this could happen in a ringbuffer for instance, to avoid frequent allocations
The actual merging operation could then be a straighforward loop:
- pop from each ringbuffer
- do sanity check on the elements
- weigh bundle vs. transaction
- merge the winner
- continue
This would allow the bundlemerger to discard non-valid transactions or too big (*1) of a bundle and fill up the block with individual transactions.
*1: We should define then the filling logic for the block, i.e. if an oversized bundle can be replaced by the next bundle in the queue or only by individual transactions.
Need to adapt the implementation a bit for that. Right now, the endpoint only receives every bundle from the pool exactly once and would need to maintain a local datastructure. However, that‘s already feasible in my opinion and can be done with the code from "pool.go" in the sequencer very easily.
The following is @hashkode idea on how to handle both transactions and bundles at the sequencer:
The actual merging operation could then be a straighforward loop:
This would allow the bundlemerger to discard non-valid transactions or too big (*1) of a bundle and fill up the block with individual transactions.
*1: We should define then the filling logic for the block, i.e. if an oversized bundle can be replaced by the next bundle in the queue or only by individual transactions.
Need to adapt the implementation a bit for that. Right now, the endpoint only receives every bundle from the pool exactly once and would need to maintain a local datastructure. However, that‘s already feasible in my opinion and can be done with the code from "pool.go" in the sequencer very easily.