Add testnet account json

[JesseAbram]

This allows for a json file to be given endowed accounts, this way accomplices can add them to our network

[HCastano]

I left a couple of questions.

This will be nice so that people don't need to add accounts straight to the Rust code if they want to get some tokens.

[HCastano]

Let's not litter the top level of the repo with this.

I'm tempted to say that we should put it in chains, but that might be misleading. Maybe it can live in a res directory in node/cli/src/chain_spec/?

[ameba23]

Let's not litter the top level of the repo with this.

I'm tempted to say that we should put it in chains, but that might be misleading. Maybe it can live in a res directory in node/cli/src/chain_spec/?

Another option would be to not have this file - and if we fail to open this file, we make the list of accounts to add be an empty vector. So we only need this file if there is something to put in it.

[HCastano]

Any reason why you went with JSON here instead instead of just a flat text file?

[JesseAbram]

ya I like json better, you can format it and it is usually colour coated and can enforce format better

[HCastano]

While the docs do say this, I'd make this error a bit more descriptive.

[HCastano]

Could be useful to print out what address we failed to parse as part of the error message

[HCastano]

Are you sure we want to_string_lossy() here? From what I understand it would mean that we accept paths with �

[ameba23]

That would only happen if get_project_root found a path which contained invalid utf8 which is very unlikely so i think this is fine.

Strictly speaking though its probably better to not convert to a string - as File::open can take a PathBuf:

let mut file = File::open(get_project_root().expect("Error getting project root").join("testnet-accounts.json"))

[ameba23]

Looks good to me. Although just to be clear, the use-case for this is the local docker-compose setup, right? If i remember rightly our deployed devnet doesn't use the pre-endowed accounts.

If so i guess the use case would be for trying things out with a lot of users, eg: benchmarking. For that this would be really useful. But its not so clear to me why this is useful for accomplices - why wouldn't they just use the existing endowed accounts?

[ameba23]

That would only happen if get_project_root found a path which contained invalid utf8 which is very unlikely so i think this is fine.

Strictly speaking though its probably better to not convert to a string - as File::open can take a PathBuf:

let mut file = File::open(get_project_root().expect("Error getting project root").join("testnet-accounts.json"))

[HCastano]

Looks good to me. Although just to be clear, the use-case for this is the local docker-compose setup, right? If i remember rightly our deployed devnet doesn't use the pre-endowed accounts.

If so i guess the use case would be for trying things out with a lot of users, eg: benchmarking. For that this would be really useful. But its not so clear to me why this is useful for accomplices - why wouldn't they just use the existing endowed accounts?

So the use case that I understand here is that we would like accomplices to have endowed accounts which are persisted between testnet resets. In order to do that in such a way that doesn't require anybody to make a PR into the Rust code we can just keep a list of accomplice accounts instead.

For other use cases, e.g benchmarking I would prefer to use a more Rust based approach.

[ameba23]

So the use case that I understand here is that we would like accomplices to have endowed accounts which are persisted between testnet resets. In order to do that in such a way that doesn't require anybody to make a PR into the Rust code we can just keep a list of accomplice accounts instead.

Ah ok makes sense - so testnet does use the endowed accounts. Yeah i can see that would be useful.