# epf week-0 update hi, im bhaskar metiya and im participating in epf6 permissionlessly. my engineering interests mainly lean towards performance optimizations. ( i like when systems are fast ) # projects im interested in ### Fast Confirmation Rule in Nimbus / Lighthouse I went though the [Devcon presentation](https://www.youtube.com/watch?v=p7JPRTELnJc) and the [Whitepaper](https://arxiv.org/abs/2405.00549) for the Fast Confirmation Rule to understand a high level overview of the confirmation Rule. A [pre-requisite change](https://github.com/ethereum/consensus-specs/pull/3431) for the Fast Confirmation Rule went live on mainnet since Deneb. The Prsym team already has an [open PR](https://github.com/OffchainLabs/prysm/pull/15164) for the confirmation rule. I plan on doing a deep dive into it and the Nimbus/Lighthouse codebases this week to understand the overall scope of the changes needed and how I would implement them. ### EIP-7928 Erigon Parallel Execution The [BAL (Block-Level Access Lists)](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7928.md) is an EIP I'm super excited about as this enables faster execution for the EVM and in turn scaling the L1. (I like when systems are fast). + This EIP might go into the Glamsterdam hard fork. There are various tradeoffs associated with the current design of the EIP as mentioned in this [EthResearch post](https://ethresear.ch/t/block-level-access-lists-bals/22331). EIP-7928 currently adopts an Execution BAL with execution time of `paralellel IO + parallel EVM`. The other BAL variants include State BAL with execution time of `max(paralellel IO, parallel EVM)` ( much faster but almost 2x the size) and Access BAL `parallel IO + serial EVM`. A newer [EthResearch Post by cskiraly](https://ethresear.ch/t/bafs-scaling-ethereum-l1-with-block-level-access-filters/22585) also talks about BAF (Block-(NOT)Access Filters) which act as Bloom Filters over BAL which identifies which part of the state `S` was not accessed. This could potentially decrease the size of the access lists without the risk of false positives as we use a negated bloom filter. This looks like a project with a lot of optimization tradeoffs and testing needed. I plan to understand the tradeoffs, the [Erigon Block STM Polygon POS Implementation](https://github.com/erigontech/erigon/compare/main...bstm_e3), and the [execution dependencies](https://ethresear.ch/t/execution-dependencies/22150) in the coming week to scope out this project. Overall this project looks super interesting but needs more consideration. # what's next? I plan on reading through the codebases of the client projects to understand the scope of the changes i plan on implementing and scope out a project proposal that i will be actively working on during EPF. > godspeed, @zyzyznn