A Node is an implementation of the vector protocol -- it is the piece of software that allows you to safely create and interact with any vector state-channels. Nodes can be run within the browser using the browser-node package, as well as on a server using the server-node docker images. See the Basics section for more information on the differences between the two.
While seemingly simple, there is a lot going on in your vector node! The basic node architecture is illustrated below:
Handles any and all vector related messaging, and relies on NATS as the messaging protocol. The messaging is handled globally, and will be decentralized once more reliable p2p messaging protocols become available.
Handles any and all chain communication. This could include querying contract state, or sending onchain transactions. All of the logic happens through the node's chain service.
Nodes will store their latest channel state, and all transfers. The server-node can use postgres or sqlite as the database provider, while the browser-node relies on IndexedDB.
Nodes all have an associated signer they are configured with on start. This is the key used to sign all channel state updates. If you are operating as alice within the channel, you should always make sure you have funds for liquidity and gas stored on this ETH address. bob on the other hand, just has to store the key securely.
Alice and Bob are the central characters in nearly every peer-to-peer protocol story, and Vector is no different. In the vector protocol, alice is assumed to be a high-fidelity user (has gas in their signing address) and bob is assumed to be a low-fidelity user (doesn't always have gas in their signing address). This assumption manifests itself in a couple of different ways:
To deposit, bob can simply send funds from anywhere (i.e. directly from an exchange, using a metatransaction, etc) to the channel. alice , on the other hand, must call the depositAlice function (she can still use a meta-transaction service to submit this transaction rather than doing it herself as there are no msg.sender checks) to add funds to the onchain channel. This also means that while bob can deposit without deploying the channel to its channelAddress (which is generated using CREATE2 , alice must deploy the contract to be able to deposit. While
During cooperative channel withdrawals, a commitment is created and signed by both participants to remove funds from the onchain multisig. However, because you don't make the assumption that bob holds gas, alice will automatically submit the withdrawal commitments to chain unless otherwise specified. Fees for this can be configured on your node, and are deducted from the amount withdrawn.
Connext can be (and frequently is!) used as a cross-chain solution, and using a public identifier helps to track participants across the different chains. It is derived from a publicKey and you can also derive an associated ethereum address from it. Public identifiers will always be prefixed with vector .
A transfer is main the mechanism to update state within a channel.
See Custom Transfers for more details.