I vaguely remember we had that. It's somewhat easy to implement by checking serialized bytes. But it's more user friendly if it's in bls.

Describe the bug

Export this file in the root index https://github.com/ChainSafe/bls/blob/master/src/errors.ts

Expected behavior

Be able to import those errors from import {CustomError} from "@chainsafe/bls"

Describe the bug
empty signature results in Segmentation fault (core dumped)

Expected behavior
false

Steps to Reproduce
bls.Signature.fromHex('').verify(bls.PublicKey.fromHex('xxx'), 'test')

Running a synchronous NodeJS script that does not call initBLS first, and calling verify on a valid signature returns false. It should throw instead of returning a false value.

Consider implementing generateRandomSecretKey() which is just

function generateRandomSecretKey() {
  let sk = 0;
  while (sk === 0) {
    sk = randomBytes() % CURVE_ORDER
  }
  return sk;
}

and remove the @chainsafe/bls-keygen which depends on bcrypto and then you have fun unnecessary node-gyp compilation. @wemeetagain what do you think?

This issue is being used to standardize repositories to confirm with the Lodestar monorepo's labels.

When I try to install @chainsafe/blst on my arm64 arch, this error returned:

Retrieving BLST native bindings /Users/jasperli/work/etherfi-app/node_modules/@chainsafe/blst/prebuild/darwin-arm64-115-binding.node ...
Error: Error importing BLST native bindings: 404 Not Found

May I suggest that arm64 development is not supported now?

Usage of bls is problematic under some alternative JS environment for the following reasons:

• usage of top-level-wait in a lib
• automatic detection of the proper implementation (i.e. use native when node env is detected)

Ideally there would be a way to allow bls users to select the implementation used at runtime. Users should not be able to specify their chosen implementation after the initialization has been done (thus ignoring their choice).

First idea

Single global implementation

BLS_IMPLEMENTATION=herumi node ...

import bls, {init} from "@chainsafe/bls";

// Make sure the initialization has been done
// Can be called several times, initialization is done only once
await init();

const secretKey = bls.SecretKey.fromKeygen();
const message = new Uint8Array(32);
const signature = secretKey.sign(message);

No automatic init would be done, users explicitly have to do it. Essentially it's a modified version (with env variable) of the existing switchable singleton. This would be the only way to use the lib.

Second idea

Explicitly pass around a bls object tied to an implementation.

const bls = await BLS.init("herumi");
const secretKey = bls.SecretKey.fromKeygen();
const message = new Uint8Array(32);
const signature = secretKey.sign(message);

When this commit gets released,

herumi/bls-eth-wasm@5a789d8

bump the dependency to remove browser-specific code in herumi/context

See https://github.com/ethereum/bls12-381-tests/ recommended by Proto

Method should accept array of PublicKey instances to reduce number of decompression calls.

We should also use this method in lodestar attestation verification instead of aggregating public keys (less wasm invocations)

ethereum/consensus-specs#2051

FYI on the eth2 implementers call today, it was mentioned that we will likely want/need to expose underlying group operations in our BLS library (multiplication and addition in G2).
Will be required when we add 'polynomial commitments'

https://discord.com/channels/593655374469660673/779360832588742686/784072468629422131

Describe the bug
The BLS spec requires that the secret key (SK) must be a uniformly random integer such that 1 <= SK < r.
Where r is the order curve.

The last check is missing:

• fromBytes
• fromBytes

Expected behavior

Check that the provided SK < r.

With all the BLS changes happening, I'd really appreciate it if you guys could bump the herumi version y'all are using to v1.10 which is eth2-spec v0.12 compliant. In particular, it would be helpful for the deposit interface.

The npm install fails on M1 mac with this error:

npm ERR! ../src/secp256k1/src/scalar_8x32_impl.h:741:5: error: implicitly declaring library function 'memcpy' with type 'void *(void *, const void *, unsigned long)' [-Werror,-Wimplicit-function-declaration]
npm ERR!     memcpy((void *) seed32, (const void *) seed, 32);
npm ERR!     ^
npm ERR! ../src/secp256k1/src/scalar_8x32_impl.h:741:5: note: include the header <string.h> or explicitly provide a declaration for 'memcpy'
npm ERR! 1 error generated.
npm ERR! make: *** [Release/obj.target/bcrypto/src/secp256k1/src/secp256k1.o] Error 1

BTW, secp256k1 C module builds fine from git source.

https://github.com/supranational/blst

They should be generated with swig tool

according to the original paper, BLS seems to support shortest signature size like 160bits, but i cant find any lib that can support that size directly. i know 160bits is less secure, but produce more user friendly signature for keyboard typing, which can be used in some cases.

Consider following CI to automate npm publish, tag, release(with changelog)

name: Release

on:
  push:
    branches:
      - 'master'

jobs:
  tag:
    name: Check and Tag
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Create tag
        id: tag
        uses: butlerlogic/[email protected]
        with:
          GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
          strategy: package # Optional, since "package" is the default strategy
          tag_prefix: "v"
    outputs:
      tag: ${{ steps.tag.outputs.tagname }}
      version: ${{ steps.tag.outputs.version }}

  release:
    name: Release
    runs-on: ubuntu-latest
    needs: tag
    if: needs.tag.outputs.tag != ''
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Install dependencies
        run: yarn install --non-interactive --frozen-lockfile
      - name: Build
        run: yarn run build
      - name: Create npmrc with npm token:
        run: TODO
      - name: Publish to npm registry
        run: yarn publish --ignore-scripts --no-git-tag-version --no-commit-hooks --non-interactive
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ needs.tag.outputs.tag }}
          release_name: Release ${{ needs.tag.outputs.tag }}
      #in case of failure
      - name: Rollback on failure
        if: failure()
        uses: author/action-rollback@9ec72a6af74774e00343c6de3e946b0901c23013
        with:
          id: ${{ steps.create_release.outputs.id }}
          tag: ${{ needs.tag.outputs.tag }}
          delete_orphan_tag: true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

To achieve fast batch bls verification, we need to be able to perform scalar multiplication on G2 points (bls pubkeys).
It would be best to do that in js (https://github.com/ChainSafe/eth2-bls-wasm) without extra wasm invocation.

Example in go:
https://github.com/prysmaticlabs/prysm/pull/6479/files#diff-6292da8af56d8aa08aa61b7dedcb6982R154

ethereum/consensus-specs#1799

@mpetrunic commented on Mon Jul 29 2019

• add comments to exposed functions and classes
• add typedoc and setup publish to github pages

This library relies on https://github.com/herumi/bls-eth-wasm which in turn relies on https://github.com/herumi/bls which has support for threshold signatures via https://github.com/herumi/bls#api-for-k-of-n-threshold-signature.

I guess right now you would rely on https://github.com/herumi/bls-eth-wasm exposing those methods so you could access them or are there any plans on adding support/examples for threshold signatures in any another way? Maybe it is already possible to verify an aggregated signature against a subset of public keys and I overlooked it. The use-case would be an M-of-N MuSig implementation where any M signatures being valid according to a set of N public keys results in the verification of an aggregated signature passing.

How is aggregating 30 keys useful?

eth2 would be around 32k validators very soon, and probably 320k after some time. And each slot is voted by around 1k voters

I think it would make sense to benchmark 32, 1024, 32768 and 131072 public keys / signatures.

It takes 4m 40s currently for the benchmark step, most of which is spent signing payloads for benchmark

It's not actually necessary since the functionality will be the same but it might be a good idea that the Lodestar team does it upfront.

Describe the bug
I got this error while import the package in nodejs :

Error: Package subpath './blst-native' is not defined by "exports" in .\node_modules\@chainsafe\bls\package.json

import:

import bls from "@chainsafe/bls/blst-native";

Is your feature request related to a problem? Please describe.
Found out during the testing that on some environment top-level-await are not properly supported. Which are used to initialize the BLS object if the package is imported directly.

Describe the solution you'd like

The best approach to fit in all cases is to import the BLS from the switchable. And when is appropriate use the init to initialize the object.

import bls, {init} from "@chainsafe/bls/switchable";

That init does accept one parameter and it's redundant to identify and pass the parameter for the right implementation. This logic of detecting is already part of the package so we can reuse here. We can provide third option here auto which could be the default value as well. So user don't need to write custom logic and switchable will detect the right implementation.

Describe alternatives you've considered
The alternative safe approach is to use the await import. But that can't be done with correct user experience as code outside that block will not access to the bls object.

Additional context
ChainSafe/lodestar#2723