The primary focus of the Lighthouse team has been implementing v0.12.1 of the Eth2 specification. This is almost the final release prior to mainnet and shouldn't contain any more significant changes to the state transition logic. We expect some more changes on the networking front, though.
Since this release is very close to what we'll run in production we're taking a bit longer for this update. We're tracking our progress on issue #1182 and we have an "Update spec to v0.12" pull request that's passing all our tests (but we still have a few more changes to add).
In addition, I (Paul) have re-written our fork choice implementation so that it matches v0.12.1 and is fully separated into its own crates without any "impure" database logic. This separation makes it much easier to audit the code against the specification, ultimately making it less likely for bugs to hide in the code-base. During this process I have raised two interesting issues with the specification:
- #1180: Remove a redundant database lookup that occurs in the best-case scenario (i.e., hopefully all the time).
- #1184: Address a significant oversight regarding corruption of the fork choice store (and remove a redundant function call).
We noticed high CPU usage when Lighthouse was connected to large DHTs like
Witti and Topaz. We tracked this down to our discovery protocol (
Age decided to revamp the entire architecture,
optimizing it, making it more concurrent and more asynchronous. Included in
this re-write is the ability for Lighthouse to connect to peers using only
Multiaddrs, no longer requiring an ENR for enabling discovery connections.
Initial testing has shown to solve the previously seen CPU usage issues and Age is in the process of integrating the new discovery into Lighthouse for the next round of testnets.
Memory usage made available to eth2stats.io
Not all Lighthouse implementations have it enabled, but as you can see our memory consumption is best-in-class among the Witti clients and an order of magnitude less in some cases. Reduced memory consumption means lower overheads and higher profits for stakers.
We're quite proud of our optimization efforts over the past months and are looking forward to more soon (we still haven't managed to get memory consumption as low or as consistent as we think is possible). As always, we will share our findings with other clients to benefit the ecosystem as a whole.
Raspberry Pi compatibility
We're keen to support as many platforms as possible and we're very glad to support ARM now.
Trail of Bits have completed the first round of our security review, however they're waiting on our comments to the issues before the report is ready for release. We're glad to say that no critical issues were found.
We're looking forward to a subsequent review from Trail of Bits (targeting our networking stack and the changes introduced since the first round) and are in the process of interviewing and selecting another security firm for a second independent assessment that should take place closer to mainnet (to be confirmed).