[ProjectTracking]: congestion control milestone 2

[akhi3030]

All information below was gathered by @Akashin. I am filling it out on his behalf.

Goals

Current status

Right now we have fully implemented Local Congestion Control, meaning that shard validators and RPC nodes will not be overloaded by transactions coming into their local transaction pools and receipts generated from local transactions.

Technically, this is achieved by introducing two limits:

• The size of the local transaction pool for each shard is limited to 100MB, after the limit is reached, the node stops accepting new transactions. This limit is configurable
• The size of the delayed receipts queue is limited to 20,000 receipts, after the limit is reached, the chunk producer will stop including new receipts in the chunk. This limit is not configurable but is not yet enforced by consensus

For the exact implemented features see https://github.com/near/nearcore/milestone/26?closed=1

Next steps

Local Congestion Control only limits local congestion sources but ignores global sources of congestion such as receipts incoming from the other shards. The Global Congestion Control milestone aims to address this by introducing a global limit on the number/size of delayed receipts that are present in the queues across all shards.

Technically, this can be achieved through:

• Communicating information about the per-shard size of delayed receipts by including it in the chunk header
• Chunk producers should stop including new receipts in the chunk when the aggregate size of delayed receipts across all shards is more than some threshold (e.g. 100MB)

The high-level outline of technical work can be found at https://github.com/near/nearcore/milestone/27

See the meeting notes for the relevant discussion.

As a nice to have, we can enforce this constraint at a protocol level, though this is arguably a low-priority attack vector.

Links to external documentations and discussions

• State of congestion control in September 2023. This document also provides links to additional docs.
• Zulip thread

Estimated effort

TODO. Nominally all the engineering effort should be in code owned by the core team. In the past engineers from the runtime team have also contributed and may contribute in future as well.

Assumptions

TODO

Pre-requisites

TODO

Out of scope

TODO. I believe that this project should just be for implementing global congestion control. The related project for transaction priority should be tracked in a different project.

[jakmeier]

I suggest we close this issue in favour of its successor #48