This repository contains a program that generates a BatchContribution from the initialContribution.json from the spec. The generation is done using the reference implementation ceremony client.
This can help KZG ceremony client implementations to validate that their batch contribution logic is working as expected. This is possible since f(initialContribution, subCeremonySecrets) -> newBatchContribution is deterministic.
Clients can also cross-validate their implementations with the devnet sequencer, but that is slower to validate than a unit test and also implies building the API flow logic.
In your client implementation, create a test that:
- Loads
initialContribution.json - Execute a contribution with fixed secrets
[0x111100, 0x221100, 0x331100, 0x441100]. Each secret is a big-endian byte representation of the n-th sub ceremonyx(private key). - Serialize your new batch contribution, and compare it with
updatedContribution.json.
If they match, then your KZG ceremony client generates a batch contribution that matches the reference implementation, so there's a high chance that you're not missing any details.
Soon I'll include a link on how this test vector is used in a Go client implementation.
Simply run cargo run. The updateContribution.json file in the repository is just a cached version.
$ cargo run
unmarshaling initial contribution file...
done.
fixed secrets for test vector: ["0x111100", "0x221100", "0x331100", "0x441100"]
updating contribution...
done.Today running the program generates the output for the fixed secrets [0x111100, 0x221100, 0x331100, 0x441100] (one for each sub-ceremony). If the output of your client matches the expected output, that's high signal that your implementation is correct since getting that by chance is impossible.
However, we could change the code in this repo to generate (N * #sub-ceremonies) random test vectors and N updatedContribution.json outputs.
If you're interested in generating the output for specific secrets, you can easily change that in main.rs.