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

Who are the testnet witnesses? #22

Open
theoreticalbts opened this issue Dec 12, 2017 · 2 comments
Open

Who are the testnet witnesses? #22

theoreticalbts opened this issue Dec 12, 2017 · 2 comments

Comments

@theoreticalbts
Copy link
Contributor

theoreticalbts commented Dec 12, 2017

This is more of a deployment issue than a tinman issue, but I'm putting this here for lack of a better place.

Who are the testnet witnesses?

There are two possible answers:

  • (a) We (Steemit) run the testnet witnesses. This has advantages of being already implemented, allowing us to test various scenarios of witness behavior, and allows us to quickly and efficiently upgrade the testnet release (or make other changes that require witnesses to do something) without having to coordinate with 20 external individuals.
  • (b) The testnet witnesses are run by the same people who run the main net witnesses. This has the disadvantage of needing additional coordination with 20 external people, and changes to tinman transaction generation will be needed to give votes to them, and someone will have to operate witness nodes for any witnesses that can't be contacted or choose not to participate in the testnet. But it has the advantage of being most similar to the production environment and allowing current witnesses to test their witness-specific setup with the new code.

My feelings on the above options are as follows:

  • (a) is better for the immediate short term, since it's a shorter route to MVP.
  • We should have a long-running type (b) testnet.
  • It would be good to define a path by which a type (a) testnet can morph into a type (b) testnet.
  • It would be good to be able to create a type (a) testnet with a minimum amount of developer time.
  • Maybe we should have an automated script that, over the weekend, launches a new type (a) testnet using the latest develop.
  • We should probably have a centralized place to track past, current and future testnets (IP addresses of seed nodes, purpose of the testnet, planned duration, commit hash of a steemd version that should be able to connect to it, any API endpoints operated by Steemit, whether it's type (a) or (b), etc.)
@mvandeberg
Copy link

mvandeberg commented Dec 12, 2017

I believe the genesis conversion process covers this question (#17)

All witnesses will be copied over, setting their signing key to initminer's key. Then, we will vote for the top 30 witnesses with initminer. This will allow us to produce blocks as the witnesses. Because their active auth will still be valid (as the copied posting auth), they can change the signing key and take over whenever they want.

By voting for the top 30, it means we only need 2/3 of witnesses to fully participate and allows some of the runner up witnesses to be active on the test net.

This was referenced Dec 12, 2017
@bobinson
Copy link
Contributor

bobinson commented Oct 8, 2018

(b) The testnet witnesses are run by the same people who run the main net witnesses.

IMHO this is the best choice in assuring community involvement in the long term & I will be ready to extend resources.

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

No branches or pull requests

3 participants