Try   HackMD

Ethereum Protocol Fellowship Week 0

Tuesday June 20th, 2023

Today I did some light reading. Just starting out!

Wednesday June 21st, 2023

A few weeks back I submitted a PR for implementing the expected_withdrawals HTTP API in Lighthouse.

Issue
https://github.com/sigp/lighthouse/issues/4029

PR
https://github.com/sigp/lighthouse/pull/4390

Spec
https://github.com/ethereum/beacon-APIs/issues/301

Helpful link for beacon API specs
https://ethereum.github.io/beacon-APIs/

Today I received some feedback. I need to:

  • run clippy, make lint, and cargo fmt –all to fix some formatting issues
  • support ssz responses
  • add optional propsoal slot query param
  • fix chain.get_expected_withdrawals arguements. second arg should be state.slot() + 1
  • check if expected_withdrawals_invalid_state test requires builder_threshold. might be good enough to just use ApiTesterConfig::default()?

I will update the list above as I complete these tasks

other notes:

  • run a specific test in lighthouse using this command cargo test --release tests::expected_withdrawals_valid_capella -- --nocapture

Thursday June 22nd, 2023

I received an email last night from Mario and Josh to schedule an interview for the EPF cohort #4! Super excited to chat with them, I'm going to spend the next few days making sure I'm ready for the interview. I also want to make sure I write down some questions I have about the cohort so I dont forget to ask.

Today I continued work on implementing the requested changes for the expected_withdrawals HTTP endpoint in Lighthouse.

I'm working specificially on the SSZ seralization portion. I left the following question in the Eth R&D discord

Hello, I have a question regarding the getNextWithdrawals spec

https://github.com/ethereum/beacon-APIs/commit/8fc2729b555ac03250731923a63d424d49cb8445

for the application/json response schema, we want to return a json object with the following properties

{
  execution_optimistic: bool,
  finalized: bool,
  data: array of Withdrawals
}

that all makes sense to me. however for application/octet-stream response type, the response schema is definied as

SSZ serialized Withdrawals list. Use Accept header to choose this response type

Does that mean, only the withdrawals list is ssz serialized? execution_optimistic and finalized wouldnt be part of the serialized response?

Based on my discussions in Eth R&D it seems that it is the case that, when ssz serialization is specified, execution_optimistic and finalized are not part of the serialized response.

This allowed me to progress with implementing SSZ serialization for this endpoint. The plan is to now submit my PR for an additional review tomorrow.

Friday June 23rd, 2023

I cleaned up some of the code I was working on yesterday related to the expected withdrawals http endpoint. I also removed some unecessary configurations I made in my integration tests, i.e.:

check if expected_withdrawals_invalid_state test requires builder_threshold. might be good enough to just use ApiTesterConfig::default()?

I pushed up my changes, and pinged the lighthouse devs to inform them that my PR is ready. for another review.

Monday June 26th, 2023

Did a bunch of work on starting up the redb implementation is the slasher backend. I actually teamed up with a potential fellow to begin work on this! Here is our PR

https://github.com/sigp/lighthouse/pull/4430

Tuesday June 27th, 2023

I've added some notes here regarding the redb implementation

https://hackmd.io/6W9QPfw_TzyZT8nH6ub2dQ

I have some additional feedback regarding my PR for updating the Node health endpoint in Lighthouse to match the spec

PR: https://github.com/sigp/lighthouse/pull/4310

Issue: https://github.com/sigp/lighthouse/issues/4292

Spec: https://ethereum.github.io/beacon-APIs/#/Node/getHealth

I have some TODOs to work on:

  • linting fixes
  • ensure we dont lose previous Sync::Stalled behaviour

I ended up getting these fixes pushed up today for another review

Wedsday June 28th, 2023

Continued brainstorming and making progress on the redb implementation for the slasher backend

I have some additional feedback regarding my PR for implementing the expected_withdrawals HTTP API in Lighthouse.

https://github.com/sigp/lighthouse/pull/4390

I have some TODOs to work on:

  • Add query after path param for better readability
  • Fix proposal slot calculation, should be something like let proposal_slot = query.proposal_slot.unwrap_or(state.slot() + 1);
  • Validate that the proposal_slot is greater than state.slot
  • Try to answer the question: I wonder how far ahead of the prestate we should allow proposal_slot?
  • use the max_seed_look_ahead to calculate a look ahead limit
  • We can safely ? the state_id.state as the "state not found" is handled in the function itself
  • chain.get_expected_withdrawals does not indicate that the state isn't a capella state. It seems like errors from this function indicates an expected condition and should probably return 500.
  • verify the withdrawals in the test case response
  • validate that proposal_slot is a slot after the capella fork
  • advance through the epochs and correctly call get_expected_withdrawals

One of the guys at lighthouse left the following comment on my PR

I wonder how far ahead of the prestate we should allow proposal_slot to be - if user provides a far future slot, we should probably return an error rather than computing it - although I haven't seen any specific number in the spec.

Looking at the prysm implementation of this endpoint they calculated a look ahead limit using MaxSeedLookahead

lookAheadLimit := uint64(params.BeaconConfig().SlotsPerEpoch.Mul(uint64(params.BeaconConfig().MaxSeedLookahead)))

and then returned an error if proposal slot >= state.slot + lookAheadlimit

I'm going to add this as a TODO

Thursday June 29, 2023

Two PRs were approved today for v4.3.0 of Lighthouse

PR: Update Node Health Endpoint

PR: Added debouncing and metric counting to logs

These are some of my biggest contributions to Lighthouse so far and I'm really excited that they will be part of v4.3.0.

I also completed the above TODOS for the expected withdrawls endpoint and pushed up my changes for another review. Hopefully this endpoint will also make it to v4.3.0

Friday June 30, 2023

I recieved some more feedback regarding my PR for implementing the expected_withdrawals HTTP API in Lighthouse.

https://github.com/sigp/lighthouse/pull/4390

  • refactor & move api logic to separate file
  • remove the unwrap calls
  • use dedicated const for look ahead limit. set to two
  • more accurate error messages
  • proposal slot must be greater than state slot

I'm a bit disappointed in myself, I should have caught some of these fixes. I really want to reduce the amount of back and forth needed for future pull requests so that I don't waste the core Lighthouse teams time.

Monday July 3, 2023

I implemented changes based on the feedback that was given to me on Friday. I am now waiting for another review

Tuesday July 4, 2023

I spent a good chunk of the day writing up a test redb db implementation using some of the interfaces that exist in lighthouse. I have issues with some of the types being used in the interfaces vs the types that the redb implementation expects. For example, REDB keys must impleement the std::Borrow interface, but the existing interface doesnt implement that. Changing the existing interface will make things backwords incompatible, which is a bit of an issue

Wednesday July 5, 2023

I investigated what it would take to work on the following issue: https://github.com/sigp/lighthouse/issues/4457

This enables SSZ requests in the post beacon block endpoints. I added some comments regarding how I think it would work, and I may pick this issue up soon.

Thursday July 6, 2023

I started working on the following issue https://github.com/sigp/lighthouse/issues/4457

This will add SSZ support in the request body for beacon/blocks v1 and v2 endpoints. I broke up this feature into a few parts

  • Create specific ssz beacon/blocks v1 and v2 route handlers
  • add logic to existing http routing so that when application/octet-stream is provided in the Content-Type header, send to the new ssz route handler
  • Write integration tests for the new ssz beacon/blocks v1 and v2 route handlers
  • Ensure that existing beacon/blocks v1 and v2 routes are unaffected by the new ssz route handlers

Friday July 7, 2023

I put together the new ssz route handlers, added the relevant logic to the existing http routing and began putting together some integration tests.

I'm having issues with de-decoding ssz SignedBeaconBlock encoded data in my integration tests. I'm getting an exception when Decoding the data. In the SignedBeaconBlock struct I added the Decode macro, which should allow me to decode appropriately formatted SignedBeaconBlock data. I also had to change the the ssz enum behavior from transparent to union on this struct because of the Decode macro I added. I have a feeling this is whats causing the issue

Just to add some more info here: changing the ssz enum behavior from transaparent to union causes other related integration tests to fail. I think I need to step back and rethink how im decoding ssz encoded SignedBeaconBlock data.

Monday July 10, 2023

I spent Sunday and today continuing my work on adding SSZ support in the request body for beacon/blocks v1 and v2 endpoints. I was able to resolve the issues I was having decoding SignedBeaconBlock data

Initially I had added the Decode macro to the SignedBeaconBlock struct and attempted to decode the ssz data like so


let block = Decode::from_ssz_bytes(&block_bytes)?;

However this was throwing an exception. After some investigation, I realized there were existing functions to decode an SSZ encoded SignedBeaconBlock


let block = SignedBeaconBlock::<T::EthSpec>::from_ssz_bytes(
                &block_bytes, 
                &chain.spec
            )?

The fork name (provided in chain.spec) has an affect on how SignedBeaconBlock data should be ssz encoded/decoded.

Last changed by 
 
Eitan Seri-Levi
Software Engineer at Sigma Prime
0
384

Read more

LIL-Boost

Local inclusion boost

Jul 29, 2024
Persisting Data Columns

Currently the das branch does not act on columns received over gossip. Furthermore it persists them inconsistently for the following reasons:

Mar 20, 2024
PeerDAS Sync

During sync, a node should opportunistacly download columns they are assigned to custody. We&#39;ll want to expose an RPC method to fetch columns in batch.

Mar 17, 2024
Redb Beacon Node Backend

During the EPF, I put together some code that abstracted away some of the levelDB specific database functionality within the beacon node backend. I set it up very similarly to the slasher DB where theres a database interface that implements the relevant functions/traits

Feb 29, 2024
Read more from Eitan Seri-Levi
Published on HackMD