# ignacio (jsign) - Update 7

- Since the start of the program, I’ve been walking “bottom up”: first understanding and improving [go-ipa](https://github.com/crate-crypto/go-ipa) (the cryptographic library used for Verkle Tries), and [go-verkle](https://github.com/gballet/go-verkle) (the library implementing the Verkle Trie data structure). Now I started moving more to the [beverly-hills branch of go-ethereum](https://github.com/gballet/go-ethereum/tree/beverly-hills-head), a work in progress by Guillaume to integrate all this into Geth.
- Coming back to the [Verkle Tree integration EIP](https://notes.ethereum.org/@vbuterin/verkle_tree_eip), and comparing it with the current progress in the `beverly-hills` geth branch, I noticed an optimization (and simplification) on how `GetTreeKey(..)` was implemented, which:
- [I created a PR which was merged](https://github.com/gballet/go-ethereum/pull/140). (First PR directly for the future Verkle Tries `go-ethereum`! Until now, I’ve merged PRs but in go-verkle and go-ipa which were dependencies; important! but go-ethereum is special :) )
- The PR allowed this function, which is called every time go-ethereum needs to access the Verkle Trie, to be slightly faster and use 20% less memory per method call.
- [This required a small auxiliary merged PR in go-verkle](https://github.com/gballet/go-verkle/pull/300), since the optimization only can be understood if you know how the whole stack works (go-ethereum+go-verkle+go-ipa); which was my point about trying to understand all the stack).
- After more reading of the mentioned EIP, [I noticed that the current go-ethereum integration of Verkle Tries had an integer overflow bug](https://discord.com/channels/595666850260713488/824798757618188339/1045341312590811196). This is a security bug since someone could craft a smart-contract accessing a storage slot that would corrupt the Verkle Trie state. This isn’t a big deal today since we aren’t in mainnet, but this can cause a consensus split in the network.
We’ll wait a bit to fix this because Guillaume is doing some big refactors, so maybe I’ll create a PR to fix this later.
- I finally bought a [2TiB NVME M2 SSD (970 EVO Plus)](https://semiconductor.samsung.com/consumer-storage/internal-ssd/970evoplus/) to run a full mainnet Ethereum node. After having this, I started syncing a geth+lighthouse node at home. After ~3.5 days, I’ve it synced! I wanted this for multiple reasons:
- First, adding more validators in South America :)
- I plan to work on analytics next to understand Merkle Patricia Trie's depth and shape in real mainnet. This was something that Dankrad suggested might be worth exploring before, but I didn’t have comfortable access to a mainnet node (until now). (To be clear: I did this buy because I wanted, not because I was forced! Kev even offered me access to some cloud validator, but I preferred to have my local validator.)
- I’m sure having access to a node locally will be useful for other work I’ll do in the future.