flow-emulator icon indicating copy to clipboard operation
flow-emulator copied to clipboard

Add BLS signature support

Open tarakby opened this issue 4 years ago • 7 comments

Context

Cadence supports BLS signature scheme (signature verification, public key validation). Flow VM uses external dependencies (Relic library) to implement the Cadence BLS features. In order to keep the emulator free of external non-Go libraries, the emulator currently panics when Cadence BLS features are used.

Issue To Be Solved

  • either support Relic in the emulator: write scripts that allows compiling Relic static library in the included GOPATH.
  • or write a Go implementation of BLS (performance doesn't matter). This includes using Go packages for pairings and operations on BLS12-381.

tarakby avatar Jun 14 '21 23:06 tarakby

Wouldn't compiling the crypto library as it stands (with relic as a sub-module) and releasing it as a go package suffice to make it importable under the normal go logic?

huitseeker avatar Jun 15 '21 20:06 huitseeker

When the flow-go/crypto is imported as a package, files are copied from the github repo flow-go/crypto into the local GOPATH folder. Only the source files ( .go , .c, .h in our case) right under flow-go/crypto are copied. The relic files are not copied since they are part of a different repo.

There are no Go tools (to the best of my knowledge) that allow cloning and compiling Relic files or any external dependency at the same time the package is imported. go generate allows running scripts but it is still an extra command that importers have to run (this is the first option I mentioned in the ticket, a script already exists but needs further automation).

A third option I could add is to include the Relic compiled static library to be imported along with the source code files. If we manage to make go get copy the static library then the problem should be solved too.

tarakby avatar Jun 15 '21 22:06 tarakby

A third option I could add is to include the Relic compiled static library to be imported along with the source code files. If we manage to make go get copy the static library then the problem should be solved too.

This is the idea I had in mind and why I was suggesting a separate repo and release schedule. See, for example, how herumi creates a go package for bindings to his own bls library:

https://github.com/herumi/bls-go-binary

The package contains bls (a C++ library) as a submodule, and contains (non-go) scripts to build the static binary, which is checked in as part of the source. The go package tooling then downloads all of that and just builds the binding layer on top.

Incidentally, this approach may solve things like https://github.com/onflow/flow-go/pull/756 by letting people switch out our distributed relic variant with theirs, using a replace directive.

huitseeker avatar Jun 16 '21 14:06 huitseeker

Ah yes you're right, my statement below wasn't quite right, because it's possible indeed to have the static library as part of the Go package.

If we manage to make go get copy the static library then the problem should be solved too.

I also remember why I didn't include this as the 3rd option, mainly because it is less preferable: I believe it is not a good practice in general to include compiled binaries along with source files in a repository, plus this would open the arch compatibility issues. I'm happy to discuss this option together with the team.

tarakby avatar Jun 17 '21 07:06 tarakby

I think this is a flow-go issue. https://github.com/onflow/flow-go/blob/master/crypto/bls_no_relic.go

bluesign avatar Sep 17 '22 09:09 bluesign

@bluesign that file is there to allow the emulator to build properly (but without supporting BLS). If we remove the file, building the emulator would fail because some relic related files need are not found. These relic files need to be built separately which adds friction to the emulator users. For now, it has been preferred to exclude BLS features from the emulator (not all users need them), instead of adding friction to all the emulator users.

This current issue is about addressing specifically the emulator issue.

tarakby avatar Sep 20 '22 18:09 tarakby

@tarakby I understand the situation, but this is not emulator issue in my opinion, I mean emulator here is the one consumer of flowgo/fvm and indirectly flowgo/crypto. You are totally right, effected party is emulator in this case, but for example probably REPL doesn't also support BLS functions.

Now there are not many consumers of FVM, but eventually (probably agree too) fix should be in the flowgo repository.

bluesign avatar Sep 30 '22 18:09 bluesign