# Blockchain / VM integration points

## Generate deployment

* [x] `Program::from_str` : parse an aleo instructions source code string
* The program struct needs to support getting a program id, list of function names, etc
* ideally this parsing would fail gracefully when the program string contains features not supported.
* [ ] `sythesize(program) -> HashMap<function_name, (ProvingKey, VerifyingKey)>`
* generate a verifying key for each function in the given program.

## Verify deployment
* [ ] When synthetizing verifying keys snarkvm also produces a [certificate](https://github.com/Entropy1729/snarkVM/blob/6f601cb1458b65e035f6d9043475cc543c8acfb1/vm/compiler/src/snark/certificate/mod.rs) that's used to verify the deployment (the verifying key generation itself).
* We may need something similar if we expect the verifying key to be invalid or forgeable.
* We may skip it completely if we reach the conclusion that key synthesis can happen completely on the nodes. (this will depend on how slow the process is and how big the keys are)
* [ ] We currently call this [verify deployment code](https://github.com/Entropy1729/snarkVM/blob/6f601cb1458b65e035f6d9043475cc543c8acfb1/vm/compiler/src/process/stack/deploy.rs#L49-L141), but we don't have a strong dependency on it. We can just remove that validation if it's deemed unnecessary or we don't want to worry about it yet.

## Generate execution
* [x] (we sort of have this) Conceptually we need something like this: `execute(private_key, program, funcion_name, inputs, proving_key) -> (outputs, proof, fee)`
* In our current implementation, we don't store proving keys locally during deploys, we just re-generate them on the fly for each execution. We can go either way, probably what makes the UX better in the long run.
* We currently rely on [Stack.execute_function](https://github.com/Entropy1729/snarkVM/blob/6f601cb1458b65e035f6d9043475cc543c8acfb1/vm/compiler/src/process/stack/execute.rs#L95-L431) for execution generation. This has several extra checks, e.g. that no credits are produced (except for coinbase puzzles). For each of those checks we should decide if:
* the vm will handle it
* it should be extracted out to the blockchain layer
* we don't care about it
* snarkvm execution requires an [authorization](https://github.com/Entropy1729/aleo-consensus/blob/9716db72b7df47e402b6f2dd373f183815dc0bb1/src/lib/vm/mod.rs#L192) step, using the account's private key, but we're not sure what's it used for. We may need something similar.
* Instead of (outputs, proof, fee) we currently use snarkvm's Transition object. We can either stop using it or porting a subset of it over to the blockchain.
* Notice we need the execution output to include the fee (the difference between input and output gates). This assumes that those couldn't be calculated after the fact because outputs could be encrypted. If that's not the case then fees could be omitted from the execution output and calculated directly by the blockchain.
* In the case of output records, we need those to include the ciphertext and the record commitment

## Verify execution

* [x] To verify an execution we currently have a bunch of copied [code from snarkvm](https://github.com/Entropy1729/aleo-consensus/blob/9716db72b7df47e402b6f2dd373f183815dc0bb1/src/lib/vm/mod.rs#L56-L145) but as far as we can tell it should be enough if VMtropy provides us with something like: `verify(verifying_key, inputs, outputs, proof) -> bool`

## Other functionality we use
* [ ] [PrivateKey, ViewKey and Address](https://github.com/Entropy1729/aleo-consensus/blob/9716db72b7df47e402b6f2dd373f183815dc0bb1/src/account.rs#L20-L22) generation for an account. View keys are currently used to support record decryption, and private keys are used for generating Authorization during execution.
* [ ] `record.decrypt(&credentials.view_key)`
* [ ] `record.is_owner(&credentials.address, &credentials.view_key)` (if this is too much work we can fallback to just attempt decrypt for this purpose)
* [ ] Generate credits programatically: we need a way to produce a new record commitment and ciphertext from an owner address and gates. We also need to be able to generate the nonce for the record deterministically in all nodes.
* alternatively, provide a lightweight way to run a program to get its outputs (without the proof)
* [x] `Value::from_str` to parse cli args into snarkvm Inputs that can be passed to execution functions
* [ ] `Record<Testnet3, Ciphertext>::from_str` to use as CLI inputs of encrypted records
* [ ] (this is in the works) We use [records with custom](https://github.com/Entropy1729/aleo-consensus/blob/HEAD/aleo/token.aleo) fields for a few tests
* [ ] We currently depend on `Program::credits()` being pre-loaded as well as their keys. We should move this over to the blockchain side.

## VMtropy notes

- We don't have certificate/deployment verification in general
- Our `execute` function does not take a private key as input, as our vm doesn't even know about private keys. This private key might be used for signing and delegating execution (most likely when generating the `Authorization`) but my guess is it should also be used to do a ZK proof that you are the owner of the record you're spending (i.e. prove you know the private key for the given address). No idea where that would live or if it exists in snarkVM.
- `execute` also doesn't output a `fee` on our VM. Once again, it doesn't currently know what fees are.
- None of the checks done in `Stack.execute_function` are performed by our VM; they should probably live on an upper layer in my view
- `In the case of output records, we need those to include the ciphertext and the record commitment`. We don't currently have any of this, we just return regular records. Supporting this will require looking into how view key encryption works and how nonces are generated (in aleo this involves some transition view key and what not, I don't know how that works).
- `Other Functionality we use`. Anything related to private/view/public keys and encryption/decryption is not currently supported by our VM.