Try   HackMD

Week 6

Summary

I did works on Optimitic Sync test improvement. The optimistic sync is a feature some consensus client have (it's not mandatory) that allow a node to "optimistically" accept an execution payload without having the execution client to check it. It's useful during the sync phase because it's faster the consensus layer sync with the network. Notice that what was optimistically accepted will we checked later and that a validator with an optimistic head can't validate until it fully check the execution payloads. It's not mandaotry for client to have this feature and node with and without optimistic sync can interact without issues. This PR from @mkalinin (+@potuz) wants to add some tests to check clients that implemented the optimistic sync react as expected for sophisticate scenarios. I did implement the @mkalinin scenario with 2 tests (normal weights and equal weights); the @potuz test still need to be implemented.

Just to let you know, the past 2 weeks were very dense in term of work at my job so I didn't pass much time on the project.

Ressources

  • PR to add optimistic sync tests: the pR that ask more optimistic tests.
  • Consensus-specs optimistic sync doc: the consensus-specs optimistic specification; it explains how it works and how it should reacts. This is used by consensus client to be sure they are all in-line.
  • Fork choice eth2book: the optimistic sync is very linked to the fork choice so I did havce a reminder of how the head is selected.
  • Prysm optimistic sync doc: the consensus-specs documentation about the optimistic sync was not super clear, so I did have a look at Prysm and Nimbus documentation to ahve another point of view. The Prysm doc is very organic and helps me a lot to read the consensus-specs doc.
  • Nimbus optimistic doc

Activity

TODO

Last changed by 
 
Wenceslas Sanchez
0
32
Published on HackMD