Weeks Ten and Eleven EPF6

--- title: Weeks Ten and Eleven EPF6 tags: [EPF] --- # My Second PR My whole two weeks was about PRs. During week ten I had a conversation with Sally from the Besu team. She had some concerns about the database reset and how it's going to be implemented. It sounds like Besu team are not convinced on Ephemery being implemented fully native inside the code base. I've shared my views on the implementation and reasoned why Ephemery should be implemented completely native inside the client. I started working on the task, and after spending time and effort on it, luckily by the end of week eleven I was done with the task. In the conversation link you can see also the description for the PR. for Opening the PR, I ran into some issues with passing tests on besu which are not related to my changes to the code base. All tests passing are required to be passed for opening a PR by Besu's policy. I shred the info into the test failing points on Discord. Sally made a PR for it, which resolves lots of those errors. Talking with A. Hamlat, a team member of Besu, I realized most of the errors are related to the OS and are based on the machine the tests are running on, so there is nothing serious to be worried about. I already added a few tests to the PR. The next step in the project proposal is writing tests. I'm not sure if I write tests or if I work on another task and see what they ask about my PRs so far. Tests are also necessary, though, but can be postponed if they ask for something else. >- Weeks 12 and 13 >Write tests for 'restart network' and 'reset DB.' >Add any documentation that is needed for the tasks. [Link to the conversation](https://github.com/hyperledger/besu/pull/9084) [Link to the second PR: implementation of Ephemery reset database feature, resolves issue #8180](https://github.com/hyperledger/besu/commit/0bc7aa47765e9c25810630852bcefb36373686f2) Hear is the discussion: :::spoiler :::success > @0xEllie how do other EL/CL clients deal with rollover of ephemery network from one period to the next? @macfarla It hasn't been fully implemented on other clients yet. The implementation should be tailored to each client based on the language, architecture and unique mechanism. Besu is going to be the first execution client with automated restart functionality within the node, for now. > Automating a restart is one thing but deleting the db seems a bit dangerous tbh. I'd be happy with giving the user the manual instructions of what they need to do, but leaving it as a manual step. > Another idea would be using a different database dir? Maybe deterministically computing the db dir (or datapath) based on the ephemery chain id? Definitely I do agree with you! deleting DB is not right approach to reset DB. I also thought about changing db dir based on ephemery chainID at each restart. This is a good idea and can be the approach if I dont come up with a better idea or if the idea costs more than its worth. > I'd be happy with giving the user the manual instructions of what they need to do, but leaving it as a manual step. leaving it as manual, I think can be last option if we wouldn't figure out a better solution. As its not only the db that should be undergoing a change but also peers needs be reset. Maybe better not to rely on manual steps since it can be overwhelming for users over a long time. > even the auto-restart seems like it could be solved with devops - cron job to restart the service, move or delete the db as you like These are some reasons to help us why manual and devOps shouldn't be considered as an ultimate solution for Ephemery: - Restart on Ephemery happens at a specific time on every cycle. this means the manual steps are not going to be walked through only once and need to be happen on a regular base(for now every month). - Restart happens at a specific point in time on 28th day of ephemery cycle, which means its not easy for every node around the world to go through a manually-setup at a specific time in one day( might be at 3 am somewhere) - Previous reason also can lead Ephemery network into a consensus problem when there are less nodes keeping up with the new chain at the start of each cycle. - Reseting peers would still remain unresolved (or maybe problematically resolved) with manual approach. - The node would experience a down time during the restart if its not going to happen smoothly programmatically inside each client. - We will have a better access for further changes and access when its implementing natively inside the codebase. - Other requirement for implementing ephemery is enabling the Besu client to become a bootnode itself. I havent done any research on this for now but, to my knowledge so far, it probably would need to be handled inside code during each restart. This PR is only restarting the network at a calculated point in time. Meaning, it enforces the network to setup new `timestamp` and `chainId` for the network as its new genesis parameter every 28 days at a specific timestamp. Next steps are going to be `reset db`( which I'm currently researching on it )and `reset peers` afterwards. I do consider your concerns and comments in the implementation and I'm thankful for your guidance! ::: A look into my second PR description: :::spoiler # Ephemery reset database feature ## Description of implementation of Ephemery reset database feature, resolves issue #8180 commit (https://github.com/hyperledger/besu/pull/9084/commits/0bc7aa47765e9c25810630852bcefb36373686f2) This commit is going to resolve the issue with resetting the database after each restart of Ephemery network. Around the beginning of launching a Besu node, when the network is Ephemery, it creates a new directory inside the data path named `Ephemery-chain-[chainId]`. This improves users' convenience in two ways: - Avoids confusing ephemery data with other networks' data. So when a user wants to delete all the data on Ephemery network and go on another network, they easily can remove the whole directory of Ephemery with no bad consequences. - Data on mainnet are quite big. When interruptions happen while the network is syncing, the sync data can be resumed. In this case, removing the data path folder would delete all the already synced data on mainnet too, and it takes so much time to download the data for mainnet again. Thus, Ephemery data can be dropped away easily without confusing its data for another network. At the network restart due time, the folder will be deleted. This can be handled manually too—please let me know so I will make a PR for it; however, deleting old data after restart has no harm. It actually makes it less reliant on users' actions. At each start of Ephemery network, it creates a new directory based on chainId. Almost everything will be refreshed by each restart, but not things that are not needed to be refreshed, such as the node public key. The Ephemery node needs to maintain the same public key even with a new chainId. The mechanism for restart is mirroring the main besu start while enforcing new changes such as `chainId` and `timestamp`. It also downloads new data inside a new folder and drops the old data. For more code readability and neat implementation, I renamed the main part of the mechanism for the `BesuCommand.java` class inside the `run()` method. It should be run sequentially, so I renamed it `initialProcess()`. If you don't like it or you think this doesn't speak much about the function, again, please let me know so I will consider it in another PR. Every change to the code base is happening only under `If Network Is Ephemery`. Therefore, this PR doesn't change anything on other networks, and more importantly, the mainnet. Hope it's aligned with your concerns. :::