celo-org / celo-bls-snark-rs Goto Github PK
View Code? Open in Web Editor NEWImplements SNARK-friendly BLS signatures
Home Page: https://celo.org
License: Apache License 2.0
Implements SNARK-friendly BLS signatures
Home Page: https://celo.org
License: Apache License 2.0
We should just instantiate the random oracle with a cryptographic hash function. No need for a key. Also, terminology in the code relating to PRFs should change.
Depends on #55.
Use Blake2s in the composite hasher.
What is the current behavior?
SHA256 is used.
Pixel is a forward-secure signature scheme which is attractive: https://eprint.iacr.org/2019/514.pdf.
We should discuss and decide what we want to do about it - should we take, e.g., a two weeks detour to check it out?
Questions that I have at the moment:
Currently, we're using BLS signatures which are not forward secure.
The current implementation is not compatible with hardware wallet architecture, which using Ledger as a reference can have a little as 4kB volatile memory. A hardware compatible implementation should be made which never exceeds this limit.
Although we are not implementing the SNARK circuit at the moment, we should make sure that we're using a hash function that is SNARK-friendly enough, so that we can batch multiple epochs.
It seems we require around 800 bits of output. They way we achieve it at the moment, when using a 256 bit output, is:
Some possibilities:
Currently the repo does not use constant-time signing for BLS. This may make users vulnerable to side-channel attacks. Making signing constant-time will prevent such attacks.
The currently used std::io
uses allocation internally. An embedded-friendly implementation not using allocation would build towards hardware wallet compatibility.
Phase 1:
Phase 2:
Help wishlist:
The direct hasher should use proper Blake2x, rather than the current construction. I believe this would simplify the eventual security proof.
We use a method similar to Blake2x.
We should have a Groth16 implementation natively and in the circuit.
A promising direction is implementing bls12-377 in sapling-crypto.
Currently, we only know the performance of a window size of 4 and number of windows around 10k. We should have more benchmarks on different window sizes such that the product remains the same.
@PratyushRT Can you post the image you showed and details on what you benchmarked?
Upgrade the Rust toolchain to 1.37 in this repository, in celo-blockchain and celo-monorepo. After doing that, use cargo vendoring.
We use Rust 1.36.
Validator update logic is as follows:
In #63 support was added for the PoP from section 4.4 of https://cseweb.ucsd.edu/~syilek/pkreg.pdf. Compared to the B-Pop protocol in section 4.1, the one in section 4.4 has several weakness. First, PoP4.4 requires sampling a random challenge value, and we'll have to figure out how to do this in a distributed system. Second, PoP4.4 makes honest parties vulnerable to MitM attacks during key registration. Section 4.4 indeed explains how this attack can be carried out with a signing oracle, but by changing the hash function the problem is just moved to needing a registration oracle. In the real world you might obtain a registration oracle via a MitM on an honest party trying to register a key. Unless some sort of at-most-once-per-key registration semantics are implemented (which seems more fraught than switching to B-Pop), this attack becomes practical.
B-Pop may be seen as applying Fiat-shamir to PoP4.4 and gaining non-malleability.
For about a year now the Rust constant-evaluation pipeline has been robust enough that lazy_static is entirely replaceable by the once_cell crate, which provides a macro-free way of doing what lazy_static once did.
Currently, the blake2s circuit code doesn't support all the parameter block operations needed.
The BLS public key should be tied to the Ethereum address (and maybe other details).
Currently, the BLS public key and the Ethereum address are independent, opening the validator registration process, opening it to possible attacks.
Celotool currently depends on the Geth repository and Rust toolchain to create proofs of possession. It would be much better to have a pure JS implementation of that part. There's a WIP TypeScript implementation.
Celotool should generate a genesis object with BLS public keys and generate proofs of possession.
The validators contract should store BLS public keys and verify proofs of possession.
Only uses ECDSA keys.
Currently Geth aggregates the public keys directly. With subtraction, it can be faster. The method already exists in the bls-zexe codebase.
We should have a hardware wallet compatible implementation. Promising directions seem to be:
We don't have one.
The method should implement the HashToG2
trait.
Some possibilities:
Currently we have 1 .go file per architecture, due to the celo-blockchain toolchain being rigid for compiling with various CGO flags.
It'd be nice if we could get rid of these files, fix celo-blockchain and specify explicit instructions on how to cross-compile / link this library in various architectures.
An approach for this can be seen in #122 (which we partially reverted due to geth's inflexibility)
We need to implement an API that can be consumed by Go.
Rust allows exposing an "unsafe" C interface, which is suitable for this goal. The Go side should have a memory-safe abstraction over this API.
A successful example is how it's done in librustzcash (although the consumer is C++, I've successfully used a similar method with Go in the past):
https://github.com/zcash/librustzcash/blob/master/librustzcash/src/rustzcash.rs
Some questions to answer:
Let's use this issue to track any potential optimizations which can be done to reduce the size of our circuits
To authenticate a validator owns the private key behind a claimed public key, bls-zexe should provide a proof of possession API.
There isn't any.
Currently Vec
and Box
are used in the code as dynamically allocated data structures, which is problematic in an embedded context. Using fixed-size statically allocated equivalents would build towards hardware wallet compatibility.
Blocks have the EpochData structure, which is meant to be filled with the SNARK-friendly signed data. We should have a proper encoded struct for that. This issue tracks the encoding of that set to bits.
Currently, we don't have that.
Meta-issue: #71
Meta-issue: #71
We should have another hash implementation that uses the Zcash Pedersen hash described here: https://github.com/zcash/zips/blob/master/protocol/protocol.pdf.
It should have many benefits:
We use the Zexe variant from here: https://eprint.iacr.org/2018/962.pdf
We don't have test vectors from an independent implementation.
The currently used std::error::Error
uses allocation internally. An embedded-friendly implementation not using allocation would build towards hardware wallet compatibility.
Currently we have weird BE/LE encoding in various places. We must make sure that this is consistent across all necessary codebases, because it's a giant footgun otherwise.
Geth should use an infrastructure that supports bls-zexe keys, which have a different size and properties than the ECDSA keys used in Geth.
Geth uses the crypto.Account infrastructure.
Currently errors are "boxed" using Box<dyn Error>
. This is problematic in embedded contexts because Box
uses allocation. Using stack-based error messages would build towards hardware wallet compatibility.
Geth compilation should only build the bls_zexe package.
#56 introduces separation into algebra and snark packages. Geth doesn't need the snark crate for now.
Once #100 is merged, the Zexe subdirectory won't be needed anymore. That means we can pull the bls crate to the root directory. It'd be also nice to rename the repo to something like bls-rs-snark
or similar. Crates can probably be renamed to bls-crypto
and bls-snark
The validation code will use the bls-zexe code for BLS signatures signing, verification and aggregation.
Geth uses normal ECDSA signatures.
Depends on #13.
The SNARK-friendly hasher is slow. Sometimes we only need to sign a hash to gain the aggregation benefits.
There is only the slow SNARK-friendly hasher.
The spec should specify the ultralight sync protocol. This is a bit task, so this issue is to track the initial draft sections and structure of the spec.
Some of the topics to include:
It doesn't have to include at the moment a security analysis.
Should have a LICENSE. After a discussion with @timmoreton, it seems the best would be:
What is the current behavior?
There's no license.
Currently the embedded-friendly no-std
library is being developed as a separate branch of bls-zexe
. Clients should be able to conditionally compile the repo depending on whether they want to use the no-std
version or the original version using heap allocation and fine-grained error codes.
Implements the first part of #14.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.