Update This last week I worked on: adding the fork-choice handlers that were left:on_attestation #394 on_attester_slashing #404 finishing process_rewards_and_penalties #373 implementing glue code for state transitions and block processing #392 #407

Update This last week I worked on: adding the on_tick and on_block handlers for fork-choice #381 #385 adding current sync progress to grafana #384 updating the grafana version we were using #362 fixing some parsing issues on configuration files #369 implementing the process_historical_summaries_update function for epoch processing #370 starting work on process_rewards_and_penalties #373 simplifying the test handlers we had for epoch processing spec-tests #372

Update This last week I worked on: adding gossip message validation #331 adding telemetry to the node #348, with prometheus and grafana for observability #354 #355 improving the performance of our in-memory fork-choice temporary storage #357 adding dependencies required to run etop (a module with a functionality similar to Linux's top command) #346 fixing a flaky networking test #347 improving the makefile experience #345 #351 #352

Update These last two weeks I worked on: migrating the libp2p library interface from NIFs to Ports #269 #291 #310 #320 #324 fixed errors when compiling Go code #318 #326 refactor SSZ primitives to make them fetch configuration from environment #285 cleaning up the spec-tests code #284 #296 #322 adding information about the CI to the readme #293 receiving attestation aggregates #286 changing the version used for the configuration files #328

Update These last two weeks I worked on: integrating the spec test vectors to our repo, and running them in the CI (skipping unimplemented handlers) #32 adding a runner for ssz_static tests #40 using Rust macros to reduce boilerplate in our SSZ NIF (Elixir/Erlang's version of FFI) #39 extending the NIF to enable encoding/decoding more SSZ containers #44 #45 #47 documenting the process to follow when adding a new container #49 opening issues for external contributors #75 (some of those were already completed! :rocket:) adding bindings for gossipsub from go-libp2p-pubsub #79

Update These last two weeks I worked on: integrating checkpoint sync's state retrieval with block requesting, to request blocks in ascending order #244 documenting its usage #247 adding spec constants to the repo (loading them from YAMLs) #268 starting a refactor of the libp2p library, migrating from NIFs to Ports #269 some general maintenance #245 #251 and bug fixing #250 answering questions and reviewing PRs (we had considerable activity from external contributors 🥳)

Update This last week I worked on: storing BeaconStates in our database #211 requesting missing blocks from peers #225 #228 adding the SSZ containers associated to a BlocksByRange request and response #215 adding list de/serialization and hashing to the SSZ NIF, specifically for transactions and withdrawals #222 #223 porting spec functions used to calculate the ForkDigestValue #210 improving the spec test documentation #226 #227

Update This last week I worked on: adding the WithMessageIdFn option to the go-libp2p-pubsub module #200 among other options #194 integrating the networking and storage parts with the Beacon API component #218 fixing a recurring (but harmless) error when compiling the go-libp2p bindings #186 porting some more container specifications to the SSZ NIF #196 #188 fixing some issues with tests #195 #214 #216 adding tree root hashing to the SSZ NIF #202 other general issues #193 #201 #219

Update This last week I worked on: a refactor of the SSZ library, to reduce code duplication #170 incoming request handling for Status, Goodbye, GetMetadata, and Ping requests #162 making some libp2p calls non-blocking #180 #181 updating the README #177 Req/Resp As of now, we are handling incoming Req/Resp requests. This should change how other nodes view us, from an opaque, unresponsive peer, to a seemingly functional one (even though some responses are hardcoded). All of the requests from peers are logged, which enables us to see --- among other things --- the reason for peer disconnects. 80% of the messages have reason 129 (TooManyPeers in Lighthouse), but some of them are 3 (fault/error in the spec), or 0 (unknown in Lighthouse).

Update This last week I worked on: implementing a first iteration of the networking component #107 #123 a refactor of the underlying SSZ library used #97. Previously we decided to use the lighthouse client's containers, but as they have non-trivial logic attached, we ended up implementing them ourselves, for simplicity. improving error handling in the SSZ NIF #108. This handles Elixir-type to Rust-type conversion errors. improving the error messages in the SSZ NIF #124 adding some more SSZ containers to the NIF #99 Networking

Update This last week I worked on: adding bindings for the go-ethereum/p2p library, and examples using it from Elixir #20 adding bindings to Rust's snap crate, for Snappy frame decompression #22 (for simplicity, the implementation requires reading the whole stream, but that will change in the future) using both bindings to implement some examples that send GetMetadata and Ping requests, and then decompress their responses writing an explanation of the Elixir <-> Golang interface #24 some miscellaneous chores #28 #29 With this, we have covered two of the three P2P domains: discovery and req/resp, leaving only gossipsub left. Since we can message peers, and the main source of uncertainty on this part was solved (interfacing between Elixir and Go), we agreed it'll be better to add the spec-tests first, and build up on that. Because of that, I started work on integrating the spec-tests to our repo. This would allow us to more easily verify our implementations, the first of which will be SSZ encoding/decoding.

Update This last week I added bindings for go-libp2p (PRs #12 and #17), along with some tests using them. The functionality added allows initiating connections and handling arriving ones (multiplexing by their protocol ID). The bindings are built by compiling the Go code with the cgo module, and then linking that with some C glue code into a dynamic library. thhe resulting binary is loaded by Erlang's runtime into an Elixir module. exposing the required functions. The tests consist on creating two Hosts, installing a handler on one and initiating a connection on the second one. After that, some messages are sent and received from both sides. With the implemented functionality, it would be possible to connect to other nodes and send messages, and to accept incoming connections and receive messages. We don't have any SSZ (de)serializing or Snappy (de)compression implemented yet, so that's something to work on, along with the functionality needed to get other nodes' addresses (discovery). Next steps

Introduction My name is Tomás Grüner, and I joined the program with the objective of understanding the Consensus Layer of the protocol, and using that newfound knowledge on building a Consensus Client in the Elixir language. Update First week I worked on broadly understanding the consensus specs, up to the Capella fork. With special focus on the networking protocol (communication channels, serialization and compression methods), the consensus mechanism, the different beacon operations, and the information stored in a beacon chain block. For this, useful resources were: Upgrading Ethereum (especially the part about consensus)