You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context and scope
As a DOS protection mechanism, Avalanche nodes are commonly configured to drop transactions from the mempool with a nonce greater than the latest accepted nonce by some amount (by default this is 25). If, say 26 transactions from the same account are submitted at once, then this limit will be exceeded, and the 26th transaction will be dropped from the mempool. This would cause the corresponding Warp message to fail to be delivered. #321 ensures that this is recoverable, but we should implement a throttling or queueing strategy to prevent this scenario altogether. #256 also mitigates this scenario by distributing the load across many keys.
Open questions
The relayer would need to monitor block production on the destination so that it can distribute transactions over multiple blocks. A time based approach may suffice, but relies on assumptions of the destination's consensus parameters. A more robust approach would be to listen for new blocks and meter transactions at the same rate that blocks are produced.
The text was updated successfully, but these errors were encountered:
Context and scope
As a DOS protection mechanism, Avalanche nodes are commonly configured to drop transactions from the mempool with a nonce greater than the latest accepted nonce by some amount (by default this is 25). If, say 26 transactions from the same account are submitted at once, then this limit will be exceeded, and the 26th transaction will be dropped from the mempool. This would cause the corresponding Warp message to fail to be delivered. #321 ensures that this is recoverable, but we should implement a throttling or queueing strategy to prevent this scenario altogether. #256 also mitigates this scenario by distributing the load across many keys.
Open questions
The relayer would need to monitor block production on the destination so that it can distribute transactions over multiple blocks. A time based approach may suffice, but relies on assumptions of the destination's consensus parameters. A more robust approach would be to listen for new blocks and meter transactions at the same rate that blocks are produced.
The text was updated successfully, but these errors were encountered: