# Why did:webvh Should Keep the `witness.json` File

Many thanks to Glenn Gore of Affinidi for creating an interesting test case generator for `did:webvh`, and then applying it to the question of the separate `witness.json` file.

## Performance Test Scenario

- Enterprise has used WebVH for 10 years
- They use pre-authorised keys for LogEntries
- They roll the keys every month, min 2 nextKeyHash
- They randomly swap a witness node every 12 months
- Witness threshold: 3
- number of witnesses maintained @ 4 Nodes
- They randomly swap a watcher node every 12 months (offset by 6 months from the Witness Swap)

The above is trying to simulate a realistic enterprise production deployment of WebVH with security constraints.

Here are some stats for you:

- did.jsonl = 197kb in size (120 LogEntries)
- did-witness.json = 5.9KB in size (optimised)

Generating 120 LogEntries and creating proofs etc
- Average ~50ms

Validating full WebVH of 120 entries including full validation of Witness Proofs
- Average ~28ms

This is a very good performance result compared to other high-trust traceable DIDs (Keri, BlockChain).

I can validate ~10 years of WebVH history in under 30ms, faster than likely fetching a web3 DID ;)

## Keeping All Witness Proofs

The following is the result of adjusting the did:webvh implementation to not remove witness proofs from the witness.json file. This simulates keeping all the proofs to give us an idea of the size increase that would result from keeping the proofs in the Log file. Note that in this, there remains the cost of an extra network read -- although the total number of bytes read across the network would be the same.

### Results and Analysis

With NO witness optimisation the size of the witness files grows from 5.9KB to 182KB (~31x increase)

The timings increase from to:

- Reading Witness Proofs: 7.25ms --> 104ms (14x slower)
- Validation of Proofs: 26.25ms --> 77ms (~3x slower)
- Total Validation time: 37.375ms --> 185.25ms (~5x slower)

When you take into account that this is CPU bound, it would have an effect on high-volume DID resolvers, effectively taking 100% of a CPU core for 1/5th of a second per resolution (for these big DID's).

I would believe that for high-trust DID's they are likely to have more than 3 witness nodes (this test uses threshold == 3, four witnesses), if I expand this to threshold 5 - the following are the results:

- file size grows from 5.9KB to 182KB to 269KB

Thresholds: (optimised @ 3, raw @ 3, raw @ 5)

(3 to 5 witness threshold on non-optimized)

- Reading Witness Proofs: 104ms --> 147ms (41% slower)
- Validation of Proofs: 77ms --> 97.375ms (26% slower)
- Total Validation time: 185.25ms --> 248.38ms (34% slower)

Compressing the 269KB witness proofs yields 56KB compressed file

Comparing optimised to non-optimized at 5 witness threshold

- File size = 6.6KB vs (5.9KB or 269KB) (~41x increase in file size)

- Reading Witness Proofs: 13.625ms --> 147.25ms (~11x slower)
- Validation of Proofs: 29.5ms --> 97.375ms (~3.3x slower)
- Total Validation time: 45.5ms --> 248.38ms (~5.45x slower)

So as the number of witness nodes increases, the performance degrades faster (which would be expected)

Last set of stats, normalising this to a # of LogEntries verified/second

- 3 witnesses - optimised: = 4,571 LogEntry/Second
- 3 witnesses - unoptimised = 647.77 LogEntry/Second
- 5 witnesses - optimised = 2,637.4 LogEntry/Second
- 5 witnesses - unoptimised = 483.14 LogEntry/Second

Witness verifications/Second
- 3 witnesses - optimised: = 18,285
- 3 witnesses - unoptimised = 2,591
- 5 witnesses - optimised = 13,187
- 5 witnesses - unoptimised = 2,415

Assessment from Glenn Gore (Affinidi):

> The performance results likely prove that the extra complexity is worth it - as much as I would like it to be simpler :)