State Channels bi-weekly development update - early August 2019

Protocol Features & Updates State Channels
1

This is a bi-weekly update of all things concerning the protocol design and
reference implementation of State Channels.

We plan to keep the bi-weekly schedule for these reports. Feedback is always appreciated.

Thanks to the SC contributors @dimitar.chain, @uwiger, @grzegorz225, @Aleksandarf @bot.

Dynamic transaction fee calculation

Implementation: PR #2588

The FSM used a hardcoded fee of 30 000 * local gas price (or
33 000) for all transactions. In certain cases this was insufficient and
transactions which should be ok were rejected. This was changes such that the
fee is computed dynamically for each transaction. The only exception is the
channel_mutual_close_tx transaction which requires a hard-coded fee.

Updated UML diagram

Implementation: PR #2591, PR #2596

The UML diagram describing the core states of the SC FSM has been updated.
Previously it was part of the source file itself. It has been moved out into its
own file to ease maintenance. The resulting diagram can be viewed in the
wiki. The intention is to keep the UML diagram up-to-date with
changes to the source code and easily comprehensible.

Websocket client disconnect and reconnect

Design: PR #389
Implementation: PR #2602, PR #2603

Clients can now disconnect from the FSM without the FSM shutting down
immediately. Instead a client may reconnect using the new off-chain
channel_client_reconnect_tx transaction. The tx contains the information
needed to locate the right FSM, including the client’s public key.
It must be signed by the client, proving that it possesses the private key
(or other signing capability) for the account.

Improved hard fork detection

Implementation: PR #2608

The detection logic was improved to detect whether a protocol version was active
before.

Refactorings and general improvements

Design: PR #381, PR #383
Implementation: PR #2591, PR #2596, PR #2597

The FSM has grown quite large over the last year. Therefore, an ongoing effort
is to refactor parts of the code to make it easier to comprehend and
maintainable. Refactorings are meant to be done is small chunks to keep impact
low and feature development going.

Initial design of virtual state channels

Design: PR #382

An initial design of VSCs is in review, which is meant to act as a proposal for
further community discussion.

7 Likes
2

Hello @botanicalcarebot.chain - is it you, Tino :wink:

3

Yes :slight_smile: in true digital form.

4

What does FSM stands for?

5

Finite State Machine.

1 Like
6

any plans to have maybe multi party state channels, it’d be great for aepps such as auctions, where ordering is not important (highest bid wins no matter the order)?

7

Hey @CryptoTask, @dimitar.chain was asked about multi-party channels during an AMA some time ago - here’s his answer:

#5 - Will state channel support multi-party channels? If so, when will it happen?

Multiparty channels are a hot subject. I personally am against them as so far I haven’t seen a solution that cannot be easily attacked in theory. They end up either centralized and trustful or broken by design. I hope we can offer an alternative using virtual channels.

He’ll complete me if there are any updates on the topic :slight_smile:

Best,
Albena

1 Like