# Path forward for Holesky ## Current status: - Holesky hovers around ~35-50% participation rates - Clients are continually struggling with memory usage on Holesky - We will take a long time to eject and slash all the required validators before reaching finality - This is a useful exercise and we have a lot to learn, however we need a new location for allowing users and staking pools to conduct their testing - Earliest estimated date for finality according to Manu's doc [here](https://docs.google.com/spreadsheets/d/1nndNt-XC4JzqsjmCRuiXBGCGMFomCHx_e_DZzFqvhGM/edit?usp=sharing) is 28th of March ## What we immediately need: - A location for clients and external parties to test pectra on - This location would atleast be required until 28th March, open question if its needed longer than that - Once Holesky has finality again, we can always make deposits and bring up the total stake attesting ## Overall Question: - Does any option we choose need to replace holesky altogether? Or are we fine with having a temporary location for testing? ## Options: Note: In none of the options is Holesky going away, we will allow it to play out and learn from the chain. 1. Setup a holesky shadowfork with a new validator set (same entities we know, new validator keys) 2. Setup a holesky shadowfork with the same validator set, but updated genesis validator pubkezs, using the same FORK_VERSION but a new deposit contract address (deploy deposit contract at mainnet address) 3. Setup a holesky shadowfork with the same validator set, using a new FORK_VERSION to sever the link to Holesky 4. Setup a fresh network for people to test validators on (mainnet size) Having only holesky as is and making deposits once we achieve finality again would basically remove the ability for the community to test for a considerable amount of time and should not be seriously considered. ## Details ### Option 1: Holesky shadowfork new validator set - We would have all the validators and tools be able to "easily" resync onto the holesky shadowfork - Validators would be expected to continue running their holesky nodes until the chain is fine again - CL state and Validator keys are completely new in the new beaconchain, there is no risk of invalid attestations/etc - If client teams are to officially support this, we might need to rename the chain configs and that could be messy ### Option 2: Holesky shadowfork almost identical validator keys (old FORK_VERSIONs, new deposit contract) - We would have all the validators and tools be able to "easily" resync onto the holesky shadowfork - All validators that were active at the shadowfork boundary in the original holesky chain will be activated as genesis validators on the shadowfork chain. They would have the same pubkey and indexes. - Due to the updated Validator public keys, we get a new GENESIS_VALIDATORS_ROOT and therefore a new Network digest, which invalidates any attestation from the original holesky - We deploy a new deposit contract (preferrably at the mainnet address), so old deposits from the old holesky are not imported twice when retaining the ForkIds - Everyone who had a validator on Holesky is immediately active on the shadowfork as deposits post genesis are retained as is (incl. current balance & withdrawal credentials) - Genesis validators can be operated by ethPandaOps if the client team is unable to do so - If client teams are to officially support this, we might need to rename the chain configs and that could be messy ### Option 3: Holesky shadowfork old validator keys (new FORK_VERSIONs) - We would have all the validators and tools be able to "easily" resync onto the holesky shadowfork - The new FORK_VERSIONs should invalidate any attestations from the original holesky - Everyone who had a validator on Holesky is immediately active on the shadowfork - If client teams are to officially support this, we might need to rename the chain configs and that could be messy ### Option 4: Fresh network - The small EL state size would mean it is easy to sync up to the network, we can align the contracts and configs to be as close to mainnet as possible - The problem would be that every tool and provider would need to support this new network, which usually takes time (e.g infura/metamask/RPC providers/gnosis safe/etc) - We can spread the validator keys amongst client devs and allow everyone else to make deposits quickly after genesis - Client releases are cleaner since its a new named testnet - We could officially bake in a higher gas limit in order to use it for gas limit testing as well ### Holesky Shadowfork general info - We would possess the entire EL state of Holesky, the chainID stays the same, the balances of every address is identical to Holesky - We achieve this by taking the latest good EL block of Holesky and then placing that in the genesis state execution payload of a new beaconchain - This would trigger building of a new block on top of the EL state of the holesky chain, this new chain is a shadowfork  **Note: Goerli in this case is Holesky**