EIP-3068: Precompile for BN256 HashToCurve Algorithms

Metadata

Status: StagnantStandards Track: CoreCreated: 2020-10-23

Authors

Dr. Christopher Gorman (@chgormanMH)

Requires

EIP-198, EIP-1108

Links

GitHub page Discussion on Ethereum Magicians

Simple Summary

This EIP defines a hash-to-curve precompile for use in BN256 and would allow for cheaper BLS signature verification.

Abstract

There is currently no inexpensive way to perform BLS signature verification for arbitrary messages. This stems from the fact that there is no precompiled contract in the EVM for a hash-to-curve algorithm for the BN256 elliptic curve. The gas cost of calling a deterministic hash-to-curve algorithm written in Solidity is approximately that of one pairing check, although the latter requires an order of magnitude more computation. This EIP remedies this by implementing a hash-to-curve algorithm for the BN256 G1 curve, which would reduce the cost of signature verification to essentially that of the pairing check precompiled contract. We also include a hash-to-curve algorithm for the BN256 G2 group.

Motivation

The precompiled contracts in EIP-198 and EIP-1108 increased usage of cryptographic operations in the EVM by reducing the gas costs. In particular, the cost reduction from EIP-1108 helps increase the use of SNARKs in Ethereum via an elliptic curve pairing check; however, a hash-to-curve algorithm enabling arbitrary BLS signature verification on BN256 in the EVM was noticeably missing. There is interest in having a precompiled contract which would allow for signature verification, as noted here.

At this time, we are able to perform addition, scalar multiplication, and pairing checks in BN256. Reducing these costs in EIP-1108 made ETHDKG, a distributed key generation protocol in Ethereum, less expensive. ETHDKG by itself is useful; however, what it is lacking is the ability to verify arbitrary BLS signatures. Creating group signatures by aggregating partial signatures is one goal of a DKG protocol. The DKG enables the computation of partial signatures to be combined into a group signature offline, but there is no easy way to verify partial signatures or group signatures in the EVM.

In order to perform BLS signature validation, a hash-to-curve algorithm is required. While the MapToGroup method initially discussed in the original BLS paper works in practice, the nondeterministic nature of the algorithm leaves something to be desired as we would like to bound the overall computational cost in the EVM. A deterministic method for mapping to BN curves is given here; in the paper, Fouque and Tibouchi proved their mapping was indifferentiable from a random oracle. This gives us the desired algorithm.

Specification

Here is the pseudocode for the HashToG1 function:

Here is the pseudocode for HashToBase; msg is the byte slice to be hashed while dsp1 and dsp2 are domain separation parameters. fieldPrime is the prime of the underlying field.

Here is the pseudocode for BaseToG1. All of these operations are performed in the finite field. inverse computes the multiplicative inverse in the underlying finite field; we have the convention inverse(0) == 0. is_square(a) computes the Legendre symbol of the element, returning 1 if a is a square, -1 if a is not a square, and 0 if a is 0. sqrt computes the square root of the element in the finite field; a square root is assumed to exist. sign0 returns the sign of the finite field element.

In HashToG2, we first map to the underlying twist curve and then clear the cofactor to map to G2. Here is the pseudocode for HashToG2:

Here is the pseudocode for BaseToTwist.

Rationale

The BaseToG1 algorithm is based on the original Fouque and Tibouchi paper with modifications based on Wahby and Boneh's paper. There is freedom in choosing the HashToBase function and this could easily be changed. Within HashToBase, the particular hashing algorithm (Keccak256 in our case) could also be modified. It may be desired to change the call to sign0 at the end of BaseToG1 and BaseToTwist with is_square, as this would result in the same deterministic map to curve from the Fouque and Tibouchi paper and ensure HashToG1 is indifferentiable from a random oracle; they proved this result in their paper. It may be possible to show that switching the is_square call with sign0 does not affect indifferentiability, although this has not been proven.

The HashToG2 algorithm follows from the Wahby and Boneh paper. Algorithms for computing inverse, is_square, and sqrt in finite field GF(fieldPrime^2) can be found here.

We now discuss the potential gas cost for the HashToG1 and HashToG2 operations. On a local machine, ECMul was clocked at 68 microseconds per operation. The same machine clocked HashToG1 at 94 microseconds per operation when hashing 32 bytes into G1 and 105 microseconds per operation when hashing 1024 bytes into G1. Given that it currently costs 6000 gas for ECMul, this gives us an estimated gas cost for HashToG1 at 8500 + len(bytes). Similarly, HashToG2 was clocked at 886 microseconds per operation when hashing 32 bytes into G2 and 912 microseconds per operation when hashing 1024 bytes into G2. This allows us to estimate the gas cost at 80000 + 3*len(bytes).

Backwards Compatibility

There are no backward compatibility concerns.

Test Cases

TBD

Implementation

TBD

Security Considerations

Due to recent work, the 128-bit security promised by the BN256 elliptic curve no longer applies; this was mentioned in the Cloudflare BN256 library. There has been some discussion on the exact security decrease from this advancement; see these two papers for different estimates. The more conservative estimate puts the security of BN256 at 100-bits. While this is likely still out of reach for many adversaries, it should give us pause. This reduced security was noted in the recent MadNet whitepaper, and this security concern was partially mitigated by requiring Secp256k1 signatures of the partial group signatures in order for those partial signatures to be valid. Full disclosure: the author of this EIP works for MadHive, assisted in the development of MadNet, and helped write the MadNet whitepaper.

The security concerns of the BN256 elliptic curve affect any operation using pairing check because it is related to the elliptic curve pairing; they are independent of this EIP.