---
# System prepended metadata

title: Week 1
tags: ['EPF ']

---

## Summary
This first week was consacred to things I forget/didn’t known/not well understand about Ethereum. 
I also started to think about the project to work on. I wanted a micro-economics one (RIG opened questions) but I think I would not have enough time for that kind of subjects (research topics). 

## Ressources
- [RLP serialization](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/): already know about that, but I needed a reminded.
- [RLPx transport protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md): I didn't there was a dedicated protocol for node communicatio. Honestly I am not an expert of transport protocols so it like a pain-in-the-*** to read. I found a [python implementation](https://github.com/ethereum/pydevp2p/blob/develop/devp2p/app.py)  that is not much clearer.
- [ephemery.pk910](https://ephemery.pk910.de/): one of the project is an ephemery testnet; and I remember that for my job, we needed to find a testnet that give users a lot of ETH; an intern find this project, so I re-took a look at it. It centralized (1 person manage the node) but a good starting point. It seems to be the current implementation of the ephemery-testnet from Ethereum.
- [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/README.md): after Mario presentation about Ethereum, I discovered a new service I didn't know: the engine API which make the CL to communicate with the EL; like to get payloads, block hashes etc. 
- [Engine API geth implementation](https://github.com/ethereum/go-ethereum/blob/34d507215951fb3f4a5983b65e127577989a6db8/eth/catalyst/api.go#L46): that's the go code for the interface design [here](https://github.com/ethereum/execution-apis/blob/main/src/engine/README.md). It refer to the EL [here](https://github.com/ethereum/go-ethereum/blob/34d507215951fb3f4a5983b65e127577989a6db8/eth/catalyst/api.go#L91C2-L91C6) and [may be called by the CL](https://github.com/ethereum/go-ethereum/blob/34d507215951fb3f4a5983b65e127577989a6db8/eth/catalyst/api.go#L716). I also understood [how it lives along side with the execution API](https://github.com/ethereum/go-ethereum/blob/master/node/node.go#L581). I was wondering if the `node.Node` could facilitate the deployment of a REST API wrapper of the JSON-RPC API but it requires a `rpc.API` type, so it might not help. *I found [a TODO](https://github.com/ethereum/go-ethereum/blob/34d507215951fb3f4a5983b65e127577989a6db8/eth/catalyst/api.go#L674) that may interest some people that might read this note :panda_face:*.
- [Deneb consensus-specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#modified-process_attestation): I am monitoring the changes on the consensus-specs related to validators rewards/penalty. 2 changes may impact their income:
    - `get_attestation_participation_flag_indices`: there is no more inclusion delay for the target checkpoints; it means validtor can publish a very late attestation for the target checkpoint and still have a reward (before they had a penalty).
    - `process_attestation`: the inclusion range for an attestation is between the current and the previous epoch.
    => validators that publish attestation at the beginning of an epoch will have more time for attestation publication before being penalized; but since validators attest for each epoch, it's not unfair.
I don't think it's directly link to the Deneb update: [EIP7045](https://eips.ethereum.org/EIPS/eip-7045). I don't know what are the security consern on the LMD-GHOST so I asked to [Danny Ryan](https://github.com/ethereum/consensus-specs/issues/3453).
- [EIP7045](https://eips.ethereum.org/EIPS/eip-7045): see above
- [LMD GHOST](https://vitalik.ca/general/2018/12/05/cbc_casper.html) + [bitwise LMD GHOST](https://ethresear.ch/t/bitwise-lmd-ghost/4749): I did need a huge reminder of GHOST on Ethereum (it's been a long time since I dove into consensus algorithms). I did that to be sure to undestand why the consensus-specs were cahnged regarding the target checkpoints. LMD GHOST is a fork choise rules based on the subtree that have the latest message. The bitwise version seems to be quite complicated, but this [python implementation](https://github.com/ethereum/research/blob/master/ghost/ghost.py#L99) make it more understandable. (note for myself: What is called the virtual height is the number of blocks to make the link between the mother and child through the bitwise decomposition).

## Questions
nil

## TODO
- Find an unused RaspberryPie 8gb and setup a new Ethereum node (will 8gb be enough for testing purpose ?). Maybe I will my company node or Infura IDK.
