# EPF Week 12 Update (NC Navie Chan) ## Summary This week I have successfully finished all the coding on sync committee reward API including all the unit tests. I have also kick-started the code review stage for the PR [here](https://github.com/sigp/lighthouse/pull/3790). Some initial feedback from Sproul is collected and seems like we are pretty close to getting the PR approved. I have also started looking at the block reward endpoint, and try to come up the calculation algorithm with minimal guidance. ## What I did - Finished all the coding and testing for sync committee reward API - Tried to address some of the comments Sproul left on the PR - Investigated and tried to understand how to calculate the block reward ## Goal Next Week - Address all PR comments and there will be some back-and-forth code modification along the way - Start coding block reward
Last changed by  
 
naviechan
96

Read more

EPF Week 14+15 Update (NC Navie Chan)

Summary For the last two weeks, I winded down on the Lighthouse block reward project as it is almost coming to an end, and started winding up on EIP-6110 as mentioned in EPF Repo. For Lighthouse, after finishing the implementation on the block reward endpoint, I have done some functionality testing on it and is now awaiting for @Sproul to code review. Special thanks to @Alex88 for thouroughly testing my code and caught a lot of mistakes I've made. As for unit testing the endpoint, @Sproul suggested it might not be as straightforward and will take some time hence the PR will not be including any unit test. After a brief discussion with Mikhail, I have decided to take care of the EL side of EIP-6110 by implementing it on Besu. Since my EPF project has always been about CL, EL is an unknown world to me and felt like I am back to day 1 of EPF. I have read up some documentations on CL & Besu (Besu has some excellent docs I will lin them beow), as well as execution-spec and execution-api. I have also opened a very early stage PR draft on Besu to facilitate any discussions. If you are reading this, I am shamlessly letting you know that I am thinking of working on client dev on a full time basis. If there is any opportunity (whether it's a company hiring or financial support in any form) please shoot me a dm on discord: NC#0558 What I Did

2/7/2023
EPF Week 13 Update (NC Navie Chan)

Summary This week for sync committee reward endpoint is mostly a back-and-forth between Sproul leaving PR comments and me addressing the comments. Some of the improvements including formatting code for readability, returning reward info in the correct format and following best coding practice. I have also started working on block reward endpoint- last endpoint of the project. I came up with an initial strategy for calculating block reward, including block proposal, proposer slashing, attester slashing and sync aggregate rewards. An initial implementation is done and will follow up with Sproul if I am on the right track. What I Did Addressed some of the PR comments made by Sproul for sync committee reward endpoint Drafted and coded an initial implementation of block reward Goal Next Week Sync committee: Sproul left a new wave of PR comments so I will need to address it

1/23/2023
EPF Week 10 + 11 Update (NC Navie Chan)

Summary These two weeks I have learned about how to write unit test in Rust as well as some of the tools and libraries provided by Lighthouse to mock beacon chain and beacon state. Particularly BeaconChainHarness which is a one-stop object that creates and manages a mocked BeaconChain and BeaconState that are solely for testing. However I realized the harness currently doesn't support signing and adding sync committee contribution which are essential to my unit testing on sync committee reward endpoint. I added the aforementioned functionality to harness and the mocked chain successfully produced a block that I need (A block that has no attestation but only sync committee contribution). I have also finished the coding on uniting testing sync committee rewards. The strategey here is to compare the balance of each validator in sync committee before and after a block is applied. pre_state_balance + sync_commitee_reward = post_state_balance for every sync committee particpants. An exception to this is the validator who proposes a block that includes the sync committee's output. Since in the post_state_balance it receives the normal block proposing reward and the additional sync committee proposing reward, the aforementioned equation won't work and we will need some other strategy to test the correctness of it. I will need to touch base with Sproul on this. What I did Learned how to write unit test in Rust Learned about the unit test tools and libraries that are needed for sync committee rewards Finish coding up the unit test for sync committee participation reward and attested the correctness of the current calculation of the reward. Goal Next Week

1/8/2023
EPF Week 9 Update (NC Navie Chan)

Summary This week Kevin, Sproul and I had another meeting before the holiday started. Sproul pretty much covered the detail on testing the reward endpoints, had a review of our current code, and the plan for rest of the fellowship program. Since we are progressing slower than expected, we will only be focusing on Sync Committee and Attestation rewards endpoint. We put Block reward to lower priority since Lighthouse has something similar already existed. (But still need to restructure it to meet the Beacon API spec). Code wise, this week is all about testing and refining Sync Committee reward endpoint. Hopefully it will be PR-ready soon. What I did Touched base with Sproul Refactored code to make it more unit testable Wrote some basic unit tests Updated code to use pre-state (state before a block was applied) to calculate sync committee rewards Goal Next Week

12/27/2022
Read more from naviechan
Published on HackMD