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

Checklist for Doing a Public, Coordinated Schlesi Testnet #2

Closed
7 tasks
rauljordan opened this issue Apr 27, 2020 · 2 comments · Fixed by #26
Closed
7 tasks

Checklist for Doing a Public, Coordinated Schlesi Testnet #2

rauljordan opened this issue Apr 27, 2020 · 2 comments · Fixed by #26

Comments

@rauljordan
Copy link

Hi all,

As this multiclient effort matures, it's important for teams to be on the same page regarding what is needed before we can do a public, coordinated testnet launch like the @prysmaticlabs' topaz testnet here. Here are some tentative milestones before a lighthouse+prysm public testnet announcement should occur:

  • No skipping or minimal finality delays for N epochs
  • Testnet resilience to recover under N epochs without finality
  • Initial chain sync stress tested
  • Stress testing N number of validators, where N in (16k, 50k, 100k)
  • Slashable events occurring and successfully caught by slasher
  • Major node panics/crashes resolved across both clients
  • High chain participation > 97% as well as good profitability metrics for validators (less critical as can be improved over time)

Thoughts?

@prestonvanloon
Copy link

Please add validator activation and voluntary exits.

@q9f
Copy link
Member

q9f commented Apr 27, 2020

These points are looking sane. It still requires a lot of work for a long-term public multi-client testnet. Currently, Schlesi will probably either die or be reset every other week. Right now, it still requires a lot of patching and should mainly be used by client teams to nail down remaining issues.

Lighthouse is pretty good at supporting custom chain configurations, so it's easy to setup a couple of LH nodes with a Schlesi config. Unfortunately, there is no network config abstraction in Prysm that could be used currently. On my wish-list for Prysm would be either support for a custom network specification (yaml?) to override the default beaconChainConfig or a way to fully specify networks interally, i.e., having a --chain topaz and --chain schlesi flag. Could you add that to the list maybe?

Also, spec version is always a moving target and in case we would have to reset Schlesi or Topaz today, I would go for v0.11.2 instead of v0.12.0. This would also allow other clients that implement v0.11.x to catch up with these networks soon.

A realistic timeline for a public Schlesi launch would be >6 weeks at least, as I would carefully guess. I'm not sure what the timeline for v0.12.x looks like but I believe we will be still on v0.11.x in June. Correct me if I'm wrong.

@q9f q9f mentioned this issue Jul 22, 2020
@q9f q9f closed this as completed in #26 Jul 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants