## Project Abstract

The goal of this project is to extend support for building Grandine, an Ethereum consensus client, on Windows. While Grandine has been primarily developed and tested on Linux, expanding its compatibility to Windows will make it more accessible to a broader range of developers and users.

Here is the detailed project proposal: [Grandine Windows Support](https://github.com/eth-protocol-fellows/cohort-five/blob/main/projects/grandine-windows-support.md).

## Current Status

Historically, Ethereum clients mainly target to the Linux/Unix OS enviroments. Although some of these clients may release binaries for Windows, most of them are not well tested and have running problem. These problems and challenges are what this project needs to solve.

## Challenges

All the challenges are summaried in the following table:

| Problems | Comments |
|---|---|
| Jemalloc failed to build | Can be built for correct config, but it is hard to config correctly.
| Stack overflow in debug mode. | Windows’ stack size is conservative |
| Test failures in ssz spec tests | Git's default value of core.autocrlf on Windows is true, this will change some ssz binary artifacts |
|Reth can not boot after its first run | "Database commit error code: 998", but this not due to db file corruption. |
| System metrics are not supported | Missing in Both Grandine and Lighthouse. |
| Official windows APIs are unsafe | Unsafes are forbidden by many teams in Rust via lints. |
| Screensaver + sleeping | Common use cases for Windows.|
| Not easy to run a validator | Complex setup and configs for making staking + CL + EL. |

As you can see, we have met problems in running or missing of components and dependencies, engineering, tests, and finally collaboration with EL clients.

### Solutions

Not all the challenges has perfect solutions for them, for the time limitation or the engineering complexity. For example, the stack overflow error running in debug mode stems from the depenedencies/libraries: libp2p and its internal children, you can not easily fix this problem, unless you can replace or fix these depenedencies. But the depenedencies are so fundamental that it can not replaced or fixd in a reasonable time in the span of cohort-5.

All the solutions or workarounds are summarized in the follow table:

| Problems | Solution/Workaround | Thoughts/Reflections |
|---|---|---|
|Jemalloc memory allocator failed to build | Disabled, in favor of the Windows built-in allocator | Truth: Jemalloc is great for server side but neither necessary for edge nor better |
| Stack overflow in debug mode | Run in release mode. | Reason: big on-stack allocation in debug mode in rust libp2p call stack. <br/>Reflection: 1. Limit statics and use a top singleton to manage others; 2. Rethink or may overhaul fundamental libs like libp2p. |
| Test failures in consensus spec ssz tests | Set core.autocrlf to false on Windows. | Lesson: Consistency and debuggability are so important for developers. Never overemphasis on this. |
| Reth can not boot after its first run (Database commit error code: 998) | Run in WSL on Windows. | Lessons: 1. No Windows based tests in CI of Reth; 2. Performance isn't all: mdbx is a double-edged sword |
| System related metrics are missing | Implemented missing cpu and memory stats | Points: 1. metrics have its API proposal from beaconcha.in team; 2. Grandine now has better metrics support on Windows than Lighthouse; |
| Official windows APIs are unsafe | Upstream unsafes to winsafe. | Pitfall: 'forbid' for lints just works for codes in current workspace but not for those in libraries |
|Screensaver and sleeping | No problem. | |

Finally, with all the above solutions, I can successfully run all the tests of Grandine on Windows. And I also run Grandine as a validator on Windows in the Holesky testnet successfully.

All the process of challenges and their solutions can be seen in the [issue #41](https://github.com/grandinetech/grandine/issues/41).

All the fixs or workarounds are included in the [PR #42](https://github.com/grandinetech/grandine/pull/42).

## Future of the Project

1. Add the support to other unimplemented systems or architectures

In this project, I just fix the Grandine for runing on Windows. In fact for Grandine and the whole Ethereum clients, there are still many systems or architectures which can not run well against, for example, BSD, ARM, RISC-V. All of these are directions that can be explored.

2. Improve the ease of use of Ethereum clients/validators
In the process of this project, the biggest challenge for Ethereum community is that it is not easy to run an Ethereum validator.

Before running a validator, you should prepare staking firstly. Then you need run CL and EL clients together. For each clients, there may be different roles for runing. It may be not enough to just run two processes of two-type clients. For example, for Lighthouse, BN and VC is different roles. You should run two Lighthouse processes to act for BN and VC in the same time. For the interaction of different clients and roles, different parameters need to be configured more or less to make all these working. Sometimes, the documentation updates for clients are not that timely. You need to try different parameters.

All of these may be acceptable for developers, but it is very unfriendly to the ideal of allowing everyone in the world to join the network by Ethereum.

I propose new project idea about the CL + EL integration in cohort-5. Unfortunately, I didn't have time to finish it, but it's certainly a direction worth exploring further.

## Experience within EPF

EPF is a great opportunity for the public to get to know better about the core protocol and its development for different clients.

For me, it was a great journey to join EPF cohort-5. During this time, I have gained a deep understanding of Ethereum's consensus protocol and its implementation, worked on getting Grandine supported on Windows, and conducted in-depth research on the integration of CL(Consensus Layer) and EL(Execution Layer).

I now have confidence that this experience has paved the solid road for my journey into Ethereum's core infrastructure development. I look forward to continuing this journey and going beyond.

It's my honor to be invited to Devcon SEA in Bangkok and talk and communicate with all EPFs. I look forward to meeting all of you again in the Ethereum core community in the future.