Speed up private network start time with many participation keys.

[winder]

Problem

Private network startup is slow. A major culprit is Falcon key generation.

The Falcon key generation phase is very slow, so most private networks need to use a small number of participation keys. This causes networks to quickly stall, especially in tests that use dev-mode to quickly generate many rounds.

Solution

This problem could be solved by providing pre-generated keys when creating a new private network:

• A new option to goal network create to accept a path to pre-generated keys.
• Pre-generating keys could be a new goal network subcommand.

There are other alternatives, for example:

• Increasing the state proof round interval from 256 so that fewer falcon keys are needed for larger key sets.
• An option to disable state proofs altogether. This probably isn't viable, I believe we have code which requires falcon keys to be present now.
• Deterministic accounts should be achievable by providing a way to provide the random number seed when generating accounts.

[winder]

Related to #2048

[algoanne]

Falcon keys are separate from participation keys. Falcon key generation is the slow part.

[algoanne]

We should also write a little benchmark for this, since it's a performance-related issue. Doesn't have to be super robust but we would like to know just how much it saves us.

[jannotti]

Do we generate them concurrently today?

[mciccarello]

unsubscribe