Add EIP: BLS signed transactions

EIPS/eip-7591.md

@@ -0,0 +1,114 @@
+---
+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: Draft
+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
+
+### 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(BLOB_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 = 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
+
+Copyright and related rights waived via [CC0](../LICENSE.md).
+
+