ZenGround0
commented
5 years ago Please see https://github.com/filecoin-project/specs/issues/441 for discussion on which VRF construction to use. We might be rolling our own construction using BLS signatures internally which would resolve the multiple key complexity (all miner addresses would just be BLS). Stay tuned for the conclusion there.
anorth
Description
We need a secure ECVRF implementation to complete the consensus protocol (see spec). We should source this from an existing project.
I've just confirmed that the licensing for algorand's libsodium fork is compatible with go-filecoin's licensing. I recommend moving forward with this code.
Acceptance criteria
We can call the VRF endpoint functions:
MakeProof,VerifyProof,VerifyKeyfrom our go code.Risks + pitfalls
We will need to use cgo. Algorand nodes are also calling this code so there shouldn't be too many complications coming from this.
The filecoin node needs to be able to have keys that work with VRF functions. A cursory glance shows that secp256k1 does not show up in the ECVRF spec. We'll need to look closer to see what is going on, but we might need to generate fully separate ticket signing keys, or move message signing to the underlying VRF scheme if we don't want multiple types of keys.
Managing this dependency should be done thoughtfully to avoid complexity. We can't reuse algorand's cgo work and directly import a subpath of the algorand node because it's GPL. Perhaps we'll want a cgo bindings project that we can import that handles linking to the libsodium library. Alternatively maybe we want another submodule.
Where to begin
Make a plan for dependency management. Understand the endpoints we want. Familiarize yourself with cgo bindings as used elsewhere in the filecoin project.