What is the tech stack behind the Prysm client?

Question

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

Are there elements in Prysm's architecture that are particularly differentiated from the other beacon chain clients?

Answer 1

Raul Jordan here from the Prysm project. The Prysm client is an open source implementation of the Ethereum 2.0 blockchain written in Go, just as the familiar go-ethereum project was for Ethereum 1.0 today. It is a radical departure from the current way Ethereum works, as it implements proof of stake and sharding according to a specification created by the Ethereum Research team.

The Prysm project aims to be useful to most users of Ethereum 2.0 that are either participating in consensus as a validator of the chain, or simply running a full node in the network. At its core, Ethereum 2.0 is comprised of two main things:

1. A beacon node, which is a blockchain full node that is responsible for p2p networking, chain sync, consensus, and RPC API endpoints
2. A validator client, which is a thin-wrapper around a user's keys, responsible for communicating with a beacon node to propose blocks and vote on blocks.

The Prysm codebase is a monorepo, meaning it contains all sorts of tools in there that are useful for the entire eth2 runtime. A complete implementation of a beacon node and a validator client are available in the ./beacon-node and ./validator folders at the top level of the project, respectively.

What Differentiates Prysm?

Go is the language of cloud servers, networking, and infrastructure. We believe for Eth2 to be successful, many individuals and companies will need to have easy ways of running nodes in their production deployments, with strong tooling for monitoring and instrumentation. Prysm makes this easy by leveraging the tech stack in use by some of the largest companies in the world today for production Golang applications, using proven technologies that serve billions of users across the world in companies such as Google, Uber, and more.

We believe sticking to industry best practices and providing tooling many are familiar with in the Go and cloud infrastructure ecosystem will allow Prysm to be a successful eth2 client.

What is Prysm's Tech Stack?

Here are some of the technologies used by Prysm which are used at many companies with large, production-grade Go deployments.

• Prometheus as a database for metrics gathering across all Prysm services, easily visualized through a Grafana dashboard
• BoltDB as a persistent, key-value store which uses a B+ tree internally to allow for lightning fast db reads and random page access
• gRPC as the RPC-API layer for eth2 nodes, including pluggable support for load balancing, tracing, health checking and authentication
• Protocol buffers as the core data structures for inter-process communication, providing 6x better performance than JSON. Protobufs are a standard with gRPC and power a large chunk of companies today such as Uber, Google, Twitter, and many others. Our entire API is specified as protocol buffers in github.com/prysmaticlabs/ethereumapis
• Jaeger for distributed tracing across all Prysm components, making it extremely easy for us to understand bottlenecks and errors happening in a distributed system such as eth2
• Libp2p as the basis for peer-to-peer networking between nodes, created by Protocol Labs
• The Bazel build system for fast, reproducible builds, which are critical for a monorepo with such important code. The entire Google and Uber monorepos are built with Bazel as its features offer incredible value towards building secure code. You can read more about Uber's journey with Bazel here

The Prysmatic Labs team runs a production Kubernetes deployment for eth2 leveraging this tech stack, so we put a lot of emphasis into constantly improving it and aligning with standard engineering practices in our day to day.

Ethereum has always had a reputation for doing things differently than what folks are used to in traditional software engineering disciplines, such as picking its own JSON-API format. At Prysm, we are abandoning those norms and instead utilizing more proven technologies for our stack.

What is Prysm's Architecture Like?

At runtime, the beacon node initializes and maintains a number of services that are all vital to providing all the features of Ethereum 2.0. In no particular order, these services include:

• A blockchain service which processes incoming blocks from the network, advances the beacon chain's state, and applies a fork choice rule to select the best head block.
• An operations service prepares information contained in beacon blocks received from peers (such as block deposits and attestations) for inclusion into new validator blocks.
• A core package containing Ethereum 2.0 core functions, utilities, and state transitions required for conformity with the protocol.
• A sync service which both queries nodes across the network to ensure latest canonical head and state are synced and processes incoming block announcements from peers.
• An ETH 1.0 service that listens to latest event logs from the validator deposit contract and the ETH 1.0 blockchain.
• A public RPC server that requests information about the beacon chain's state, the latest block, validator information, etcetera.
• A P2P server which handles the life cycle of peer connections and facilitates broadcasting across the network.
• A full test suite for running simulation on Ethereum 2.0 state transitions, benchmarks and conformity tests across clients.
• We isolate each of these services into separate packages, each responsible for its own life cycle, logging and dependency management. Each Prysm service implements an interface to start, stop, and verify its status at any time.

You can read our documentation at docs.prylabs.network