Questions re the QANet test commands

[lampardlamps]

I've spun up a QANet node and all seems to run smoothly, very nice work. However, I've got some rudimentary questions re the instructions:

1. Is a snapps account different from a normal account? I was under the impression that they were the same?
2. Fee-payer-party is the one who specifies which party pays fees, not the one who actually pays? A bit confusing.
3. What does --receiver-amount mean? Is it the fee paid?
4. Why is --snapp-account-key private key file needed to CREATE a snapp account? Is this actually an upgrade command, which converts a normal account into a snapp one? I've used the same key file as the fee payer one and it worked btw.
5. Even though the create and update snapps account commands return similar verbose response like the instructions, I cannot see the transaction on the explorer.

[p-shahi]

cc: @deepthiskumar @mrmr1993 @psteckler

[deepthiskumar]

1. Is a snapps account different from a normal account? I was under the impression that they were the same?

It is a naming convention, I'd say. An account now has new fields that correspond to a zkApp smart contract being deployed. For example, the verification key, app state etc. If there is a verification key set for an account then the account (zkApp account) can have it's fields updated using a zkApp proof

2. Fee-payer-party is the one who specifies which party pays fees, not the one who actually pays? A bit confusing.

It is who actually pays the fees. The fee gets deducted from the account/public key specified in the fee-payer party.

3. What does --receiver-amount mean? Is it the fee paid?

This is an option in the cli testing tool to create zkApp accounts (tool/code renaming happening soon). So --receiver-amount is to specify how much to be transferred to this new account. As usual, for any new accounts, the actual balance is what remains after deducting the account creation fee. The account from which this amount is deducted is the fee payer and that is only because the testing tool is implemented that way. Really, any account could be sending that amount.

4. Why is --snapp-account-key private key file needed to CREATE a snapp account? Is this actually an upgrade command, which converts a normal account into a snapp one? I've used the same key file as the fee payer one and it worked btw.

This is needed for the testing tool to generate signatures for the zkApp party.

5. Even though the create and update snapps account commands return similar verbose response like the instructions, I cannot see the transaction on the explorer.

Those transactions need to be sent via graphQL as mentioned in the docs here https://github.com/MinaProtocol/mina/blob/feature/snapp-tool-doc/src/app/snapp_test_transaction/README.md. mina-snapp-test-transaction doesn't talk to the daemon. It is a testing tool that generates zkApp transactions for a trivial smart contract, intended to test the protocol. This won't be used in mainnet

Hope this helps!

[lampardlamps]

@p-shahi @deepthiskumar Many thanks indeed for the explanations. Sorry I'm still not clear on some of them:

1. Is a snapps account different from a normal account? I was under the impression that they were the same?

It is a naming convention, I'd say. An account now has new fields that correspond to a zkApp smart contract being deployed. For example, the verification key, app state etc. If there is a verification key set for an account then the account (zkApp account) can have it's fields updated using a zkApp proof

Say on the mainnet, after the hard fork, will every account existing on the ledger now automatically be a zkApp account too, or will it require a create-snapp-account operation?

2. Fee-payer-party is the one who specifies which party pays fees, not the one who actually pays? A bit confusing.

It is who actually pays the fees. The fee gets deducted from the account/public key specified in the fee-payer party.

to quote the instructions: The snapp transaction here has three parties: 1. the fee payer party which specifies who pays the transaction fees and how much, 2. A party that pays the account creation fee to create the new snapp snapp account which in this case is the same as the fee payer It doesn't sound like 1 is the same as 2?

3. What does --receiver-amount mean? Is it the fee paid?

This is an option in the cli testing tool to create zkApp accounts (tool/code renaming happening soon). So --receiver-amount is to specify how much to be transferred to this new account. As usual, for any new accounts, the actual balance is what remains after deducting the account creation fee. The account from which this amount is deducted is the fee payer and that is only because the testing tool is implemented that way. Really, any account could be sending that amount.

4. Why is --snapp-account-key private key file needed to CREATE a snapp account? Is this actually an upgrade command, which converts a normal account into a snapp one? I've used the same key file as the fee payer one and it worked btw.

This is needed for the testing tool to generate signatures for the zkApp party.

okay, the UX I was expecting was, with an input of create-snapp-account, it will generate key files (similar to generate-key-file that we have now) which is automatically a snapp account. Will this be the case for the mainnet?

5. Even though the create and update snapps account commands return similar verbose response like the instructions, I cannot see the transaction on the explorer.

Those transactions need to be sent via graphQL as mentioned in the docs here https://github.com/MinaProtocol/mina/blob/feature/snapp-tool-doc/src/app/snapp_test_transaction/README.md. mina-snapp-test-transaction doesn't talk to the daemon. It is a testing tool that generates zkApp transactions for a trivial smart contract, intended to test the protocol. This won't be used in mainnet

Hope this helps!

Definitely does, thanks!

[deepthiskumar]

Say on the mainnet, after the hard fork, will every account existing on the ledger now automatically be a zkApp account too, or will it require a create-snapp-account operation?

Nope, they'll remain non-zkapp until a zkApp transaction updates certain zkApp fields

to quote the instructions: The snapp transaction here has three parties: 1. the fee payer party which specifies who pays the transaction fees and how much, 2. A party that pays the account creation fee to create the new snapp snapp account which in this case is the same as the fee payer It doesn't sound like 1 is the same as 2?

A zkApp transaction is a list of parties where each party specifies an update, an account on which the update is to be performed and an authorization for performing the update. Each update is in a separate party, the first one is the fee payer party in which the update is the fee that is to be deducted. The second one is the party that in normal payments are referred to as a sender which funds the new account. In the tool, both the party updates are performed on the same account (same public_key)

okay, the UX I was expecting was, with an input of create-snapp-account, it will generate key files (similar to generate-key-file that we have now) which is automatically a snapp account. Will this be the case for the mainnet?

Are you referring to generate-keypair ? That just generates a keypair and not an account (with balance and other fields) in the ledger. You need to make a payment to the generated address for it to be in the ledger.
For zkApp accounts one still needs to generate keypairs for any new accounts they wish to create. They can then use the newly created address in a zkApp transaction that sends funds to it and updates the verification key and/or other zkApp related fields to create a zkApp account.
Re creating zkApp accounts in mainnet- This test tool will not be used for that. We are working on a separate flow (with snarkyJS, mina signer, a new tool for deployment) for creating zkapp accounts (aka deploying smart contracts) and zkApp transactions for other user interactions between a zkApp smart contract and the zkApp account corresponding to it