What is the tech stack behind the Lighthouse client?

Question

What are Lighthouse's major components? What databases did it consider and decide on?

Are there elements in its architecture that are particularly differentiated from how other beacon chain clients are designed and implemented?

Answer 1

What are Lighthouse's major components?

From a very high level we have three components, each launched from the single lighthouse program:

• Beacon node: connects to the p2p network, verifies blocks and other messages, stores them in a database and allows access via an API.
• Validator client: responsible for controlling the validator keys and deciding when to produce blocks/attestations and if they're slashable or not. Relies upon the beacon node to be the source of truth about the beacon chain and to do a lot of the heavy lifting for block production.
• Account manager: responsible for key generation and wallet management. This is where you generate validator keys and do automated eth1 deposit submissions.

For the low level stuff, I'd direct you to @protolambda's neat diagram based upon the Lighthouse stack:

https://twitter.com/protolambda/status/1256186181840252929?s=20

What databases did it consider and decide on?

For the main client database we went with leveldb, for now. It's well-known and fairly performant. However we will likely swap to LMDB at some point in the near future; we're already prototyping with it.

We've been focusing on optimizing our database schema and access methods as opposed to locking in a database up-front. We've been doing a lot of the leading work in database optimizations (we've seen our designs in other clients) and we'd like to nail down the requirements before locking in the technology.

For the validator slashing protection database we're using SQLite. It's simple, battle-tested and works well for that particular schema. It has really impressive consistency guarantees, too.

Are there elements in its architecture that are particularly differentiated from how other beacon chain clients are designed and implemented?

Since early on we've done a lot of work in optimizing the state transition functions. Once again, we've seen our designs used in multiple clients and we're always happy to share our insights. Being performant is quite important to us since we want to reduce validator cost overheads and stay running during attacks on the network.

Additionally, we've been working towards a "panic free" state transition implementation. That means all arithmetic and array access are checked, and undefined behaviour is avoided. We're continously throwing random data at our state transition implementation (known as "fuzzing") to try and detect if there's anything we've missed. Thankfully Rust is a great language for this sort of task, it has a focus on safety.

Ultimately we want to be safe and fast. That's not to say other clients won't be as well :)