Kevin Bogner

@kevinbogner

Joined on Oct 6, 2022

  • COSIC WEEKEND 2024 (April 26-28) Location: Les Gîtes du Chaffour, Rue du Chenal 40, La Reid (Theux)Map: OpenStreetMap Friday, April 26 Time Activity 17:00 Departure for the event
     Like  Bookmark
  • Started Ethereum core development with the Ethereum Protocol Fellowship (EPF) from October 2022 until March 2023, then advanced to prototyping EIP-6110 in Lighthouse from March to July 2023, funded by a grant from the Ethereum Foundation. EPF (Oct 2022 - Mar 2023) First Commit consensus_client_reward_APIs Overviewblock_rewards and attestation_rewards in beacon-APIs sync_committee_rewards in beacon-APIs attestation_rewards API in Lighthouse Development Updates
     Like  Bookmark
  • Motivation Develop APIs that provide detailed reward data for Ethereum validators. beaconcha.in rewards Goal Provide data on rewards paid to the validators broken down for each of their duties: attestation_rewards block_rewards
     Like  Bookmark
  • This project aims to develop APIs that provide detailed reward data for Ethereum validators. The APIs will allow clients to access information regarding the amount of rewards earned for their duties and will enhance transparency in the consensus process. Prior to the development of this project, there was a lack of publicly available APIs that could accurately calculate the rewards paid to validators, hindering the development of essential tools such as block explorers and graphical user interfaces. By developing reliable and comprehensive APIs, this project aims to promote further research on the economic incentives of consensus networks and facilitate the design and operation of blockchain systems. For more information, see the project document. Overview The Ethereum beacon-APIs are a collection of generic RESTful APIs designed to enhance interoperability across beacon node implementations. The new APIs for this project, attestation, block, and sync_committee, can be found here. As part of this project, these three APIs were designed to provide information on rewards earned by validators for their respective duties. These APIs enable clients to obtain detailed information on the rewards earned by each validator, enhancing transparency in the consensus process. Now that the new APIs have been proposed and accepted, they were implemented in Lighthouse. This integration allows the APIs to be used by clients running Lighthouse and enables easy access to reward data for each validator.
     Like  Bookmark
  • :heavy_check_mark: https://github.com/mkalinin/eth2.0-specs/blob/deposits/specs/eip6110/beacon-chain.md#preset https://github.com/kevinbogner/lighthouse/blob/336dc9244465a7abea5f17b9b60834d66da1199a/consensus/types/src/eth_spec.rs#L281-L283 :heavy_check_mark: https://github.com/mkalinin/eth2.0-specs/blob/deposits/specs/eip6110/beacon-chain.md#new-containers
     Like  Bookmark
  • Hey, We got all three reward APIs implemented into Lighthouse. The specs can be found here. In the following, I want to showcase how the query the APIs and what the output looks like. Sync committee Query: $ curl --data "[\"8663\", \"0xb0bd225a6202effca9986e8c3ed50b4f29f8b3154ef21337843d945877aadd6c9bf40ff39393f329cfb243e1dfde23ee\"]" -H "Content-Type:application/json" "http://localhost:5052/eth/v1/beacon/rewards/sync_committee/5745617" | jq Output:
     Like  Bookmark
  • Hey :wave: For the last two weeks, I have been ironing out the attestation_rewards API. Also, I have been testing the endpoint manually, and the data is the same comparing it to beaconcha.in. In this update, I want to cover the 4 cases the attestation_rewards falls into: validator voted correctly, validator didn't vote correctly, validator gets penalized, and validator is not eligible.
     Like  Bookmark
  • Hey :wave: in my last update I discussed the first part of the attestation_rewards endpoint, the ideal_rewards. In this update, I want to focus on the second and last part, the total_rewards. { "execution_optimistic": false, "finalized": false, "data": [ { "ideal_rewards": [ {
     Like  Bookmark
  • Hey :wave: In my last update, I explained the structure of the attestation_rewards API. The design can be divided into three parts: Selecting the correct state, calculating ideal_rewards, and calculating actual_rewards. Selecting the correct state is already implemented and can be found here. Therefore, I want to take a closer at the ideal_rewards because they have been the focus of this week.
     Like  Bookmark
  • Hello, (This blog post was created with the help of ChatGPT and minor major modifications by myself as a fun little exercise.) Welcome to the latest dev update for our software project! In this update, we will discuss our progress on the attestation_rewards. In our last dev update, we highlighted the challenges we've been facing with the sync_committee_rewards. Since then, we've had a productive meeting with NC and sproul, during which we discussed the plan for implementing the attestation_rewards. The meeting notes created by sproul, which guide us through the implementation process, can be found here. While NC focuses on testing the sync_committee_rewards API manually, we will be using the meeting notes to guide the development of the attestation_rewards feature. It's the holiday season, so things are moving slower than usual. However, we will return to our regular pace in the coming week.
     Like  Bookmark
  • Discussed [11/30/2022] Dividing work is hard. Somebody codes and the other one reviews it might be the best approach here. Calculating the sync_committee_rewards is the hardest part for the API. ToDo [11/30/2022] [ ] NC to create draft PR and give Kevin write access to the repo.
     Like  Bookmark
  • Hello, Since my last update, I opened a draft PR for the sync_committee_rewards, which is still our primary focus. We all realized that the implementation is more complex than initially anticipated. Today, I will break down the challenges we are facing in a non-technical way. Explaining our obstacles is a good exercise for me to make sure I understand the concept and is also helpful for people not involved in the topic to understand it better. We mainly discovered the following issues that need to be solved: using the correct state, selecting the right validators, and handling edge-cases.
     Like  Bookmark
  • Hi :blush:, In my last update, I presented the work done for implementing sync_committee_rewards into Lighthouse. This week, I had two meetings with NC to discuss how we want to coordinate the work. The meeting notes can be found here. In the following, I want to talk about the current state of our work by explaining our modifications. However, this is just a draft and will most likely be changed in the future after reviews by the Lighthouse team. sync_committee_rewards.rs This part still needs some modifications. We get different values and then call compute_sync_aggregate_rewards(). pub fn compute_sync_committee_rewards<T: BeaconChainTypes>( chain: Arc<BeaconChain<T>>,
     Like  Bookmark
  • Hi, In my last update, our beacon-APIs endpoints merged; you can check them out in the API browser. Since then, the priority has been on the following three things: I got my guide merged on how to run a beacon node on Lighthouse. Worked my way through the Rust book :crab:. Had the kickoff meeting for the endpoints implementation into Lighthouse, with NC and sproul. We decided to start with the implementation of sync_committee_rewardsbecause it is the most straightforward API. The implementation can be roughly divided into the following parts: API handler - compute_sync_committe_rewards
     Like  Bookmark
  • Hey :wave:, We finally made it. We merged our endpoints (#260 and #262) to the beacon-APIs. In this development update, I want to give a more detailed showcase of the three APIs: get block rewards; get attestation rewards; and get sync committee rewards. In the following four sections, I will explain what general design decisions we took and what endpoints-specific choices we made. ![](https://i.imgur.com/s7zzPI9.png =500x500)
     Like  Bookmark
  • Hello :wave:, In my last update, I created a pull request for the beacon-APIs to fetch data for block proposals and attestations. Since then, I have primarily worked on two things: Created a pull request with a sync_committee_rewards endpoint for the beacon-APIs. Wrote the project proposal for the consensus client reward APIs. In the following, I will discuss these two tasks in detail. Sync committee endpoint The endpoint for sync committee rewards looks like the following:
     Like  Bookmark
  • Hi, Since my last update, I have focused mainly on two things: Visualizing data on my dashboard. Optimizing the data fetching process. However, since it’s a dashboard based on consensus clients, it would only be logical to display the rewards paid on the consensus side. Today there is no resource to access the consensus client block rewards. Therefore, I will work on reward calculation APIs to the beacon-APIs standard. The design and implementation will be done on the consensus client, Lighthouse. Michael Sproul already created an issue regarding this topic. This development update will be based on the issue, so if you want to grasp everything, check out the issue first.
     Like  Bookmark
  • Hi :wave:, In my last update, I concentrated on the rewards structure for validators. Since then, I have primarily worked on two things: Wrote a guide for the Lighthouse book on how to run a node. Created a pull request with two per-validator reward endpoints for the beacon-APIs. This development update is about the implementation of the endpoints, while the guide was more of a side quest. Preface I started the EPF by building a dashboard for consensus client data. However, currently, there is no source to get per-validator rewards. Therefore, sproul created an issue to describe the problem with possible solutions.
     Like  Bookmark
  • Hey :wave:, Since my last update, I have mainly worked on two things: Collecting relevant data on Consensus Clients and MEV-Boost. Deploying the Website for visualizing the data. Consensus Clients and MEV-Boost Currently, there are two primary sources for my data: Blockprint provides data on Consensus Clients.
     Like  Bookmark
  • Hello everyone :wave: It's only been a week since I started in the Ethereum Protocol Fellowship program, but I have the need to sort my thoughts by writing them down. The past few days have been challenging but also rewarding. I'm still overwhelmed by the support from people willing to help a complete stranger with a funny-looking cat picture. So, how did I get started? First Steps I've dived right into the project ideas proposed by the program's mentors. Brainstormed a bit and decided I might want to create an interactive Ethereum roadmap -- Yeah, I know what you are probably thinking.
     Like  Bookmark