---
# System prepended metadata

title: Han (weihan) - Update 9

---

# Han (weihan) - Update 9

## Summary
I had completed most of the required codes related to leaf node which includes the addition of new state epoch metadata and new Verkle proof format. 

## Development
I've finished Verkle Tree modifications and state expiry logic. I've also added some unit tests to test out the new Verkle Tree features. New proof format is completed but unit tests have yet to be included.

Check out my development branch [here](https://github.com/weiihann/go-verkle/tree/state-expiry-dev). 

## Code Journal
### New Leaf Node Optimization
Upon reflecting on the new leaf node design, I found a design flaw that actually costs more storage space that it needs. Here's why:

![](https://hackmd.io/_uploads/rkGMiAB1T.png)
As a recap, a leaf node can store 256 values. The first 128 values are stored in the "C1" group while the last 128 values are stored in the "C2" group. The state expiry scheme adds a third commitment "C3" where it is the commitment of 256 * 16-bit state epoch values. Each epoch corresponds to a value and records its last accessed epoch.

The state expiry logic is that, if all of the values in C1 or C2 are expired, then the values can be pruned away and temporarily not being able to be accessed.

The flaw is that if there's 1 value that has been accessed in the latest epoch, then the group of values would not be pruned away. Therefore, there's no point storing epochs for each corresponding values. Only a single state epoch for C1 and C2 is good enough to represent this information. The following is the latest leaf node design:

![](https://hackmd.io/_uploads/ryHP3AB16.png)

## Next week's Action Items
- Complete unit tests for new Verkle proof format
- Use current development branch for go-verkle in go-ethereum
- Complete new transaction format 