Adding cross-transaction BLS signature aggregation to ethereum

SergioDemianLerner · August 17, 2020, 4:52pm

Pairings are costly in terms of CPU, and each signature aggregation requires one pairing operation. Last time I checked, this cost was approximately 10 times more (in terms of CPU cycles) than validating a ECDSA signature. Therefore your proposal trades space for higher CPU cost.
In 2018 I proposed a hybrid solution to send transactions with both ECDSA and BLS signatures, verifying only ECDSA signatures for some time, and then switching to BLS when the block is sufficiently mature. Therefore only nodes that are synchronizing from zero need to use more CPU cycles, but they benefit from reduced bandwidth and space.

This is ok since most of the times nodes that synchronize from zero can use weak subjectivity to get signed snapshots.

The idea is here:

github.com

rsksmart/RSKIPs/blob/6e233db72a163ebdd5be828fadabd02bf65ef45e/IPs/RSKIP63.md

# Double Signing for Delayed Signature Aggregation

|RSKIP          |63           |
| :------------ |:-------------|
|**Title**      | Double Signing for Delayed Signature Aggregation|
|**Created**    |07-MAY-2018 |
|**Author**     |SDL |
|**Purpose**    |Sca |
|**Layer**      |Core |
|**Complexity** |2 |
|**Status**     |Draft |

# **Abstract**

Blockchain historic size is one of the restrictions for scaling. A RSK transaction uses 70 bytes for ECDSA signature data and approximately 30 for the transaction payload itself. Therefore by removing the signatures from transactions the blockchain can scale 2.3 times. One technique to reduce the size of signatures is signature aggregation.  This RSKIP proposes aggregating signatures in a novel construction to reduce blockchain space consumption.

## Introduction

There are several types of signature aggregation: sequential (ordered), underdered, interactive and non-interactive. In this RSKIP we’re interested in non-interactive aggregation. The type of aggregation that can be accomplished by a miner on third party transactions. Therefore we are interested in signature aggregation of signatures of different messages and different public keys. Some signature schemes, such as BLS, allow it. However the state-of-the-art signature schemes that provide this kind of signature aggregation are slow. Aggregating a BLS signature may cost 10 times more (in terms of CPU cycles) than validating a ECDSA signature. Signature verification can be cached, so signature verification is generally not part of the critical path when broadcasting a block. The same happens with signature aggregation: the heavy non-constant operations can be cached. However, in the worse case a block can contain all new transactions, and each node would need to perform the slow operations. The slow operations would grow linearly with the number of transactions, and will affect the critical path of block verification. This RSKIP brings a new solution to this problem, based on double-signing transactions

This file has been truncated. show original