Developer Update #14 — 11.26.2019
Hi everyone! It has been a while since our last developer update, but we have been busy across all fronts. This developer update is meant to give a glimpse at some of the projects we have been tackling recently and highlight the direction that we’re going in.
The goal of the State Channels project is to provide a secure, well-thought out base for applications and wallets that use state channels. Our hope is that dapps and wallets may use our reference clients & fundamental research with a high degree of certainty about the security guarantees we provide.
Here are our most recent updates about our team, our engineering, and our research, along with notes on where we’re heading next.
👨👩👦👦 Team
Magmo Joins Consensys
As part of a push to ensure long term funding is dedicated to high quality state channels research and development, Consensys is officially backing the State Channels project by supporting the Magmo team’s development.
🛠 Engineering
Implementation of Client API
The Counterfactual Playground, built earlier this year, was designed for browser based applications to interact with a wallet in a separate process. To do this it used cf.js to send JSON-RPC structured messages to a node process running outside the scope of the application (i.e., in a parent window of an iframe). So far, with the @statechannels/wallet that we are building to replace the node, we have not had this kind of communication pattern. However, recently we have designed an API and begun implementing it in expectation of applying it to a demo application we’ll be releasing soon. You can see the early version of the API docs here.
Asset Holders
To decouple channel adjudication from on-chain asset transfers, we have introduced a new type of contract called an AssetHolder. This is a generic interface which can represent bulk ownership of any kind of asset on Ethereum. Now, funds allocated to a particular state channel are held within an AssetHolder and are locked based on the outcome of a channel.
Optimized withdrawal functions
Previously, withdrawing funds from a channel required three on-chain transactions. One to conclude the channel on the adjudicator, one to set the outcome on-chain, and one to send the funds to the correct owners based on the outcome. With the addition of the AssetHolder, this would have added a fourth to update the AssetHolder with the adjudicator’s outcome. To avoid this, we have optimized the contracts to do all of these operations in a single transaction called concludePushOutcomeAndTransferAll. This has also been implemented in the wallet.
Gas Optimizations
Recently, we re-wrote the entire Solidity contracts codebase to be gas optimized throughout. The result of this optimization has yielded the following new metrics:
Happy Path (deposit, collaborative-close, withdraw)
- Previously: 612k gas
- Now: 165k (ETH) / 185k (ERC20)
Challenge path (challenge, respond)
- Previously: 1100k gas
- Now: 200k gas
Following this the wallet codebase has also been in the process of upgrading all of its functionality to support the new contracts. Most of the upgrading has consisted of either storing new data structures that previously could have been relied upon to exist on-chain, or reading event data from the chain which has replaced the on-chain storage as the data availability layer.
Connext on Mainnet
In September, Connext officially launched their V2.0 on mainnet; built on State Channels v1.0 (formerly Counterfactual). This is a tremendous milestone as it shows that the full tech stack provided by State Channels is supported in a major production use case. Since the launch, there has been continuous development on the Connext and State Channel clients, with all feedback being folded into the new wallet being built under State Channels v 2.0 which is being designed with an upgrade path in mind.
In-Browser EVM Execution of pure State Transitions
Because all state transitions in a state channel can be validated via pure functions, we are now validating these using an in-browser EVM implementation which is significantly faster than making an eth_call to an Infura node.
📝 Research
TLA+ Specification
Recently, we wrote the ForceMove protocol in a formal specification language called TLA+. This allowed us to find many interesting optimizations to the protocol and identify unintuitive attack vectors. For example, our work on TLA+ led to the introduction of a new method on the protocol called checkpoint. You can read more about that on our research forum. We are also working on an in-depth analysis of this work to be shared soon!
Turn-Taking Optimizations
Another area of research has led us to explore optimized protocols for achieving consensus on a state update in scenarios where no state machine explicitly describes the rules of the application outside of the base-level rules of ForceMove. We discuss this in a research post titled: Could/should a wallet move away from turn-taking for consensus updates?
Browser Tab Based Security Policies
To ensure that your browser is able to safely navigate to any website domain and allow that domain to interact with your state channels wallet, we are working on an approach to browser based budgets. These allow your browser to allocate some fixed amount of your capital in the state channel to that tab, so that it may operate on your behalf without disruptive popups.
🔭 What to Look Forward to
- We’re actively working on two demo applications at the moment. These will be built entirely on top of the Client API and run in the browser through our reference hub. More info soon!
- Soon, we will be releasing a report on our TLA+ specification work. We think this will be useful for other layer 2 scaling protocols to consider doing as well.
💬 Get In Touch
Want to contribute? We’re hiring.
We’re actively working on several interesting problems right now including:
- Building a browser-based wallet that works securely in production
- Designing and implementing a virtual channels hub for mass usage
- Designing and implementing a client API for JavaScript apps
- Formal specification and verification that our protocol is correct
If you’re interested in any of these problems, please reach out to us, dive into our GitHub, or contribute on the research forum.
Join the discussion
Our research forum is the home for in-depth questions about state channels. If you want to contribute or even just learn, please create an account and ask away on research.statechannels.org.
