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

Set MIN_ATTESTATION_INCLUSION_DELAY to 1 #1157

Merged
merged 1 commit into from Jun 17, 2019
Merged

Set MIN_ATTESTATION_INCLUSION_DELAY to 1 #1157

merged 1 commit into from Jun 17, 2019

Conversation

JustinDrake
Copy link
Collaborator

@JustinDrake JustinDrake commented Jun 9, 2019

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

See item 7 of #1054. We should consider increasing the slot duration as well.
@djrtwo
Copy link
Contributor

djrtwo commented Jun 10, 2019

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

@JustinDrake
Copy link
Collaborator Author

JustinDrake commented Jun 10, 2019

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
Copy link
Contributor

djrtwo commented Jun 10, 2019

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
Copy link
Contributor

vbuterin commented Jun 12, 2019

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
Copy link
Contributor

djrtwo commented Jun 13, 2019

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
Copy link
Collaborator Author

JustinDrake commented Jun 13, 2019

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.)

@JustinDrake JustinDrake added the milestone:June 30 freeze 🥶 Phase 0 spec freeze for long-lived cross-client testnet label Jun 15, 2019
@vbuterin
Copy link
Contributor

vbuterin commented Jun 17, 2019

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
Copy link
Collaborator Author

JustinDrake commented Jun 17, 2019

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.

djrtwo
djrtwo approved these changes Jun 17, 2019
@djrtwo djrtwo merged commit e80d363 into dev Jun 17, 2019
6 checks passed
@djrtwo djrtwo deleted the JustinDrake-patch-13 branch Jun 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
milestone:June 30 freeze 🥶 Phase 0 spec freeze for long-lived cross-client testnet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants