---
title: Final Update on EPF6
tags: [EPF]
---
# Final Update: Implementation of EIP-6916 on Besu

### Abstract

This project mainly aims to implement the automatic restart feature for the Ephemery public testnet natively inside the Besu client. EIP-6916 (Ephemery) introduces an ephemeral testnet that automatically resets.

During the Ethereum Protocol Fellowship Cohort 6, I implemented the auto-restart feature for the EIP-6916 (Ephemery) testnet inside the Besu client. EIP-6916 (Ephemery) is an automatically resetting testnet that restarts on a 28-day cycle. After each cycle, the network starts from a fresh database, resets all peerings, and begins again with a new genesis. The timestamp and chainID are calculated based on each cycle.

## Where I started

When I started the project, users could run an Ephemery node with Besu by using the `--network=Ephemery` command option. However, the node could not automatically restart after completing an Ephemery cycle. Users had to manually stop the client, provide a new empty folder with `--data-path`, and start the client again. This process can be annoying and can cause the node to run with bugs and errors. On the other hand, this manual process would stop the node for a while, which exposes the network to consensus issues.

## What I Did

I developed the auto-restart for Ephemery inside Besu based on the [project proposal here](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/Ephemery-Besu-Implementation.md).

With the implementation of the project, Besu is the first client that enables these features on the Ephemery network:

- Schedules the Ephemery network for periodic resets.

- Automatically restarts the Besu node when a reset is detected every 28 days.

- Handles old chain data cleanup and the reinitialization of new chain data properly.

- Disconnects old chain peers and restarts over the peer discovery on the new Ephemery chain.

- Maintains user configuration across restarts, such as the key.

### Architecture Design

Primary implementation handled all the logic inside `BesuCommand.java`. Justin, from the Besu team, commented to avoid adding overhead to `BesuCommand.java` and handle the logic inside `Runner` class. Although, for some reasons, such as design limitations or security, the final implementation is managed inside both Runner and BesuCommand. Almost all changes are wrapped under the `IfNetworkEphemery` condition.

[Link to primary implementation](https://github.com/hyperledger/besu/pull/9084)

[Link to final implementation](https://github.com/hyperledger/besu/pull/9210)

### Implementation Details

To accomplish this with auto-restart on the Ephemery network, I implemented features under these steps:

#### Stop

- The client stops and clears all the ports and old chain data and drops all the peers and stops discovery. `stopEphmery()` function inside `runner.java` handles this.

#### Prepare

Due to the Besu architecture design, we need to force the state variable inside `BesuPluginContextImpl.java` to ***`UNINITIALIZED`*** to prepare the client to start over with plugins and restart services.

- implemented `resetState` function inside `BesuPluginContextImpl.java`
- implemented `reset()` function inside `RocksDBKeyValueStorageFactory.java` and `RocksDBPlugin.java` to reset *segmentedStorage* variable to null.

#### Start

- Every 28 days, the client calls for network updates, and new parameters, chainId and timestamp, will be overwritten with new values.

- The client starts from a new empty database folder, named `Ephemery-chain-[chainId]`, and imports new Ephemery chain data inside it.

- It starts peer discovery and searches for new peers on the network.

- It preserves the initial client key given or generated at the start of ephemery sturtup.

- It writes the key to the new data directory, which enables the client to become a bootnode.

##### Log

- Informs the user with restart trigger logs on each network auto-restart. Also shows how far the next restart will be on the first startup.

- Informs the user when the public key is written to the new datapath folder inside the key file.

#### Test

Thirteen tests are written to ensure the restart functionality and all the features it promises inside.

#### Documentation

I started the development of the project by running Ephemery as a node to see what needed to be developed, what has been done, and what has not. I also wrote a tutorial on how to run an Ephemery node with Besu and Teku pairs.

[Link to starting Ephemery node tutorial](https://hackmd.io/@0xEllie/SJdF71Kvxx)

At the end of the development, I wrote a tutorial explaining what qualifies a node as a bootnode, since this was my final task related to the project's implementation.

The tutorial covers what prerequisites are required to provide a bootnode across a network.

[Link to bootnode configuration](https://hackmd.io/@0xEllie/r1QQ8Qzybe)

#### Main PRs
The primary implementation which holds all the logic inside `BesuComand.java`:
[implementation of Ephemery auto restart feature](https://github.com/hyperledger/besu/pull/9084)

After the feedback from the Besu team, I moved the main part of the
implementation inside `Runner.java`:

[Resolves feedback on the implementation of the Ephemery auto-restart feature](https://github.com/hyperledger/besu/pull/9210/commits/1a9cbdb37e7aaec9741c0ff53a95e4c942102787)

I reviewed my last PR and made it more optimized:

[EphemeryReset: optimizes restart lifecycle and improves logging](https://github.com/hyperledger/besu/pull/9210/commits/1ae2f079a9f8a1dc9bb37ce34687f0e1b352e52a)

Added tests for to ensure the implementation:
[Tests for Ephemery restart feature](https://github.com/hyperledger/besu/pull/9210/commits/a83d59e0e9ac2f78352718d1fb42d819ad73b6b9)

PR to keep the key throughout the Ephemery startup and preserve the same key over every cycle of Ephemery restart:

[Enables Besu to become a bootnode, preserves the key over every cycle](https://github.com/hyperledger/besu/pull/9210/commits/e4a6d06df37431b3b2611235816c39e3f9786145)

PR to resolve starting tests in a single-run due to RocksBD concurrency and adds tests for bootnode feature:

[Test(ephemery): enables CI/CD with in-memory storage plus keypair tests](https://github.com/hyperledger/besu/pull/9210/commits/ffb9b7f434a7b575699bbbd1020199e8c29d3501)

## Final State

With the implementation of this project, you can run an Ephemery node on Besu without the need to execute any manual changes for keeping the node up during every Ephemery cycle. This implementation is responsible for clearing old chain data and establishing new chain database from scratch inside a new directory which is named based on the chain number. It disconnects all the old peer connections and starts over with the new peering discovery. You also can run a bootnode with Besu on an ephemeral network, as it maintains the primitive key that you pass in command options. This way the node automatically moves to a new chain at each cycle, without any manual interventions. The following screenshots show the logs for the Ephemery restart schedule on Besu.



### Impact of My Work on Ephemery

- Network Reliability: Automated restarts at the precise reset timestamp (28-day cycles) prevent consensus issues that would occur if nodes were manually restarted at different times.

- Zero Manual Intervention: Node operators don't need to perform monthly maintenance tasks at specific timestamps.

- Nodes Participation: Ensures Ephemery Nodes stay synchronized with
network resets, maintaining adequate participation rates from the cycle start.

- Reduced Downtime: Programmatic restarts are faster and more reliable than manual intervention, minimizing network disruption.

- Bootnode Participation: Native implementation enables Ephemery nodes to participate as bootnodes by maintaining persistent keys across all cycles—impossible with manual restart approaches that would reset node identity.

- Future-Proof: Native auto-restart implementation provides a foundation for further Ephemery features (like bootnode functionality).

### Future Work

Ephemery on Besu reads from the local genesis file for every network upgrade, like Fusaka. Therefore, at Ethereum network upgrades, it needs to replace the Ephemery.json genesis file with the new one. Reading the genesis from a URL would eliminate the need to manually replace it. This helps maintain network reliability, as the new genesis must either be merged into the Besu codebase or downloaded manually. Both options might end up with an absence of active nodes on the new upgraded network. This way, it will be fully automated, even for the network upgrade. This will reduce human mistakes in the process as well.
I also would like to work on automatic restart on the Teku client as well.

## Feedback

### Self-evaluation

I chose this project while having no idea how it was going to turn out. After resolving the challenge of scheduling restart cycles, I learned all the ins and outs of the implementation and how the next progress on the client would be.

This project gave me the urge to implement an EIP just by reading through it. But let's just not undermine the fact that I had Mario as my mentor by my side. When you have a mentor, you know there is someone who helps you when you are stuck.

### Challenges

When I was considering the open issues to pick up as my project for EPF, I realized the automatic restart feature issue had been open for at least 6 months, which made me curious, like, what problem had stopped the project? This made me worry a bit about the feasibility of the project, since I wouldn't want to waste EPF's opportunity and their resources on an impossible project. This pressured me to come up with a solution and check for the feasibility as fast as I could. So just in case I saw it not working, I could discuss it with Mario and look for another project.

Luckily, I came up with a solution to handle the problem. The main part was finding the algorithm to choose what to include in the restart cycle and what not to; preparing for the restart acted as the pillar for the feasibility of the implementation design.

All in all, Although I knew there would be a challenge with this project, as far as I know myself, I love challenges.

I wanted to contribute to the Ethereum Study Group, but this is as close as I've gotten, as I've written two tutorials for Ephemery, which can be added to EPS.

### EPF

I'm so grateful and honored to get the opportunity to contribute to Ethereum as a fellow in the 6th cohort of EPF. It reduced my fears of touching a production-level client on Ethereum. My mentor, Mario, was the best with feedback on my work and reading through where I was in the work, so I didn't feel lost.

Working in this space feels good, as I believe in it. It's not just a company that has nothing to do with your beliefs. It gives meaning to the work, which nowadays is a big part of our lives. Even the concepts are something that feeds my mind in a way.

During the cohort, I would say I mostly used my 10 years of experience in Java rather than dealing with cutting-edge concepts on Ethereum.

Working on this project gave me the chance to look into most of the codebase of Besu, which is good for a first-time contributor, and it will help me with my future contributions to Besu.

I again thank [Mario](https://github.com/taxmeifyoucan) and [Josh](https://github.com/joshdavislight) for getting me the opportunity not just to be a part of EPF cohort 6 but also to get to know amazing fellows in the cohort with their valuable work and to let me be in the right place with the right people.

I also thank [Justin](https://github.com/jflo) and [Sally](https://github.com/macfarla) from the Besu team for giving me feedback on the PRs.