## Week 2 - Updates
After analysing all the projects proposals from client team, i have decided to work on Pureth [EIP-7919](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7919.md) implementation , I am still interested in Beam chain and will continue to explore it but for fellowship goals, i will work on Pureth.
### Choosing Nimbus EL
I will work on Nimbus EL for this implementation, i am mainly interested becuase Nimbus is optimized for light clients and it is a good candidate for Pureth related implementations. I need to learn Nim language.
### Why Pureth
Pureth is a Meta EIP which bundles other EIPs to improve data accessiblity for Ethereum by making structural changes (transitioning from RLP to SSZ), log reforms, introducing Binary API as an alternative to JSON-RPC.
The EIPs are bundled mainly into following categories :-
1. PURGE: LOG Reform (EIP-7708, 7799, 7668, 7745, 7792)
- Adds SSZ-based log filters (EIP-7745) and logs for ETH transfers (EIP-7708, 7799), removing Bloom filters (EIP 7668).
- Enables verifiable account activity tracking (EIP-7792).
2. PURGE: Remove Old Transaction Types (EIP-7706, 6404, 6466, 6493)
- These changes will introduce new transaction types for SSZ (EIP-6404) and new receipt type (EIP-6466)
- optional SSZ signatures (EIP-6493), supports features like post-quantum signatures.
- Mempool will continue to support RLP transaction but transactions will be converted to SSZ when bundled into execution block. This will help simplifying verification.
3. PURGE: Serialization Harmonization (EIP-6465, 7807)
- Transitions execution blocks and withdrawals root to SSZ, introducing a binary API to replace JSON-RPC.
- Supports SSZ transactions in blocks.
- This requires significant client updates.
4. Simple Serialize (SSZ) Requirements (EIP-7916, 7495, 7688)
- Defines SSZ data structures (ProgressiveList, StableContainer) for transactions and logs.
- Ensures forward-compatible SSZ adoption across clients, critical for block-level SSZ.
### Team
@samyxandy (Tamaghna) is also interested to work on Pureth, he seems to be interested in SSZ related implementationl, will prepare proposal with him.
### Starting with `PURGE: LOG Reform`
As the list of EIPs to be implemented is really long and i have to choose one category to start my work, i will start with `PURGE: LOG Reform` category EIPs, I need to follow a sequencial approach to implement these EIPs
1. EIP-7668: Remove Bloom Filters
Removal of Bloom Filters seems pre-requisite for EIP-7745, This simplifies receipt processing early. This implementation should be easier than other EIPs.
- Effort estimate
This should be Low effort, as this seems to be independent from other implementations and main focus would be on ensure the `eth_getLogs` doens't break with change and all tests are passing.
2. EIP-7708: ETH Transfers Emit a Log
The purpose of this EIP is to make all Eth transfers emit logs because currently smart contracts don't emit logs for Eth transfers and this leads to problem in tracking the transfers sometimes.
- Effort estimate
This should require moderate effort as following work is required to be done
- Emit SSZ logs for opcodes like SELFDESTRUCT or CALL transfers.
- Simulate tests for Eth transfer in smart contract wallet
- Need to check dependency on other EIP implementation as it might be dependent on (EIP-7916, 7495)
3. EIP-7799: System Logs
Some Eth balance changes are missing even with after the implementation of EIP-7708, So this EIP aims to add a new list to add all Block level logs so that `eth_getLogs` will be able to provide all the history.
- Effort estimate
This should require moderate effort almost similar to EIP-7708
4. EIP-7745: Two-Dimensional Log Filter Data Structure
This is the core EIP of the Bundle as it will implement the log index to query and verify the logs from EIP-7708, 7799 and replace Bloom filters.
- Effort estimate
This will require high effort and it is critical EIP to be implemented for Log Reform.
- Implement SSZ log index
- Merkle proof generation
- Update `eth_getLogs` to return SSZ logs
5. EIP-7792: Verifiable Logs (Optional)
Will pick this implementation in the end as it is optional.
- Effort estimate
This should be a high effort implementation as requires good understanding of ZK .
## Next
I will look into Nimbus-EL and prepare proposal for the implementation of `Log Reform` EIPs. Focus would be on analysing current status of these EIPs in Nimbus EL and estimate time required to finish the work, Will also prepare tasks to be completed for Nimbus implementation.