# EPF5 Dev Updates - Week 3

### This Week's Summary

This week has been quite eventful, starting off a bit slow and hectic but culminating in significant achievements and progress. Here's a detailed summary of the activities and accomplishments for the week:

## Meetings and Standups

### Weekly Standup and Office Hours
- Attended the weekly standup meeting, which is crucial for syncing up with the team. During this meeting, I had the opportunity to discuss the progress of my tasks, share any challenges I faced, and get updates from other team members on their respective tasks.
- Participated in the office hours, where I was able to ask questions and get guidance on various aspects of my work.

### Meeting with Gradine Team
- Joined the weekly meeting with the Gradine team and other contributors, gaining valuable insights into the ongoing efforts and upcoming tasks within the project. We discussed updates on current milestones, provided feedback on recent code changes, and engaged in strategic planning for future releases.

## Achievements

### Support for macOS
- **Completion:** Successfully completed the support for running the Gradine client on macOS. This involved addressing compatibility issues, setting up the development environment, and ensuring that the client operates smoothly on macOS systems. I had to debug several platform-specific issues and make necessary adjustments to the codebase.
- **Validation:** After setting up the Gradine client, I joined as a validator on Holesky using Geth and Lighthouse. This practical experience helped me understand the validation process better and the intricacies involved in running a node. It also provided me with a deeper understanding of the interaction between different Ethereum clients.

### Fuzzing Gradine
- **Access Challenges:** I attempted to gain access to the latest fuzzer used by the Ethereum Foundation (EF) protocol security team but was unable to do so. The current fuzzer available on GitHub was outdated and not suitable for the latest hard fork.

- **Consultation with Infosecual:** Had a productive chat with Infosecual, from whom I learned that each Ethereum client uses a separate fuzzer tailored to its specific needs. He suggested looking into the fuzzers included in the Lighthouse repository, as they might be adaptable for Gradine, given both projects are written in Rust.

- **Jimmy Chen's Guidance:** I had to reach out to Jimmy Chen from Lighthouse, and he told me that,
> There's an archived beacon-fuzz repo ([beacon-fuzz](https://github.com/sigp/beacon-fuzz)), which is now being maintained privately due to the sensitive nature of the work and its potential impact on the live beacon chain. It's managed by the SigP security team, and I don't have access to it either.

So, my primary goal from now on is to build a fuzzer for Gradine.

## Future Directions

This conversation guided my next steps, pointing me towards leveraging existing fuzzing tools from similar projects and adapting them for Gradine's unique requirements.

## Testing and Investigations

### Consensus-Spec-Test
- **Test Execution:** Ran the consensus-spec-test using the command `python -m pytest --preset=minimal eth2spec`. The results were:
- 996 tests passed.
- 192 tests were skipped.

- **Review Plan:** Plan to review the test report to understand why certain tests were skipped and to correct any mistakes. This involves examining the logs, identifying patterns in the skipped tests, and understanding if there are configuration or setup issues causing these skips.
- **Feedback from Saulius:** Saulius informed me that tests are built and run on every GitHub commit, and all tests should pass. He provided resources to help align my testing environment with the CI pipeline:
- [GitHub CI Workflow](https://github.com/grandinetech/grandine/blob/develop/.github/workflows/ci.yml)
- [GitHub Actions Run](https://github.com/grandinetech/grandine/actions/runs/8579857603/job/23515314345)
- **Current Investigation:** Currently investigating the reason behind the 192 skipped tests on my end. My goal is to ensure that all tests run and pass consistently, aligning with the results seen in the CI pipeline. This involves checking for environment-specific issues, dependency mismatches, or potential misconfigurations in my local setup.

## Plans for Week 4

### Fuzzing Gradine
- **Lighthouse Fuzzers:** I will look into the archived beacon-fuzz repository to get started on building a fuzzing tool for Gradine and understand how Lighthouse integrates these fuzzers into their testing workflow.
- **Rust-based Fuzzers:** Explore other Rust-based fuzzers like AFL++. AFL++ is known for its effectiveness and feedback-driven approach, making it a suitable choice for fuzzing Gradine. This exploration will include setting up AFL++ and configuring it for Gradine, running initial fuzzing tests and analyzing the results, and iteratively refining the fuzzing process to cover more code paths and potential edge cases.

### Testing
- **Skipped Tests Investigation:** Continue investigating the skipped tests in the consensus-spec-test. This includes reviewing the detailed test report to identify common factors among the skipped tests and cross-referencing with the CI pipeline configuration to ensure my local setup matches the expected environment.
- **CI Pipeline Alignment:** Ensure that my local testing environment is fully aligned with the CI pipeline. This involves following the configurations and dependencies as specified in the CI workflow, running comprehensive tests locally to mirror the CI pipeline’s test runs, and addressing any issues that prevent tests from passing in my local environment.

### Collaboration and Learning
- **Regular Communication:** Maintain regular communication with the Gradine team and other contributors to stay updated on new developments and share my findings. This involves actively participating in standup meetings and office hours, sharing progress updates and seeking feedback from the team.
- **Leveraging Expertise:** Utilize the expertise of colleagues and available resources to enhance my understanding of Gradine’s codebase and testing methodologies. This includes reviewing relevant documentation and previous implementations, engaging in discussions and knowledge-sharing sessions with more experienced team members, and experimenting with different testing and fuzzing techniques to broaden my skill set.

# References

- [GitHub CI Workflow](https://github.com/grandinetech/grandine/blob/develop/.github/workflows/ci.yml)
- [GitHub Actions Run](https://github.com/grandinetech/grandine/actions/runs/8579857603/job/23515314345)
- [AFL++](https://aflplus.plus/)
- [Beacon-fuzz](https://github.com/sigp/beacon-fuzz)