Stateless Summit 2
Starting quite far back ~6 months ago, when I was actively looking for a new gig: during a test assignment I discovered bloom filters for myself, which for a dapp builder is quite a shame. TLDR — it's a data structure based on bit masking to check if a transaction or log topic might be present in a specific block.
Then I discovered Vitalik's take to remove bloom filters, because:
This EIP proposes recognizing that reality, and removing bloom filters from the protocol. Applications that need history querying would be encouraged to develop and use decentralized protocols that create provable log indexes using eg. ZK-SNARKs and incrementally-verifiable computation.
During the talks I got more external validation for the issue that I see with the Ethereum state, and even some data to back it up.
Trustless Logs Indexing
So after a few sweaty days at work, a few hours of research on EIP-7745b and EIP-8304 + an issue with a clarifying question, and great office hours with RazorClient, I got inspired by how many things I need to learn and found a next area to catch up on, which is SSZ.
SSZ
As a first thought I went to the SSZ Ethereum docs, right up until the moment I realized that I'm participating in the EPF and it's not my ordinary evening, so I decided that epf.wiki exists for a reason. I'm in the middle of phase (3), 2 weeks in, so I returned to the purpose of the phase:
Phase one is the very beginning of the cohort. The first few weeks are dedicated to general learning about the EPF program, the Ethereum protocol as a whole and its development. Use resources from EPF Study group to get started and make yourself familiar with various areas of Ethereum.
Wiki
The decision to proceed with wiki reading seems to be paying off, as I stumbled upon EIP-4788, which seems very similar to what 7745b does but on the execution layer — and how EIP-8304 improves upon it. Then I proceeded to read the execution client spec every time I had a free minute. As time runs out for me to peacefully read all the documentation, I'll be catching up on the remaining parts of the EPF wiki related to execution clients, and would probably stay on a project related to it.
SSZ Engine API
I started watching recent videos related to SSZ, including the most recent SSZ Engine API call hosted by the same @RazorClient. As I heard, the release of the v2 engine shouldn't be bound to a hardfork and may happen in the middle of them, and client teams can switch at their own pace.
If my memory serves me right, during the call somebody asked how the work is going with the test cases, which got me thinking that during my potential project on TLI I'd ideally be able to help on the client side with e2e tests, as the EIP-8304 spec already contains sample encoding.
Trustless Indexing Client
Tamaghna's comment on the necessity of the library got me thinking that, instead of introducing a temporary library for testing, it would be better to implement indexing in existing trusted setups like ponder.sh — I could fork it or add it as a feature.
Engine API v2
It seems like the SSZ-fication of the execution layer is a quite major shift and something that has been discussed for a while, so I went to listen to and check out the original SSZ breakout rooms #1, #2.
The second one seems to have been more productive, and I also saw that the Union type is part of the spec, so the first one was productive as well. However, I came away with the knowledge that for each transaction type Ethereum would need to introduce a new SSZ implementation as well, and it's not planned to have XX tx codes.
Side gigs
While looking at gfi.bordel.wtf I clicked on a recent one, #3015, and saw that nobody had started work there, which means I can check it out. It turned out to be a quite small change for the new model of gas tracking for state and execution. While at first it was quite trivial, with the help of AI I got the first draft ready, which I polished by using the right types — Unit instead of Python's int.
Next
I think it makes sense to dive deeper into the pureth docs and existing work, together with Engine API v2, and to catch up on Pureth meta-related EIPs like ProgressiveList and ProgressiveContainer. Ideally I'd team up with someone to work on Pureth log indexing, as for bigger things I'd need to dedicate full-time to this.