In this post Iḿ going to discuss a yet only partialy resolved subject that came up with the separation of the Web 3.0 entropy into its own [WEn3](https://hive.blog/hive-169321/@pibara/progress-on-the-the-coinzdense-project-web-30-entropy-layer) layer for the [coinZdense](https://coin.z-den.se/) project.

The subject at hand has a rather big impact on the design and implementation of **coinZdense** project. 


Discussing this subject is probably easiest with a sample application RC.

```yaml
---
appname: DEMO1
hashlen: 32
otsbits: 5
heights:
- 8
- 6
- 8
- 7
```

In this sample RC, we have a four level signing key. That is, a signing key consisting of four level key:

* A level-0 key with a merkle-tree height of 8, for signing up to 256 level-1 keys.
* A level-1 key with a merkle-tree height of 6, for signing up to 64 level-2 keys.
* A level-2 key with a merkle-tree height of 8, for signing up to 256 level-3 keys.
* A level-3 key with a merkle-tree height of 7, for signing up to 128 transactions or WEn3 subkeys

The level-0 key is generated once and can't be replaced. The level-1, level-2 and level-3 keys though will need replacement when exausted and exaustion is part of normal operations.
Alocating a replacement level-key takes up CPU resources and time. This creates a rather anoying user experience that once in a while an operation that normally takes mili seconds ends up taking many seconds or even minutes.

It roughly takes the same time per *potential* signature that a level key can make, as it takes to actually make the signature, that means that for example if a single signature takes 50 mili second, and a level-3 key can sign 128 transactions, the replacement of a level-3 key will take up roughly 6.4 seconds. 

If a higher level key gets replaced, so do the lower levels, though replacement of higher level keys will be more rare, when they happen the impact on user experience will be higher.

| level | replace levels | once every N transactions | transaction equivalent | time |
| - | - | - | - | - |
| 3 | 3 | 128 | 128 | 6.4 sec |
| 2 | 2,3 | 32768 | 384 | 19.2 sec |
| 1 | 1,2,3 | 2097152  | 448 | 22.4 sec | 

A signing latency of many seconds or more isn't acceptable from a user experience perspective. We need to try and pre-calculate level keys and attempt to avoid these latencies. We will want to do this in a measured and parameterized way.

We define an allocation factor **af** where at an af of 1,0 we schedule all level keys that are going to schedule the creation of all level keys that are going to be needed within a number of transactions equal to the level-1 transaction equivalences in order of which ones are needed first.

In our example config this would be 448. We look 448 transacion into the future and see what level keys we are going to need. Those keys get scheduled for creation in paralel operations.

It might be optimal to have an **af** that is larger or smaller than 1.0, something that remains to be studied. At this point in time, figuring out the API and algoritms for allocation in WEn3 and calculation in the hash-based-signing layer is the next milestone in the coinZdense project that we need to achieve, It is something that adds nothing, functionaly, but is still an aspect of the project that is esential to the projects real world usability.