Vector is an ultra-simple, flexible state channel protocol and implementation.
At Connext, our goal is to build the cross-chain routing and micropayment layer of the decentralized web. Vector sits on top of Ethereum, evm-compatible L2 blockchains, and other turing-complete chains, and enables instant, near free transfers that can be routed across chains and over liquidity in any asset.
Out of the box, it supports the following features:
- 💸 Conditional transfers with arbitrary generality routed over one (eventually many) intermediary nodes.
- 🔀 Instant cross-chain and cross-asset transfers/communication. Works with any evm-compatible chain.
- 🔌 Plug in support for non-evm turing complete chains.
- 💳 Simplified deposits/withdraw, just send funds directly to the channel address from anywhere and use your channel as a wallet!
- ⛽ Native e2e gas abstraction for end-users.
- 💤 Transfers to offline recipients.
This monorepo contains a number of packages hoisted using lerna. Documentation for each package can be found in their respective readme, with some helpful links in Architecture below.
Contents:
Prerequisites:
make
: Probably already installed, otherwise install wbrew install make
orapt install make
or similar.jq
: Probably not installed yet, install wbrew install jq
orapt install jq
or similar.docker
: See the Docker website for installation instructions.
To start, clone & enter the Vector repo:
git clone https://github.com/connext/vector.git
cd vector
To build everything and deploy a Vector node in dev-mode, run the following:
make start-router
# view the node's logs
bash ops/logs.sh node
# view the router's logs
bash ops/logs.sh router
That's all! But beware: the first time make start-node
is run, it will take a very long time (maybe 10 minutes, depends on your internet speed) but have no fear: downloads will be cached & most build steps won't ever need to be repeated again so subsequent make start
runs will go much more quickly. Get this started asap & browse the rest of the README while the first make start
runs.
By default, Vector will launch using two local chains (ganache with chain id 1337
and 1338
) but you can also run a local Vector stack against a public chain (or multiple chains!) such as Rinkeby. To do so, edit the chainProviders
and chainAddresses
fields of config.json
according to the chain you want to support.
Note: this will start a local Connext node pointed at a remote chain, so make sure the mnemonic used to start your node is funded in the appropriate native currencies and supported chain assets. By default, the node starts with the account:
mnemonic: "candy maple cake sugar pudding cream honey rich smooth crumble sweet treat";
privateKey: "0xc87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3";
address: "0x627306090abaB3A6e1400e9345bC60c78a8BEf57";
To apply updates to config.json
, you'll need to restart your vector node with make restart-node
.
(make start
/make restart
are aliases for make start-router
/make restart-router
)
Four different Vector stacks are supported:
messaging
: standalone messaging + auth servicechains
: EVMs in dev-modenode
: vector node + databaserouter
: vector node + router + databaseduet
: 2x node/db pairs, used to test one-on-one node interactionstrio
: 2x node/db pairs + 1x node/router/db , used to test node interactions via a routing node.
For any of these stacks, you can manage them with:
make ${stack}
egmake duet
builds everything required by the given stackmake start-${stack}
egmake start-router
will start up the router stack.make stop-${stack}
stops the stackmake restart-${stack}
stops the stack if it's running & starts it againmake test-${stack}
runs unit tests against some stack. It will build & start the stack if that hasn't been done already.
You can find WIP documentation on integrating and using Vector here.
Vector uses a layered-approach to compartmentalize risk and delegate tasks throughout protocol usage. In general, lower layers are not context-aware of higher level actions. Information flows downwards through call params and upwards through events. The only exception to this are services, which are set up at the services layer and passed down to the protocol directly.
You can find documentation on each layer in its respective readme:
- Contracts - holds user funds and disburses them during a dispute based on commitments provided by channel parties.
- Protocol - creates channels, generates channel updates/commitments, validates them, and then synchronizes channel state with a peer.
- Engine - implements default business logic for channel updates and wraps the protocol in a JSON RPC interface.
- Server-Node - sets up services to be consumed by the engine, spins up the engine, and wraps everything in REST and gRPC interfaces.
- Router - consumes the server-node interface to route transfers across multiple channels (incl across chains/assets)
Note that the engine and protocol are isomorphic. Immediately after the core implementation is done, we plan to build a browser-node
implementation which sets up services in a browser-compatible way and exposes a direct JS interface to be consumed by a dApp developer.
You can build the whole stack by running make
.
Running tests:
- Unit tests are run using
make test-{{$moduleName}}
. - Two party integration tests are run using
make start-duet
and thenmake test-duet
- Three party (incl routing node) itests are run using
make start-trio
and thenmake test-trio