Limit number of accepted transactions based on congestion levels #8877
Comments
aborg-dev
added
the
A-congestion
|
Comment from Bowen: We will need to decide whether this capacity is measured in gas or number of receipts. We can start with something simple. |
|
Right now, when a transaction is accepted by a validator it is only forwarded to a few other validators. It would be interesting to see whether this indeed would be the case in the congestion test #8920 |
…9222) This PR introduces a soft limit on the number of delayed receipts in each shard. The limit is around 10000 delayed receipts to make sure this is enough to saturate the chunk capacity even if receipts are very small. The largest number of delayed receipts that we've seen in the last 3 months is around 400 and it stays at 0 most of the time. In the future, we would be also using other signals like the size of delayed receipts, but this information will have to be first computed and stored in the chunk headers/trie store and will be done in #9228. Addresses: #8877
|
This is implemented with #9222, now we have a per-shard limit of ~20000 delayed receipts after which chunk producers will stop including more transactions into the chunks that they produce. |
…9222) This PR introduces a soft limit on the number of delayed receipts in each shard. The limit is around 10000 delayed receipts to make sure this is enough to saturate the chunk capacity even if receipts are very small. The largest number of delayed receipts that we've seen in the last 3 months is around 400 and it stays at 0 most of the time. In the future, we would be also using other signals like the size of delayed receipts, but this information will have to be first computed and stored in the chunk headers/trie store and will be done in #9228. Addresses: #8877
…9222) This PR introduces a soft limit on the number of delayed receipts in each shard. The limit is around 10000 delayed receipts to make sure this is enough to saturate the chunk capacity even if receipts are very small. The largest number of delayed receipts that we've seen in the last 3 months is around 400 and it stays at 0 most of the time. In the future, we would be also using other signals like the size of delayed receipts, but this information will have to be first computed and stored in the chunk headers/trie store and will be done in #9228. Addresses: #8877
…ear#9222) This PR introduces a soft limit on the number of delayed receipts in each shard. The limit is around 10000 delayed receipts to make sure this is enough to saturate the chunk capacity even if receipts are very small. The largest number of delayed receipts that we've seen in the last 3 months is around 400 and it stays at 0 most of the time. In the future, we would be also using other signals like the size of delayed receipts, but this information will have to be first computed and stored in the chunk headers/trie store and will be done in near#9228. Addresses: near#8877
This is a tracking issue for work on limiting how many transactions chunk producers will include into the chunk based on the general congestion level in the system.
This is not expected to be a full solution for multi-shard scenario (because of cross-shard incoming receipts), but it would be on a critical path towards providing a cap on the memory usage of delayed receipts and on the wait time for accepted transactions.
Ideas to try
The text was updated successfully, but these errors were encountered: