This EIP introduces a new EIP-2718 transaction type that is signed with BLS signatures.
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.
BLS_TX_TYPE = Bytes1(0x04)
The transaction type will have the following format:
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])).
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:
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:
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.
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.
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 = keccak(pk_bls) with address_1 == address_2.
We know that pk_ecdsa must be equal to pk_bls (follows from keccak).
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 negligble probability) to find two private keys, one in ECDSA and one in BLS that control the same account.
Copyright and related rights waived via CC0.