`TestAccount`

[harrysolovay]

How expensive is it to create a PublicKey from a PrivateKey? If it is cheap, might it be worthwhile to initialize a member publicKey: PublicKey whenever a PrivateKey is constructed (and to deprecate toPublicKey)?

I believe this would simplify usage in a number of ways.

Accessing test accounts

- let [
-   { privateKey: deployerPrivateKey, publicKey: deployerPublicKey, },
-   { privateKey: senderPrivateKey, publicKey: senderPublicKey },
- ] = Local.testAccounts as [TestPair, TestPair];

+ let [deployer, sender] = Local.testAccounts as [PrivateKey, PrivateKey]

Side note: #1516

Fewer naming decisions

This change would encourage access via the publicKey prop instead of via a separate variable (deployerPublicKey/senderPublicKey), thereby sparing the developer of choosing a name for the PublicKeys. Without the need to distinguish between public and private keys in the given scope, the developer can name the PrivateKey without a postfix

• deployerPrivateKey -> deployer
• senderPrivateKey -> sender

Additionally, this allows the developer to forgo extra work to share references to initialized PublicKeys.

- declare function something(privateKey: PrivateKey, publicKey: PublicKey): void
+ declare function something(privateKey: PrivateKey): void

Meanwhile, sign calls become more minimal.

- let pending = await deployTxn.sign([deployerKey, appKey]).send();
+ let pending = await deployTxn.sign([deployer, app]).send();

[mitschabaude]

Interesting suggestion. I mean, you do have the option of not using the public key in testAccounts, and converting it wherever you use them.

but many APIs, like Mina.transaction() only take a PublicKey and not a PrivateKey, for the reason that you usually don't have the private key when you want to use them in a production environment.

So it's convenient to have the public key at hand

[harrysolovay]

Good point. Thoughts on adding a TestAccount type, which would extend PrivateKey and initialize the publicKey member? Any other test-account-specific operations could go in that subclass.