The objective of this effort is to create the first automatically reset ephemeral Ethereum testnet which would serve as a cross-client testing network without issues stemming from a long-term running history.
Warning
Ephemery will activate Pectra hardfork on epoch 10 starting iteration 3943814, February 13 7PM UTC. Make sure to upgrade your clients and validators to latest Pectra release candidates! Read more about the Pectra activation.
An ephemeral testnet is a single network that rolls back to the genesis after a set period of time. This kind of network is focused on short term and heavy testing usecases. The purpose of this is also to avoid problems like insufficient testnet funds, inactive validators, state bloat, and similar issues faced by long-running testnets.
More resources:
| Current value | |
|---|---|
| Network ID |  |
| Iteration number |  |
| Rollback period | 28 days |
| Next rollback |  |
https://ephemery.dev/ (add RPC with single click)
- https://rpc.bordel.wtf/test (geth)
- https://otter.bordel.wtf/erigon
- https://eth.ephemeral.zeus.fyi (lighthouse-geth, full beacon)
- https://checkpointz.bordel.wtf/
- https://ephemery.beaconstate.ethstaker.cc/
- https://checkpoint-sync.ephemery.ethpandaops.io/
- https://beaconstate-ephemery.chainsafe.dev/
At this moment, most official client releases don't include predefined Ephemery testnet. Check this overview of supported clients. To connect other clients to Ephemery network, it has to be done mannualy.
Download latest Ephemery parameters from its release and point your client to it like with any custom network.
wget https://github.com/ephemery-testnet/ephemery-genesis/releases/download/ephemery-111/testnet-all.tar.gz
mkdir ephemery && tar -xzf testnet-all.tar.gz -C ephemery
Example setup for geth and lighthouse. First initialize geth genesis and then run clients with configuration pointing to downloaded testnet files and variables:
geth --datadir geth-ephemery init ephemery/genesis.json
source ephemery/nodevars_env.txt
geth --datadir geth-ephemery --authrpc.jwtsecret=/tmp/jwt --bootnodes $BOOTNODE_ENODE
lighthouse bn -t ephemery --execution-endpoint http://localhost:8551 --execution-jwt=/tmp/jwt --boot-nodes=$BOOTNODE_ENR_LIST
This connects your client to the current Ephemery iteration. To connect to the latest iteration of the network after the client already ran a previous one, you need to use a different datadir or delete the existing one.
To keep up with the reset and run your node constantly switching to latest network, e.g. for running public infrastracture, use retention script.
Docker setups, services and more deployment options can be found in Ephemery scripts repo.
Ephemery supports Pectra with iteration 3943814, February 13 7PM UTC. Starting with this iteration, Pectra is scheduled to activate in every upcoming iteration at epoch 10, around 8:14PM UTC. The first activation is before any other testnet, this might get bumpy but enables us to collect valuable testing data for client developers.
To run a node or a validator on Ephemery, use a Pectra compatible client. Not all clients will have a stable Pectra release, you might have to use a release candidate for testing or compile the latest version manually.
As a staker, you will be able to test new features introduced in Pectra like validator aggregation thanks to new MaxEB. We increased the ETH payout in faucets to allow you to easily try this. As a user or developer, you can explore new possibilites of account abstraction and other upgrades coming in Pectra.
The network is currently in its early stages, it runs as a small network with a manual reset mechanism. Each reset changes network parameters and requires a new genesis. Setup and reset mechanism is coordinated via this repository. Each release contains values for the new release.
To run a node and participate in the network, use setup from this repository. There are various deployment options, you can either use a Docker setup, cloud-init script or manually modify the retention.sh script to suit your system and run it as a cron job. There are also instructions for manually setting up a node.
Checkout current version of specs for client implementation and feel free to provide feedback.
Contribute by participating in the network and identifying issues caused by the ephemeral setup. You can help a lot by testing features and infrastracture which might break during the reset. Here are few ideas for general testing:
- Run a node, especially client which is not tested yet
- Add validators, monitor attestations, proposed blocks, slashing issues
- Use your wallet, find out how it behaves after the reset, how it handles different network ID from same RPC
- Deploy dapps, try your favorite developer tooling
- Run infrastracture, explorers, etc
- Reach out with your own ideas for testing
Feel free to open issue in this repository with your findings and ideas. And feel free to join the discussion in Matrix room.
Ephemeral testnet needs a lot of research and development to be stable and widely usable. Here is a simple roadmap overview, for details on current tasks, check the tracking issue.
- Proposal and initial discussion
- Private network with manual reset mechanism
- Using external script to reset the network
- A small private chain was created to identify feasibility issues and to stabilize the devops setup.
- Public network with manual reset mechanism
- Stable network open to the public and wider debugging, simplifing node/validator setup
- Creating general specifications for automatically reset ephemeral testnet
- Discussion about implementation details and specifications based on data gathered from the network with manual resets
- Specs draft
- EIP in review
- Validating specs in EIP
- Automatic onchain infrastracture
- Refuding validators
- Deploying primitives for dapps
- Preliminary client implementation work
- Single client pair, testing on private/public chain
- Improving and finishing specs
- Cross client implementation
- Testing all client combos
- ACD discussion between client teams
