Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Allow different ways of limitting the transactions in a block #1651

Closed
tomusdrw opened this issue Feb 1, 2019 · 2 comments
Closed

Allow different ways of limitting the transactions in a block #1651

tomusdrw opened this issue Feb 1, 2019 · 2 comments
Labels
I4-annoyance The client behaves within expectations, however this “expected behaviour” itself is at issue.
Milestone

Comments

@tomusdrw
Copy link
Contributor

tomusdrw commented Feb 1, 2019

Currently we limit the size of all extrinsics in the block (see #1581) and have the limit hardcoded in the runtime.

However interaction with other modules (namely srml-contract) may require some other mechanism of limitting the number of transactions. For instance contracts use up gas and we can have a block gas limit alike Ethereum.

Would be perfect if the weight of the transaction was also given to the pool to allow better (more optimal) allocation of extrinsics to block to maximise both: fee and utilisation

It's a follow up issue on #1354 (see comment #1354 (comment))

@tomusdrw tomusdrw added this to the 1.x series milestone Feb 1, 2019
@tomusdrw tomusdrw added the I4-annoyance The client behaves within expectations, however this “expected behaviour” itself is at issue. label Feb 1, 2019
@rphmeier
Copy link
Contributor

rphmeier commented Feb 1, 2019

When we're building blocks we also want to be informed of when this limit has been hit and how close we are to it. If the proposer can get back an Error::BlockFull(remaining_weight) and finish proposing / push more transactions withsum(new_txs.weight) <= remaining_weight that would work really well.

@tomusdrw
Copy link
Contributor Author

tomusdrw commented Oct 4, 2019

I guess that's resolved with #3157

@tomusdrw tomusdrw closed this as completed Oct 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
I4-annoyance The client behaves within expectations, however this “expected behaviour” itself is at issue.
Projects
None yet
Development

No branches or pull requests

2 participants