Which BLS curve/DKG algorithm is going to be used for Casper?

Casper
#1

From [https://www.youtube.com/watch?v=8-AZys80RrU](http://this video) it looks like Casper is undergoing major changes and the new version will be based on BLS signatures.

Is it known at the moment, which elliptic curve is going to be used for Casper? Also, which Distributed Key Generation is going to be used for Casper? Is it going to be joint-Feldman?

How is one going to handle adding/removing validators to/from an existing validator set? When a validator joins, one will need generate a key share for this validator …

#2

which elliptic curve is going to be used for Casper?

The sharding/Casper proof of concept code uses BN128, and the not-set-in-stone plan is to move to BLS12-381.

which Distributed Key Generation is going to be used for Casper?

We only do plain BLS aggregation (see here); there is no DKG. Aggregate public keys are recomputed for every aggregate signature with cheap curve multiplications.

#3

Justin - thank you, this is very helpful.

Do you plan to implement signature verification in Solidity or it is going to be not smart-contract-based?

#4

Signature verification will be outside of the EVM, implemented in native code. There will be a smart contract on the main chain to make 32 ETH deposits and initialise BLS identities with proofs of possession.

#5

Vow … This does look like a total rework of Casper …

#6

Its easy to get confused on this point, because the other post about offchain collation headers says:

The confusion is because the old post has the best description of the beacon chain. The new post only focuses on the BLS signatures, and mentions the beacon chain only in passing. Perhaps it would help to have a full overview of the beacon chain and the signature scheme, in a single document.

1 Like
#7

Although that post points in an overall direction which we have taken today, be careful with what ethresear.ch posts say. :slight_smile: The ideas are generally quite fresh, definitely not authoritative, and most of them don’t make it to the final design.

In that post I used Dfinity’s random beacon for illustrative purposes but RANDAO is the current plan. Also note the definition of “beacon chain” has changed. In that post I had a stricter definition where the beacon chain’s only role is to produce a random beacon.

Today we use the term “beacon chain” more loosely. It’s now both a random beacon and a “manager chain” for things like crosslinks, slashing conditions, accounting, Casper FFG. In other words, in Ethereum 2.0 the beacon chain is the new main chain.

See this document.

#8

Recently our team has started implementing the beacon chain in js. One of our blockers is implementing py_ecc in pure js. Just wondering if anyone has worked on something similar? Our repo is here.

#9

Have you considered compiling into asmjs or something similar from another language?

For example you could try using Cython to compile the python version, and then using some C -> asmjs compiler to get asmjs out.

I worry that native javascript will be absurdly slow for what is already a very expensive calculation (pairing verification).

#10

Thanks for the response! That’s exactly how we decided to proceed.