feat: lower ENR_OFFER_LIMIT from 4 to 2

[KolbyML]

What was wrong?

It takes 1,200 days to gossip a state snapshot

How was it fixed?

By lowering ENR_OFFER_LIMIT it would drop our time to gossip a state snapshot from 1,200 days to 600 days.

The trade offs of this approach is

• we are gossipping it to less nodes, so there is a lower chance of the gossip succeeding, but this isn't an issue because our new Census/enr choosing mechanism will statistically pick the most optimal nodes. So gossiping to less shouldn't have that big of an impact.

I would say this solution makes sense due to Neighborhood gossip https://github.com/ethereum/portal-network-specs/blob/master/portal-wire-protocol.md#neighborhood-gossip so since we now have a higher likely hood of gossiping the data that nodes that do want it, we can rely on Neighborhood gossip to do the rest of the work.

I choose 2 instead of 1 to still be somewhat conservative, it might make sense to do 1 because it would heavily lower our costs, but I think it is good to still have some redundancy

[morph-dev]

This is the default value of the cli flag (enr-offer-limit).

I have a feeling that 4 is better default value, and that 2 should be set on bridges that would otherwise take very long time. So why not do that instead?

I'm not strongly opinionated on this, so it's up to you.

[KolbyML]

This is the default value of the cli flag (enr-offer-limit).

I have a feeling that 4 is better default value, and that 2 should be set on bridges that would otherwise take very long time. So why not do that instead?

I'm not strongly opinionated on this, so it's up to you.

I think it makes sense as a default because of the size of the state. Because of Neighborhood gossip and our new weighted census mechanism, the odds of a offer's succeeding is very high. All we need is 1 successful offer and Neighborhood gossip will seed the rest. So if we tried to gossip that data 10 minutes later, from me running a bridge it will always return 0/4 gossips.

Lowering bridge requirements by 2x is a massive cost reduction. Also with the improvements to the bridge as stated earlier 4 seems a little over kill

[carver]

Two feels insufficient in an adversarial environment, which we need to be prepared for. (For example, an actor that wants to defeat our bridge by accepting and then dropping data). I expect we'll keep tweaking this in the future, but no objection in the short term, as we just work to get data distributed in a friendly environment the first time