interledgerjs/ilp-plugin-ethereum

Settle Interledger payments with ETH and ERC-20 tokens

Interledger.js Monorepo

Packages

Payments

Name	Version	Description
@interledger/pay		Send payments over Interledger using STREAM
@interledger/stream-receiver		Simple & composable stateless STREAM receiver

Utilities

Name	Version	Description
ilp-logger		Debug logging utility for Interledger modules
ilp-packet		Serialization/deserialization utility for ILP packets
ilp-plugin		Connect to a local, open BTP server
ilp-plugin-btp		One plugin to rule them all
ilp-protocol-ccp		Serialization/deserialization for the CCP routing protocol
ilp-protocol-ildcp		Fetch asset and account details from a parent
ilp-protocol-stream		Reliably send streams of money and data over ILP
oer-utils		Tools for OER parsing and serialization

Installation

The monorepo is set up to use lerna and pnpm workspaces. To get started run the following:

1. pnpm install - pnpm will install the dependencies and do the necessary linking (no need to run lerna bootstrap).
2. pnpm build
3. pnpm test - This will run the tests in all the packages.

Running script commands

Script commands such as test and lint can be run from the root of the project by running:

# Run tests for all packages
pnpm test

# Run tests for a specific module a package
pnpm test --scope=<package-name>

Or in the package directory:

pnpm test

If you are interested in contributing, please read the contributing guidelines.

For Maintainers

Versioning

Independent versioning is used for this project and releases can only be made from master. You will need to set the GH_TOKEN env variable to your personal GitHub access token. Please make sure that you are up to date with master and that the tests and linting pass. Then use the following to create a release:

# On master
GH_TOKEN=<github-token> lerna version --conventional-commits --create-release github

and follow the command prompts. This will commit the package version changes and create the necessary tags - all of which will be pushed to master. It will also create changelogs and official GitHub releases.

If you want to release an alpha then run

# On master
GH_TOKEN=<github-token> lerna version --conventional-commits --conventional-prerelease --create-release github

This will append -alpha.<alpha-version> to the release name. The alpha release can be graduated (1.0.1-alpha.1 => 1.0.1) by running:

# On master
GH_TOKEN=<github-token> lerna version --conventional-commits --conventional-graduate --create-release github

Adding new packages

All source code is expected to be TypeScript and is placed in the src folder. Tests are put in the test folder. The NPM package will not contain any TypeScript files (*.ts) but will have typings and source maps. A typical project should have the following structure:

|-- src
|-- test
|-- package.json
|-- tsconfig.build.json

The tsconfig.build.json file should have the following

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "composite": true,
    "baseUrl": ".",
    "rootDir": "src",
    "outDir": "dist",
    "tsBuildInfoFile": "./dist/tsconfig.build.tsbuildinfo"
  },
  "include": [
    "src"
  ]
}

The package.json file should specify the following

{
  "name": "<package-name>",
  "license": "Apache-2.0",
  "publishConfig": {
    "access": "public"
  }
}

In the scripts section of the package.json, be sure to have build, cover (which runs tests with coverage) and codecov. These will be called from the CI pipeline. Please use the following as a guideline:

"scripts": {
  "build": "tsc -p tsconfig.build.json",
  "cover": "...",
  "codecov": "curl -s https://codecov.io/bash | bash -s - -s coverage -F <flagname>"
}

The cover script should run the tests with code coverage and output the coverage results in a format that can be uploaded to codecov. The flagname will be used by codecov to track coverage per package. Please make sure it matches the regex ^[a-z0-9_]{1,45}$.

Importing legacy modules

This process preserves the commit history of the legacy modules.

git clone [email protected]:adrianhopebailie/interledgerjs.git
git clone [email protected]:interledgerjs/legacy-module.git
cd legacy-module
git pull
cd ../interledgerjs
lerna import ../legacy-module --dest=packages --preserve-commit --flatten

You then need to replace the tsconfig.json file with the tsconfig.build.json and update the package.json as described above.

Dependencies

We keep devDependencies that are shared across all packages in the root package.json file. Dependencies can be added to individual packages using Lerna

lerna add <package to install> --scope=<package-name>

# Add dev dependency
lerna add <package to install> --scope=<package-name> --dev

Running script commands

Script commands such as test and lint can be run from the root of the project by running

# All tests in all packages
lerna run test

#Scoping to a package
lerna run test --scope=<package-name>

ilp-plugin-ethereum's Issues

Built-in mechanism to start settling

This would trigger the counterparty to claim if it's profitable to do so, enabling the sender to get their collateral back.

Return ILP Reject packets instead of throwing

Same as interledgerjs/ilp-plugin-xrp-asym-server#20

Race condition when opening client channel

There is a race condition in the code that establishes a client channel.

Upgrade to Ethers v5 beta

Add more intelligent nonce management for concurrent txs

Refer to MetaMask/metamask-extension#3475 and https://github.com/MetaMask/nonce-tracker/blob/master/index.js for ideas

support a design map

Add persistent channel watcher

If a server ever goes offline and comes back online, the channel watcher currently does not watch open channels if the client is not connected.

Not working with Machinomy ^1.6.1

It looks like this plugin is incompatible with machinomy v.1.6.1 despite it as a dependency.

An example:
This function call: https://github.com/interledgerjs/ilp-plugin-ethereum-asym-client/blob/58a71f3c6310188ea668dfd21d431eeb98ba1f69/index.js#L93-L96
Doesn't match what machinomy expects: https://github.com/machinomy/machinomy/blob/b816cb4621bf6e0e51324920a7762dcc262abe49/index.ts#L264-L269

I found a few others incompatibilities well.

Include a link to the source code of the smart contract used

This would be helpful for anyone looking at how this plugin works under the hood

Estimate gas for ERC-20 approve, then add open/deposit hardcoded gas limit

As opposed to having a hardcoded gas limit for the two combined operations. (Machinomy gas usage for those operations is probably pretty constant, but ERC-20 implementations could in theory use more or less gas.)

Error: Cannot find module 'machinomy/lib/payment'

Incorrect log when request peer to close channel fails

ilp-plugin-ethereum/src/account.ts

Line 1243 in 316ac9f

const updatedChannel = this.refreshChannel(

This line should await the updated channel state before logging that it was successful (and log if the state is not updated).

Logs incorrectly report fee in unit of ERC-20, rather than ETH

e.g. Depositing 10 DAI to channel for fee of 0.00048373 DAI

Add unit tests

What happened to the unit tests? I noticed the branch is gone.

A lot of those tests were testing balance/account/store logic as well as packet construction very thoroughly. If they are gone, it is very possible that somebody could edit the plugin and cause a minor breaking change (like balance logic not being calculated properly or persisted to the store) and the integration tests would still pass. I feel this could be pretty dangerous considering the plugin is in beta and will have updates.

Support custom signing keys in Machinomy paychan contracts

Since each claim requires the private key to sign it (and each stream requires signing many claims), only custodial wallets may use this. With custom signing keys, MetaMask and hardware wallet integration for client software would be feasible.

Limit incoming queue to a single claim

On a T04 errors, the plugin sends the latest claim to the peer. Often, this requires verifying the signature, which if many T04s are triggered, can overwhelm the plugin/connector.

Alternatively, only allow a single validate claim task in the queue, and if a new one is enqueued, drop any others without running them.