Testing workflow

During blockchain application development, a "local" blockchain (generally consisting of a single node) is used to simulate deployment and interaction with smart contracts. When developing an application that leverages NEBRA UPA, a few extra components are required in order to test the end-to-end workflow in this simulation environment:

• UPA contracts must be deployed to the target chain, AND

• An aggregator must monitor the chain and supply aggregated proofs

The upa tool can be used to run a "development" aggregator, which aggregates all submitted proofs, and the UPA contracts can be deployed in a specific configuration which accepts these aggreagtions.

In this way, the complete UPA pipeline is available on the local development chain, and applications can be fully tested.

NOTE: In contrast to the production deployments, the development aggregator accept and aggregate invalid proofs. Submission of invalid proofs should be tested against a NEBRA UPA testnet deployment.

Unit testing using the dev-aggregator

Launch a development node

For example, in a separate terminal, run:

$ yarn hardhat node

NOTE: Unless otherwise specified, the upa command will attempt to connect to an RPC node at http://localhost:8545. If your development node listens on a different port, use the --rpc-endpoint option, or the RPC_ENDPOINT env variable (see ./setup.md) to specify the correct endpoint.

Create a deployer account

In order to deploy the UPA contracts and submit aggregated proofs, a keyfile for a funded account is required. A suitable keyfile can be created using the upa tool.

NOTE: This keyfile should only be used on development networks, not on live networks holding tokens of real value.

$ upa dev ethkeygen --keyfile upa-dev.keyfile

The keyfile can be recorded in a .env file for convenience:

$ echo KEYFILE=upa-dev.keyfile >> .env
$ echo KEYFILE_PASSWORD= >> .env

(Otherwise, it must be specified in subsequent commands)

NOTE: For development chains, the upa dev fund command can be used to fund the keyfile from a hosted account. (See upa dev fund --help)

Deploy a development version of UPA

$ upa deploy --verifier node_modules/@nebrazkp/upa/test/data/test.bin

This creates a upa.instance file in the current directory.

NOTE: The development version of the UPA contracts behave exactly the same as the production versions, except that they accept fake aggregation proofs. All other checks are performed identically. This allows any issues to be caught during local testing.

Launch a development aggregator

$ upa dev-aggregator

NOTE: By default dev-aggregator checks for a upa.instance file in the current directory. Therefore, if run from the same directory as deployment above, the instance file does not need to be specified. (See --help for how to specify the instance file).

Execute tests

Application tests can then be run against the local node, using upa.instance to initialize a UpaClient.

For example, if unit tests are written to always initialize a UpaClient from a upa.instance, they can be executed, pointing at the local node:

$ yarn hardhat test --network localhost

Similarly any CLI or browser client code can now be exercised against the local node.