State Channels JS library

It will be great having more state channels’ apps running on phones. Currently there is an example implementation of the off-chain protocol built in the node itself. This sadly requires a synced node and an opened connection to it. It might be worth the effort moving some of the functionality to the client’s side.

One big obstacle for this would be validating contracts off-chain. In order to do this, the client would need to be able to run the VM locally, which is not a trivial task. In my opinion this should not be a blocker for developing a librarary that does everything else, except contracts. That would mean builing a library that can talk to a few nodes in order to build a consesus for the state of the chain. It must be able to connect to the other participant and implement a huge portion of the off-chain protocol. It must be able to create and validate non-contract transactions in trustless manner - both on-chain and off-chain - and sign them. Once there is a solution for the contract’s executution, we can enrich this client library with it. At this point of time I am talking for a library that supports only payments, not contracts.

At the moment I am thinking it would be a great starting point having this runnable in a browser, so we need a JS library. As we already have the SDK, we might already have some of the pieces to build it. Later on this can be integrated in the Base Aepp.

So functionally speaking - what shall it do? I tried shortlist:

  • it must be able to build and check on-chain transactions: channel_create, channel_deposit, channel_withdrawal, channel_close_mutual, channel_snapshot, channel_close_solo, channel_slash and channel_settle. This seems to be covered by the JS SDK, for example - the channel_create can be seen here.
  • it must be able to build and check off-chain transactions - the channel_offchain transaction as well as a subset of the off-chain updates: transfer, deposit and withdrawal (note - no contract create and call). This is already handled in the SDK as well.
  • transactions must be authenticated and checked in a safe manner. This requires RLP encoding and decoding, building a signed_tx and etc. but all of this is already provided by the SDK. Since we are not doing contracts yet, no generalized accounts (yet).
  • it must be able to build and update off-chain trees. This is required for the trustless part: receiving an incoming off-chain transaction and a set of updates, the library must be able to check that adding it to the current state trees, the root of the newly produced trees will match the one in state_hash of the off-chain transaction. This might not be provided already by the SDK but there must be at least a decent MPTrees library
  • in order to be able to talk to another participant, it must be able to open a noise connection to another participant (probably to a responder). I am not sure how this will play in a browser environment
  • it must implement most of the off-chain protocol. I think the all messages must be handled, including the contract updates as those must be rejected at this point. This will be a decent chunk of work but it must be done anyway if we want to move parts of the FSM to the client itself
  • although a different approach could be taken, it would probably have to reimplement either parts of or the whole Finite State Machine in JS.
  • with regard of keeping the client safe at all time and being trustless, it must be able to build consesus for the on-chain state of the channel: if the client is helping Alice, she must be informed by her client library when Bob tries cheating on-chain (with providing some old state on-chain). This means that the client must ask a few different nodes for the channel’s state and build consesus upon their responses. This is also required for waiting a certain amount of confirmations for on-chain transactions (channel_create, channel_deposit and etc).

Note that all of the points above were just functionalities, each app can build a UX of their own :slight_smile:

So, what do you think for all of this? Did I miss something?


Fantastic! We’re looking for some JS pros who can support us here. If you feel you’d be the right one, please comment here and / or apply for a dev grant via