[P2P, Runtime] Update P2P & base config (part 2)

[bryanchriswhite]

Description

This is another of a series of PRs split out from #500. Here we update the base and P2P configs in preparation for the addition of the libp2p module.

Issue

#347

Type of change

Please mark the relevant option(s):

• New feature, functionality or library
• Bug fix
• Code health or cleanup
• Major breaking change
• Documentation
• Other

List of changes

• Replace consensus_port with port in P2P config.
• Update default P2P config port to from 8080 to 42069.
• Add use_libp2p field to base config.
• Add hostname field to P2P config.
• Update state hash test after modifying genesis (updated port numbers).

Testing

• make develop_test
• LocalNet w/ all of the steps outlined in the README

Required Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have tested my changes using the available tooling
• I have updated the corresponding CHANGELOG

If Applicable Checklist

• I have updated the corresponding README(s); local and/or global
• I have added tests that prove my fix is effective or that my feature works
• I have added, or updated, mermaid.js diagrams in the corresponding README(s)
• I have added, or updated, documentation and mermaid.js diagrams in shared/docs/* if I updated shared/*README(s)

[Olshansk]

Found one minor place where we still use "8080".

1. Can you do a global search for 8080-8084 and update all of them for consistency? E.g. see build/deployments/.env.example as well.

2. I know you tested it with the docker-compose localnet, but please double check that the k8s localnet works too. Bonus points: updating the github template to include it.

[bryanchriswhite]

Still have to add hostname to the k8s P2P config but I'm not sure how to do that just yet and won't have time in this sitting. Perhaps we can tag-team?

(cc @okdas @Olshansk)

[Olshansk]

Still have to add hostname to the k8s P2P config but I'm not sure how to do that just yet and won't have time in this sitting. Perhaps we can tag-team?

(cc @okdas @Olshansk)

Similar to the configs you updated in build/config/config1.json, you would do the same in build/localnet/manifests/configs.yaml and some of the other manifests. It seems like you already renamed the port from consensus_port but didn't add the hostname there.

Regarding Localnet and Tiltfile, a good starting point would be to look at build/localnet/templates/v1-validator-template.yaml.tpl which is used as a template by build/localnet/templates/v1-validator-template.sh. Since the naming convention for the scaling k8s validators is v1-validatorXXXX, that will likely need to be the hostname (don't quote me on this) for the cluster to resolve each container separately.

Hopefully that's a good enough starting point. Seeing how I'm OOO for ETH Denver next week, hopefully @okdas can help out with some pointers as well.

[Olshansk]

I just have one question (not a blocker but might involve a change).

Also, let's have @okdas review the Tiltfile changes as well to make sure I didn't miss anything there.

[okdas]

Unless you feel strongly about this, I would suggest keeping just one template file for StatefulSet and a Service to avoid creating more templates. I've supplied an example on how an existing pattern can be utilized to achieve the same result.

[okdas]

This looks great, thank you!

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	Secret	Commit	Filename
5841025	Generic High Entropy Secret	75e529d	build/config/genesis.json	View secret
5841025	Generic High Entropy Secret	75e529d	build/localnet/manifests/configs.yaml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>