This week I have started reaching out to my fellow Kevin Bogner and mentor Michael Sproul and drafted up the specification of rewards API. Furthermore, I have also decided to implement rewards API on Lighthouse within the course of fellowship. May contribute to other clients if time permits.
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
Feb 7, 2023Summary 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
Jan 23, 2023Summary 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. 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
Jan 16, 2023Summary 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
Jan 8, 2023or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up