[Testing] Prefer pre-generated keys in tests

[bryanchriswhite]

Objective

Enabling faster and more deterministic tests.

Origin Document

Goals

• Ability to pre-generate an arbitrary number of keys
• Pre-generated keys are accessible via vanilla go imports (see: storj/common testidentity pkg)
• Pre-generated keys are tracked in version control (same keys everywhere: devs, CI, etc.)

Deliverable

• [x] ~~Add a make target which generates the keys, output as go source code.~~ Load existing pre-generated keys from private-keys.yaml
• [ ] Add a package (e.g. testkeys; also see #609) which exports a means by which to retrieve the pre-generated as cryptoPocket.PrivateKeys
  • I think the iterator pattern is nice for this because it fits well with our use case as we typically don't want to reuse keys (identity), across nodes for example.
  • It would be prudent to ensure that we can also retrieve specific identities, I think via index should suffice.

Non-goals / Non-deliverables

• Refactoring existing tests to use pre-generated identities.

General issue deliverables

• [ ] Update the appropriate CHANGELOG(s)
• [ ] Update any relevant local/global README(s)
• [ ] Update relevant source code tree explanations
• [ ] Add or update any relevant or supporting mermaid diagrams

Testing Methodology

• [ ] All tests: make test_all
• [ ] LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md

---

Creator: @bryanchriswhite Co-Owners: @deblasis

[Olshansk]

@bryanchriswhite Though it is not pre-generated, we do have runtime/test_artifacts/keygen/keygen.go which enables determinstic keys:

func (k *keyGenerator) SetSeed(seed int) (teardown func()) {
	k.privateKeySeed = seed
	return func() {
		k.reset()
	}
}

func (k *keyGenerator) Next() (privateKey, publicKey, address string) {
	k.privateKeySeed += 1 // Different on every call but deterministic

Do you think that's enough in terms of our testing utility to validate the need for this scope of work?

[bryanchriswhite]

@Olshansk thanks for surfacing that! :raised_hands:

That should address the determinism aspect. The only other improvement I was anticipating would potentially be a speed improvement in CI (depending on "things" which I haven't looked into yet).

This issue was based on observations I made while debugging tests. It's definitely not urgent but I'm not sure how important it is (or could be, depending on "things").

I think the MVC here is to just go after the second delivarable. We already have ~1K keypairs in private-keys.yaml which we could then use in unit tests.