Goal I am continuing my work on the client-side integrations for the ephemeral testnet and validating EIP-6916. Target 1: Ephemery integration into client [geth] - prepare geth fork with ephemery changes for feedback from geth team Target 2: Lodestar maintenance for ephemery network Stretch 1: Ephemery validator running on raspberry pi Status

Resolving issues with alloc data ephemery-geth local quickstart Download latest ephemery release Clear chain data in local geth directoryrm -r chaindata Build and run geth branch locallymake geth ./build/bin/geth --ephemery --verbosity 4 Screenshot 2024-06-21 at 18.45.35 Updates

Reviewing pk910's previous work + using geth ChainConfig Geth local setup Make sure golang version is up to date Pull latest changes to my fork & rebuild git remote add upstream git@github.com:ethereum/go-ethereum.git git pull upstream master make geth

tldr; This time when Lodestar launches on ephemery and looks for the EL client, I want it to find Geth. pk910's initial Lodestar configuration essentially downloads the latest ephemery settings based on whatever is saved at https://ephemery.dev/latest/genesis.ssz and https://ephemery.dev/latest/bootstrap_nodes.txt. export const depositContractDeployBlock = 0; export const genesisFileUrl = "https://ephemery.dev/latest/genesis.ssz"; export const bootnodesFileUrl = "https://ephemery.dev/latest/bootstrap_nodes.txt"; First up, I want to check I can use this approach to sync with Geth. Then, when I am sure that my Lodestar launch command correctly gathers the latest ephemery settings, my plan is to replace the ephemery downloads with the genesis included inside the Lodestar executable.

Progress Initial project proposal Ephemery is a short-lived testnet. The ephemery team is focused on integrating this new-ish network into existing clients and infrastructure. The periodic resetting of the test network effectively erases the onchain activity that occured during that iteration. This reduces the impact of accumulated network bloat, seen with other testnets, and results in lower resource requirements for testnet users (also conveniently lowering the barrier to entry for running the testnet in the first place). In particular, the reset feature optimises for short-term validator testing, reducing the burden on longer-running testnets. Earlier in the programme, I described my intention for the cohort in my Project Proposal: writing client-side integrations for the ephemeral testnet and validating the draft EIP as part of the ephemery team, beginning with Lodestar.

tldr; Lodestar PR - add ephemery config - merged Dialogue continues with Chainsafe on Lodestar implementation issue Progress: CL Genesis

tldr; Reached out to Chainsafe to seek feedback on Lodestar issue Reviewing latest changes to ephemery specs (draft EIP) Progress: Genesis I created the above Lodestar issue as a basis for discussing the addition of the ephemery network. The current status of ephemery genesis in my Lodestar work is:checkpointSyncUrl working with the existing Lodestar --checkpointSyncUrl flag backup download url working without --checkpointSyncUrl flag

tldr; Generating ephemery genesis inside Lodestar. ephemery package Native genesis The ephemery package needs to calculate the latest ephemery iteration and output a file genesis.ssz TBC whether this should be when yarn run build is run (a) at root level, (b) at package level, or when a function generateGenesis() is executed

Status: Updates to genesis code for eth2-testnet-genesisEncountered MacOS issues, fixed operation not permitted error in terminal Meeting scheduled 5 October with mentors to review draft PRs and align on approach to Lodestar code Draft genesis script (Holly) + retention script (Adedamola)[x] Genesis script uses eth2-testnet-genesis to generate a new genesis.ssz at a specified out dir [ ] Checkpointz and Lodestar ephemery flags in progress - see notes below Manual draft genesis script TODOs (see PR) include:

Had a go at an outline genesis script that I can run manually from command line at the moment. Things that are taking a bit of time: learning about ssz and Chainsafe's ssz package adding to Lodestar ChainConfig type aligning with Adedamola on our approach to Lodestar as a whole, taking into account reset functionality (originally a stretch goal of mine) merging latest changes from Lodestar (which include Holesky testnet configuration) and reviewing these updates GENESIS

Status: Moving to bi-weekly updates Draft genesis script (Holly) + retention script (Adedamola) in Lodestar Next steps: Sense-check our understanding + drafts with Mario and pk, potentially also dapplion as a follow-up step More detail:

Continuing to work on my Lodestar fork to add native genesis to Lodestar. Presented my project proposal on Ephemery at the weekly office hours session. It was great to see Teri and Adedamola present about Ephemery too! Status: Reviewing SSZ Implementing native genesis Links:

Continuing to plan/work on my Lodestar fork to add native genesis to Lodestar. Also, I have agreed with Adedamola that we will collaborate on our Lodestar work, with Adedamola taking on work on Ephemery reset. Status: Alignment with Adedamola: catch up, sharing information about code and plans for Ephemery package

Continuing to work on my Lodestar fork to add native genesis to Lodestar. Status: Reviewing SSZ Reviewing ephemery scripts

Continuing to work on my Lodestar fork to add native genesis to Lodestar. Status: Skeleton ephemery package added Reviewing SSZ Links: Working document: My dev update

Following up on my Week 4 update, where I was able to run Geth + Lodestar locally, I am now working on my Lodestar fork in order to run Lodestar with ephemery as a valid network option (building on the existing work by pk910 - thanks pk!). Status: Submitted my project proposal Able to run my Lodestar fork Reviewing (my) Lodestar network settings vs the Ephemery spec Beginning: adding the ephemery genesis into Lodestar Links:

Steps taken: Forked Lodestar Ran yarn at root level Added pk910’s config updates to my Lodestar fork (thanks pk!) Ran yarn again Ran yarn run build Launched Lodestar ./lodestar beacon --network ephemery This recognises ephemery as a valid network option and Lodestar looks for the EL client! It fails because I'm not running Geth yet :)

MVP: Client-side implementation for Ephemery genesis in Lodestar Stretch 1: Native chainstate reset in Lodestar Stretch 2: DAppNode package for ephemery Driving forward Ephemery integration I am writing client-side integrations for the ephemeral testnet and validating the draft EIP as part of the ephemery team. Why Ephemery?

[x] Reviewed Geth and Lodestar warnings [x] Fixed sync issue, troubleshooting with matrix group Fixes made to enable sync: Checked using correct state root via Lodestar logs Added flag in geth —authrpc.addr 0.0.0.0 to resolve auth / communication issue (although geth should have worked with default configuration) Status:

[x] Reviewed Mario’s workshop on client nodes https://notes.ethereum.org/@MarioHavel/nodes-workshop,https://github.com/eth-protocol-fellows/cohort-four/issues/95, https://drive.google.com/file/d/1rMVv-2z2sK1l8Ll_U56stTifgUYljZln/view?usp=sharing [x] Read Ephemery EIP https://github.com/ethereum/EIPs/blob/04369cb50ee6c1894dec868141e8a32e66dc4f16/EIPS/eip-testnet-draft.md [x] Reached out to Optimism about ephemery [x] Played with ephemery setup locally! Explored running from CLI following client docs: Geth and Lodestar Status: