Skip to content

Version 26.7.1 #772

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
alexandratran merged 1 commit into from
Jul 13, 2026
Merged

Version 26.7.1 #772

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions versioned_docs/version-26.7.1/concepts/architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
---
title: Architecture
description: Learn about the Teku high-level architecture.
sidebar_position: 1
---

# Teku architecture

The following diagram outlines the Teku high-level architecture.

![Architecture](/img/architecture.png)

Teku contains both a beacon node and validator client implementation.
The beacon node is the primary link to the Beacon Chain.
The validator client performs [validator duties](proof-of-stake.md).

You can [run the beacon node only](../get-started/start-teku.md#start-the-beacon-node), or [run the beacon node and validator client](../get-started/start-teku.md#start-the-clients-in-a-single-process).

Read more about the [Ethereum consensus client architecture](https://ethereum.org/en/developers/docs/nodes-and-clients/). For more information about the Teku architecture, contact us on [Teku Discord channel](https://discord.gg/teku).
29 changes: 29 additions & 0 deletions versioned_docs/version-26.7.1/concepts/builder-network.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
---
title: Builder network and MEV-Boost
description: Learn about external builders and MEV-Boost.
sidebar_position: 2
---

# Builder network and MEV-Boost

[Consensus clients](./node-types.md#consensus-clients) are responsible for proposing
blocks containing an execution payload obtained from their local
[execution clients](./node-types.md#execution-clients) via the Engine API.

A consensus client can optionally configure an external builder and delegate the
execution payload construction to it, instead of using the execution client.

## MEV-Boost

The most common builder deployment is to run a specialized external software
such as [MEV-Boost](https://github.com/flashbots/mev-boost).
MEV-Boost works by requesting a payload proposal from several entities (called
relays), and selecting the best bid in order to improve validator rewards and
increase the maximal extractable value (MEV).

Teku allows you to
[configure the beacon node to use a builder network](../how-to/configure/builder-network.md)
to generate execution payloads.
In case of failures or non-timely responses, Teku falls back to the payload
produced by the local execution client specified using
[`--ee-endpoint`](../reference/cli/index.md#ee-endpoint).
45 changes: 45 additions & 0 deletions versioned_docs/version-26.7.1/concepts/node-types.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
---
title: Consensus and execution clients
description: Learn about execution and consensus clients.
sidebar_position: 5
---

An Ethereum node is an instance of an Ethereum client, which consists of:

- A consensus client (for example, Teku)
- An execution client (for example, Besu)

:::info

Before The Merge, execution clients were known as
[Eth1 clients](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/), and consensus clients
were called [Eth2 clients](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/).

The Merge, completed on **September 15, 2022**, transitioned Ethereum from
proof of work to [proof of stake consensus](proof-of-stake.md).

:::

Execution and consensus clients communicate with each other using the [Engine API](https://besu.hyperledger.org/public-networks/how-to/use-engine-api).

![Ethereum node](/img/execution-consensus-clients.png)

### Execution clients

Execution clients, such as [Besu](https://besu.hyperledger.org/), manage the execution layer, including
executing transactions and updating the world state. Execution clients serve
[JSON-RPC API](https://besu.hyperledger.org/public-networks/reference/api) requests and
communicate with each other in a peer-to-peer network.

### Consensus clients

Consensus clients, such as Teku, contain beacon node and validator client implementations. The beacon node
is the primary link to the [Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/) (consensus layer).
The validator client performs [validator duties](proof-of-stake.md) on the consensus layer. Consensus
clients serve [REST API](../reference/rest.md) requests and communicate with each other in a peer-to-peer network.

:::info

To become a validator, you must also run a validator client (either [in the same process as the beacon node](../get-started/start-teku.md#start-the-clients-in-a-single-process) or [separately](../get-started/start-teku.md#run-the-clients-separately)).

Check warning on line 43 in versioned_docs/version-26.7.1/concepts/node-types.md

View workflow job for this annotation

GitHub Actions / Spelling 

[vale] reported by reviewdog 🐶
[Microsoft.Adverbs] Remove 'separately' if it's not important to the meaning of the statement.

Raw Output:
{"message": "[Microsoft.Adverbs] Remove 'separately' if it's not important to the meaning of the statement.", "location": {"path": "versioned_docs/version-26.7.1/concepts/node-types.md", "range": {"start": {"line": 43, "column": 182}}}, "severity": "WARNING"}

:::
95 changes: 95 additions & 0 deletions versioned_docs/version-26.7.1/concepts/p2p-networking.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
---
title: Peer-to-peer networking
description: Learn how Teku connects to the consensus-layer P2P network using the TCP and QUIC transports, peer discovery, ports, IPv6, advertised addresses, and multiaddresses.
sidebar_position: 7
---

# Peer-to-peer networking

Teku connects to the consensus-layer peer-to-peer (P2P) network using two transports to exchange data
and a discovery protocol to find peers.
This page explains how the transports, discovery, ports, and address configuration fit together.

:::note
If you encounter peering issues, see the [network troubleshooting guide](../how-to/troubleshoot/network.md#resolve-peering-issues).
:::

## Transports

Teku supports two P2P transports, both enabled by default:

- **TCP** - The original libp2p transport.
- **QUIC** - A transport that runs over UDP.

When QUIC is enabled, Teku advertises both its TCP and QUIC addresses to the network, and remote
peers can connect over either transport.
When Teku dials a peer, it uses QUIC if both the local node and the peer support it, and otherwise
falls back to TCP.

## Peer discovery and ENR

Teku uses [discovery v5](https://github.com/ethereum/devp2p/tree/master/discv5) over UDP to find
peers on the network.
Discovery starts from a set of [bootnodes](../how-to/find-and-connect/run-a-bootnode.md) and lets nodes
locate each other dynamically.

Teku identifies itself on the discovery network using an
[Ethereum Node Record (ENR)](https://eips.ethereum.org/EIPS/eip-778), which advertises the node's IP
address and ports.
The UDP discovery address is used only to find peers; it is not a connectable transport address.

:::note
Instead of relying on automatic discovery, you can also
[connect Teku to specific peers](../how-to/find-and-connect/connect-to-specific-peers.md), such as nodes
you operate, using static or direct peers.
:::

## Node identity and private key

The P2P private key identifies the beacon node on the network and secures the communication channel
between nodes.
Teku generates a key automatically on first startup, or you can supply your own using the
[`--p2p-private-key-file`](../reference/cli/index.md#p2p-private-key-file) option.

Using a persistent private key file gives the node a stable ENR, which is useful for
[bootnodes](../how-to/find-and-connect/run-a-bootnode.md) and other nodes that you want peers to
reconnect to reliably.

## P2P port options

Teku exposes a listening port and an advertised port for each transport and for peer discovery:

| Purpose | Protocol | Listening option | Advertised option |
| --- | --- | --- | --- |
| TCP transport | TCP | [`--p2p-port`](../reference/cli/index.md#p2p-port) | [`--p2p-advertised-port`](../reference/cli/index.md#p2p-advertised-port) |
| Peer discovery | UDP | [`--p2p-udp-port`](../reference/cli/index.md#p2p-udp-port) | [`--p2p-advertised-udp-port`](../reference/cli/index.md#p2p-advertised-udp-port) |
| QUIC transport | UDP | [`--p2p-quic-port`](../reference/cli/index.md#p2p-quic-port) | [`--p2p-advertised-quic-port`](../reference/cli/index.md#p2p-advertised-quic-port) |

Each option has an `-ipv6` counterpart (for example,
[`--p2p-quic-port-ipv6`](../reference/cli/index.md#p2p-quic-port-ipv6) and
[`--p2p-advertised-quic-port-ipv6`](../reference/cli/index.md#p2p-advertised-quic-port-ipv6)) that
adds a second address family for dual-stack operation.
The listening mode (IPv4, IPv6, or dual-stack) depends on how you combine these options with the
[`--p2p-interface`](../reference/cli/index.md#p2p-interface-p2p-interfaces) option.
By default, Teku listens over IPv4.
For IPv6 or dual-stack, see [Configure IPv6](../how-to/find-and-connect/configure-ipv6.md).

The address Teku advertises to peers can differ from the address it listens on, which matters when
the node is behind a NAT or router.
Teku autodetects the advertised address by default; you can configure it with
[`--p2p-advertised-ip`](../reference/cli/index.md#p2p-advertised-ip-p2p-advertised-ips).
You can also [specify NAT methods](../how-to/find-and-connect/specify-nat.md).

## Multiaddresses

Teku identifies peers using [multiaddresses](https://libp2p.io/concepts/fundamentals/addressing/).
A multiaddress includes the transport and port, so the TCP and QUIC addresses for the same node
differ:

- TCP - `/ip4/<ip>/tcp/9000/p2p/<peer_id>`
- QUIC - `/ip4/<ip>/udp/9001/quic-v1/p2p/<peer_id>`

The `p2p_addresses` field returned by the
[`/eth/v1/node/identity`](https://consensys.github.io/teku/#tag/Node/operation/getNetworkIdentity)
API endpoint lists the TCP and QUIC transport addresses.
The `discovery_addresses` field lists the UDP discovery address.
81 changes: 81 additions & 0 deletions versioned_docs/version-26.7.1/concepts/peer-das.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
---
description: Learn about the PeerDAS upgrade and its implications for node operators.
sidebar_position: 4
---

# PeerDAS

Peer Data Availability Sampling (PeerDAS), specified by [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594), is the main
feature of the next Ethereum upgrade, Fusaka.

PeerDAS introduces enhanced capacity extension over [proto-danksharding](proto-danksharding.md).
The goal of this enhancement is to significantly increase the average number of blobs in every slot while keeping moderate
network and storage requirements for most node operators.

This is achieved using multiple techniques:

- **1D blob extension** - PeerDAS applies one-dimensional erasure coding extension to each blob, so its size doubles.
The extended blob can be split into 128 parts such that you can reconstruct the original blob from any 64 parts.

- **Column splitting** - In danksharding, the base data unit is the blob.
Each node is required to download all blobs referenced in the block to verify its availability.
In PeerDAS, extended blobs are rows which stack one below another and are split into columns, creating DataColumnSidecars.
This is the base data unit in PeerDAS and consists of 1/128th of each extended blob from the block, with additional
data like proofs and block header.

- **Data availability sampling** - The last major change is easing node operator requirements for data availability checks.
By splitting blobs data into columns, so that every single node operator is required to get pieces of each blob, it's
impossible to lose any whole blob; either all blobs are available or none are.
Security research has proven that it's enough to download 1/8 of the data (1/16 of the extended data) to prove data
availability or confirm its non-availability.

Decreasing the size of required download, store, and share data by 8 for most nodes compared to danksharding
makes it possible to schedule a target number of blobs increase of almost 5x compared to the danksharding launch,
with potential room to increase it by another 4x in the future.
This change significantly increases the blob capacity of the Ethereum network and TPS of Layer 2.
Moreover, [EIP-7892: Blob Parameters Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) allows for changing maximum
number of blobs and blob target without a hard fork,
making future blob capacity changes easier.

## Expected implications for node operators

Proto-danksharding was launched with increased network requirements over the previous fork and additional storage required
for the data layer of about 50 GB for 3 blobs,
which was later increased to about 100 GB for 6 blobs in the Pectra fork.

With PeerDAS, consensus layer clients will use network and storage space for sidecar data according to their roles:

- **Full nodes** - These are nodes without any validators.
Their requirements are to store 4 data columns in custody (which is permanent storage for a moving window of about 18
recent days) and sample another 4. This means the data is downloaded, data availability is checked, but nothing is stored.
4 columns with a scheduled 14-blob target (which could be increased in the future) will occupy about 16 GB of space, which
means significantly less storage consumption by non-validator nodes.

- **Validator nodes** - Requirements for validator nodes are to custody at least 8 columns, with the number calculated based
on the effective balance of active validators, adding a requirement of 1 extra column per every 32 ETH.
Therefore, 1 validator requires 8 columns, 8 validators require 8 columns, 20 validators require 20 columns, with a maximum of
128 columns for 128 validators or 4096 ETH in consolidated validators. For 1-8 validators and 14 blobs, a node will
take 32 GB of space, which is still less than current requirements. But nodes with a lot of validators will basically
become supernodes.

- **Supernodes** - These are either nodes running in altruistic mode or those operated by big validator operators with
4096 or more ETH staked.
This type of node stores and shares all columns data.
An operator can enable this mode using the [`--p2p-subscribe-all-custody-subnets-enabled`](../reference/cli/index.md#p2p-subscribe-all-custody-subnets-enabled) command line option;
big operators run in this mode as a protocol requirement.
Storage consumption is increased, taking about 500 GB with 14 blobs of data layer space compared to 100 GB in Pectra.

:::warning important

If a node operator needs complete blob data through the REST API (for example, the `getBlobs` endpoint),
they must either run in supernode mode or enable
[`--rest-api-getblobs-sidecars-download-enabled`](../reference/cli/index.md#rest-api-getblobs-sidecars-download-enabled),
which allows Teku to retrieve required sidecars on demand from the P2P network.
Other types of nodes store only partial blob data.

:::

All node space requirements are subject to change proportionally to the target number of blobs, which is currently scheduled
to be 14 starting from January 7, 2026 (about 1 month after the Fusaka fork).
Further target changes may be applied later and do not require a hard fork, but require node operators to upgrade their
clients in a timely manner.
39 changes: 39 additions & 0 deletions versioned_docs/version-26.7.1/concepts/proof-of-stake.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
title: Proof of stake
description: Learn about Ethereum proof of stake consensus.
sidebar_position: 3
---

# Proof of stake

In Ethereum's [proof of stake (PoS)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/), you
must run a [full node](node-types.md) and
[stake 32 ETH](https://ethereum.org/en/staking/) to become a validator.

:::note

You must run a beacon node and an execution client to operate a node on Mainnet. To become a validator, you
must also run a validator client either [in the same process as the beacon node](../get-started/start-teku.md#start-the-clients-in-a-single-process) or [separately](../get-started/start-teku.md#run-the-clients-separately).

Check warning on line 16 in versioned_docs/version-26.7.1/concepts/proof-of-stake.md

View workflow job for this annotation

GitHub Actions / Spelling 

[vale] reported by reviewdog 🐶
[Microsoft.Adverbs] Remove 'separately' if it's not important to the meaning of the statement.

Raw Output:
{"message": "[Microsoft.Adverbs] Remove 'separately' if it's not important to the meaning of the statement.", "location": {"path": "versioned_docs/version-26.7.1/concepts/proof-of-stake.md", "range": {"start": {"line": 16, "column": 154}}}, "severity": "WARNING"}

:::

The PoS mechanism randomly chooses validators to propose or validate blocks on the [Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/) in defined time frames.

Check warning on line 20 in versioned_docs/version-26.7.1/concepts/proof-of-stake.md

View workflow job for this annotation

GitHub Actions / Spelling 

[vale] reported by reviewdog 🐶
[Microsoft.Adverbs] Remove 'randomly' if it's not important to the meaning of the statement.

Raw Output:
{"message": "[Microsoft.Adverbs] Remove 'randomly' if it's not important to the meaning of the statement.", "location": {"path": "versioned_docs/version-26.7.1/concepts/proof-of-stake.md", "range": {"start": {"line": 20, "column": 19}}}, "severity": "WARNING"}

Proposers are responsible for proposing new consensus blocks, and non-proposing validators are responsible for validating (attesting to) proposed blocks.
Validators are rewarded for proposing and attesting to consensus blocks eventually included in the Beacon Chain, and penalized for malicious behavior.
Validators also receive transaction fees for included blocks.

Each consensus block contains an execution payload, which contains a list of transactions and other data required to execute and validate the payload.

When a node validates a consensus block, its [consensus client](node-types.md#consensus-clients) processes the block
and sends the execution payload to the [execution client](node-types.md#execution-clients), which:

1. Assembles a block on the execution layer.
1. Verifies pre-conditions.
1. Executes transactions.
1. Verifies post-conditions.
1. Sends the validity result back to the consensus client.

If the block is valid, the execution client includes it in the execution chain and stores the new state in execution state storage.

If a consensus block receives attestations backed by enough staked ETH, the block is included in the Beacon Chain.
46 changes: 46 additions & 0 deletions versioned_docs/version-26.7.1/concepts/proto-danksharding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
---
description: Learn about the proto-danksharding upgrade and its implications for node operators.
sidebar_position: 4
---

# Proto-danksharding

Proto-danksharding, specified by [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), is part of
the next Ethereum upgrade, the Dencun upgrade.

Proto-danksharding introduces a new "blob-carrying" transaction type, which allows data to be posted
to Ethereum Mainnet more cheaply than currently possible, thus improving scalability while
preserving decentralization.

## What are blobs?

Check warning on line 15 in versioned_docs/version-26.7.1/concepts/proto-danksharding.md

View workflow job for this annotation

GitHub Actions / Spelling 

[vale] reported by reviewdog 🐶
[Microsoft.HeadingPunctuation] Don't use end punctuation in headings.

Raw Output:
{"message": "[Microsoft.HeadingPunctuation] Don't use end punctuation in headings.", "location": {"path": "versioned_docs/version-26.7.1/concepts/proto-danksharding.md", "range": {"start": {"line": 15, "column": 17}}}, "severity": "WARNING"}

Blobs are "sidecars" of data that ride alongside blocks, and are primarily used by the sequencers of
Ethereum Layer 2 rollups to contain batched transactions executed on those rollups.

Blobs are made up of 4096 32-byte field elements.
Blobs are designed to remain available for exactly 4096 epochs, or roughly 18 days.

Check warning on line 21 in versioned_docs/version-26.7.1/concepts/proto-danksharding.md

View workflow job for this annotation

GitHub Actions / Spelling 

[vale] reported by reviewdog 🐶
[Microsoft.Adverbs] Remove 'roughly' if it's not important to the meaning of the statement.

Raw Output:
{"message": "[Microsoft.Adverbs] Remove 'roughly' if it's not important to the meaning of the statement.", "location": {"path": "versioned_docs/version-26.7.1/concepts/proto-danksharding.md", "range": {"start": {"line": 21, "column": 68}}}, "severity": "WARNING"}
After a blob expires, a majority of consensus layer clients can no longer retrieve the specific
data within the blob, but evidence of the blob's prior existence remains on the network.

The blobs' fee market structure is designed to target an average of three blobs attached to each
beacon block, with a maximum of six blobs.
Each blob holds 128 KB of temporary data.
This means that proto-danksharding might increase the data associated with a block by 384 KB on
average (128 KB per blob times three blobs) with a maximum of 768 KB (six blobs per block).

## What changes in consensus layer clients?

Check warning on line 31 in versioned_docs/version-26.7.1/concepts/proto-danksharding.md

View workflow job for this annotation

GitHub Actions / Spelling 

[vale] reported by reviewdog 🐶
[Microsoft.HeadingPunctuation] Don't use end punctuation in headings.

Raw Output:
{"message": "[Microsoft.HeadingPunctuation] Don't use end punctuation in headings.", "location": {"path": "versioned_docs/version-26.7.1/concepts/proto-danksharding.md", "range": {"start": {"line": 31, "column": 42}}}, "severity": "WARNING"}

With proto-danksharding, consensus layer clients will:

- Use more network bandwidth in the peer-to-peer layer to receive and distribute the blobs.

- Require roughly 48 GiB more storage space for blobs, with a maximum of 96 GiB.

Check warning on line 37 in versioned_docs/version-26.7.1/concepts/proto-danksharding.md

View workflow job for this annotation

GitHub Actions / Spelling 

[vale] reported by reviewdog 🐶
[Microsoft.Adverbs] Remove 'roughly' if it's not important to the meaning of the statement.

Raw Output:
{"message": "[Microsoft.Adverbs] Remove 'roughly' if it's not important to the meaning of the statement.", "location": {"path": "versioned_docs/version-26.7.1/concepts/proto-danksharding.md", "range": {"start": {"line": 37, "column": 11}}}, "severity": "WARNING"}
This estimate comes from the following calculation:

- 3 blobs per block x 128 KB each = 384 KB per block
- 32 blocks per epoch x 4096 epochs for blob expiry = 131,072 blocks with blobs
- 384KB x 131,072 blocks = 48 GiB increase in storage

See this article,
[Ethereum Evolved: Dencun Upgrade Part 5, EIP-4844](https://consensys.io/blog/ethereum-evolved-dencun-upgrade-part-5-eip-4844),
for more information about Dencun and proto-danksharding.
Loading
Loading