Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(docs): use master link of NEP-539 #12183

Merged
merged 1 commit into from
Oct 2, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/architecture/how/receipt-congestion.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ For a finite amount of time, we can accept more inflow than outflow, we just hav

Next, we look at ideas one at a time before combining some of them into the
cross-shard congestion design proposed in
[NEP-539](https://github.com/near/NEPs/pull/539).
[NEP-539](https://github.com/near/NEPs/blob/master/neps/nep-0539.md).

## Idea 1: Compute the minimum max-flow and stay below that limit

Expand Down Expand Up @@ -185,7 +185,7 @@ that are not on the critical path.

## Putting it all together

The proposal in [NEP-539](https://github.com/near/NEPs/pull/539) combines all
The proposal in [NEP-539](https://github.com/near/NEPs/blob/master/neps/nep-0539.md) combines all
ideas 2, 3, and 4.

We have a limit of how much memory we consider to be normal operations (for
Expand All @@ -208,4 +208,4 @@ it back cannot lead to a slowed down global throughput.
Another design decision was to linearly interpolate the limits, as opposed to
binary on and off states. This way, we don't have to be too precise in finding
the right parameters, as the system should balance itself around a specific
limit that works for each workload.
limit that works for each workload.
Loading