mattrglobal / bbs-signatures Goto Github PK

I am running the library on an Apple Silicon (aka M1) MacBookPro and receive the subject error.

Steps to reproduce (a series of commands in shell):

$ node -p "process.arch + ' ' + process.platform + ' ' + process.version"
arm64 darwin v14.16.0

$ mkdir bbs-expt
$ cd $_
$ npm init -y
Wrote to /Users/[REDACTED]/dev/expt/bbs-expt/package.json:

{
  "name": "bbs-expt",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}
$ npm i @mattrglobal/bbs-signatures

[NPM OUTPUT GOES HERE]

$ echo "require('@mattrglobal/bbs-signatures')" > index.js
$ node index.js

This results in node process crash with the following output:

(node:32546) Warning: Accessing non-existent property 'abort' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)

<--- Last few GCs --->

[32546:0x150008000]      125 ms: Scavenge 10.0 (11.7) -> 9.7 (12.4) MB, 0.4 / 0.0 ms  (average mu = 1.000, current mu = 1.000) allocation failure


<--- JS stacktrace --->

FATAL ERROR: wasm code commit Allocation failed - process out of memory
 1: 0x1044310cc node::Abort() [/opt/homebrew/opt/node@14/bin/node]
 2: 0x10443124c std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string<std::nullptr_t>(char const*) [/opt/homebrew/opt/node@14/bin/node]
 3: 0x104531448 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/opt/homebrew/opt/node@14/bin/node]
 4: 0x1045313dc v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/opt/homebrew/opt/node@14/bin/node]
 5: 0x1049a42e4 v8::internal::wasm::WasmCodeAllocator::AllocateForCodeInRegion(v8::internal::wasm::NativeModule*, unsigned long, v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/opt/homebrew/opt/node@14/bin/node]
 6: 0x1049a4de8 v8::internal::wasm::NativeModule::CreateEmptyJumpTableInRegion(int, v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/opt/homebrew/opt/node@14/bin/node]
 7: 0x1049a3d3c v8::internal::wasm::NativeModule::AddCodeSpace(v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/opt/homebrew/opt/node@14/bin/node]
 8: 0x1049a4c04 v8::internal::wasm::NativeModule::NativeModule(v8::internal::wasm::WasmEngine*, v8::internal::wasm::WasmFeatures const&, v8::internal::VirtualMemory, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, std::__1::shared_ptr<v8::internal::Counters>, std::__1::shared_ptr<v8::internal::wasm::NativeModule>*) [/opt/homebrew/opt/node@14/bin/node]
 9: 0x1049a6c18 v8::internal::wasm::WasmCodeManager::NewNativeModule(v8::internal::wasm::WasmEngine*, v8::internal::Isolate*, v8::internal::wasm::WasmFeatures const&, unsigned long, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>) [/opt/homebrew/opt/node@14/bin/node]
10: 0x1049b1af4 v8::internal::wasm::WasmEngine::NewNativeModule(v8::internal::Isolate*, v8::internal::wasm::WasmFeatures const&, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, unsigned long) [/opt/homebrew/opt/node@14/bin/node]
11: 0x104987df0 v8::internal::wasm::AsyncCompileJob::CreateNativeModule(std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, unsigned long) [/opt/homebrew/opt/node@14/bin/node]
12: 0x104987fa4 v8::internal::wasm::AsyncCompileJob::GetOrCreateNativeModule(std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, unsigned long) [/opt/homebrew/opt/node@14/bin/node]
13: 0x10498ee3c v8::internal::wasm::AsyncCompileJob::PrepareAndStartCompile::RunInForeground(v8::internal::wasm::AsyncCompileJob*) [/opt/homebrew/opt/node@14/bin/node]
14: 0x10498ec68 v8::internal::wasm::AsyncCompileJob::CompileStep::Run(v8::internal::wasm::AsyncCompileJob*, bool) [/opt/homebrew/opt/node@14/bin/node]
15: 0x10498eb78 v8::internal::wasm::AsyncCompileJob::CompileTask::RunInternal() [/opt/homebrew/opt/node@14/bin/node]
16: 0x104484bb0 node::PerIsolatePlatformData::RunForegroundTask(std::__1::unique_ptr<v8::Task, std::__1::default_delete<v8::Task> >) [/opt/homebrew/opt/node@14/bin/node]
17: 0x104483ca4 node::PerIsolatePlatformData::FlushForegroundTasksInternal() [/opt/homebrew/opt/node@14/bin/node]
18: 0x104484d6c node::NodePlatform::DrainTasks(v8::Isolate*) [/opt/homebrew/opt/node@14/bin/node]
19: 0x104464cfc node::NodeMainInstance::Run() [/opt/homebrew/opt/node@14/bin/node]
20: 0x10440c800 node::Start(int, char**) [/opt/homebrew/opt/node@14/bin/node]
21: 0x195b1df34 start [/usr/lib/system/libdyld.dylib]
[1]    32546 abort      node index.js

However, doing the same with the latest Node.js (v15.12.0) works well (assuming the files from above are still in place):

$ node -p "process.arch + ' ' + process.platform + ' ' + process.version"
arm64 darwin v15.12.0

$ node index.js
(node:32587) Warning: Accessing non-existent property 'abort' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)

$ node --trace-warnings index.js
(node:32591) Warning: Accessing non-existent property 'abort' of module exports inside circular dependency
    at emitCircularRequireWarning (node:internal/modules/cjs/loader:698:11)
    at Object.get (node:internal/modules/cjs/loader:712:5)
    at asmFunc (/Users/[REDACTED]/dev/expt/bbs-expt/node_modules/@mattrglobal/bbs-signatures/lib/wasm_asm.js:95:18)
    at Object.<anonymous> (/Users/[REDACTED]/dev/expt/bbs-expt/node_modules/@mattrglobal/bbs-signatures/lib/wasm_asm.js:184429:18)
    at Module._compile (node:internal/modules/cjs/loader:1092:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1121:10)
    at Module.load (node:internal/modules/cjs/loader:972:32)
    at Function.Module._load (node:internal/modules/cjs/loader:813:14)
    at Module.require (node:internal/modules/cjs/loader:996:19)
    at require (node:internal/modules/cjs/helpers:92:18)

Any ideas, if this could be fixed for Node v14?
Also what about the non-existing property issue?

The 0.4.0 release included some breaking API changes therefore the samples and doc's need to be updated in the following places

• Usage in the readme
• Browser Sample see #49 for an example of an issue running this sample is currently causing.
• Node Sample

Update this library to target the 0.4.1 rust crate once released

When running this library in certain browsers, the following error is being reported.

Impact is that the ASM.js rollback is being used instead of WASM which has a serious impact on performance.

Browsers tested (x indicates the occurrence of the issue)

[x] Brave
[x] Chrome
[ ] Safari
[ ] Firefox

I tried to use it in react but i get this error:

TypeScript error in /Users/tec2/web/node_modules/@mattrglobal/bbs-signatures/lib/types/index.ts(14,10):
Cannot re-export a type when the '--isolatedModules' flag is provided.  TS1205
    12 |  */
    13 | 
  > 14 | export { BbsBlindSignContext } from "./BbsBlindSignContext";
       |          ^
    15 | export { BbsBlindSignContextRequest } from "./BbsBlindSignContextRequest";
    16 | export { BbsBlindSignRequest } from "./BbsBlindSignRequest";
    17 | export { BbsCreateProofRequest } from "./BbsCreateProofRequest";

Any ideas how to avoid this error?
Thank you in advance!

Add a runnable sample to the repository on how to use the API

Running wasm-opt with the -Oz flag leads to a Segmentation fault meaning we are unable to build the most optimised version of WASM in our CI pipeline. Potential solutions include

1. Change the OS that the build pipeline is running in.
2. Monitor for future releases of wasm-opt that may rectify this issue.
3. Try older releases of wasm-opt

Issue that might be of relevant here

Add in clippy support for linting rust code. Alternatively we can lean on the rust compiler more to catch some of the common issues see here for example.

Currently because of limitations in how wasm-pack works with regards to generating WASM and the associated JS that is isomorphic to both browser and NodeJS. There is some messy post-build code required to create a CJS compatible version that will also run in NodeJS. The CJS based version is then what is predominantly used by most upstream libraries, hence keeping the ES module is perhaps redundant.

jest's default testing environment is jsdom, however when the tests are run for either asm.js or wasm in this environment using

yarn test:asm

OR

yarn test:wasm

errors such as the below are reported.

asm

TypeError: abort is not a function

wasm

RuntimeError: unreachable

To reproduce remove the testEnvironment: "node" from ./jest.config.js and run the tests.

As shown by rn-wasm-crypto and supplied by polkadot-js/wasm using wasm2js from binaryen the wasm can be compiled back into asm.js to support react native

This is currently reporting unknown coverage which should be fixed

To reproduce:

1. Clone my fork's branch (#48) that has the key pair generation function names fixed (otherwise the sample will stop working there)
2. Run the browser samples as instructed by the readme file under ./sample/browser
3. Observe the crash

Chrome Dev Tools Logs:

localhost/:1 Uncaught (in promise) Error(JsValue(TypeError: Reflect.get called on non-object
TypeError: Reflect.get called on non-object
    at Object.get (<anonymous>)
    at Module.eval (webpack:////home/peter/a/blockchain/bbs-signatures/pkg/index_bg.js?:644:23)
    at Module.eval (webpack:////home/peter/a/blockchain/bbs-signatures/pkg/index_bg.js?:451:22)
    at __wbg_get_2e96a823c1c5a5bd (http://localhost:8080/bbs-signatures.min.js:149:102)
    at js_sys::Reflect::get::hdb44b494eb45724a (http://localhost:8080/294ad96f2bf83bcad951.module.wasm:wasm-function[1000]:0x1b98b7)
    at js_sys::try_iter::hb9f6985e5939da27 (http://localhost:8080/294ad96f2bf83bcad951.module.wasm:wasm-function[260]:0x155380)
    at <serde_wasm_bindgen::de::Deserializer as serde::de::Deserializer>::deserialize_seq::h8a61401663b55dff (http://localhost:8080/294ad96f2bf83bcad951.module.wasm:wasm-function[335]:0x1665a5)
    at serde::de::impls::<impl serde::de::Deserialize for alloc::vec::Vec<T>>::deserialize::h1a24def40ef00233 (http://localhost:8080/294ad96f2bf83bcad951.module.wasm:wasm-function[5448]:0x240a27)
    at <core::marker::PhantomData<T> as serde::de::DeserializeSeed>::deserialize::hbf6636bd759ab427 (http://localhost:8080/294ad96f2bf83bcad951.module.wasm:wasm-function[5478]:0x24107b)
    at <serde_wasm_bindgen::de::SeqAccess as serde::de::SeqAccess>::next_element_seed::h2d960dcb668c8169 (http://localhost:8080/294ad96f2bf83bcad951.module.wasm:wasm-function[354]:0x16a3fc)))

With Dev Tools "Pause on Exception" this is where it goes sideways:

We've been working on a react native wrapper around the FFI interface that matches the interface of this library. We use it to expose the same functionlity in react native and leverage the jsonld-signatures-bbs library.

https://github.com/animo/react-native-bbs-signatures

Currently, however, we need to add overrides for all dependencies of @mattrglobal/bbs-signatures and map it to @animo-id/react-native-bbs-signatures. If we were to make @animo-id/react-native-bbs-signatures an optional peer dependency of this library and import it conditionally like is already done with node vs wasm, we wouldn't need any overrides anymore.

The package won't be installed by default and the user is still responsible for adding the dependency. It just adds support for the import in this library, meaning all packages that depend on this package (e.g. the bls12381-key-pair package) would automatically import the correct version.

We would still need to add the dependency to a react native project because autolinking only supports top-level packages declared in package.json, but it would make the setup easier.

Currently we have to add the following mapping to the package.json (depending whether you're using yarn/npm)

yarn

+   "resolutions": {
+     "@mattrglobal/bbs-signatures": "@animo-id/[email protected]",
+   }

npm

+   "overrides": {
+     "@mattrglobal/bbs-signatures": "@animo-id/[email protected]",
+   }

The resolution field says that any instance of @mattrglobal/bbs-signatures in any child dependency must be swapped
with @animo-id/react-native-bbs-signatures.

In some cases for instance when a party would like to prove control of a key pair that will be used as the cryptographic binding to say a credential as documented here signatures offer an easy mechanism to do so and BLS signatures as a scheme are a good candidate to solve this problem

Currently we have benchmarking support for the WASM in node environments but not for browser based execution

related to mattrglobal/bls12381-key-pair#15

I use this lib through transmutes "@transmute/did-key-bls12381". All I do is a simple generate a key. But upgrading my node version to run the test I get these warnings.

Have you guys seen it before? Does not exist on 12.22.
Does this make sense to you guys?

I do guess this warning comes out of this lib as it is the only mentioned in the stacktrace

Some sources of the error is found here: nodejs/node#32987