# EPF Cohort 6 - Week 1 Update

As our cohort progresses, I've decided to focus on developing a production-ready validator for Ream, that will be tested thoroughly on testnets before eventual deployment on Mainnet. To accomplish this foundation, I've started the following foundational work over the past few weeks to get a headstart on enabling the validator to operate against a beacon node:

1. Implemented helper functions outlined by the honest validator sections of the [consensus specs](https://github.com/ethereum/consensus-specs/tree/dev/specs): Phase0, Altair, Bellatrix, Capella, Deneb and Electra.
2. Implemented signing with BLS signatures in the ream-bls crate supporting [blst](https://github.com/supranational/blst) and [bls12_381](https://github.com/zkcrypto/bls12_381) backends.
3. Implemented a beacon API client for the validator.
4. Implemented client-side requests to the required [Beacon API endpoints](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi) necessary for validator functionality.

I communicated with another fellow, Mark - [Patchoulis](https://github.com/Patchoulis), who shares interest in building the Ream Validator Client and has been actively contributing to related issues. We've discussed the next phases of development and are exploring potential collaboration on this project.

## Week 1

This week I focused on implementing core validator functionality, including duty fetching, block proposal, attestation creation, and aggregated attestation submission. These represent the initial implementations following the [validator flow](https://ethereum.github.io/beacon-APIs/validator-flow.md) specification and will undergo thorough testing throughout the upcoming months.

I also looked into features for validator management, specifically different signing methods that could be implemented: local signing and remote signing architectures. The [web3signer API](https://docs.web3signer.consensys.io/) enables a validator to store their keys in outside a validator client and still use them to sign blocks, attestation and other beacon chain objects. Remote signing is accomplished by making a request to the web3signer REST API and receiving a signature for the requested object. This may be a feature we will want to implement once the minimal viable client is functional.

Additionally, I researched into voluntary exits and explored how we would integrate this functionality into our validator implementation. I found that if a validator does not explicitly exit and goes offline, they will incur [penalties](https://eth2book.info/latest/part2/incentives/slashing/#other-penalties) for missing their protocol duties as well as higher penalties in the case of an inactivity leak. I have started working on implementing exit capabilities into the validator.

## Resources

- [Validator Flow](https://ethereum.github.io/beacon-APIs/validator-flow.md)
- [Remote Signing for the Validator](https://docs.web3signer.consensys.io/)
- [Voluntary Exits](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet/part-iii-tips/voluntary-exiting-a-validator)