ethereum-oasis-op / baseline Goto Github PK

Expected Behavior

build respects http_proxy environment variable

Actual Behavior

build ignores http_proxy variable (to be more specific: node-fetch ignores the variable)

> [email protected] build:contracts /home/digits/src/baseline/radish34
> pushd contracts && npm run build && popd

~/src/baseline/radish34/contracts ~/src/baseline/radish34

> [email protected] build /home/digits/src/baseline/radish34/contracts
> sol-compiler

{ FetchError: request to https://ethereum.github.io/solc-bin/bin/list.json failed, reason: connect ETIMEDOUT 185.199.111.153:443
    at ClientRequest.<anonymous> (/home/digits/src/baseline/radish34/contracts/node_modules/node-fetch/index.js:133:11)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at TLSSocket.socketErrorListener (_http_client.js:401:9)
    at emitOne (events.js:116:13)
    at TLSSocket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:66:8)
    at _combinedTickCallback (internal/process/next_tick.js:139:11)
    at process._tickCallback (internal/process/next_tick.js:181:9)
  name: 'FetchError',
  message: 'request to https://ethereum.github.io/solc-bin/bin/list.json failed, reason: connect ETIMEDOUT 185.199.111.153:443',
  type: 'system',
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT' }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `sol-compiler`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build 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/digits/.npm/_logs/2020-04-01T15_13_49_337Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build:contracts: `pushd contracts && npm run build && popd`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build:contracts 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/digits/.npm/_logs/2020-04-01T15_13_49_349Z-debug.log
make: *** [Makefile:23: contracts] Error 1

There's an issue for node-fetch to respect the env variable, but in one of the answers it says, that node-fetch is the wrong abstraction level for that. So it seems when you're using node-fetch you have to implement the proxy settings in JS yourself.

A better solution is probably to download the contracts in sol-compiler in a different way than using the node-fetch, e.g. curl does quite a good job, is widely available, and respects the http_proxy env variable.

Steps to Reproduce the Problem

1. export http_proxy=...; export https_proxy=$http_proxy
2. make

Specifications

• Version: master branch (2020/03/31)
• Platform: Linux/x64
• Subsystem: RHEL7

Overview

Currently the integration test suite (run by make test) takes several minutes to complete. All tests take less than a second, except for two tests that make calls to the zkp /generateProof endpoint.

Reference

The generation of the proof is very time consuming. Your laptop has to whir away through lots of tedious elliptic curve operations for minutes. It’s nothing to do with the blockchain. Once the proof is generated (within the zokrates container), the act of sending the proof to the shield contract as a blockchain transaction is very quick (especially when using ganache).

Note: the periodic "socket hangup" issue that produces test failures is caused by the long process time of POST /generateProof. This should be solved by replacing that http REST call with bulljs queues. That work is currently on the "development" branch and will be eventually merged into "master"

Potential solution

What we could do is create a set of lazy dummy arithmetic circuits (i.e. dummy files for createMSA.zok and createPO.zok where the body of the function just contains a dummy line of useless code). This would make testing much faster. Developers would just have to be cautious when editing any of the backend zkp code (in case they break the "proper" .zok files).

Note: createMSA.zok and createPO.zok are already quite ‘simplified’ to reduce proving time, because the merkle tree being used only has 16 leaves (which takes a minute or two to generate the proof) , rather than 4 billion (which takes around 5 minutes).

We could use the "dummy" circuits for integration testing and use the "real" circuits for unit testing of the zkp service.

Overview

As a developer (admin/general) user, I would like to abstract components of interaction across the different microservices in a modular manner. To this extent, leverage the queuing system to establish a reusable process for managing workers and job queues for complex system to system interaction. Currently, the only process that deals with the queues, is the interaction of api with messenger on radish34. The purpose of this feature request is to abstract interactions to a modular workflow, where in each step in a workflow can be represented in terms of API -> Messenger; API -> ZKP -> Blockchain -> Messnger; etc.

Here is a general suggested outlay of workflow steps:
Workgroup = set of orgs defined in the orgRegistry set up as a group of participants in a business relationship
Workflow = the series of things a set of counterparties agreed upon as a process flow. For example, in the case of Radish34, it is RFP -> MSA -> PO.
Step = A single baselined Record/Function/BusinessEvent/Document (e.g,. RFP, MSA, PO) process in a workflow
Tasks = A series of jobs which can be a composition of multiple interactions or system actions that constitute a step or span across multiple tests. Example in the case of an MSA step is: select a set of counterparties, serializing a record, sending messages, executing off-chain functions (not in Radish34, but definitely in protocol-compliant stack), executing and sending/receiving EdDSA sigs, invoking ZK service, ensuring that the ZK circuit (or a code package/container in a non-Radish34 implementation) of a previous Step is executed correctly, etc.

Note that some of this work has been begun on a development branch on this repo

Reference

• MSA Process Abstraction
• Baseline Queue

Questions

Assumptions

Acceptance

• Successfully run integration tests on radish34 master

Tasks

• Complete MSA process in radish34 as an extension of a baseline workflow mechanism
• Comple PO process in radish34

**Disclaimer: This is a broad stroke and a sample feature request. It would need to be further updated (potentially broken down into further feature requests), based on discussions with other members of the Oasis community

Overview

As a procurement user, I would like to leverage Baseline protocol and the reference implementation in Radish34 to manage tokens (NFT and FT) on the mainnet in a private manner

Reference

• [Smart contract management]#19

Questions

• Which industry standards can be used to generalize the schema for procurement components?

Assumptions

Acceptance

• Test cases for token management (unit and integration) are successfully run

Tasks

• Develop system interaction components (api, zkp, contracts) to manage ERC1155 tokens
• Develop custom data integration schemas to interface with the api

**Disclaimer: This is a broad stroke and a sample feature request. It would need to be further updated (potentially broken down into further feature requests), based on discussions with other members of the Oasis community

Expected Behavior

docker-compose run --rm deploy sh deploy.sh should complete successfully.

Actual Behavior

Error

Steps to Reproduce the Problem

note: Some build steps had to be updated because pushd/popd wasn't working in npm scripts on Ubuntu.

1. build steps for Ubuntu are here: https://github.com/splunk/baseline/tree/integrate-splunk#ubuntu

Specifications

• Version:
• Platform: Ubuntu 18, Node.js v11, Docker 19.03.8
• Subsystem:

> [email protected] deploy /home/jayson/Code/baseline/radish34
> docker-compose run --rm deploy sh deploy.sh

WARNING: Found orphan containers (splunk, cadvisor) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating redis-supplier2    ... done
Creating redis-supplier1    ... done
Creating geth-bootnode      ... done
Starting mongo-buyer     ... done
Creating mongo-supplier1    ... done
Creating mongo-supplier2    ... done
Creating radish34_ganache_1 ... done
Starting zkp                ... done
Creating redis-buyer        ... done
Creating geth-miner1        ... done
Creating geth-miner2        ... done
Creating geth-node          ... done
Creating messenger-buyer     ... done
Creating messenger-supplier1 ... done
Creating messenger-supplier2 ... done
Patiently waiting 10 seconds for ganache container to init ...
Checking for ganache ...
✅  ERC1820Registry deployed: 0x448de9B34ac4DD0901DCc3f2fF1a31822B51a397
✅  OrgRegistry deployed: 0x31088fd0eede771d5bda1558e06a666Cd9BF110c
✅  BN256G2 library deployed: 0x8f17969A8dc9cbAe2EB98541F33c7c396f615241
✅  Verifier deployed: 0xDf3C747B74CeFe4ffEa5baa2D0eAFE2B0F86A8F3
✅  Shield deployed: 0x7370f1C710F3af6f28Be19ed99e0ed8f1B59b1CB
(node:8) UnhandledPromiseRejectionWarning: Error: incorrect number of arguments
    at Contract.assignManager (/app/node_modules/ethers/contract.js:130:19)
    at Object.assignManager (/app/src/utils/organization.js:29:39)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async assignManager (/app/src/deploy.js:39:31)
    at async main (/app/src/deploy.js:115:3)
(node:8) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:8) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Depends on #88

Based on the mini-library described above a deployment (for now) CLI can be created. The CLI can become part of the baseline and Radish contracts deployment procedure.

The CLI will be non-interactive - it will expect parameters to be externally output via comand line parameters.

It will have several commands available. Working example of two commands would be:

• deploy-client - for deployment of client contracts
• deploy-protocol - for deployment of protocol contracts

Both of these commands will probably have their own separate set of parameters, but some of the common ones would be:

• deployer private key
• URL to mainnet node

etc.

Expected Behavior

Compute Witness & Generate Proof should succeed.

Actual Behavior

Compute Witness doesn't save createMSA_witness file and proof generation fails.

Steps to Reproduce the Problem

1. create contract through front end

Specifications

error:

Compute witness...
Generate proof...
Error: Generate proof failed: thread 'main' panicked at 'couldn't open ./output/createMSA/createMSA_witness: No such file or directory (os error 2)', zokrates_cli/src/bin.rs:499:29
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
at Socket.zokrates.stderr.on.err (/app/node_modules/@eyblockchain/zokrates.js/lib/generate-proof.js:85:14)

i went into the container to look for the file and it is indeed not there.

root@db7db09ed294:/app/output/createMSA# ls -la
total 452904
drwxr-xr-x 7 root root       224 Mar 20 17:53 .
drwxr-xr-x 4 root root       128 Mar 20 17:53 ..
-rw-r--r-- 1 root root     25090 Mar 20 20:52 Verifier_createMSA.sol
-rw-r--r-- 1 root root  73119989 Mar 20 20:50 createMSA_out
-rw-r--r-- 1 root root  44069790 Mar 20 20:50 createMSA_out.ztf
-rw-r--r-- 1 root root 335299968 Mar 20 20:52 createMSA_pk.key
-rw-r--r-- 1 root root      1486 Mar 20 20:52 createMSA_vk.key

• Version:
• Platform: macOS 10.15, docker 2.2.0.4
• Subsystem:

• Combine the folders for contracts/ and deploy/
• One stop for compiling and deploying contracts
• Additional test cases to cover functionality in Shield.sol
  • Need a test for createPO in Shield.test.js
• Capture gas consumption during network interaction
• Remove the need for redundant utils across the repo (use axios for mocking test data)

Overview

As a developer for better release management, and targeted software delivery processes, I would like to leverage a full fledged test suite and infrastructure management framework. Maintenance of build, test, and publish a Baseline utility or application extension can be better managed and handled through a CI/CD pipeline.

Reference

• Github Actions
• Travis CI
• Linting

Questions

• Which tool of choice for building Ci/CD pipelines?
• How to consider variability of options for using custom CI/CD tools?

Assumptions

Acceptance

• Unit tests for api, ui, zkp, messenger are updated/created and successfully tun
• Integration tests are updated for queue based management
• Semantic release management is built into the repo
• Automate package builds integrated with github packages

Tasks

• Develop test case suite (integration and unit) based on different steps in the workflow
• Update docker images to Dockerhub to handle concerns around layer caching and compute intensive, high latency tasks
• Build CI/CD pipeline and associated scripts for semantic release management

**Disclaimer: This is a broad stroke and a sample feature request. It would need to be further updated (potentially broken down into further feature requests), based on discussions with other members of the Oasis community

Expected Behavior

*** Running setup for createPO ***
{"verificationKey":{"H":[["0x2d5f6d4b7d13b5cebd8d6cece9dbce5ecb04d3ea80217e0426c2b1d72c2d972d","0x02ff4a4667c3fead0b270277aba0fef1a8f2e94e85b160d19385c089ac7cf501"],["0x25ddb0f3266fc2b2efefa6247f24355a327353f6ccfb5ca9fb5ab1352370a21b","0x1c078f4b5447ef774133731e301b43a9c8657123409333efffa74486a86fb47f"]],"Galpha":["0x0d36fc5d69ce3f50ec40bb9d3540fb1d898a2f91d48932bf55cfcb304af635e3","0x1a555461b3ac218af5fca356d75b9d0eecce6bb8d44aab275141e1a980077a67"],"Hbeta":[["0x29a47d9266d3a915ba517cd2d099ef4872c568d86d69c63ff5fa55aa7a5f6284","0x1125edf840c07eda41a962f71f1e0d8b4c0052587c6b6918ebb3a267c43b6255"],["0x2d15aefb7f2a3374e28671f5b4b5dc1db80660656b16fd81953a6104a95b61ef","0x2e43d6f090a7402b948824568e69a956646a8ddc79eba4bfad65da4863663ce5"]],"Ggamma":["0x11cf0010dc05657a0933a3366efab90a055ef76c926af3c94cd79df0daace624","0x138c005e154787838b851afc869be363e089b2e3786c197c1a7a7f8023e2adcf"],"Hgamma":[["0x267470583b8333a4c8b81331d12d6badfd49c416810fd23006ec393f812c8a56","0x14321eed994c76846d2b8b532e7995d3cb76c022ab05af426a99e98a53076779"],["0x0cfcd3abdf0119481374bf209c71f7afcd8920b85de0e95294933ddd3c16c92a","0x23871104deb8a7c03efaf1ede048dd9f968b4602ea7f824a5c8d4aaa1e6f4143"]],"query":[["0x1a7251f3ac3930802d03eae0f4d8187a62bcf752b33cedd98defe74ddc07cd8f","0x06a13bbc659fae79a8e0ab7fa474d4ae451d42633116e42e17334ee21a847fc5"],["0x26620d77c65980fb18256ee17bc0e80adc30ddb4c54cd61154432d713889ea33","0x237af6ad935a45192f8a279e3543bca9b04aa547d16501c3c164c9ef38ad59c0"]]}}

Actual Behavior

Error: export-verifier verifying key file not found
   at Object.exportVerifier (/app/node_modules/@eyblockchain/zokrates.js/lib/export-verifier.js:29:11)
   at _callee$ (/app/src/routes/generateKeys.js:30:20)
   at tryCatch (/app/node_modules/regenerator-runtime/runtime.js:45:40)
   at Generator.invoke [as _invoke] (/app/node_modules/regenerator-runtime/runtime.js:274:22)
   at Generator.prototype.(anonymous function) [as next] (/app/node_modules/regenerator-runtime/runtime.js:97:21)
   at asyncGeneratorStep (/app/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)
   at _next (/app/node_modules/@babel/runtime/helpers/asyncToGenerator.js:25:9)
   at processTicksAndRejections (internal/process/task_queues.js:86:5)

Steps to Reproduce the Problem

1. Follow readme steps until step 4
2. runs npm run setup

Specifications

• Version: latest
• Platform: MacOs 10.15.4
• Subsystem: node -v -> v11.15.0 || npm -v 6.7.0

Overview

As a developer using the Radish34 demo, such that I can reliably and repeatedly bring up the system, create a set of health checks for each service that test their readyness to be used. Tie these health checks into the docker compose file so service health can be reported.

Reference

• Tutorial on health checks
• Docker health check docs

Assumptions

• We will be able to setup dependencies in the docker-compose and health checks such that one liners like this make && make start && make test will reliably run.
• This work will help with CI because we'll need to have a reliable and un-attended way to bring up the system to a testable state.

Acceptance

• Using docker ps view all the services that are up and their health status
• Setup docker compose to use the 'healthy' flag to gate the running of tests/system health

Tasks

• Setup health checks on all services that look for process status AND key files needed for the demo
• Integrate health checks with docker compose
• Run repeated (at least 5 times in a row) system setup/teardown w/o failure

Overview

As a proper system, so I can be compliant with log level support, install a logging framework (like Winston) and remove all usages of the generic console.log. Replace them with appropriate 'info', 'warn', 'error', 'debug' level logging calls.

Assumptions

• We will use the same logging format across all services
• The logs for HTTP requests vs system calls should be handled
• Log tracing is not required at this point but would be nice
• Log rotation/truncation is out of scope
• Logs should in their own folder and added to gitignore

Acceptance

Minimum effort is to

• install logger framework
• remove console.logs and replace the log call with the appropriate level 'info' 'warn' 'debug' etc...
• adjust environment configs to the appropriate log level (e.i. 'debug' in development, 'info' in production)
• update documentation on how to view access the log files
• adjust logging format for all services such that they are the same.

Ideal logging format is
[UTC timestamp] [service name] [host] -

Expected Behavior

I don't know I could not see next page

Actual Behavior

After access http://radish34-ui.docker/ select buyer account and buyer role and try push next button it does not move forward and at JS Console error I got this message:

Warning: An unhandled error was caught from submitForm() Error: Network error: Response not successful: Received status code 400
at new ApolloError (ApolloError.ts:46)
at Object.error (QueryManager.ts:255)
at notifySubscription (Observable.js:140)
at onNotify (Observable.js:179)
at SubscriptionObserver.error (Observable.js:240)
at observables.ts:15
at Set.forEach ()
at Object.error (observables.ts:15)
at notifySubscription (Observable.js:140)
at onNotify (Observable.js:179)
at SubscriptionObserver.error (Observable.js:240)
at httpLink.ts:184

Steps to Reproduce the Problem

1. Start radish
2. Access http://radish34-ui.docker/
3. Select Buyer account
4. At Connect to registry select buyer role
5. Push Next button

Specifications

• Version:
• Platform:
• Subsystem:

Expected Behavior

UI container comes up with make start

Actual Behavior

UI container exits

Steps to Reproduce the Problem

1. Clone the repo, latest master branch
2. cd baseline and make && make deploy-contracts
3. make start
4. cd radish34 and docker-compose logs -f ui and you'll see the error (included below).

Specifications

• Version:

➜  radish34 git:(master) npm --version
6.7.0
➜  radish34 git:(master) node --version
v11.15.0
➜  radish34 git:(master) docker --version
Docker version 19.03.8, build afacb8b

• Platform:

➜  radish34 git:(master) sw_vers
ProductName:	Mac OS X
ProductVersion:	10.15.4
BuildVersion:	19E266

• Subsystem: N/A

Logs

➜  radish34 git:(master) docker-compose logs -f ui
Attaching to radish34_ui_1
ui_1                   | 
ui_1                   | > [email protected] start /app
ui_1                   | > react-scripts start
ui_1                   | 
ui_1                   | 
ui_1                   | There might be a problem with the project dependency tree.
ui_1                   | It is likely not a bug in Create React App, but something you need to fix locally.
ui_1                   | 
ui_1                   | The react-scripts package provided by Create React App requires a dependency:
ui_1                   | 
ui_1                   |   "jest": "24.9.0"
ui_1                   | 
ui_1                   | Don't try to install it manually: your package manager does it automatically.
ui_1                   | However, a different version of jest was detected higher up in the tree:
ui_1                   | 
ui_1                   |   /app/node_modules/jest (version: 24.8.0) 
ui_1                   | 
ui_1                   | Manually installing incompatible versions is known to cause hard-to-debug issues.
ui_1                   | 
ui_1                   | If you would prefer to ignore this check, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
ui_1                   | That will permanently disable this message but you might encounter other issues.
ui_1                   | 
ui_1                   | To fix the dependency tree, try following the steps below in the exact order:
ui_1                   | 
ui_1                   |   1. Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
ui_1                   |   2. Delete node_modules in your project folder.
ui_1                   |   3. Remove "jest" from dependencies and/or devDependencies in the package.json file in your project folder.
ui_1                   |   4. Run npm install or yarn, depending on the package manager you use.
ui_1                   | 
ui_1                   | In most cases, this should be enough to fix the problem.
ui_1                   | If this has not helped, there are a few other things you can try:
ui_1                   | 
ui_1                   |   5. If you used npm, install yarn (http://yarnpkg.com/) and repeat the above steps with it instead.
ui_1                   |      This may help because npm has known issues with package hoisting which may get resolved in future versions.
ui_1                   | 
ui_1                   |   6. Check if /app/node_modules/jest is outside your project directory.
ui_1                   |      For example, you might have accidentally installed something in your home folder.
ui_1                   | 
ui_1                   |   7. Try running npm ls jest in your project folder.
ui_1                   |      This will tell you which other package (apart from the expected react-scripts) installed jest.
ui_1                   | 
ui_1                   | If nothing else helps, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
ui_1                   | That would permanently disable this preflight check in case you want to proceed anyway.
ui_1                   | 
ui_1                   | P.S. We know this message is long but please read the steps above :-) We hope you find them helpful!
ui_1                   | 
ui_1                   | npm ERR! code ELIFECYCLE
ui_1                   | npm ERR! errno 1
ui_1                   | npm ERR! [email protected] start: `react-scripts start`
ui_1                   | npm ERR! Exit status 1
ui_1                   | npm ERR! 
ui_1                   | npm ERR! Failed at the [email protected] start script.
ui_1                   | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
ui_1                   | 
ui_1                   | npm ERR! A complete log of this run can be found in:
ui_1                   | npm ERR!     /root/.npm/_logs/2020-03-28T00_17_26_654Z-debug.log
radish34_ui_1 exited with code 1

Expected Behavior

Running npm i && npm run postinstall should take about 6 minutes to clean install npm packages in root and all sub directories **

Actual Behavior

The following error is returned:

npm ERR! missing script: postinstall

Steps to Reproduce the Problem

1. Open terminal and move into radish34 folder
2. run npm i && npm run postinstall

Specifications

• Version:
• Platform: Mac OSx Catalina
• Subsystem:

Expected Behavior

Following the documentation, and running npm run setup the script successfully generates the zk material for createMSA, but fails to do so for createPO. I expect both to work as per the documentation.

Actual Behavior

CreateMSA goes through successfully, but createPO fails with the following found in the zkp container logs:

Error: export-verifier verifying key file not found
    at Object.exportVerifier (/app/node_modules/@eyblockchain/zokrates.js/lib/export-verifier.js:29:11)
    at _callee$ (/app/src/routes/generateKeys.js:30:20)
    at tryCatch (/app/node_modules/regenerator-runtime/runtime.js:45:40)
    at Generator.invoke [as _invoke] (/app/node_modules/regenerator-runtime/runtime.js:274:22)
    at Generator.prototype.(anonymous function) [as next] (/app/node_modules/regenerator-runtime/runtime.js:97:21)
    at asyncGeneratorStep (/app/src/routes/generateKeys.js:22:103)
    at _next (/app/src/routes/generateKeys.js:24:194)
    at processTicksAndRejections (internal/process/task_queues.js:86:5)

Steps to Reproduce the Problem

Follow the steps for running the demo until step 4.

Expected Behavior

Assigned the deployer as the manager for OrgRegistry. TxHash: 0x1689ac60fba5c25b5559e0fbca066c4063a433dec552adc9208977e161f05852

Actual Behavior

Patiently waiting 10 seconds for ganache container to init ...
Checking for ganache ...
(node:9) UnhandledPromiseRejectionWarning: Error: incorrect number of arguments
at Contract.assignManager (/app/node_modules/ethers/contract.js:130:19)
at Object.assignManager (/app/src/utils/organization.js:29:39)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async assignManager (/app/src/deploy.js:39:31)
at async main (/app/src/deploy.js:115:3)

Steps to Reproduce the Problem

1. Follow setup instructions until step 6

Specifications

• Version: latest
• Platform: MacOs 10.15.4
• Subsystem: node version v11.15.0

Running a fresh install of Radish and going through the flow of the UI, I encounter an error when trying to create MSA. The app throws generic GraphQL error. Nothing meaningful is seen in the API logs though.

Error In the browser:

Unhandled GraphQL subscription error Error: GraphQL error: Cannot query field "organizations" on type "PartnerPayload".
GraphQL error: Cannot query field "myPartners" on type "PartnerPayload". Did you mean "partner"?

API Buyer Logs:

Received new document of type proposal_create. Parsing now...
api-buyer              | Saving new Proposal (id: 461bf86e-fd79-46e3-a7da-44cac49c6796) from partner...
api-buyer              | Getting server settings:
api-buyer              | http://ganache:8545
api-buyer              | { messengerKey:
api-buyer              |    '0x04d788f521b36fd9ffeac1682a9f544af76c1ece33736a1b4b3cc25dd992a9cf09fe69d9ece791d0f961276876bd35990e2d5c01dfdfea2a25a20f6c81b8412cb2',
api-buyer              |   name: 'Org1',
api-buyer              |   role: 1,
api-buyer              |   zkpPublicKey:
api-buyer              |    '0x21864a8a3f24dad163d716f77823dd849043481c7ae683a592a02080e20c1965',
api-buyer              |   zkpPrivateKey:
api-buyer              |    '0x29ae268c4e58726d63fb5b0dae75e8d70f77519d12063f1a8fa9ebec085e533d',
api-buyer              |   address: '0xB5630a5a119b0EAb4471F5f2d3632e996bf95d41' }
api-buyer              | { ERC1820Registry: '0x8c245F84a017bb8E7cE9a09bc217bA881fE1B763',
api-buyer              |   OrgRegistry: '0x3d6a2161011047D349B079e2aBFF1EEC3b21f892',
api-buyer              |   Verifier: '0x325E2408388f7dA33a8FB1cA0d9e5cE8567045D9',
api-buyer              |   Shield: '0xb96a2317e8f581e6Caa1e9e602dD39fEf381d855',
api-buyer              |   BN256G2: '0x8f17969A8dc9cbAe2EB98541F33c7c396f615241' }

Important further clarification: All unit tests pass properly. I can see the data from the unit tests in the UI.

Overview

As a developer, I would like to make sure that the codebase is linted using best practices for maintaining and managing well styled code. Currently, the api/, radish34/, messenger/, have varying linting settings making it difficult to have a consistent linter. In addition, the solidity contracts in contracts/ are not fully linted, and might need to re-consider replacing solhint with ethlint

Reference

• Linting and compilation scripts
• ESLint Config
• Ethlint
• Solhint

Questions

Assumptions

Acceptance

• Script to lint, fix, and validate code after linting .js and .sol files
• Pre-commit hooks are updated to check linting prior to commits

Tasks

• Update linter spec for radish34/
• Run build and deployment scripts

**Disclaimer: This is a broad stroke and a sample feature request. It would need to be further updated (potentially broken down into further feature requests), based on discussions with other members of the Oasis community

Expected Behavior

successful start

Actual Behavior

Start dotdocker containers
> Start proxy
√ Pulling codekitchen/dinghy-http-proxy:latest
\ Creating dotdocker-proxy
Starting dotdocker-proxy
> Start dnsmasq
√ Pulling andyshinn/dnsmasq:latest
× Creating dotdocker-dnsmasq
→ (HTTP code 404) no such container - No such image: andyshinn/dnsmasq:latest

Steps to Reproduce the Problem

Specifications

• Version:
• Platform:
• Subsystem:

Expected Behavior

The Verifier.verify() function, not the function that calls it (i.e. Shield.createMSA() and Shield.createPO(), should require that each public input to the snark is less than the scalar field:

21888242871839275222246405745257275088548364400416034343698204186575808495617

Actual Behavior

While the Shield.createMSA() and Shield.createPO() functions may not be vulnerable due to the way they hash some variables and check if the single public input matches the hash, other circuits in the future may be vulnerable if the developer does not do the required check.

To avoid this problem entirely, perform the check in the Verifier.verify() function. This bugfix should probably be done upstream in the Nightfall repository.

See also:

semaphore-protocol/semaphore#16

https://github.com/EYBlockchain/nightfall/pull/96

Expected Behavior

contracts should deploy successfully

Actual Behavior

contract deployment fails

Steps to Reproduce the Problem

1. make
2. make deploy-contracts

Specifications

• Version: latest
• Platform: macOS 10.15, docker 2.2.0.4
• Subsystem:

output from make deploy-contracts

✅  ERC1820Registry deployed: 0x48518130D429cbbfeaB451589804e3f06e771b22
✅  OrgRegistry deployed: 0x361cDE6eBCE28366d838F4Ec0E2E567EC79de58D
✅  BN256G2 library deployed: 0xF5eC22d79357f5F301A4B03481Df21D219231B62
✅  Verifier deployed: 0x36670e25a536496F889E732e53f21092A4e302A7
✅  Shield deployed: 0xe249E1Fb19fab52A406fa4dC62104269517199ea
✅  Assigned the deployer as the manager for OrgRegistry. TxHash: 0xb0b707b266c77d8cc45d3e215640e47eb93d2f878730b2fb4407b3097b3bbb22
✅  Set OrgRegistry as Interface Implementer for deployer. TxHash: 0xe57bf4d8f122e6bbd9b7160a7fa7dbd5dee6dc658a745d390740ce2becf63192
Could not retrieve Whisper ID. Check health of MESSENGER services: Error: socket hang up
    at connResetException (internal/errors.js:581:14)
    at Socket.socketOnEnd (_http_client.js:451:23)
    at Socket.emit (events.js:224:7)
    at endReadableNT (_stream_readable.js:1206:12)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  code: 'ECONNRESET',
  config: {
    url: 'http://messenger-buyer:4001/api/v1/identities',
    method: 'get',
    headers: {
      Accept: 'application/json, text/plain, */*',
      'User-Agent': 'axios/0.19.2'
    },
    ...
    _currentUrl: 'http://messenger-buyer:4001/api/v1/identities'
  },
  response: undefined,
  isAxiosError: true,
  toJSON: [Function (anonymous)]
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] deploy: `docker-compose run --rm deploy sh deploy.sh`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] deploy 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!     /Users/jayson/.npm/_logs/2020-04-02T15_36_31_660Z-debug.log
make: *** [deploy-contracts] Error 1

I've tried this on two different machines. make completes successfully. make deploy-contracts gives the same error on both machines. between attempts i've run make clean, docker system prune then make again.

Expected Behavior

containers should start

Actual Behavior

containers crash

Steps to Reproduce the Problem

1. make
2. make start

Specifications

• Version:
• Platform: macOS 10.14, docker 2.2.0.4
• Subsystem:

error:

api-buyer | /app/node_modules/config/lib/config.js:771
api-buyer | throw new Error('Config file ' + fullFilename + ' cannot be read. Error code is: '+e2.code
api-buyer | ^
api-buyer | Error: Config file /app/config/default.json cannot be read. Error code is: EISDIR. Error message is: EISDIR: illegal operation on a directory, read
api-buyer | at Config.util.parseFile (/app/node_modules/config/lib/config.js:771:13)
api-buyer | at /app/node_modules/config/lib/config.js:601:26
api-buyer | at Array.forEach (<anonymous>)
api-buyer | at Config.util.loadFileConfigs (/app/node_modules/config/lib/config.js:600:16)
api-buyer | at new Config (/app/node_modules/config/lib/config.js:116:27)
api-buyer | at Object.<anonymous> (/app/node_modules/config/lib/config.js:1436:31)
api-buyer | at Module._compile (internal/modules/cjs/loader.js:805:30)
api-buyer | at Object.Module._extensions..js (internal/modules/cjs/loader.js:816:10)
api-buyer | at Module.load (internal/modules/cjs/loader.js:672:32)
api-buyer | at tryModuleLoad (internal/modules/cjs/loader.js:612:12)
api-buyer | at Function.Module._load (internal/modules/cjs/loader.js:604:3)
api-buyer | at Module.require (internal/modules/cjs/loader.js:711:19)
api-buyer | at require (internal/modules/cjs/helpers.js:14:16)
api-buyer | at Object.<anonymous> (/app/dist/utils/serverSettings.js:10:38)
api-buyer | [nodemon] app crashed - waiting for file changes before starting...

The current contracts deployment procedure for Radish34 is based on a nodejs project and custom deployments of several contracts. Although it works flowlessly for an MVP procedure, several improvements can be made to make it "baseline" ready:

Separating and abstracting away, the deployment processes for client contracts and protocol contrats.

Current contracts deployment procedure is unified for every necessary contract in order to run Radish34 locally. Looking forward into abstracting this procedure, so that it becomes a part of baseline, the contracts can be separated in two categories.

• Protocol contracts - contracts that will be present on mainnet at the time of deployment and do not need to be deployed, but need to be deployed when using local environment. Ex. ERC1820Registry contract.
• Client contracts - contracts that will need to be deployed (and maintained - in future story) as part of the client setup - separate instance for every client. Ex. Org Registry, Shield, Verifier

We can create a mini-library that can be used to execute the procedure for both categories of contracts. This library will allow for configuring contracts, picking and choosing what to be deployed and generally perform the deployment process given the inputs.

This library will become the core of the next story.

Tidying up the code for better readability and maintenance

Currently the code uses custom wrappers around ethers and native ethers.js code for deployment of contracts. Most of these are already present in other ethers.js based deployment libraries like etherlime-lib. These will allow for reducing and tidying the codebase.

Overview

As a developer I want to run the Baseline Radish34 POC on an AWS EC2 instance, and access it via a browser.

Expected Behavior

When the radish34 demo is spun up, the partners page on the UI service displays a list of partners pre-registered with the OrgRegistry smart contract, as a list. Upon selecting any particular row, the UI should display a page containing profile information of the partner

Actual Behavior

Upon selecting any particular row, the UI navigates to a 404 error page

Steps to Reproduce the Problem

1. Assuming all the steps in spinning up the demo are addressed (), run docker-compose up -d ui to turn up the container
2. Navigate to radish34-ui.docker on local browser, and select partners page on the left hand side menu
3. Select any row in the grid of listed partners

Specifications

• Version: Docker 2.2.0.4
• Platform: Mac OS
• Subsystem: NodeJS/React App

Overview

As a user of the Radish34 use case, I would like to improve performance and availability of the privacy enabled interactions with the Zero Knowledge Service. Currently on a local development set up, it is often required to up the Docker Preferences for resource configs (CPU cores, RAM), in order to ensure successful execution of zero knowledge proofs on the ZKP service that leverages the Zokrates utility. In addition, the privacy of merkle tree service (timber) can be further optimized by increasing the Merkle depth of the tree stored in the Shield contract

Reference

Questions

Assumptions

• This issue's scope of privacy management utility is currently limited to usage of Zokrates. It would be better to limit the scope of this issue to performance of the existing ZKP component by substituting with other modes of performance management

Acceptance

• Measurement and test completion of proof generation and verification times by varying proving schemes
• Measurement and test completion of verification on chain with changes in the Shield contract
• Pluggable options to include additional proving schemes and hashing mechanisms

Tasks

• Build components in api for secure management of keys used for signing processes
• Substitute current hashing mechanisms with other mechanisms (Poseidon, Mimc, and Pedersen), with related changes that need to be made with zkp/circuits and contracts/ levels

**Disclaimer: This is a broad stroke and a sample feature request. It would need to be further updated (potentially broken down into further feature requests), based on discussions with other members of the Oasis community

Overview

As a developer user, I would like to lower the risk of managing multiple trusted setup. This has related implications on the performance of the overall application. There are two ways to do so:

1. Switch to universal snarks (Examples: Plonk, Sonic, Marlin, Supersonic)
2. Retain the actual snark a aggregate proofs (Examples: ZEXE and MNT4/6)
3. Other techniques (Examples: Halo, Fractal)

Reference

• Plonk
• Halo
• Sonic
• Marlin
• Supersonic
• Fractal
• Zexe

Questions

Assumptions

Acceptance

Tasks

• Research other options for improving the security of the overall application framework
• Develop gadgets and integrable utilities for using universal snark based trusted set ups (for example, Plonk or Halo)

**Disclaimer: This is a broad stroke and a sample feature request. It would need to be further updated (potentially broken down into further feature requests), based on discussions with other members of the Oasis community

Expected Behavior

The steps in the Radish README should complete successfully. Specifically, this step should succeed: npm i && npm run postinstall

Actual Behavior

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
$ npm i && npm run postinstall
npm WARN [email protected] license should be a valid SPDX license expression

audited 884760 packages in 6.363s
found 0 vulnerabilities

npm ERR! missing script: postinstall

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/edgema/.npm/_logs/2020-04-16T08_45_46_534Z-debug.log

Next error:

$ npm run build:contracts

.
.
.
> sol-compiler

sh: sol-compiler: command not found

Steps to Reproduce the Problem

1. Clone the repo
2. Follow the pre-requisites in the Radish README
3. Execute steps under Setup

Specifications

• Version:
• Platform: Mac
• Subsystem: 10.14.6

Overview

As a developer/admin user, I would like to create a smart contract management suite to deploy, manage and update Baseline (as modeled in Radish34) smart contracts to the mainnet

Reference

• EIP1077
• Upgradable Contracts

Questions

• What are the variations and consequences of Eth2.0? Should there be additional capabilities for handling web assembly adapters for smart contract languages?

Assumptions

Acceptance

• Gas consumption metrics for upfront deployment and ongoing maintenace of Radish34 smart contracts on the mainnet
• Successfully run test cases for updated implementation based on upgradable and user managed smart contracts
• Successfully run test cases for updated implementation based on relaying capabilities using the EIP1077 standard

Tasks

• Build capabilities to deploy the existing Radish34 contracts on the mainnet
• Update the deployment operation to be parameterized based on users registered in the OrgRegistry to create a managed user registration module under deploy/
• Build capabilities for the smart contracts to be upgradable using proxy patterns

**Disclaimer: This is a broad stroke and a sample feature request. It would need to be further updated (potentially broken down into further feature requests), based on discussions with other members of the Oasis community