Summary

The code base has been quieter over the past two weeks as Paul and Adrian were on annual leave and Mehdi and Luke have been focussing on expanding our team whilst the specification goes through some significant changes. We're all back in Australia now and keen to get back into it!

Our updates this week include:

• Alex Stokes has joined as a regular contributor.
• Alex has updated our Boolean Bitfield implementation to be cleaner and more explicit.
• We've seen significant updates to the Serenity spec which will require significant refactoring on our end.

Details

Expanding the Team

Alex Stokes has joined as a regular contributor for the next couple of months (at least). Alex has previously been involved in the EIP-1011 Casper effort, the Vyper project, and many more things. I (Paul) became familiar with Alex whilst reviewing his purity_checker Vyper LLL port. I really enjoyed working with him and am excited to have him on-board. You can follow him on Twitter if you're into deep ruminations about programming languages and governance (I know you are).

Furthermore, we've been hiring internally at Sigma Prime and are excited to post a listing for a Rust developer! Check out our positions vacant repository and get in touch if you think it would be suitable for you. We'll also be announcing some new additions to our security team over the coming weeks.

Serenity Spec Updates

Phases

The EF research team have been making many updates to the spec over the past couple of weeks. Most notably, the concept of "phases" has been introduced. There are presently two phases:

• Phase 0: specifies a minimum viable beacon chain.
• Phase 1: specifies the shard chains, which rely upon the beacon chain produced in Phase 0.

Practically everything that was in the previous spec is now contained in the Phase 0 document. The idea is that implementation teams can start with Phase 0 without needing to be concerned with Phase 1; i.e. each phase should depend on the phases before it, but never the ones after it. Of course, all phases are designed with the same common goal: a sharded, proof-of-stake Ethereum.

The phases are not only relevant to implementers, but will also define the public release stages. First, users will see a beacon chain testnet (Phase 0), then once it is stable they will see functional shard chains being added to that testnet (Phase 1).

Lighthouse is currenly focussed on building functionality for Phase 0, and will begin focussing on Phase 1 after the research has progressed.

Implementation Details

Over the past fortnight, the spec has seen many significant changes from an implementation perspective. This will require some refactoring on our end (and likely for all teams), which is an unfortunate but inescapable consequence of working on a first-of-its-kind project. Some of the most significant changes are listed below.

• ActiveState and CrystallizedState have been merged into a single object: State. I'm glad to see this as it provides simplicity for several reasons: fewer distinct objects to manage, less database/mapping lookups, simpler database schema, and it's also easier to explain to newcomers.
• Restrictions around the inclusion of SpecialObjects in BeaconBlocks to mitigate against DoS attacks.
• Additional specifications regarding how the proof-of-work (a.k.a. Ethereum 1.0) block references are managed. Specifically, the addition of known and candidate hashes that point to the block receipt roots instead of the entire block hash.
• Additional slashing conditions for block proposers and attesters.

There are plenty of things I have missed here, but we'd be here all day otherwise. If you'd like to keep up to date I suggest "watching" (subscribing to Github notifications) on the github.com/ethereum/eth2.0-specs repo. Be warned, there's a lot going on!

Future Works

The coming week will likely see Adrian and myself focussing primarily on recruitment and on-boarding instead of cutting code. After that we'll be working on libp2p and spec updates respectively. Alex, however, will be knee-deep in Rust, working on state transitions and/or fork choice rules.

Contributors

As always, we're keen for more contributors! If you want to get involved, please get in touch. Rust is an amazing language that's surprisingly easy to learn. You'd be doing yourself a disservice by not learning it!