# Checklist for Ethereum Merge This checklist is meant for confirming that your Execution Layer(EL) and Consensus Layer(CL) are correctly configured in preparation for the Ethereum merge. :::warning This checklist is not definitive. Every client combination has minor variations that make writing definitive guides extremely hard. This checklist is meant to let you cover most of the common pitfalls related to configuring nodes. ::: To start off, your setup should look either like the Ethereum node or Ethereum validator shown in the diagram below. If it doesn't, then please visit [this](https://notes.ethereum.org/@launchpad/node-faq-merge) guide before coming back here.  Since there are a minimum of two pieces of software to configure, we will give you two checklists: One for the EL and one for the CL. ## Execution Layer node checklist: - [ ] Check the flags used to start your EL node, ensure that the `network` is set correctly - [ ] Check the flags used to start your EL node, ensure that the `jwtsecret` flag is set correctly. - [ ] Check the flags used to start your EL node, ensure that there is **NO** flag with the words `terminaltotaldifficulty`. During normal operation, **this flag is not needed**. **It is only meant to be used for emergencies**. - [ ] The EL and CL have an API call that ensure that the configuration is correct. The output of this check is present in your logs. So check the logs of the EL node, You should periodically see the log line: `engine_exchangeTransitionConfigurationV1` with no error associated with it. If you are on a Linux machine, running `grep -i "engine"` on your logs (except for Erigon EL nodes) should show you the relevant log lines. - [ ] In general, please check if your logs indicate any `CRIT` or `ERROR` log lines. A cursory look should suffice as all misconfigurations will be repeatedly printed in the logs. ## Consensus Layer node checklist - [ ] Check the flags used to start your CL node, ensure that the `network` is set correctly - [ ] Check the flags used to start your CL node, ensure that the `jwtsecret` flag is set correctly. - [ ] Check the flags used to start your CL node, ensure that there is **NO** flag with the words `terminaltotaldifficulty`. During normal operation, **this flag is not needed**. **It is only meant to be used for emergencies**. - [ ] Check the logs of the CL node, ensure that **NO** logs relating to `No eth1 RPC configured` or `No execution engine` are present. - [ ] Check the logs of the CL node, you should see no errors related to the `eth1` RPC. If you are on a Linux machine, running `grep -i "eth1"` on your logs should show you the relevant log lines. - [ ] The EL and CL have an API call that ensure that the configuration is correct. The output of this check is present in your logs. So check the logs of the CL node, You should periodically see the log line: `engine_exchangeTransitionConfigurationV1` with no error associated with it. If you are on a Linux machine, running `grep -i "engine"` on your logs should show you the relevant log lines. - [ ] In general, please check if your logs indicate any `CRIT` or `ERROR` log lines. A cursory look should suffice as all misconfigurations will be repeatedly printed in the logs. - [ ] If you have a validator connected to your beacon node, then please make sure that you have a fee recipient configured. More information can be found [here](https://launchpad.ethereum.org/en/merge-readiness/#fee-recipient). ## Common pitfalls: We wanted to list some common pitfalls so that you can avoid them in your setup: - Override flags - Due to the low hashrate of testnets such as Ropsten, we had to utilize the Total Terminal Difficulty Override flag. This flag is used to determine when the merge is triggered. Some setups reused their configs from older testnets while leaving the `override-totalterminaldifficulty` flag enabled. Since the flag contains a value that isn't related to the testnet or is a placeholder, the node doesn't behave as expected. In a non-emergency scenario, this flag will never need to be used. So please make sure its not present in your setups unless explicitly mentioned otherwise. - New Engine API port - The Engine API is exposed on a different port from the JSON-RPC port. This change might not be anticipated by some setups and it might lead to misconfigurations. The misconfiguration will be present in the logs as an error. - Improperly configured Engine API port - Since the Engine API port is a new configuration, a lot of automation tools do not take it into account. If the CL cannot connect to the EL's Engine API port, it will let you know in the logs. The Engine API is only used after the merge, meaning any misconfiguration on it will only be noticed after the merge occurs **OR** in the logs. Therefore, its extremely important to check the logs for the recurring Engine API misconfiguration message. An absence of the misconfiuration message implies that everything is fine. - Updating just the EL or just the CL - In testnets, we faced a scenario where users updated either the CL or the EL without checking the minimum required versions for the Merge. This led to API incompatibilities or differing TTD values being present and hence an improper setup. Please visit the [Ethereum Foundation Blog](https://blog.ethereum.org/) for announcements and up to date information on minimum required versions. - Not configuring JWT tokens - The Engine API port communication is JWT token authenticated. The failure to configure this token on **BOTH** the CL and the EL would imply that they cannot communicate, hence improperly configured. This failure to communicate error will be shown in the logs as a missing Engine API configuration. Please ensure that the JWT token is configured on both pieces of software. - Disk space requirements - Running both pieces of software does require more disk space. To accomodate this please ensure that atleast 200GB SSD's are used for testnets and 1-2TB SSD's are used for Ethereum Mainnet.