A High Level Introduction to GoNetwork’s State Channel Architecture

7 min readJun 9, 2018

A Brief History

Last year we turned our attention to scaling. It became apparent to build Dapps that could reach consumer markets, blockchains needed to address transaction throughput and latency. Based on our research, we set our sights on contributing to L2 scaling solutions by developing State Channels. For a deeper insight into our design process, refer to the section Inspiration and Background¹.

High-Level Framework Overview

Figure: High level view of GoNetwork framerwork

The gonetwork-framework is composed of 3 modules, we provide a brief outline below the implementation and purpose of each:

As an aside, it is important to distinguish between network in the context of state channels and transport:

The transport network; connections to transmit off-chain and network packets between nodes. This layer is managed by the Connection Module.
The state channel network; peer connections which have established a state-channel on the blockchain. This layer is managed by the Blockchain Module.

Engine ( 2. in figure)

The engine represents the core of the architecture. All state changes are initiated and validated through the engine. The first release of the engine implements the The State Machine Approach to replicate channel state between peers. The engine is designed for portability amongst different transport and blockchain implementations.

Our state channel implementation has the following properties and constructs:

A duplex channel is composed of 2 simplex channels with monotonically increasing state. Consequently, incorrect or stale state submission during channel closing results in a loss for the faulty actor.
Off-chain Locked transfers implementation(HTLC)
Lock transfers operate asynchronously e.g. many in-flight, out-of-order secret reveal, out-of-band secret reveal
A “opened” lock transfers are converted to direct transfers increasing channel longevity indefinitely

Connection Module ( 1. in figure)

The connection manager defines the transport layer between nodes. Off chain transactions and network packets are exchanged using this transport layer. The base implementation makes use of MQTT with persistent queues. A production quality transport layer may consider addressing message privacy by leveraging a message encryption strategy.

Blockchain Module ( 3. in figure)

The blockchain module abstracts the underlying blockchain implementation. The out of box adapter interfaces with the Ethereum Blockchain. In order to deal with mobile environments with limited bandwidth and intermittent connections, the service maintains limited state (i.e. it does not implement Geth Light Node Protocols). Rather, the implementation leverages 3rd party http providers to monitor the blockchain and to submit raw transactions constructed on mobile.

Framework Advantages

GoNetworks framework eliminates trust during the transaction (TX) lifecycle; TX creation and signing are completed off-chain within the context of the framework. In essence, a users private key is never entrusted to a third party.

Furthermore, the framework implements an adapter based approach, making it a viable off-chain state channel solution for differing transport and blockchain implementations. We outline some abstract components that may be extended below:

i) Implement the transport interface to integrate new transport layers

E.g. use a messaging API from FB, Telegram, etc. (adhering to their terms of service of course)

ii) Implement blockchain interface to integrate other blockchains besides Ethereum

iii) Implement custom key retrieval with signature callbacks

E.g. the private key is AES encrypted locally on the device and requires user password or biometric input

iv) Out-of-band communication (e.g. send locked transfer over MQTT, reveal secret with QR Code)

Future blog posts will delve into the inner workings of the various modules; how they operate and their nuances (not to be confused with nonce).

Current Development Strategy

Developer adoption is driven by dev tools that reduce time complexity of implementation and integration. Though we will continue to enhance and improve the gonetwork-framework, we have expanded our efforts towards GoNetwork Simulator.

The current framework release specifically targets React and React-Native development environments with typescript. With that in mind, the simulator itself is developed as a React Native mobile app embedding the gonetwork-framework and aims to deliver:

Rapid initialization of an end to end state channel network for local testing.
Developer walkthroughs
Overview on key state channel concepts
Working code samples and snippets to kickstart app integration
Interactive demonstration of key features of the framework

It is actively being developed, please watch for updates on our github projects page.

Lets Run the Engine

Ok, so we talked a bit about the engine, sometimes it’s best to see things in action. The engine packages a few crude test clients. By default, the test clients connect to a publicly available mqtt server, but feel free to modify this in the source file to whatever broker service you prefer (both the client1 and client2 must be modified accordingly).

In this particular example, we wont simulate any of the blockchain setup interactions² (i.e. creating the channel, approving the channel, depositing). We will instead opt to emulate the events that the blockchain-service would emit to the engine.

git clone https://github.com/gonetwork-project/gonetwork-framework.git

cd into the cloned directory and run

npm install
npm run compile

this will compile the typescript framework code into the /lib directory for use

Test mediated Transfer

The mediated transfer client demo showcases orchestration and coordination of the target and initiator state machines by sending many in-flight locked transfers and maintaining state consistency. This demo requires 2 terminals to execute.

In terminal #1:

node test/throughput/client2-mediated.js

in terminal #2 run:

node test/throughput/client1-mediated.js

This test highlights the handshake and exchange of messages between the 2 clients during a locked transfer exchange. 21 units are transferred from client1 to client2.

the output from client2-mediated.js will include the following output:

...
nonce: <BN: 2a>, 
...
transferredAmount: <BN: 15>, //0x15 = 21 in base 10
...

Test Direct Transfers

You can also test direct transfers between two clients. Kill the previous processes e.g. ctrl+C.

In terminal #1 run:

node test/throughput/client2.js

in terminal #2 execute:

node test/throughput/client1.js

At the end of the test run, each terminal will output their transactions per second (TPS)

Using our Macbook Pro:

2.8 GHz Intel Core i7

16 GB 2133 MHz LPDDR3

We achieved the following metrics between channel participants:

Client 1: Direct Transfers Sent Per SECOND per USER 1824.817518248175Client 2: Direct Transfers Processed Per SECOND per USER 142.49073810202339

Conclusion

Overall, there are many exciting developments to come when we consider L2 scaling from the industry. We aim to contribute as much as they have to the community. Lastly, much of our work would not be possible without the hard work and contributions of many individuals and teams in the space, but we’d like to extend our personal gratitude to the etherumjs contributors whose libraries made our visions possible.

1. Inspiration and Background

State Channel Design Overview

To begin, we list influential reads of varying depth that were instrumental in our conception of a state channel solution:

Each of the papers built upon and refined the state channel concepts. Today we see the focus shifting to channel factories and generalized state channel implementations with counter factual systems. One thing is certain, the fundamental building block for all these implementations rely on the Hashed Time Lock Contract (HTLC) primitive. As such, HTLC’s were considered an essential milestone of our initial framework release.

We considered 2 implementation strategies for State Channels:

Poon-Dryja payment channel style with a secret reveal mechanism and penalty for presenting old state, this is outlined in Lightning Specification
Raiden Networks state channels akin to Decker-Wattenhofer duplex payment channels; a composition of 2 simplex channels with no penalty but requiring monotonically increasing states.

Both implementations strategies allow for indefinite channel lifetime. The advantage of Lightning style channels is there ability to cope with generalized state updates with ordering enforced with penalties.

On the other hand, Raiden style channels are “forgiving” insofar as they don’t explicitly penalize an actor for stale state submission. As the state is always monotonically increasing, the faulty actor incurs a loss of any value transfer sent ahead of the state presented. From a game theory perspective, a rational actor will always aim to submit the latest state as it ensures them the greatest value.

More so, Raiden Channels can transmit state asynchronously with the use of merkle trees. If the state has commutative properties, many in-flight locked transfers may be initiated and completed out of order or cancelled. When dealing with ERC20 token transfers, the locked value transfers are not Idempotent, thus care must be taken to apply the locked transfer only once.

Transport Layer Design Overview

When considering the transport layer implementation, we Initially considered leveraging webRTC. However, webRTC like most p2p networks suffer from NAT-Traversal problems which is further exacerbated by gsm networks that rarely expose device ports. WEBRTC falls back to ICE or STUN protocols which tend to be central servers. Lastly, the webRTC support across varying platforms is limited at the time of development.

We then considered a pub/sub network implementation which greatly reduces complexity. IOT (Internet of Things) devices leverage a pub/sub broker MQTT (http://mqtt.org/) which is an oasis standard. There are many FOSS licensed implementations (e.g. https://mosquitto.org/) that are also supported across all major hardware specs.

The transport layer leverages MQTT for simplicity and library availability across our target native platforms.

2. The repo’s test folder includes scripts to run all the blockchain interactions as well, refer to /test-manual/ropsten-manual-test.js which requires some