hyperledger / cacti Goto Github PK

Hyperledger Cacti is a new approach to the blockchain interoperability problem

Home Page: https://wiki.hyperledger.org/display/cactus

License: Apache License 2.0

JavaScript 2.31% Go 9.70% Shell 1.85% Dockerfile 0.36% TypeScript 59.43% Makefile 0.47% Solidity 0.88% Rust 7.25% Logos 0.16% Kotlin 16.47% CSS 0.09% Mustache 0.08% ANTLR 0.01% Roff 0.01% EJS 0.01% Java 0.10% PLpgSQL 0.83% HTML 0.01%

hacktoberfest

cacti's Introduction

Hyperledger Cacti

Hyperledger Cacti is a multi-faceted pluggable interoperability framework to link networks built on heterogeneous distributed ledger and blockchain technologies and to run transactions spanning multiple networks. This project is the result of a merger of the Weaver Lab project with Hyperledger Cactus, which was subsequently renamed to Cacti. It draws on the cutting-edge technological features of both constituent projects to provide a common general purpose platform and toolkit for DLT interoperability. This was the first-of-a-kind merger of two systems, architecture and code bases, to create a new project, under the Hyperledger Foundation. See this Hyperledger Foundation blog article for more information about the merger.

Cacti is a Graduated Hyperledger project. Information on the different stages of a Hyperledger project and graduation criteria can be found in the Hyperledger Project Incubation Exit Criteria document.

Scope of Project

The existence of several blockchain and distributed ledger technologies of different flavours in the market as well as networks of varying scopes and sizes built on them necessitates the need for interoperability and integration, lest we end up with a fragmented ecosystem where digital assets and the workflows (often contracts) governing them remain isolated in silos. The solution to this is not to force all chains to coalesce (i.e., "a single chain to rule them all") but rather enable the networks to orchestrate transactions spanning their boundaries without sacrificing security, privacy, or governance autonomy (i.e., self-sovereignty). Hyperledger Cacti offers a family of protocols, modules, libraries, and SDKs, that can enable one network to be interoperable with, and carry out transactions directly with, another while eschewing the need for a central or common settlement chain. Cacti will allow networks to share ledger data, and exchange and transfer assets atomically, and manage identities, across their boundaries, as illustrated in the figure below.

As a fusion of two earlier systems (Cactus and Weaver) that have similar philosophies and goals, yet offer distinct mechanisms backed by different design and trust assumptions, Cacti offers a spectrum of selectable and configurable features for cross-network transaction orchestrations. An example illustrated below shows how distributed applications running on Fabric and Besu ledgers respectively can carry out the same set of cross-network transactions using the Node Server (Cactus legacy) or through Relays (Weaver legacy).

The current Cacti code base contains the legacy Cactus and Weaver source code in aggregated form with their original folder structures intact. But the packages built from the two sections of code are unified and released under a common cacti namespace, and the CI/CD pipelines for testing and releases are also integrated under a common set of GitHub Actions. A deeper merge and integration of source code is part of our roadmap, and will be carried out over a longer time period, but the current setup of code and release packages makes it easy for new users to navigate Cacti and for legacy users to carry out seamless upgrades.

(Reference for legacy users: Cactus source code lies here (i.e., the root folder), excluding the weaver folder. Weaver source code lies within the weaver folder.

Documentation

See the official Hyperledger Cacti documentation to get all your questions answered about the project, to get started with setup, testing, and evaluation, and to get hands-on with code and configurations. Here, you can find separate (and specific) instructions for getting started with running and experimenting with Cactus modules and Weaver modules respectively.

Roadmap

See ROADMAP.md for details on the envisioned integration.

Inclusive Language Statement

These guiding principles are very important to the maintainers and therefore we respectfully ask all contributors to abide by them as well:

Consider that users who will read the docs are from different backgrounds and cultures and that they have different preferences.
Avoid potential offensive terms and, for instance, prefer "allow list and deny list" to "white list and black list".
We believe that we all have a role to play to improve our world, and even if writing inclusive documentation might not look like a huge improvement, it's a first step in the right direction.
We suggest to refer to Microsoft bias free writing guidelines and Google inclusive doc writing guide as starting points.

Contact

mailing list: [email protected]
discord channel: https://discord.com/invite/hyperledger

Contributing

We welcome contributions to Hyperledger Cacti in many forms, and there’s always plenty to do!

Please review contributing guidelines to get started.

License

This distribution is published under the Apache License Version 2.0 found in the LICENSE file.

cacti's People

Contributors

Stargazers

Watchers

Forkers

petermetz denis-yu-glotov jonathan-m-hamilton jimulle memazouni harshad-pawar noahmarconi appbootup blefevre xuexl-mack rafaelapb serial-coder etaroid asifwaquar sownak rookielinlucy666 tkuhrt yanliu18 gwangchina86 00kai0 balabhaskar27 hartm stone-ch chipleinen vipinsun jkcomment ankurdaharwal doben suyukuoacn figo050518 embedded dilumb segawahiroki sillysachin yixin-li-94 sidepocketneo cj-jeon driqra pret-a-porter eleontev sheetalsingala takeutak fyhassy keitatiek gabrielsoaresm94 jagpreetsinghsasan alejandroalffer wangfeiping itsshadowl acrowise majiang konsmosc kikoncuo catarinapedreira ryu-shinzaki fumiya-kobayashi nkmr-jp eu09 tonyrowntree ddotafonso jscode017 travis-payne ca2sigtestchaingru azaharac siv2r izuru0 kosasih maramih seyoungnam tkyonezu zjdw123 opentaps djanie1 elenaizaguirre leeyoungone jeff-ushry awadhana twiggins120 hanxu12 ayudateam miguelpardal zackvilla be-secure alvaropicazo sharath2106 suvajit-sarkar ayuda-solution juanmherrerav preeti13456 henryeleonu hsouf brioux theliso m-courtin sumodgeorge sfuji822 princekumar4812 satyamgupta0103 jgusta shoebsd31

cacti's Issues

Ubuntu VM Resource leakage

Set up the simple-assert-transfer example with all the containers running on the same ubuntu 1804 vm. One of the JVM processes took 100% on all 8 CPU cores and filled up the ram in a couple hours of operation.

Refactor data-check for protocol implementation

Problem statement
Users and developers should be able to implement their own validator's verification logic and the code structure should reflect this capability

Current state
"Data-check" logic is located under the Validator class as a standalone function and implement only the "existence" verification

Desired state
"Data-check" logic is located under the connector section and is part of the plugin (different integration for each platform). Verification logic and how to build your own figures in the documentation

Todo

Move the data-check function and the verification components to the plugin section
Implement a more generic verification scheme to help new developers implement their own functions
Document the importance of the validator's verification logic and how to modify it to match specific use cases

docs: make docs more accessible & accurate

Description

As a user of Cacti, I want to be able to find relevant documentation for my needs. Cacti has a fair amount of pre-existing documentation, but it is tucked away in ./docs/tutorials/ and has not been updated for open source collaboration. The objective of this story is to refresh & migrate the existing documentation from the docs to a wiki

Acceptance Criteria

Existing documentation migrated to wiki
Documentation updated to reflect point in time state of OSS with expectation of future enhancements)
Weaver and Cactus documentation made coherent and unified.

Note this story is specific to migrating the existing documentation, but there are also separate stories on creating net new documentation

Multi-request for federation leader

Add ability to queue requests for federation leader, considering the distributed nature e.g. if leader drops then can't lose queue

Cross AZ / Cross Region Deployments

Description

As an operator of validator nodes I want to be able to invite other organizations to join my private cluster so that we can make our resources work together.

For example

Company A wants to build a public BIF deployment to back a paid service where people can transfer assets between 2 different networks.

Business is booming and soon Company A leadership decides that they want to partner with Company B so that they share the cost of running the infrastructure and double the marketing reach through their combined brands.

They issue a fancy press release announcing the partnership, shake hands and then give the problem of figuring out the rest to the engineering department who soon realizes that the data centers of Company B are on a different continent and moving their infrastructure is (of course) not an option.
So, they have to make it so that a cluster of BIF validator nodes are working together in a productive fashion even though the latency between them can be > 200ms at times which is a challenge when you have a leader election algorithm (Etcd/Raft) that is sensitive to latency.

Acceptance Criteria

Verify that we are able to tune Etcd so that cross AZ/R deployments are operational. Start here: https://github.com/etcd-io/etcd/blob/master/Documentation/tuning.md
If Etcd doesn't work, document very thoroughly what tests were done and what were the exact results based on which the conclusions were drawn.
Look into CockroachDB for inspiration on how they solve the exact same challenge in the context of their software. Document the learnings from there and include it in the architectural documentation of BIF regardless of what decision is made in the end of the story.

Enhance Credential Storage

Write a plugin that uses encryption at rest through some stable piece of software such as Vault or one of the cloud providers own key/secret management solutions (or both, actually).

Fix typo in name of "pluggins" directory

Document Pre-1.0 Versioning Scheme

Hyperledger rules state that we aren’t allowed to release a 1.0 without being graduated first from the labs (and satisfying a long list of other criteria).

We’ll have to issue the pre-1.0 releases still with breaking changes and to signal these to users the semver minor part should be used.

Example: release is considered a major release where features/bug fixes increment the patch part only. Release is considered a second major release where backward compatibility is not guaranteed towards 0.1.0.

The task here is to put this in the README of the project in a headline to clarify to users what to expect when upgrading.

Cleanup merged readme.md

Post merge of lab readme.md and original sources readme.md there is some housekeeping to take care of:

broken links
historical information that should be in wiki / elsewhere
new links to other useful references (Code of Conduct, Contributing.md, Rocketchat)

CI Setup Options

Every branch/PR should be hooked up with CI automatically so that contributors get feedback about their proposed changes without maintainer dependencies.

Look into the following options as a minimum:

Any CI providers out there who do sponsorships (there’s a bunch of them but we need containers which may cull the herd a bit)
Pre-existing test nets
Anything Hyperledger has? Most likely not, resources are only assigned to graduated projects.
Could set up something manually on a cheap VPS provider (e.g. none of the big-name cloud providers) Example: https://www.wishosting.com/order/config/index/VPS/?group_id=2&pricing_id=112

Intermittent Travis CI Issues

Investigate flaky Travis CI failures and determine if one or more fixes required

Besu Support

With emphasis on the privacy groups feature: https://besu.hyperledger.org/en/stable/Concepts/Privacy/Privacy-Groups/

The latter is important according to our design principles: each DLT we support should be able to leverage their own innovation through BIF not just be forced to operate on the lowest common denominator of the capabilities of the rest of the supported DLTs.

Avoid MVCC_READ_CONFLICT when adding signatures

Current state
Signatures on Fabric are stored in a single key-value store and will cause MVCC_READ_CONFLICT if modified concurrently

Desired state
Change on-chain storage and according functions to avoid conflicts and allow for concurrent modification of different signatures.

Create Code of Conduct

In order to make BIF a welcoming community, where expectations are clear, we need a code of conduct document. This is largely expected to borrow from / reference the Hyperledger code of conduct, but should still have a reference within this repository.

Reapplying web3 patch for quorum crashes on npm install

Web3 node module is automatically patched during npm post-install. If web3 was already patched in a previous install the update will crash. temp.

Workaround: Remove the node modules before re-install

Change npm package scope to @hyperledger-labs

Received the recommendation on Rocket chat that we should publish under the labs scope when we are in the labs stage.
I raised the issue of migration effort and the answer was that it is acceptable to publish under multiple different names to save early adopters the headache.

Target new package scope:
@hyperledger-labs/blockchain-integration-framework

Once we graduate we can publish the same package under all these aliases in parallel if need be:
@hyperledger-labs/blockchain-integration-framework
@hyperledger/blockchain-integration-framework
and potentially of course whatever the final project name will end up being
@hyperledger/$FINAL_PROJECT_NAME

Security hardening of secrets

To split into issues per DLT

Production usage capability; discussion remaining on whether to solve within BIF or leave open for each consumer. Regardless should align with plug-in philosophy.

Continuous Monitoring of npm audit results

Tying the CI success to npm audit is not a good idea because the CI could then break without the source code having changed at all.
Instead have monitoring/alerting set up somehow (maybe as part of the CI script and a webhook/callout) or just as a sticker on the README.

Fix Eslint Errors

> @hyperledger-labs/[email protected] lint REDACTED_PATH/blockchain-integration-framework
> esw 'src/**/*.js' 'tests/*.js' 'examples/simple-asset-transfer/tests/*.js' 'examples/simple-asset-transfer/fabric/*.js' 'examples/simple-asset-transfer/quorum/*.js' --color


REDACTED_PATH/blockchain-integration-framework/tests/validator.js
  6:1  error  Expected 1 empty line after require statement not followed by another require  import/newline-after-import

REDACTED_PATH/blockchain-integration-framework/examples/simple-asset-transfer/tests/connector-quorum.js
   16:56  error  Delete `·`                                    prettier/prettier
   16:56  error  Unexpected space before function parentheses  space-before-function-paren
   17:45  error  Unexpected space before function parentheses  space-before-function-paren
   17:45  error  Delete `·`                                    prettier/prettier
   19:23  error  Unexpected space before function parentheses  space-before-function-paren
   19:23  error  Delete `·`                                    prettier/prettier
   36:42  error  Delete `·`                                    prettier/prettier
   36:42  error  Unexpected space before function parentheses  space-before-function-paren
   41:23  error  Unexpected space before function parentheses  space-before-function-paren
   41:23  error  Delete `·`                                    prettier/prettier
   47:43  error  Unexpected space before function parentheses  space-before-function-paren
   47:43  error  Delete `·`                                    prettier/prettier
   52:23  error  Unexpected space before function parentheses  space-before-function-paren
   52:23  error  Delete `·`                                    prettier/prettier
   58:65  error  Delete `·`                                    prettier/prettier
   58:65  error  Unexpected space before function parentheses  space-before-function-paren
   63:23  error  Unexpected space before function parentheses  space-before-function-paren
   63:23  error  Delete `·`                                    prettier/prettier
   69:48  error  Unexpected space before function parentheses  space-before-function-paren
   69:48  error  Delete `·`                                    prettier/prettier
   76:23  error  Unexpected space before function parentheses  space-before-function-paren
   76:23  error  Delete `·`                                    prettier/prettier
   83:59  error  Unexpected space before function parentheses  space-before-function-paren
   83:59  error  Delete `·`                                    prettier/prettier
   87:18  error  Unexpected space before function parentheses  space-before-function-paren
   87:18  error  Delete `·`                                    prettier/prettier
   93:57  error  Unexpected space before function parentheses  space-before-function-paren
   93:57  error  Delete `·`                                    prettier/prettier
   97:55  error  Unexpected space before function parentheses  space-before-function-paren
   97:55  error  Delete `·`                                    prettier/prettier
  105:59  error  Delete `·`                                    prettier/prettier
  105:59  error  Unexpected space before function parentheses  space-before-function-paren
  114:64  error  Unexpected space before function parentheses  space-before-function-paren
  114:64  error  Delete `·`                                    prettier/prettier
  118:18  error  Delete `·`                                    prettier/prettier
  118:18  error  Unexpected space before function parentheses  space-before-function-paren
  124:47  error  Unexpected space before function parentheses  space-before-function-paren
  124:47  error  Delete `·`                                    prettier/prettier
  139:56  error  Unexpected space before function parentheses  space-before-function-paren
  139:56  error  Delete `·`                                    prettier/prettier
  168:59  error  Unexpected space before function parentheses  space-before-function-paren
  168:59  error  Delete `·`                                    prettier/prettier
  177:60  error  Unexpected space before function parentheses  space-before-function-paren
  177:60  error  Delete `·`                                    prettier/prettier
  181:18  error  Unexpected space before function parentheses  space-before-function-paren
  181:18  error  Delete `·`                                    prettier/prettier
  191:70  error  Delete `·`                                    prettier/prettier
  194:44  error  Unexpected space before function parentheses  space-before-function-paren
  194:44  error  Delete `·`                                    prettier/prettier
  205:42  error  Unexpected space before function parentheses  space-before-function-paren
  205:42  error  Delete `·`                                    prettier/prettier
  216:59  error  Unexpected space before function parentheses  space-before-function-paren
  216:59  error  Delete `·`                                    prettier/prettier
  228:59  error  Unexpected space before function parentheses  space-before-function-paren
  228:59  error  Delete `·`                                    prettier/prettier
  232:18  error  Unexpected space before function parentheses  space-before-function-paren
  232:18  error  Delete `·`                                    prettier/prettier
  243:52  error  Delete `·`                                    prettier/prettier
  243:52  error  Unexpected space before function parentheses  space-before-function-paren
  251:60  error  Delete `·`                                    prettier/prettier
  251:60  error  Unexpected space before function parentheses  space-before-function-paren
  266:59  error  Unexpected space before function parentheses  space-before-function-paren
  266:59  error  Delete `·`                                    prettier/prettier
  279:56  error  Delete `·`                                    prettier/prettier
  279:56  error  Unexpected space before function parentheses  space-before-function-paren
  283:18  error  Delete `·`                                    prettier/prettier
  283:18  error  Unexpected space before function parentheses  space-before-function-paren
  289:51  error  Delete `·`                                    prettier/prettier
  289:51  error  Unexpected space before function parentheses  space-before-function-paren
  307:44  error  Delete `·`                                    prettier/prettier
  307:44  error  Unexpected space before function parentheses  space-before-function-paren
  316:59  error  Unexpected space before function parentheses  space-before-function-paren
  316:59  error  Delete `·`                                    prettier/prettier
  338:54  error  Unexpected space before function parentheses  space-before-function-paren
  338:54  error  Delete `·`                                    prettier/prettier
  356:24  error  Unexpected space before function parentheses  space-before-function-paren
  356:24  error  Delete `·`                                    prettier/prettier
  365:50  error  Unexpected space before function parentheses  space-before-function-paren
  365:50  error  Delete `·`                                    prettier/prettier
  372:63  error  Unexpected space before function parentheses  space-before-function-paren
  372:63  error  Delete `·`                                    prettier/prettier
  385:59  error  Unexpected space before function parentheses  space-before-function-paren
  385:59  error  Delete `·`                                    prettier/prettier
  400:56  error  Unexpected space before function parentheses  space-before-function-paren
  400:56  error  Delete `·`                                    prettier/prettier
  417:24  error  Unexpected space before function parentheses  space-before-function-paren
  417:24  error  Delete `·`                                    prettier/prettier
  426:50  error  Unexpected space before function parentheses  space-before-function-paren
  426:50  error  Delete `·`                                    prettier/prettier
  434:46  error  Delete `·`                                    prettier/prettier
  434:46  error  Unexpected space before function parentheses  space-before-function-paren
  441:45  error  Unexpected space before function parentheses  space-before-function-paren
  441:45  error  Delete `·`                                    prettier/prettier
  449:59  error  Unexpected space before function parentheses  space-before-function-paren
  449:59  error  Delete `·`                                    prettier/prettier
  458:53  error  Unexpected space before function parentheses  space-before-function-paren
  458:53  error  Delete `·`                                    prettier/prettier
  475:24  error  Unexpected space before function parentheses  space-before-function-paren
  475:24  error  Delete `·`                                    prettier/prettier
  484:36  error  Unexpected space before function parentheses  space-before-function-paren
  484:36  error  Delete `·`                                    prettier/prettier
  489:35  error  Unexpected space before function parentheses  space-before-function-paren
  489:35  error  Delete `·`                                    prettier/prettier
  497:59  error  Unexpected space before function parentheses  space-before-function-paren
  497:59  error  Delete `·`                                    prettier/prettier
  506:54  error  Unexpected space before function parentheses  space-before-function-paren
  506:54  error  Delete `·`                                    prettier/prettier
  510:18  error  Unexpected space before function parentheses  space-before-function-paren
  510:18  error  Delete `·`                                    prettier/prettier
  516:51  error  Delete `·`                                    prettier/prettier
  516:51  error  Unexpected space before function parentheses  space-before-function-paren
  535:49  error  Unexpected space before function parentheses  space-before-function-paren
  535:49  error  Delete `·`                                    prettier/prettier

REDACTED_PATH/blockchain-integration-framework/examples/simple-asset-transfer/fabric/connector.js
   5:1   error  Delete `⏎`                                                                                                                                                                           prettier/prettier
  17:11  error  Insert `;`                                                                                                                                                                           prettier/prettier
  21:36  error  Insert `⏎······`                                                                                                                                                                     prettier/prettier
  22:1   error  Insert `··`                                                                                                                                                                          prettier/prettier
  23:7   error  Insert `··`                                                                                                                                                                          prettier/prettier
  24:1   error  Replace `······` with `········`                                                                                                                                                     prettier/prettier
  25:5   error  Replace `},·{·...obj[omitKey]·})` with `··},⏎······{·...obj[omitKey]·}⏎····);`                                                                                                       prettier/prettier
  35:11  error  Insert `;`                                                                                                                                                                           prettier/prettier
  41:1   error  Line 41 exceeds the maximum line length of 120                                                                                                                                       max-len
  41:64  error  Replace `·dltId:·'dltID',·originDltId:·'originDLTId',·receiverPk:·'receiverPK'` with `⏎······dltId:·'dltID',⏎······originDltId:·'originDLTId',⏎······receiverPk:·'receiverPK',⏎···`  prettier/prettier

REDACTED_PATH/blockchain-integration-framework/examples/simple-asset-transfer/quorum/connector.js
  13:36  error  'item' is defined but never used  no-unused-vars

✖ 125 problems (125 errors, 0 warnings)
  123 errors and 0 warnings potentially fixable with the `--fix` option.

Stop Using --exit CLI option of Mocha for Test Execution

Tests should have a way to tear down themselves and the resources they allocate without having to use the --exit option of mocha which forcefully kills the process.
This behavior could hide issues implicitly that would be discovered through timeouts otherwise (for example lack of ability to gracefully terminate the software in general).

Source:
https://mochajs.org/#command-line-usage

--exit                     Force Mocha to quit after tests complete  [boolean]

Web3 Patching Typo

Describe the bug

The npm script doesn't return zero upon exit.

To Reproduce

Re-run ci.sh twice

Expected behavior

ci.sh works

Logs/Stack traces

Starting the SDK server ... REDACTED_PATH/blockchain-integration-framework/examples/simple-asset-transfer/fabric/scripts
7472
Initializing the network ...
[2019-11-18T18:36:08.522] [INFO] init-network - Naima enrolled Successfully
[2019-11-18T18:36:09.160] [INFO] init-network - Mike enrolled Successfully
[2019-11-18T18:36:10.229] [INFO] init-network - Hugo enrolled Successfully
[2019-11-18T18:36:10.971] [INFO] init-network - Luca enrolled Successfully
[2019-11-18T18:36:11.257] [INFO] init-network - Channel 'mychannel' created Successfully
[2019-11-18T18:36:21.430] [INFO] init-network - Successfully joined peers in organization Org1 to the channel:mychannel
[2019-11-18T18:36:21.786] [INFO] init-network - Successfully installed chaincode
[2019-11-18T18:36:31.852] [INFO] init-network - Successfully joined peers in organization Org2 to the channel:mychannel
[2019-11-18T18:36:32.160] [INFO] init-network - Successfully installed chaincode
[2019-11-18T18:38:27.578] [INFO] init-network - Successfully instantiate chaincode in organization Org1 to the channel 'mychannel'
+ cd ./quorum/api/
+ rm -rf ./node_modules/websocket/.git/
+ npm install

> @hyperledger-labs/blockchain-integration-framework.examples.simple-asset-transfer.quorum-api@0.1.0 postinstall REDACTED_PATH/blockchain-integration-framework/examples/simple-asset-transfer/quorum/api
> patch --verbose --force ./node_modules/web3-core-helpers/src/formatters.js ./web3_timestamp_fix.patch

Hmm...  Looks like a normal diff to me...
patching file ./node_modules/web3-core-helpers/src/formatters.js
Using Plan A...
Hunk #1 FAILED at 266.
1 out of 1 hunk FAILED -- saving rejects to file ./node_modules/web3-core-helpers/src/formatters.js.rej
done
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @hyperledger-labs/blockchain-integration-framework.examples.simple-asset-transfer.quorum-api@0.1.0 postinstall: `patch --verbose --force ./node_modules/web3-core-helpers/src/formatters.js ./web3_timestamp_fix.patch`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @hyperledger-labs/blockchain-integration-framework.examples.simple-asset-transfer.quorum-api@0.1.0 postinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/multipass/.npm/_logs/2019-11-19T02_38_40_111Z-debug.log

Screenshots

If applicable, add screenshots to help explain your problem.

Cloud provider or hardware configuration:
Are you running the software on a dev machine or somewhere in the cloud?

Operating system name, version, build:

Use this command: printf "$(uname -srm)\n$(cat /etc/os-release)\n"

For example

Linux 4.15.0-70-generic x86_64
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

BIF release version or commit (git rev-parse --short HEAD):

76a97af

BIF Plugins/Connectors Used

Fabric, Quorum

Additional context

This was a bug introduced while re-working code in response to reviews, silly mistake of mine.

Eliminate Need for Patching web3 Entirely

Describe the bug

Right now we have a very fragile patching mechanism in place for web3, best would be to not need it at all.
This is difficult because of how web3 works/implemented, but nevertheless we should look into solutions that are more robust and doesn't require line number based patching.

To Reproduce

Try to update the web3 dependency and observe that doing so may break BIF examples.

Expected behavior

Updating web3 (or any other dependency that abides by semantic versioning principles) should not break our code unless it was a major version upgrade.

Logs/Stack traces

Screenshots

Cloud provider or hardware configuration:
Are you running the software on a dev machine or somewhere in the cloud?

Operating system name, version, build:

Use this command: printf "$(uname -srm)\n$(cat /etc/os-release)\n"

For example

Linux 4.15.0-70-generic x86_64
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

BIF release version or commit (git rev-parse --short HEAD):

0.1.0

BIF Plugins/Connectors Used

fix(connector-quorum): linter error in Quorum contracts: security/no-inline-assembly

Depends on #334

Located in file:
src/pluggins/contracts/quorum/Root.sol

        assembly { len := mload(signs) }
        bool[] memory res = new bool[](len / signLen);
        uint index = 0;
        for (uint off = 0; off < len; off += signLen) {
            assembly {
                sign := add(signs, off)
                mstore(sign, 65) // signLen
            }
            address signer = recover(message, sign);
            res[index++] = ethToFValidator[signer] != address(0);
        }
        return res;

        // Divide the signature in r, s and v variables
        // ecrecover takes the signature parameters, and the only way to get them
        // currently is to use assembly.
        assembly {
            r := mload(add(signature, 0x20))
            s := mload(add(signature, 0x40))
            v := byte(0, mload(add(signature, 0x60)))
        }

cc: @hugo-borne

CI End to End Tests Not Operational

Describe the bug

npm run test:bc is not working.

To Reproduce

Run npm run test:bc observe failure.

Expected behavior

Tests are passing.

Logs/Stack traces

Bunch of host not reachable errors quoting localhost IP addresses (which is suspect because the containers have static, non-localhost private IPs.

Cloud provider or hardware configuration:
Dev machine and also in CI.

Operating system name, version, build:

Linux 4.15.0-70-generic x86_64
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

BIF release version or commit (git rev-parse --short HEAD):

v0.1.0

BIF Plugins/Connectors Used

Fabric, Quorum

Additional context

This is the continuation of the earlier issue related to CI: #36

WalletProxy.sol does not appear to be in the repo

In https://github.com/hyperledger-labs/blockchain-integration-framework/blob/master/src/pluggins/contracts/quorum/Root.sol, "contract Root is WalletProxy". The import implies WalletProxy is in the same directory. However, WalletProxy.sol is not in the directory.

Release v0.1.0-beta.rc.1

As per Hyperledger standards, only graduated projects can utilize version to 1.0+

When the import logic is finalized (smart contract, API, connector, tests and scenarios) on develop for Fabric and Quorum:

create a release branch: release/v0.1.0-beta.rc.1
re-test everything (tests, scenario ..)
upgrade dependencies
generate package-lock fix incoming bugs and create new tests if necessary (for import logic for example)
change the versions in the package.json merge release branch in develop and master

GitHub Issue Template Typo: User Stories reference BAF, not BIF

instantiate proposal resulted in an error

Doesn't always happen. When it does this is how it goes:

cd examples/simple-asset-transfer/

$ npm run fabric

> @hyperledger-labs/blockchain-integration-framework.examples.simple-asset-transfer@0.1.0 fabric /REDACTED/blockchain-integration-framework/examples/simple-asset-transfer
> cd fabric/scripts && ./start.sh

4000/tcp:            12171

Stopping peer1.org1.example.com ... done
Stopping peer0.org2.example.com ... done
Stopping peer1.org2.example.com ... done
Stopping peer0.org1.example.com ... done
Stopping ca_peerOrg2            ... done
Stopping ca_peerOrg1            ... done
Stopping orderer.example.com    ... done
Removing peer1.org1.example.com ... done
Removing peer0.org2.example.com ... done
Removing peer1.org2.example.com ... done
Removing peer0.org1.example.com ... done
Removing ca_peerOrg2            ... done
Removing ca_peerOrg1            ... done
Removing orderer.example.com    ... done
Removing network artifacts_default

ece5fece7250
51399562d912
f8622986b858
a81365dff541


Untagged: dev-peer0.org2.example.com-mycc-v1-355c3869dbdeb00af7c2dfeb05990f0fe3b1e87eb7a494ddec689e468087df2f:latest
Deleted: sha256:78bcd3ae860fa8cfe85524816237bb446101dffb7b9ecd61ead52c12cfd5762e
Deleted: sha256:edb8e174e95df0d4a6e59bd183206ee1bb1fbfdd8cceb8ae121ad06668e2d38f
Deleted: sha256:6bad450d8e5a09d301477f297c1615583f4d354edba6871676b9a0d7a6cfaf56
Deleted: sha256:47b25f3399230b05afa47c40c29657038ffe58a8b6705c612292ca5fb75317d3
Untagged: dev-peer1.org2.example.com-mycc-v1-d2bedf8545a99e60c83dff6b233903d5339e006f3c73b6b598611ac8ecceeea1:latest
Deleted: sha256:b33a905b1b6aeb608abebf433f0ccbe436a6b832eae28f316b343a6b06380c3e
Deleted: sha256:57de8f14f35c2c1d7d049d9384bd4be06255ef7d5818af9366341dbcc427b378
Deleted: sha256:1ac81559b9d6e7ba10e4569807c992f8679fd6b71aba48c97c90de0748003420
Deleted: sha256:c8198bebbf73f82af98604991f2c015f8380f28f9e268b99a0b3414530fe4a7b
Untagged: dev-peer0.org1.example.com-mycc-v1-2e8aae988c044f8defc1f175963163be4afda372a371605758993dbcd58f0411:latest
Deleted: sha256:ebefd1db6277fbfa43b15b5420db2a0757b2fef5714d988872256d125d359933
Deleted: sha256:1f997ce912c11570b4cd1c1a803ab8488563e889fd7c6bd93717673bc8201d43
Deleted: sha256:526989f9d6ee38645c7378fba21134495fa71870ff8710d6672c3b6d72c26565
Deleted: sha256:d17ea48c834c486ade174a8a5d8fabfa7d169988552e50c455e40bac5cd18d50
Untagged: dev-peer1.org1.example.com-mycc-v1-44e5460ab42b5b6dc9bbe3754df0e6d53c8cbd3ee340c3b5c41e86483014e2cb:latest
Deleted: sha256:b1cc0d8425ca5b6089ba24ced2c50b2139dcec682d503fb2dcd98a98ba4164d8
Deleted: sha256:0a78f2c479b71586bab48438d1a63b8cfe2e6f5386025c9c9fc9d4083cbfd89d
Deleted: sha256:ef2477285bf7db037e024e9400eb049b30cd6ba748f7e2b1a47174378e078cdd
Deleted: sha256:0110ca36ba5d3b814816e85c7e1f00b65b2759aaf42a7671fe679c32a653959e

Creating network "artifacts_default" with the default driver
Creating ca_peerOrg2            ... done
Creating orderer.example.com ... done
Creating ca_peerOrg1            ... done
Creating peer1.org1.example.com ... done
Creating peer0.org2.example.com ... done
Creating peer1.org2.example.com ... done
Creating peer0.org1.example.com ... done


============== Installing node modules =============
audited 22795 packages in 16.688s
found 1 low severity vulnerability
  run `npm audit fix` to fix them, or `npm audit` for details

Starting the SDK server ... /REDACTED/blockchain-integration-framework/examples/simple-asset-transfer/fabric/scripts
5537
Initializing the network ...
[2019-11-15T11:32:53.827] [INFO] init-network - Naima enrolled Successfully
[2019-11-15T11:32:54.226] [INFO] init-network - Mike enrolled Successfully
[2019-11-15T11:32:54.962] [INFO] init-network - Hugo enrolled Successfully
[2019-11-15T11:32:55.443] [INFO] init-network - Luca enrolled Successfully
[2019-11-15T11:32:55.626] [INFO] init-network - Channel 'mychannel' created Successfully
[2019-11-15T11:33:05.718] [INFO] init-network - Successfully joined peers in organization Org1 to the channel:mychannel
[2019-11-15T11:33:05.983] [INFO] init-network - Successfully installed chaincode
[2019-11-15T11:33:16.032] [INFO] init-network - Successfully joined peers in organization Org2 to the channel:mychannel
[2019-11-15T11:33:16.256] [INFO] init-network - Successfully installed chaincode
[2019-11-15T11:34:24.316] [ERROR] init-network - Error: Failed to instantiate the chaincode. cause:instantiate proposal resulted in an error :: Error: error starting container: error starting container: Failed to generate platform-specific docker build: Error executing build: API error (500): ttrpc: closed: unknown ""
    at /REDACTED/blockchain-integration-framework/examples/simple-asset-transfer/fabric/scripts/init-network.js:145:13
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @hyperledger-labs/blockchain-integration-framework.examples.simple-asset-transfer@0.1.0 fabric: `cd fabric/scripts && ./start.sh`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @hyperledger-labs/blockchain-integration-framework.examples.simple-asset-transfer@0.1.0 fabric script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/multipass/.npm/_logs/2019-11-15T19_34_24_329Z-debug.log
npm ERR! path /REDACTED/blockchain-integration-framework/examples/simple-asset-transfer/quorum/api/node_modules/websocket
npm ERR! code EISGIT
npm ERR! git /REDACTED/blockchain-integration-framework/examples/simple-asset-transfer/quorum/api/node_modules/websocket: Appears to be a git repo or submodule.
npm ERR! git     /REDACTED/blockchain-integration-framework/examples/simple-asset-transfer/quorum/api/node_modules/websocket
npm ERR! git Refusing to remove it. Update manually,
npm ERR! git or move it out of the way first.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/multipass/.npm/_logs/2019-11-15T19_34_35_411Z-debug.log

Refactor multisig error handling

Mulisig class do not behave like the rest of the code and do not throw errors when handled incorrectly and will just fail silently

Contribution of Corda Interopability

There is additional contribution of Corda Interoperability from Accenture to be merged into Github (pending Open Source scanning closure).

JWT expires and according logic

Current state
JWT are generated once at the first connector call with no expiration date or a very large one (>1 year). The same JWT are used for all communication with the validator's local Blockchain node

Desired state
JWT should expired on a more timely fashion, so that acquiring the JWT do not grant access to the validator's Blockchain nodes Note: Avoid imperative programming, suggestion to use RxJS streams that handle retries and renewal in a declarative fashion.

Document and enforce convention of exact npm dependency versions

Auto-upgrade (^) and wildcards (*) are bad because they violate the reproducible build best practice that states that a given state of the source code (any given git commit hash) always results in the same run time software byte by byte.

For critical security updates we need to depend on the CI environment executing npm audit and ensuring that the CI job fails if npm audit doesn't return all green.

Pull github repo for fabric-sdk

Current state
Local instance of the fabric SDK

Desired State
Pull the fabric sources from the Github repository or declare a git sub-module to a specific commit Goal: avoid manual replication in the local repo

Migrate Sources to Typescript

Migrate sources to Typescript to help plugin/connector developers.

Consider publishing *-api packages to npm, similar to conventions in Java where frequently there’s separate packages for implementation code and interface specifications.

Ask single signature

Implement a special mode for signature gathering.

In certain use cases, the participants should be able to ask for a single verification to a specific validator for testing purposes and to be able to bypass the validator's network if needs be.

docs: add Checklists for Dev, Release, Hot-fix

Checklist of checklists

New developer's checklist - steps from cloning to running example scenario
Release checklist - npm version, git tagging, npm publish, github release, code freeze(?)
Hot-fix release checklist - branch from tag, backport fix, rebase, versioning scheme, etc
PR merge checklist - make sure branch was rebased or rebase it right there and then

docs(identity): design Indy solution blueprint + add RFC

@hugo-borne to share materials
From there we will circulate ideas with the community to try and confirm interest & approach
Assuming there is sufficient community interest & buy-in, then will define roadmap scoping

Consortium Plugin - Indy: #675

node_modules/websocket: Appears to be a git repo or submodule.

When you follow the simple-asset-transfer example, starting the fabric DLT fails with the issue below.

Problem doesn't always manifest.

Workaround

Delete the .git directory of the problematic node module

rm -rf examples/simple-asset-transfer/node_modules/websocket/.git/

Solution Ideas

Maybe it fixes itself when we up the NodeJS version requirements (so new npm version) from forcing 8.x to 10.x, needs testing.

Crash log

$ npm run fabric

> @hyperledger/blockchain-integration-framework.examples.simple-asset-transfer@0.1.0 fabric /home/redactedusername/a/blockchain/blockchain-integration-framework/examples/simple-asset-transfer
> cd fabric/scripts && ./start.sh


Stopping peer1.org1.example.com ... done
Stopping peer0.org2.example.com ... done
Stopping peer1.org2.example.com ... done
Stopping peer0.org1.example.com ... done
Stopping ca_peerOrg1            ... done
Stopping ca_peerOrg2            ... done
Stopping orderer.example.com    ... done
Removing peer1.org1.example.com ... done
Removing peer0.org2.example.com ... done
Removing peer1.org2.example.com ... done
Removing peer0.org1.example.com ... done
Removing ca_peerOrg1            ... done
Removing ca_peerOrg2            ... done
Removing orderer.example.com    ... done
Removing network artifacts_default

========== No containers available for deletion ==========


========== No images available for deletion ===========

Creating network "artifacts_default" with the default driver
Creating orderer.example.com ... done
Creating ca_peerOrg1            ... done
Creating ca_peerOrg2            ... done
Creating peer0.org2.example.com ... done
Creating peer0.org1.example.com ... done
Creating peer1.org2.example.com ... done
Creating peer1.org1.example.com ... done


============== Installing node modules =============
npm ERR! path /home/redactedusername/a/blockchain/blockchain-integration-framework/examples/simple-asset-transfer/node_modules/websocket
npm ERR! code EISGIT
npm ERR! git /home/redactedusername/a/blockchain/blockchain-integration-framework/examples/simple-asset-transfer/node_modules/websocket: Appears to be a git repo or submodule.
npm ERR! git     /home/redactedusername/a/blockchain/blockchain-integration-framework/examples/simple-asset-transfer/node_modules/websocket
npm ERR! git Refusing to remove it. Update manually,
npm ERR! git or move it out of the way first.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/redactedusername/.npm/_logs/2019-11-05T19_50_11_296Z-debug.log

Starting the SDK server ... /home/redactedusername/a/blockchain/blockchain-integration-framework/examples/simple-asset-transfer/fabric/scripts
23015
Initializing the network ...
[2019-11-05T11:50:22.757] [ERROR] init-network - Error: failed TypeError: Cannot read property 'curve' of undefined
    at enroll (/home/redactedusername/a/blockchain/blockchain-integration-framework/examples/simple-asset-transfer/fabric/scripts/init-network.js:24:25)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @hyperledger/blockchain-integration-framework.examples.simple-asset-transfer@0.1.0 fabric: `cd fabric/scripts && ./start.sh`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @hyperledger/blockchain-integration-framework.examples.simple-asset-transfer@0.1.0 fabric script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/redactedusername/.npm/_logs/2019-11-05T19_50_22_771Z-debug.log

npm publish 0.1.0

Description

When I cut a release I want a simple script that publishes the package with the right version to npm.
For now this would be just the built-in npm publish itself but later we should have a single script generating the change logs and doing the publishing as well as the version bumping.

Acceptance Criteria

Have the forgotten 0.1.0 release published onto npm

Create contributing.md

In order to make BIF a welcoming community, where clarity on contribution process & expectations are clear, we need a contributing markdown file.

This document should minimum include:

References to documentation
Standards / quality gates
PR process

Examples / Fabric Script clean.sh Syntax Error

When trying to re-initialize the artifacts, the clean script fails.

Environment

$ printf "$(uname -srm)\n$(cat /etc/os-release)\n"
Linux 4.15.0-66-generic x86_64
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Logs

$ cd examples/simple-asset-transfer
$ ./fabric/scripts/clean.sh 
./fabric/scripts/clean.sh: line 1: syntax error near unexpected token `)'
./fabric/scripts/clean.sh: line 1: `docker rm -f $(docker ps -a | awk '{ print $1,$2 }' | grep "dev\|none\|test-vp\|peer[0-9]-" | awk '{print $1 }'))'

Rework mechanism to achieve quorum on signatures

Improve the existing gathering signature scheme to include a stronger mechanism for achieving quorum.

Current State

To gather all validators’ signatures, we define two roles:

Leader: responsible for gathering the signatures of other validators for a given data object and for electing the next leader among the list of alive validators.
Follower: verifies that some data the leader transmitted to him is valid then sends him its signature of the data when asked. It also answers the leader’s request for heartbeat proving that it is still running.

The process of gathering signatures is quite simple. The federation uses a publish/subscribe system to allow the leader to easily broadcast its requests to all the followers without knowing them one by one. Followers subscribe to the leader’s publishing stream whose address is known and fixed for a given period.

Once the signature request is received, each follower verifies that information to sign is valid and sends back its signature to the leader. The leader collects all the signatures for a period of time then sends them to either the follower or the client who asked for the signatures.

The signatures gathering process is started when a client1 asks a validator he knows for signatures corresponding to some given data. If the validator is a leader it starts the protocol and sends back the response to the client. Otherwise, the follower asks its leader to do the job and then relies the response the leader sends him to the client.

Leader election

The leader in the set of validators changes after a pre-defined period. We’ve chosen to implement a simple protocol to elect the next leader. It’s the responsibility of the current leader to pick its successor among the set of alive followers.

The leader first broadcasts a Heartbeat request to the followers. Once received, each follower sends back a heartbeat message, including its coordinates, to inform the leader that it’s alive. The leader waits some time to get all followers answers, after which remaining ones are considered dead, then randomly picks the next leader from the set of alive ones.

NB. We are not yet handling the fact that a leader can get down before electing its successor. This can be fixed by adding a third role that would be a vice-leader to replace the leader when the later gets down.

It then broadcasts the coordinates of the new leader to inform the followers. After that all the validators including the leader either:

Switch from leader to follower
Switch from follower to leader
Start following the new leader

Signatures

For signatures we are using the ECDSA secp256k1 elliptic curve and sha3 (256) to hash data to 32 bytes prior to generating its signature.

Every validator generates a pair of keys (public, private) at setup and stores them locally. The public keys are also stored in an identity system (Not yet implemented) that associates organizations’ DLTs with the set of their transfer validators public keys. This system allows any body to retrieve them any time

_Will leverage existing consensus mechanism from external software (investigating etcd and add in distributed lock for time to live. _

Add Scenarios to Travis CI

chore: continuous deployment and releases

The release process should be as automated as possible.
One manual chore of issuing a release right now is to write a change log, but that can be automated with tooling and a strict convention on commit messages that allows the tooling to automatically gather up meaningful changes from the commit log and dump them in a designated file (CHANGELOG.md)

https://github.com/conventional-changelog/conventional-changelog

https://github.com/commitizen/cz-cli

Create v0.1.0 Release

docs(examples): add a Hyperledger Bevel Example

Description

As a user I want to have a working example that uses Bevel to pull up an environment so that I have well maintained tooling taking care of the infrastructure from day one of my exploratory journey while checking out what BIF can do and once I decide to adopt BIF I can roll it out in production with the Bevel tooling I'm already comfortable with since that's how I got started to begin with (instead of the partially hand-rolled scripts we currently have for the examples)

Potential dependencies:

Does Bevel work on microk8s as of right now? If yes we can probably make the end to end test happen with our github actions running on Ubuntu VMs.

Acceptance Criteria

examples/Bevel directory exists and it has a documented, Bevel backed clonse of the current state of the art which is in examples/simple-asset-transfer
CI also covers the Bevel example. This may be hard given that TravisCI has only 8GB RAM and 2 vCPUs

                       === npm audit security report ===                        

┌──────────────────────────────────────────────────────────────────────────────┐
│                                Manual Review                                 │
│            Some vulnerabilities require your attention to resolve            │
│                                                                              │
│         Visit https://go.npm.me/audit-guide for additional guidance          │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Insecure Credential Storage                                  │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ web3                                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ No patch available                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ web3                                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ web3                                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/877                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Denial of Service                                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ mem                                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.0.0                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ npm-check [dev]                                              │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ npm-check > depcheck > yargs > os-locale > mem               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/1084                      │
└───────────────┴──────────────────────────────────────────────────────────────┘

Support NodeJS 10.x, 12.x

The current LTS NodeJS versions should always be supported in general.

Need to have the CI set up before we can move with this. For the CI progress watch: #13

hyperledger / cacti Goto Github PK

cacti's Introduction

Hyperledger Cacti

Scope of Project

Documentation

Roadmap

Inclusive Language Statement

Contact

Contributing

License

cacti's People

Contributors

Stargazers

Watchers

Forkers

cacti's Issues

Description

Acceptance Criteria

Description

Acceptance Criteria

Checklist of checklists

Workaround

Solution Ideas

Crash log

Description

Acceptance Criteria

Environment

Logs

Current State

Leader election

Signatures

Description

Acceptance Criteria

Recommend Projects

Recommend Topics

Recommend Org