Stress test

[konradkonrad]

This adds go test-runnable testcases to stress- and edge case-test a shutter on gnosis chain live system, in an end-to-end fashion. It does however not use the encrypting-rpc-server, but instead submits transactions directly to the sequencer contract.

As a pre-requisite, an account with sufficient "ETH" (or other gas tokens corresponding to the chain the system is deployed on) is required. Its private key needs to be available hex encoded in an environment variable STRESS_TEST_PK=0xcaffee….

The most notable test cases are

• TestStressManyNoWait, which sends a large number of shutterized transfers at once, in order to test the limits of decryption key generation and propagation on the keyper side, as well as decryption performance on the validator side.
• TestInception, which sends shutterized transactions inside shutterized transactions.
• TestStressExceedEncryptedGasLimit, which tests that there is a limit to the gas that can be used in encrypted transactions per block.

Most other test cases are very simple, and could be considered basic functionality "smoke tests".

Note: Due to the live nature of the test environment, not all PASSing tests can show the absence of errors. For example:

TestStressExceedEncryptedGasLimit 1) The test relies on a hardcoded value for the limit. If the parameters of the live system change, that value may be outdated. 2) The test shall PASS if not all transactions end in the same shutterized block. It can however happen, that an external entity also submitted transactions and therefore the assumed correct behavior happened only by chance.

Also: Since we have no insight to the validator, we rely on timeouts for waiting for transactions to be included on-chain. Additionally, we can not reliably check for failing transactions.

In short: this PR is to some extent ab-using the go test environment to allow us excecuting these tests.

There are also two special "Test…" functions, that do not test anything, but can be used for house keeping:

• TestEmptyAccounts, which allows to drain all funds from extra accounts that got generated during previous test runs.
• TestFixNonce, which can help to clear out nonce-gaps from the public mem-pool for the main test account.

[jannikluhn]

Haven't reviewed yet, but I think this should be in a separate repository. Are you using a lot of code from the encrypting rpc server that would make this difficult?

[fredo]

Haven't reviewed yet, but I think this should be in a separate repository. Are you using a lot of code from the encrypting rpc server that would make this difficult?

Was going to ask the same. Does it make sense to put it into rolling shutter?

[konradkonrad]

Haven't reviewed yet, but I think this should be in a separate repository. Are you using a lot of code from the encrypting rpc server that would make this difficult?

I agree, and it should not be hard, I think the only bit of re-use that's left in there is rpc.ComputeIdentity.