Connext v0.3 Developer Update
Ma, we made it!
Hello, hello! We’re back with more exciting updates about our progress. Without further ado,
🎉100% Complete Virtual Channel Implementation on Rinkeby!
You’re probably thinking to yourself, “how is this different from what you guys finished last update?” Let us break it down for you:
Two weeks ago, we finished the “happy case” for creating, using and closing Virtual Channels (VCs). In the happy case, a new “meta” channel (between Alice/Bob) is created from two existing state channels (between Alice/Ingrid and Ingrid/Bob). Alice and Bob are then able to transact freely between each other even though they don’t technically have a state channel open between them because they know that, at some point in the future, their transactions can be decomposed into two sets of transactions in the Alice/Ingrid and Ingrid/Bob channels.
This all works great while Alice, Bob and the intermediary, Ingrid, play nice with each other. What happens if someone tries to cheat? That’s when one of the dispute cases are triggered.
For example, Dispute 1 occurs when Alice/Bob’s virtual channel is closing, but no double signed (final) update is available that Ingrid can decompose into updates in the Alice/Ingrid and Ingrid/Bob channels. Here, Ingrid calls a contract function, vcCloseInit, which sets a timeout period by which Alice and Bob need to submit an update. If they fail to do so, Ingrid can then call vcCloseInitTimeout, which forcibly closes the virtual channel on chain with the original balances.
What happens if Ingrid lies about this dispute (i.e. Ingrid tries to penalize Alice and Bob for a channel that is already closed)? Alice and Bob can, in return, dispute Ingrid’s dispute (🙃) and submit proof to the contract that the VC was already closed in the form of the VC’s opening certificate — which contains information on the longevity of the VC.
This is just one dispute case out of the many many possible ways that Alice, Bob or Ingrid could act outside of their expected behavior. You might notice, however, that the ultimate “fallback” in these cases is to call a contract function to “register” the VC to the blockchain and then resolve the dispute with the contract acting as the mediator. Because doing this costs gas and takes time, there is a natural disincentive to use the “fallback” and so well designed dispute resolution mechanisms — and, by extension, well-written dispute resolution code — almost never needs to be used.
tl;dr Connext’s Virtual Channels now handle all possible dispute cases! 🙌 Code can be found here.
As we’ve mentioned before, the vast majority of the work needed to make state channels work in production has to happen off-chain. For a dApp, protocol or exchange that wants to integrate state channels, this means an automated intermediary server that can open/close channels, efficiently handle transactions and resolve disputes.
This is why we built Ingrid. 💁
Ingrid is a one-click-deploy server that sets you up to be a virtual channel hub. Along with the Connext client package, which is integrated on your frontend, Ingrid is one of the two critical pieces of infrastructure that you need to use to get started with Connext.
As you can see above, Ingrid listens for changes to virtual channels and reacts appropriately. Ingrid is programmed to be a “greedy” actor so that, when possible, the server will always act in the best interest of the dApp. This works because, conversely, we’ve design our client packages to always act in the best interest of end users.
More on how Ingrid works and integration documentation coming soon!👊
That’s all for this week, but we have some exciting ~surprises~ in the pipeline in the next couple of weeks so definitely keep watching this blog to stay up to date!