Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-blockchain BLS12-381 standardisation #605

Closed
JustinDrake opened this issue Feb 11, 2019 · 3 comments
Closed

Cross-blockchain BLS12-381 standardisation #605

JustinDrake opened this issue Feb 11, 2019 · 3 comments
Labels
general:RFC Request for Comments

Comments

@JustinDrake
Copy link
Collaborator

This is a heads-up that the BLS spec is likely to change. Many blockchain projects are converging towards BLS12-381 (Zcash Sapling, Chia, Ethereum 2.0, Filecoin, Dfinity, Algorand, etc.) and there is a strong desire for everyone to standardise on the fine details. This include standardising

  • hash functions (to G1 and G2)
  • generator points (for G1 and G2)
  • point serialisation (for G1 and G2)
  • possibly message hashing

Given that Zcash Sapling is already in production, one sensible approach may be to start from what Zcash has.

Dan Boneh and folks from Algorand have a IETF draft. I encourage anyone interested in this discussion to email Sergey Gorbunov (sgorbunov@uwaterloo.ca) who seems to be leading the effort.

@axic
Copy link
Member

axic commented Feb 11, 2019

cc @Schaeff

@JustinDrake
Copy link
Collaborator Author

Announcement tweet and Medium post.

@JustinDrake
Copy link
Collaborator Author

Closing in favour of #675.

JustinDrake added a commit that referenced this issue Mar 15, 2019
SHA256 is de facto blockchain standard. Standardisation of the hash function is a prerequisite for [full standardisation of BLS12-381 signatures](#605). Blockchain projects are likely to provide a cheap SHA256 opcods/precompile, and unlikely to provide a Keccak256 equivelent. (Even WASM-enabled blockchains are likely to provide a SHA256 opcode/precompile since WASM does *not* natively support optimised SHA256 CPU instructions.) With Ethereum 2.0 embracing SHA256 the wider industry is more likely to converge towards a unified cross-blockchain communication scheme via Merkle receipts.

There are no security blockers with SHA256 (see comments by Dan Boneh [here](#612 (comment))).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
general:RFC Request for Comments
Projects
None yet
Development

No branches or pull requests

3 participants