TL;DR: Aggregating attestations can improve Tezos’ L1 performance and security. Achieving this requires adoption of a new signature scheme for consensus operations.
We’re excited to share a sneak peek into an initiative for making Tezos’ L1 lighter, more secure, and ready for further optimizations.
In the upcoming S protocol proposal we plan to include changes to how the Tenderbake consensus algorithm handles consensus committees and attestations.
The purpose is to
- Reduce the network’s bandwidth and storage demand
- Strengthen Tezos L1’s security
- Simplify rewards calculation
- Pave the way for future optimizations, including faster block times
For this to happen, bakers must adopt a new signature scheme for consensus operations. In this post we explain the changes, what they mean for bakers, and how we intend to make it a smooth transition for all.
Aggregating attestations
The S proposal will introduce aggregated attestations, enabled by the BLS cryptographic scheme (the one behind tz4 addresses).
Aggregated attestations enable significant efficiency gains by allowing individual attestations in a block to be summarized into a single operation, instead of having one operation per attesting baker.
A clear gain is that it cuts bandwidth and storage needs dramatically – up to 63x less, from 900 MB/day to 14 MB/day.
If enough bakers adopt the BLS signature scheme by migrating to tz4 addresses, it also allows for each block to be attested by all bakers. Right now, only a subset of bakers (180–200 out of ~300) attest to each block due to bandwidth and disk footprint considerations. A single, aggregated attestation operation removes the need for this limitation.
Having all bakers attest each block has several benefits:
- More attestations per block make L1 more secure.
- Rewards calculation is simplified, as attestations exactly match staking power.
- The need to calculate attesting rights at each block is removed, boosting network performance.
A step-wise transition
To support this evolution, bakers are encouraged to adopt tz4 for their consensus operations.
Protocol S initiates a smooth transition phase to accommodate this change. During this period, blocks will carry both individual attestations (from bakers using tz1, tz2, or tz3 addresses) and a single aggregated attestation (from those using tz4).
As tz4 adoption grows, we will eventually be able to move to a more streamlined model with just one aggregated attestation per block – unlocking greater scalability and performance across the network.
What it means for bakers
There are a few things bakers should be aware of for this transition.
Consensus keys: Bakers using separate consensus keys can keep their existing manager key, and simply generate a tz4 key for consensus.
DAL companion key: When using a tz4 consensus key for signing blocks and (pre)attestations, you’ll also need a second tz4 key to participate in the DAL. Due to differences in how consensus data and DAL data are handled, the same key can’t be used to aggregate both consensus attestations and DAL attestations in a block. The DAL companion key is generated similarly to a consensus key and integrated seamlessly into the baking process.
Hardware signers: Signing and verifying with tz4 addresses (using the BLS12-381 curve) is more computationally intensive, and is currently not supported by Ledger hardware devices. Signing times for tz4 addresses on these devices are 5–10x longer compared to other addresses, which is prohibitively slow. We’re working on solutions like leveraging OCaml 5 parallel processing and exploring faster signing hardware.
More info coming
In upcoming posts, we will share more details into how aggregated attestations work, and how we intend to address challenges like the increased computational load of BLS12-381.
In the meantime, we are happy to hear from community members who may have questions or concerns about the changes.
Let’s aggregate!
