Interledger implementation in Rust :money_with_wings:

All crates require Rust 2018 edition and are tested on the following channels:


Interledger implementation in Rust :money_with_wings:

Requirements

All crates require Rust 2018 edition and are tested on the following channels:

  • stable

Connecting to the Testnet

See the testnet instructions to quickly connect to the testnet with a bundle that includes the Interledger.rs node and settlement engines.

Understanding Interledger.rs

  • HTTP API
  • Rust API
  • Interledger.rs Architecture
  • Interledger Forum for general questions about the Interledger Protocol and Project

Installation and Usage

To run the Interledger.rs components by themselves (rather than the testnet-bundle), you can follow these instructions:

Using Docker

Prerequisites

  • Docker

Install

Run

Building From Source

Prerequisites

  • Git
  • Redis
  • Rust - latest stable version

Install

You can find the Interledger Settlement Engines in a separate repository.

Run

Append the --help flag to see available options.

See configuration for more details on how the node is configured.

Configuring Redis

We have some account settings such as amount_per_minute_limit or packets_per_minute_limit. In order to enable these options, you need to load the redis-cell module as follows. You don't need to load this module unless you use the rate-limit options.

or you can specify an argument when you start up the redis instance as follows.

Examples

See the examples for demos of Interledger functionality and how to use the Interledger.rs implementation.

Contributing

Contributions are very welcome and if you're interested in getting involved, see CONTRIBUTING.md. We're more than happy to answer questions and mentor you in making your first contributions to Interledger.rs (even if you've never written in Rust before)!

Issues

Collection of the latest Issues

koivunej

koivunej

good-first-issue
1

RUSTSEC-2020-0159 means there should be an investigation into migrating to time. Some parts of the current timestamp parsing in the -packet, or -stream should be extra carefully verified against the respective interledger RFC's as there might not be good existing test cases.

koivunej

koivunej

ci
0

Looking at the existing examples in serde/json for example, there probably is currently no supported way around installing cargo-fuzz on a nightly and just cargo fuzz build the targets under each crates/interledger-*/fuzz.

Implementing this might be difficult for the caching, because these fuzz targets are not part of the workspace and have their own target/ directory, which might not work out of the box with the rust-cache action introduced in #732.

Originally posted by @koivunej in https://github.com/interledger-rs/interledger-rs/issues/732#issuecomment-894163497

koivunej

koivunej

good-first-issue
0

This was noticed while adding the benchmarks in #663 that the redis_helpers.rs is copypasted all over. I do remember attempting to split it, the latest one being https://github.com/KristianWahlroos/interledger-rs/pull/2. Since #729 will leave some FIXME and todo! related to these files, maybe they should be refactored into a single place before fixing.

Marking this as good-first-issue because I seem to have made quite small commits which should be easy to follow/replicate.

omertoast

omertoast

bug
3

Deprecated Xpring API had an endpoint #404<assetCode> to create accounts on Xpring's side. ilp-cli testnet setup command was using this endpoint to create an account and peer with it to connect the testnet easily.

  • https://github.com/omrtozd/interledger-rs/blob/0fcaf5d0a9b34d52bde08250a5f52f5398f6c7ab/crates/ilp-cli/src/interpreter.rs#L326-L335

But since Xpring rebranded as RippleX, API endpoints and responses changed with it. For now, I find out three things that need to change, in order to ilp-cli testnet setup command work.

  1. API endpoint, which changed from #404<assetCode> to https://ripplex.io/portal/ilp/hermes/accounts/. Also, you should send a POST request instead of a GET request.

  2. The method to change the account asset. You should send a POST request to https://ripplex.io/portal/ilp/hermes/accounts/ with a JSON payload, an object named assetCode in it to use an asset other than XRP. You can see the old method here: https://github.com/omrtozd/interledger-rs/blob/master/docs/manual-config.md#get-your-own-credentials

  3. The XpringResponse struct, due to the change in the response format.

  • XpringResponse Struct: https://github.com/omrtozd/interledger-rs/blob/0fcaf5d0a9b34d52bde08250a5f52f5398f6c7ab/crates/ilp-cli/src/interpreter.rs#L394-L403

  • Example response:

koivunej

koivunej

bug
3

#693 introduced fuzzing targets to some crates and in the interest of avoiding forever lasting PRs, I didn't fix all of the found issues. Current status at the end of the PR is:

  • packet: address is good, packet roundtrip added late, immediate roundtrip failure(s), #[ignore] tests
  • btp: most fuzzed, looking quite good
  • stream: roundtrip added late, immediate roundtrip failure(s), #[ignore] tests
  • ccp: roundtripping, might be good

Other crates have not been fuzzed.

~One obvious fix which isn't implemented yet is matching the interledger-packet datetime string against a regex before asking chrono to parse it in crates/interledger-packet/src/packet.rs. This fix would be similar to what was done for the variable length btp timestamp in e6f21c9b486b8397e0d0a961a2148646ff1f987b.~ Done in #707.

#[ignore]'d test cases:

Marking this as good-first-issue as with any hand-written parsing code, there are most likely issues still to be discovered even after fixing the #[ignore] test cases. Mentoring is available by pinging me or anyone who recently contributed to the repository. As there are many things to do, it might be best to avoid huge PRs like I ended up doing and tackling one issue at a time.

koivunej

koivunej

bug
0

#703 silenced two loggings which were output for decryption failures and for any parsing failure (including decryption failure). As before #703, the behaviour on invalid but successfully decrypted prepares was not changed, so they are still forwarded to next handlers.

Succeeding in decrypting the packet but failing to parse it should most lead to an immediate rejection. This should be confirmed from the stream RFC and fixed.

Marking this as good-first-issue as this code isn't too involved, and there are examples of rejection in the interledger-stream already. Also mentoring is available by pinging me or someone else who has been recently active.

koivunej

koivunej

discussion
0

In #696 I included 58835a5c0363d717866eeb7b742453709d6cb288 which updates the README not to include any MSRV.

MSRV first appeared in c4a5364d9c269270801f080ba47be222bfd498d7. After the adding of MSRV the version has been bumped at least for 1.45 defining the f64 -> u64 conversion in #654 and 1.46 for sized-chunks in #689. Meanwhile we've been developing and CI has always been testing and running clippy on the latest stable. Now #696 with the new lint fixes pushes it the minimum to 1.51.

Since this crate depends, even directly, on many crates which are expected to evolve in the near future thanks to const generics, I think it's best to keep only the support for latest stable.

Opening this issue up for discussion since I do not want to block #696 on the README update (which is overdue either way).

Srtake

Srtake

0

According to ILP SPSP specification, given the open STREAM connection, either the SPSP Client or the Server can begin sending ILP packets of data. In a wallet, we may want to send these additional data when making payments to satisfy our business requirements.

In Interledger.js ilp packet, there is an optional data field in PayOptions in spsp.ts. Could you tell me whether there is any approach to implement this functionality? I researched the HTTP APIs of Interledger-rs, but have not found it yet.

aphelionz

aphelionz

good-first-issue
1

Due to route propagation delays, sometimes the container can appear spun up while there are still connectivity issues. It would be good if the image could report out a health check once everything is stable. This will help with k8s deployments, among other things.

pradovic

pradovic

6

CircleCI plan does not cover the instance needed to run build and tests, which is currently stopping a couple of PRs which are ready to merge.

One possible solution would be to switch to github actions. I am already on it, and will open the PR soon, so this could be a solution if accepted.

koivunej

koivunej

2

While handling the latest 1.49 clippy lints in #667, there are at least two public instances of Result<_, ()> which are now nagged by clippy changing of which require a minor version bump:

  • 2233dc97c614a212f75ddb417b46f937aa589477 (interledger-settlement)
  • 170c9e7062df6fff157fac11d09277e5ec621192 (interledger-stream)
  • 43728cfbafa9b89ef1978faf1a2511c1cf881833 (interledger-store)
  • whole of #690 which updated bytes = "0.4" of interledger-packet which is re-exported
  • #719 changed interledger-packet::ErrorCode::new signature

Given commit 3f1a8de2a359c02c8d8edda88eacdd652d3992bd I had thought that 1.0.0 versions had already been pushed, but in light of us needing to make breaking changes to keep up with clippy, I'd recommend reverting the 1.0.0 bump and going ahead with the next released versions being 0.x series. crates.io doesn't have any 1.0 crates nor does dockerhub, at least as far as I can search it.

matdehaast

matdehaast

3

Currently I think the only work being done is by the Equilibrium folks, whilst the current maintainers/owners are not actively involved anymore.

@kincaidoneil has been reviewing the code and helping out but I want us to more formally work out the ownership/custodianship going forward.

@sentientwaffle @emschwartz @gakonst do you guys have any input?

kincaidoneil

kincaidoneil

crate/interledger-settlement
0

Unfortunately, #591 still has an issue: when peering two nodes, if the account that's prefunding is created before the other account, the settlement will be triggered immediately and then fail because the peer's account has not yet been created. Having the settlement engine backoff and retry isn't a great strategy, since the settlement engine has now idea why it failed or if/when it's messages will get through.

A better solution would be to only create the account on the settlement engine after the node knows the account has been created on the peer, which could be done via an interactive account creation process.

matdehaast

matdehaast

0

Seems there is a panic without any logging if you attempt to run the latest ilp-node from dockerhub.

Steps to reproduce

  1. docker pull interledgerrs/ilp-node
  2. docker run -it interledgerrs/ilp-node --ilp_address example.node_a \ --secret_seed 8852500887504328225458511465394229327394647958135038836332350604 \ --admin_auth_token admin-a \ --redis_url #404 \ --http_bind_address 127.0.0.1:7770 \ --settlement_api_bind_address 127.0.0.1:7771

This will result in the following

thread 'main' panicked at 'calledResult::unwrap()on anErrvalue: ()', src/libcore/result.rs:1188:5 note: run withRUST_BACKTRACE=1environment variable to display a backtrace.

Ideally it should give an error about there being no redis connection etc and then panic.

kincaidoneil

kincaidoneil

performance
1

Since calling handle_request on the service interface requires a mutable borrow, we're cloning the entire service chain on every packet to get around this.

For ILP-over-HTTP requests, it happens twice:

https://github.com/interledger-rs/interledger-rs/blob/4b491ab76ca4b73ef53e101fc2cb1a71e32f53d2/crates/interledger-http/src/server.rs#L124-L135

https://github.com/interledger-rs/interledger-rs/blob/4b491ab76ca4b73ef53e101fc2cb1a71e32f53d2/crates/interledger-http/src/server.rs#L63-L74

Here's where it happens for BTP packets:

https://github.com/interledger-rs/interledger-rs/blob/4b491ab76ca4b73ef53e101fc2cb1a71e32f53d2/crates/interledger-btp/src/service.rs#L258-L259

This probably isn't great for memory usage or performance (and is probably much worse than #469 or #554). We should consider redesigning the service interface so it doesn't require a mutable borrow, since it appears very few (if any?) services require mutation.

kincaidoneil

kincaidoneil

docs
2

In trying to setup an account that would prefund its peer, I couldn't find any documentation on what a positive/negative balance represents or how I should set the settle_to, nor what units I should use. The best I could find was this in line the ETH example:

The settle_threshold and settle_to parameters control when settlements are triggered. The node will send a settlement when an account's balance reaches the settle_threshold, and it will settle for balance - settle_to.

We need to document, within the HTTP API specification and the ilp-cli help text (and maybe elsewhere, too?):

  • When settle_to gets triggered, and what a positive or negative balance represents
  • What units the settlement parameters need to be in, with a couple examples (I was using an account with asset scale 2 and I tried to set settle_to to 4.52 but the CLI gave me a confusing error until I changed it to 452. We should clarify this or change the API to use the standard, arbitrary precision representation of the asset, since it's more intuitive).

Related to #120

gakonst

gakonst

crate/interledger-ccp
0

As discussed with @sappenin we should check if our CCP implementation is compatible with the one from the Java and Javascript connectors and if not, write some tests and identify which interoperability points we're missing.

ibanfi

ibanfi

1

The stock ILP node is able to handle flat exchange rate only, it cannot handle complex business logic (pricing curves) and it cannot handle either when I want to provide special exchange rate for my customers.

The idea is: instead of implementing a complex and parameterized rate service into the ILP node (or outside, providing as a service), let the customer do this. The sender sends the amount and defines the target amount/currency or target rate. In this case the ILP node won't apply its own rate, it accepts and processes the requested transaction. Of course we have to consider so many restrictions, including:

  • Whitelist with acceptable customers/IP address/etc.
  • Explicit trust lines between sender end recipient address
  • Amount limitations (not more than $100)
  • Rate limitations (not more than 1:100)
  • Transaction is acceptable only if the sender and the recipient address are on the same node (connector)
  • etc.

Sample payload

Target amount

Special rate

matdehaast

matdehaast

feature
2

Adding custom logic within the packet path allows people to add business logic in an easy manner. This can currently be done by writing your own services in rust and compiling the node. However that limits to people capable of writing Rust.

Other projects allow plugin type models for similar functionality though are language specific:

Another option is to have the plugin be a WASM module. This would mean implementors could choose any WASM language to write the logic and I believe WASM can allow you to have strict checks on the interface of the module before running it.

Versions

Find the latest versions by id

Information - Updated Jun 23, 2022

Stars: 178
Forks: 65
Issues: 87

Wagyu Etherum blockchain ledger and wallet in Rust

Cross platform ether wallet generator that makes automated creation of crypto wallets easy

Wagyu Etherum blockchain ledger and wallet in Rust

Reference implementation of the Stacks blockchain in Rust

Reference implementation of the Proof of Transfer (PoX) mining that anchors to Bitcoin security

Reference implementation of the Stacks blockchain in Rust

This repository contains core Rust and Haskell libraries used by various

components of the Concordium blockchain, as well as some tools used for testing

This repository contains core Rust and Haskell libraries used by various

Blockchain Commons torgap-sig-cli-rust

torgap-sig-cli-rust is a fork of Minisign, with support for

Blockchain Commons torgap-sig-cli-rust

A Blockchain implementation in Rust

MIT (c) Doublify Technologies

A Blockchain implementation in Rust

Diem core repo for Rust

Diem is a user focused blockchain application, that has increased in popularity significantly in the crypto / blockchain space

Diem core repo for Rust

Rust implementation of the Inter-Blockchain Communication (IBC) protocol

This project comprises primarily four crates:

Rust implementation of the Inter-Blockchain Communication (IBC) protocol

A simple blockchain example written in Rust:

Defines data structures to model a minimum blockchain

A simple blockchain example written in Rust:

A Blockchain implementation in pure Rust

Below find an example usage of the library:

A Blockchain implementation in pure Rust
Facebook Instagram Twitter GitHub Dribbble
Privacy