TL;DR
What is Beacon Chain?
Ethereum consists of two parts. One is the Execution Layer secured by PoW consensus, and another is Consensus Layer or Beacon Chain, which is secured by PoS consensus. The Beacon Chain has been running since December 2020. The Beacon Chain introduced the consensus logic and block gossip protocol which now secures Ethereum.
Here is a video by the EW Team which can help readers to understand the concept of the Execution Layer and Consensus Layer.
PoS Ethereum Architecture
The execution client (also known as the Execution Engine, EL client, or formerly the Eth1 client) listens to new transactions broadcasted in the network, executes them in EVM, and holds the latest state and database of all current Ethereum data. The consensus client (also known as the Beacon Node, CL client, or formerly the Eth2 client) implements the PoS consensus, which enables the network to achieve agreement based on validated data from the execution client.
Here is video on The Merge Transition by EW Team which explains this concept in a simple mannner.
Nodes Vs Clients
Ethereum is a distributed network of computers/nodes running software that can verify blocks and transaction data. The software application/client must be run on the user's computer to turn it into an Ethereum node.
A node is any instance of Ethereum client software that is connected to other computers also running Ethereum software, forming a network. On the other hand, a client is an implementation of Ethereum that verifies data against the protocol rules and keeps the network secure.
Here is an article by the EW Team on Ethereum Clients' Node Syncing Methods, where readers can get an overview of the syncing methods used by Ethereum Clients, its Syncing Strategies and Key Points on the Syncing Processes.
Beacon Node API
It is the collection of RESTful APIs provided by Ethereum Beacon nodes. This API specification is for the beacon node which enables users to query and participate in Ethereum 2.0 phase 0 beacon chain. The goal of this specification is to promote interoperability between various beacon node implementations.
The specification describes a RESTful set of endpoints that should be implemented by an Eth beacon node or a third-party service. This reduces the overhead of having to learn a new set of APIs when trying out a different client, and it allows network participants to reliably talk to each other over HTTP.
This API's purpose is a means of communication between users' beacon node and their validator clients. The communication between the beacon node and the validator client should be done privately, either on the same machine or through an SSH connection.
Beacon Nodes Vs Validator Clients
Sometimes readers are confused between Beacon Nodes and Validator Clients. So, here is a quick difference by EW Team.
Here is video by the EW Team on the concept of Validator.
Beacon Node API Vs Validator Client API
The Beacon Node API allows interactions between beacon nodes, including p2p networking connectivity as well as getting current beacon chain state and blocks from other nodes. On the other hand, the Validator Client API is designed for the interactions between a single validator client and the beacon node it is connected to for purposes of propagating block proposals and attestations to the network.
Security
Users should not expose the beacon node API to the public internet or it will open users' nodes to denial-of-service (DoS) attacks. This API includes several endpoints which can be used to trigger heavy processing. Users can also use a firewall to limit access to certain remote IPs, allowing access only from one other machine on the local network.
The node/identity and node/peers endpoints expose information about the users' node's peer-to-peer identity. The --http-allow-origin flag changes the server's CORS policy, allowing cross-site requests from browsers. Users should only supply it if they understand the risks, like malicious websites accessing their beacon node if they use the same machine for staking and web browsing.
Examples
Lighthouse implements the standard Beacon Node API specification. A Lighthouse beacon node can be configured to expose a HTTP server by supplying the --http flag. The default listen address is 127.0.0.1:5052. Prysm also supports the official Eth Beacon Node API specification. Here is an example of client implementation of Beacon Node APIs by Alex Stokes.
Related Resources
- ethereum.org
- ethereum.github.io
- ethereum/beacon-APIs
- docs.ethhub.io
- lighthouse-book.sigmaprime.io
- docs.prylabs.network
Related Videos
- The Merge Transition
- Ethereum: The Great Renaming
- Proof of Work
- Proof of Stake
- How to Join Kintsugi testnet?
- Kintsugi Fuzzer Issue
- What is Kiln Testnet?
- How to Join Kiln Testnet?
Related Articles
- An overview of expected changes with the Ethereum Merge upgrade
- MEV in DeFi
- Ethereum Mainnet Shadow Forking: An Overview
- What do Bellatrix, Paris & TTD mean in Ethereum Merge Upgrade?
- Ethereum's roadmap for 2022 and beyond!
Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.
To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Support us at Gitcoin
You've something to share with the blockchain community, join us on Discord!
