---
eip: 7591
title: BLS signed transactions
description: Introduces a new transaction type signed with BLS signatures
author: Marius van der Wijden (@MariusVanDerWijden)
discussions-to: https://ethereum-magicians.org/t/eip-7591-bls-signed-transactions/19911
status: Stagnant
type: Standards Track
category: Core
created: 2024-01-10
---

## Abstract

This EIP introduces a new [EIP-2718](./eip-2718.md) transaction type that is signed with BLS signatures.

## Motivation

The BLS signature scheme allows for easy aggregation and verification of aggregated signatures.
If a substantial number of transactions on mainnet were BLS signed transactions, we can aggregate signatures in a block and batch-verify them.
This will reduce growth of the chain history.


## Specification

BLS_TX_TYPE = Bytes1(0x04)

### Transaction Type

The transaction type will have the following format: 

```
[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, sender, signature]
```

with `sender` being the BLS public key of an account with address `address = [0:20](keccak256(sender))`.

The signature value `signature` is calculated by constructing a BLS signature over the following digest:

`tx_hash = keccak256(BLS_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, sender]))`.

### Header changes

The block header will be amended with the `aggregated_sig` field, containing an aggregated signature of all BLS transactions in the block.

The resulting RLP encoding of the header is therefore:

```
rlp([
    parent_hash,
    0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash
    coinbase,
    state_root,
    txs_root,
    receipts_root,
    logs_bloom,
    0, # difficulty
    number,
    gas_limit,
    gas_used,
    timestamp,
    extradata,
    prev_randao,
    0x0000000000000000, # nonce
    base_fee_per_gas,
    withdrawals_root,
    blob_gas_used,
    excess_blob_gas,
    aggregated_sig,
])
```

### Block changes

The block building algorithm needs to be changed in order to built the aggregated signature of all BLS signed transactions in the block. 
All transactions in the block will be added without the signature field set. 

Blocks with transactions containing the `signature` field MUST be rejected.

On block verification, the `verifyAggregate` algorithm is used as follows:

```
valid = verifyAggregate(sender_1, ... sender_n, tx_hash_1, ... tx_hash_n, aggregated_sig)
```

## Rationale

Removing the ECDSA signature from a transaction saves 65 bytes. The BLS public key is 48 bytes, the aggregated signature is 96 bytes.
Thus we save `-96 + (65-48)* #transactions` bytes per block. With ~7000 blocks per day, 1.000.000 transactions per day, the average block contains roughly 150 transactions.

Thus we would save 2454 bytes or 2.4KB per block. This would equate to ~1.5% saving given an average block size of 160KB. 

In addition to the (admittedly meager) size savings for full nodes, the ability to add a new transaction type to utilize a different signature scheme does have some merit to it. This proposal shows that it would be possible to add for example a quantum safe signature scheme to ethereum.

## Backwards Compatibility

This EIP introduces backward incompatible changes to the block validation rule set on the execution layer and introduces a new transaction type and a new header field. Thus a hardfork is needed.

## Security Considerations

The messages signed via BLS are distinct (no hash collisions on the txhash), thus the aggregation is secure even without a proof-of-possession.
The public keys are not distinct which is not a problem in BLS.

We assume that keccak256 and ECDSA and BLS are working as intended. 
Suppose we have two addresses `address_1 = keccak256(pk_ecdsa)` and `address_2 = keccak256(pk_bls)` with `address_1 == address_2`.
We know that `pk_ecdsa` must be equal to `pk_bls` (follows from keccak256).
This would mean that we would either be able to find `x` with `g_bls^x = y` for a given `y` (violates the security of BLS)
or find `z` with `d_ecdsa^z = y` (violates the security of ECDSA).

Thus it would be impossible (with greater than negligible probability) to find two private keys, one in ECDSA and one in BLS that control the same account.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).