Set MIN_ATTESTATION_INCLUSION_DELAY to 1

[JustinDrake]

See item 7 of #1054. We should consider increasing the slot duration as well.

[djrtwo]

My opinion is to do nothing with this constant until adequate production network testing is done on a couple of clients.

[JustinDrake]

I'd set MIN_ATTESTATION_INCLUSION_DELAY to 1 and keep SECONDS_PER_SLOT to 6 so that the cross-clients testnets (i.e. testnets based on the frozen spec) are tested in worst-case conditions.

[djrtwo]

That's reasonable. My point is that we need to stress test them in all sorts of ways (fast slot times, quick inclusion delay, etc) so I don't want to get in the habit of adjusting these constants right now because of what we assume is going to work before testnets.

[vbuterin]

MIN_ATTESTATION_INCLUSION_DELAY is a protocol design parameter, not a performance parameter (ie. it's more like TARGET_COMMITTEE_SIZE than the slot duration). When we were discussing decreasing MIN_ATTESTATION_INCLUSION_DELAY to 1, it was in the context of simultaneously increasing the beacon slot duration to 12. So IMO it's reasonable to set it to 1 now.

[djrtwo]

When we were discussing decreasing MIN_ATTESTATION_INCLUSION_DELAY to 1, it was in the context of simultaneously increasing the beacon slot duration to 12

I think I'm missing something -- we have not adjusted slot duration to 12.

[JustinDrake]

we have not adjusted slot duration to 12

I'm cautiously optimistic we can safely set the beacon slot duration at 6 seconds, MIN_ATTESTATION_INCLUSION_DELAY == 1, and the shard slot duration at 3 seconds. I guess I'm at least curious to see how the testnets fare in these conditions. (Part of my optimism is that in the short- and medium-term we won't have that many validators/nodes. And in the long I expect solutions in the vein of Handel to help a lot.)

[vbuterin]

I'm leaning toward 12 / 3 or even 16 / 4 😆 (BTW did I mention that I favor staggering shard block periods so that it becomes possible to achieve arbitarily fine-grained initial-confirmation times at layer 2?)

But we do need to decide MIN_ATTESTATION_INCLUSION_DELAY now imo; the block times are just a tweak, but whether this parameter is 1 or 2 or 4 affects validator logic and the rhythm of the chain pretty fundamentally. I'm leaning toward 1 for simplicity.

[JustinDrake]

I'm leaning toward 1 for simplicity.

I'm happy with 1 for the freeze :) Can be adjusted upwards if necessary during post-freeze finalisation.