From c8f64ea23422dc8a941cb52312cce69af37869a2 Mon Sep 17 00:00:00 2001 From: TinyFoxy Date: Wed, 2 Oct 2024 16:33:05 +0800 Subject: [PATCH] docs: use master link of nep-539 --- docs/architecture/how/receipt-congestion.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture/how/receipt-congestion.md b/docs/architecture/how/receipt-congestion.md index 0b0010a055d..34f51eec3eb 100644 --- a/docs/architecture/how/receipt-congestion.md +++ b/docs/architecture/how/receipt-congestion.md @@ -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 @@ -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 @@ -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. \ No newline at end of file +limit that works for each workload.