gridplus / cryptobridge-contracts Goto Github PK

Hi @alex-miller-0! I was thinking of including your parity bootstrapping script in a new project, and I wanted to make sure it was posted under a compatible license. After a (very) quick glance it seems you haven't indicated how this code is licensed.

Assuming there's no license expressed in this repo, this technically means that nobody is able to use the code here, as no license for use has been granted. ChooseALicense.com has a great explanation of this.

This is a bounty associated with the Relay.sol contract. Currently, there are three functions that make up a full withdrawal:

1. prepWithdraw makes a Merkle-Patricia proof given transaction data and saves a temporary Withdrawal struct to storage. This is the most expensive function because it stores several pieces of data.

2. proveReceipt takes receipt data and forms a Merkle-Patricia proof. If successful, it saves the receiptsRoot for the block to storage.

3. withdraw forms a standard Merkle proof given [modified] headers (they are modified by the cryptobridge client to contain a subset of the Ethereum header data). If successful, this triggers an ERC20 transfer and deletes the temporary Withdrawal struct associated with the sender.

This process takes about 500,000 gas and requires three transactions on the withdrawal chain. For the next version, I would like to cut that gas usage by as much as possible and reduce it down to one transaction. This is where you come in.

Requirements:

A successful proposal will do the following:

1. Reduce the gas consumption by a significant quantity
2. Reduce the number of withdrawal transactions from 3 to 1. If this cannot be done, it must show evidence of that. A reduction from 3 to 2 is also acceptable if there is evidence it cannot be reasonably reduced to 1.
3. Update the test cases in bridge.js to call the updated API with new data.
4. Update the README to reflect API changes

Hints

Any method to perform the above requirements is fine, but I would suggest looking at passing larger bytes arrays and slicing them with utility functions, perhaps in an external library. This would require a considerable rewrite of prepWithdraw, which has the arguments pre-sliced. For an example of bytes slicing, you can look at the way logs are sliced in proveReceipt.

This affects #11 and #17

(draft)

Info: trufflesuite/ganache#294

(affects: #13)

Problem

After starting the parity-duo with npm run parity 7545 8545, the two parity processes get killed within a few seconds.

The parity/chains/*/error.log contain the error message:

IPC error: Operation not permitted (os error 1)

Environment

It happens in both:

• Win10, native cli
• Win10, bash (ubuntu)

Workaround

within parity/boot.js, locate:

//add this to disable ipc, if you get "IPC error: Operation not permitted (os error 1)"
args.push('--no-ipc') 

const parity = spawn('parity', args, { stdio: 'pipe', cwd: PATH });

Background: A relay system has two contracts (one on each of two chains), which have mappings between pairs of tokens. A user with a given token may deposit it into the relay contract on that chain and withdraw its copy on the other chain. The withdrawal is a two step process, with the first part being the formation of a Merkle proof to show the transaction (deposit) was in the transaction tree. This issue only covers this first part.

The function prepWithdrawal in Relay.sol takes a set of parameters (token, fromChain, and amount) and forms a transaction. It uses this transaction to make a Merkle proof that it was included in a given transaction root in withdraw. I am having trouble reconstructing the transaction and forming the proof -- this is where you come in!

To claim the bounty:

1. Rewrite the prepWithdraw, withdraw, and merkleProof Solidity functions to perform a proper Merkle proof. Use the parameters token, fromChain, and amount to form the transaction data that goes into making the proof. You can pass the transaction root from a given block into the function and match it with the proof.
2. Add test(s) to relay.js using this functionality. At a minimum, it should a) make the deposit to get the transaction hash, b) get the block from the transaction hash and make the Merkle proof in Javascript, c) pass the relevant data to Solidity to make the same proof.
3. Be concise with your Solidity functions. We want the user to pay as little gas as possible and for the contract to take as little gas as possible to deploy. For example, if you don't need to RLP encode data in Solidity and you can do it in Javascript instead, push that functionality out to the tests.
4. Document everything you write. If something is non-obvious, please explain your thinking - there is no such thing as too many comments!

These repos may help:

https://github.com/ConsenSys/rb-relay

https://github.com/ethereumjs/merkle-patricia-tree

https://github.com/zmitton/eth-proof

(affect #11)
Windows 10, bash on Windows, Hyper-V ubuntu instance.

The following error raises with truffle test

P:\sand\cryptobridge\contracts>truffle.cmd test
0xf399c77f9a403c541bbac8dae1e016bf942f09f5
Using network 'development'.

Error: Bridge contract constructor expected 1 arguments, received 0
    at C:\Users\laz\AppData\Roaming\npm\node_modules\truffle-core\node_modules\truffle-contract\contract.js:388:19
    at new Promise (<anonymous>)
    at C:\Users\laz\AppData\Roaming\npm\node_modules\truffle-core\node_modules\truffle-contract\contract.js:372:16
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

Truffle "hijacks" the test-system, so it is not obvious how to debug this using a standard IDE debugging setup.

Additionally there is no log-file produced.

Please verify that the existent code actually works as-is on your side, thus additional setup/debugging effort is avoided.

"npm install" has issues if you leave it in the repository.

Work on issue #11 has brought up multiple issues, mainly with documentation, dev-system-setup, and some more or less hidden bugs.

The work on this issues was/is beyond the scope of #11, yet it is important that this work is done. This is a prioritized/sequenced list:

• Provide a Docker Image
• Provide Windows Support (minimum: Win10 Pro/Docker)
• Update Project Docs
  • Provide concise installation steps for (starting with "Prerequisites node.js" etc.), ideal a cli-sequence
  • Provide the additional steps for contributing(!) developers
  • Provide installation remarks re Windows
  • low priority: reduce size of readme.
• Update Test System
  • Split down larger test files into separate files
  • Separate unit and integration tests
  • Provide Mock and Real Integration test
• Upgrade to Latest Libraries (e.g. BytesLib.sol)
• #15 - IPC Error (Already solved)
• #17 - Constructor Error (Already solved)

(high severity issue)

Work on #11 has brought up a cascade of problems, which finally do not seem related to Windows.

Setting up an isolated development-environment should be simplified. This way, any interested parties (like contributors, developers or evaluators) can come faster in contact with the cryptobridge-contracts, .

The suggested solution is to provide a minimal docker image, which contains everything and with the right versions, so test/work/evaluation can be started immediately, without loosing time and creativity with dev-system setup & troubleshooting.

Tasks

(draft)

• Split down larger test files into separate files
• Separate unit and integration tests
• Provide Mock and Real Integration test

Requirements

• Ensure that existent test-mechanisms are reused
• Ensure that test-system can be reused

(affects #11, but is out of its scope. Should be provided in future)

Suggested Steps (Prioritized)

• Provide concise installation steps for (starting with "Prerequisites node.js" etc.), ideal a cli-sequence
• Provide the additional steps for contributing(!) developers
• Provide installation remarks re Windows
• low priority: reduce size of readme.

Notes

This came up during setup for work on #11. There were missing dependencies and finally problems with installation of termios on windows.

This documentation should be provided by the project, as its beyond the scope of issue #11

(I will at this point retry the setup using this time an Ubuntu Subsystem on Win10. )

(related: #11)

Problem

The parity/boot.js which launches the 2 parity test-instances use npm modules which introduces problems.

Installation on a Windows 10 machine brings up several problems, even if the Bash Shell is used (Windows Linux Subsystem, with Ubuntu 16.04).

The installation on a standard Windows 10 Home machine should be enabled and simplified.

This would possibly mean to either solve existent problems (workarounds or fixes), or (prefered) to replace the incompatible modules which seem to have low usage & maintenance.

Modules:

• https://www.npmjs.com/package/spectcl
• Gottox/child_pty#20
• https://github.com/Gottox/node-termios

Usage Statistics:

• https://www.npmjs.com/package/spectcl < 200 downloads
• https://www.npmjs.com/package/child_pty - <400 downloads
• https://www.npmjs.com/package/termios - < 400 dowlnloads

in comparison (picked quickly a pupolar module)

• https://www.npmjs.com/package/node-pty > 20k downloads
• https://www.npmjs.com/package/co-child-process > 120k (120.000) downloads
• https://www.npmjs.com/package/child-process-promise

Overview of steps

• research and select new module
• rewrite code boot.js
• rename truffle.js to e.g. test-client.js (name-clash on windows)
• verify installation on a blank Win10 Home natively
• update documentation (related: #12)

Alternative

• provide dockerimage, like e.g: https://github.com/erkmos/parity-testrpc

Further Info

• https://github.com/paritytech/parity/wiki/Demo-PoA-tutorial#2-setting-up-the-two-nodes

(blocks #11)

Copied from the in-source documentation:

// even one(!) more parameter leads to "CompilerError: Stack too deep, 
// try removing local variables.". Applying Packing/Slicing has its 
// limits, as it has stack-cost, too (and needs sometimes local vars,
// as it does below).
// Suggestion (essentially a must): 
// Overall rewrite of proveReceipt, to use other techniques/concepts,
// thus stack-cost is reduced significantly. After this, at minimum
// one of the 2 other functions (prep / withdraw) will be mergable.

This re-implementation will possibly spawn over to other code-files. It is an absolute necessity, in order to allow the completion of #11.

(affects #11)

The libraries in use should be updated to the latest versions, starting with BytesLib.sol