Instant & Feeless— Flash Channels
Update: Flash channels are deprecated in their current state. We aim to reintroduce Flash Channels as a part of future GoShimmer milestones. For more information look at our docs.
The goal of the IOTA Foundation is it to build a flourishing Machine Economy, where machines seamlessly interact and transact with each other. With IOTA, we have introduced the first scalable distributed ledger architecture that has no transaction fees and is able to run in the Internet of Things environment. The power of IOTA is in its network, as it scales horizontally with the number of network participants transacting with each other.
Over the recent years, Layer-2 solutions (such as Bitcoin’s Lightning Network, and Ethereum’s Raiden) became a popular solution to enable fast transactions with lower transaction fees for conventional Blockchains. During the last months, the IOTA Team (most prominently Paul Handy, Lewis Freiberg and Chris Dukakis) have been working diligently to develop a similar approach in IOTA as an ad-hoc solution: Flash channels.
Flash is a bi-directional off-Tangle payment channel to enable instantaneous, high-throughput transactions. In essence, they provide a way for parties to transact at high frequency without waiting for each transaction to confirm on the public IOTA network. Instead, only two transactions will ever occur on the main IOTA network: opening and closing transactions of the Flash channel. An off-Tangle approach reduces the per-transaction overhead to a negligible level by creating signed transactions off the tangle and opens up a feeless transaction model for instant, token streaming.
When a channel is created each party deposits an equal amount of IOTA into a multi-signature address controlled by all parties. Once the initial deposits are confirmed the channel does not need to interact with the network until it is closed.
Once the parties have finished transacting, the final balances are published to the network. This approach can reduce thousands of transactions down to just two transactions.
Flash channels rely on an equal incentive for parties to participate in the channel in good faith. Incentives are required, like with any multi-signature scenario, as a signing party may refuse to continue signing transactions.
Flash combats this by reducing the total amount of transactable tokens within the channel as they are used. This reduces the incentive for a party to attach a previous transaction bundle as they will never achieve a better outcome than the channel’s most recent state.
To illustrate, assume that two parties enter a channel with 50 tokens each — the pool would control 100 tokens, but only 50 tokens will ever be transacted in the channel. When one user wants to send 5 tokens to the other, they also release 5 tokens to them, such that each party would consider that they still have a controlling interest of 45 tokens. Another way of looking at it, is that if one user proposes to send 10 tokens to the other, the other would consider that as a payment of 5 tokens. As future transactions are signed, the amount in each of these chosen output addresses shall only go up, whereas the amount sent to the remainder address shall only go down.
The remainder is also used as collateral to stop a premature exit from the channel. If a party refuses to close the channel, the latest signed bundle can be attached to the tangle which will deposit the remainder into a multi-sig address. When the parties have agreed on a reasonable outcome they can access the address and distribute funds — both sides have a stake in coming to a resolution, as a stalemate will result in lost funds.
To demonstrate how Flash Channels work we’ve built a Proof of Concept application for you to try out with a friend. This demo uses WebRTC to connect directly to your partner and allows you to transact off tangle until you decide finalise the channel.
The demo will have 2 Ki testnet tokens deposited into it for demonstration purposes. What’s very unique about this demo is that the hashing, signing, Proof of Work and the interactions with the IOTA network are all happening in real-time inside your browser.
You can test the demo here. You must have WebGL enabled to use this demo (Note: This is best experienced on a desktop. The use of VPNs can block the WebRTC connection).
Flash uses a tree topology to reduce the number of transactions to be attached. Usually each transfer would have to be attached to the tangle, requiring a large amount of PoW.
This approach takes advantage of the fact that an address can be used twice while remaining reasonably secure. This lets us build a tree, where the leaves (the very bottom of the tree) are the individual transactions that will occur in the Flash channel.
The maximum number of transactions required to settle a Flash channel relates directly to the depth of the tree. The depth is determined by first assessing the number of individual transactions that will occur offline within the Flash channel then applying log2(x)to that number.
For example: if you require a 60 transaction channel you’ll require a tree with a depth 6 as log2(60) = 5.907which we will round up to a depth of 6.
Each time you create a transaction you move left to right along the bottom of the tree. If a parent node has been used twice then the transaction will have to shift to the parent’s sibling and generate a bundle for that node.
For example: In the above binary tree, to create a transaction we generate the bundles required to reach 16.In this case bundles 1,2,4,8 & 16 must be generated. To create the next transaction we then move across to 17, 18, etc. As we move across the tree, we generate only the bundles required to reach the new leaf bundle.
Once the depth of the channel, the initial deposit amount of each user and the final settlement addresses for the channel participants have been entered, an initial transaction is created within the Flash channel. This transaction generates bundles for each node down the tree and then a final bundle with all of the channel’s IOTA deposited into a remainder address.
At this point a deposit address (root of the binary tree) is displayed. Users must deposit the amount agreed upon and wait for the transfers to be confirmed before they start transacting in the channel.
When creating a new transaction in the channel a user must construct a bundle and propose it to the other parties in the channel. After reviewing and confirming the proposed bundle, the users will generate and return the signatures. Once both parties have each other’s signatures they validate the bundle’s signatures and then change their local channel balances.
When constructing a new transaction bundle the Flash library will add the new transaction’s value to the desired users balance and then place the remaining channel balance in the remainder address.
When transacting in the channel each user has an equal right to refuse the transaction occurring. If a user receives a proposed transaction that they do not agree with, they reject it by not signing the bundle.
Channels can also be setup to be M of N multisigs. This means that in a Flash channel of 3 users only 2 might be required to create a transaction. This is useful for cases that may want a trusted intermediary to assist in channel disputes.
To close a channel, the proposing user constructs a bundle that does not propose a new value transfer. Instead they take the remaining channel balance and divide it amongst the channel’s users according to the proportion of the user deposit when the channel was opened. During this process the user finds the least amount of bundles required to close the channel.
The other users in the channel then check the bundles then return signature or reject the closing bundles. These bundles are then attached to the network.
Flash channels is the first module to extend IOTA’s core capabilities to enable real time streaming of transactions. This functionality perfectly pairs with the fast and free settlement of the IOTA network for new and disruptive applications in the field of the Internet of Things and beyond.
At the moment, Flash is in beta, but we encourage application developers to start integrating it into their applications and provide us early feedback. Some of the first applications based on Flash that we’ve built together with partner companies will go live in October, so stay tuned.
For more info and the Flash Channels library please click here.
The Tangle is scalable thanks to its novel approach to distributed ledgers. Because of its approach to consensus, each transacting user has to complete to a nominal amount of Proof of Work. This work is minimal but requires time to complete. Flash removes this by moving the transactions off-network until they are attached, potentially reducing thousands of transactions to two transaction.
Overall, IOTA is for general purpose transacting; whereas Flash is for use-case specific applications where token streaming between two parties is required.
Flash Channels are the current answer to a small subset of transactions situations. It is useful for situations where you might want to stream content: pay per second of video or car charging. Alternatively, settlement between financial institutions and a consumer could be dropped to sub-second speeds: point of sale or online purchases.
To use Flash you use plain old IOTA tokens within the channels. No extra tokens required to pay for fees since the network is free.
Since IOTA is feeless, opening and closing channels are free. This means that you can create Flash Channels for short periods of time or with small balances since there are no fees when opening/closing channels.
Flash is not concerned with routing. IOTA is feeless, therefore you are free to open as many Flash channels as you want with partners. This removes a complex routing requirement that would eventually lead to centralisation.
In the demo, we use WebRTC to connect you directly to your channel partner. The server only acts to serve the web page and connect the peers initially. No intermediaries are required for the channel to work.
No. Flash defines a specific way that two or more users should interact around a multisig wallet.
This contrasts with other attempts at instant payment networks. For example, Bitcoin’s Lighting Network requires a parallel routing network using custom softwareto operate alongside the Bitcoin blockchain.
Flash Channels are limited by the time it takes for all parties in a channel to sign the proposed bundle and return signatures to all parties. This only takes milliseconds to complete when you aren’t waiting for users to manually confirm transactions.
Since Flash uses standard transactions for opening and closing, you could expect the average confirmation of the network. At the time of writing it is about 3 minutes on average. As the network grows this time will drop.
We don’t (at the moment 😉), instead Flash relies on an simple use of economic incentives. Once timestamps are enforced, we will introduce timelocks to Flash.
When you enter into a Flash channel you define the amount of collateral you will add to the channel. If you are starting a channel with an unknown partner you may open a low value channel or require the unknown partner to deposit a larger collateral into the channel.
If there is a dispute part way through a channel, a user can release the funds that have been approved during transactions by attaching the most recent channel state. The remaining funds will be deposited into the remainder address (generated at channel opening). These funds will remain here until both users agree to a division of funds and then sign a transaction releasing them.
Any application that requires instant, bi-directional transactions between two parties. Some of these use cases include EV Charging, Bandwidth on Demand, Other Resources On-Demand (such as Computation, Storage etc.), Pay per Article, and many others. One example that was recently presented by Carsten Stöcker at our Berlin Meetup can be seen below:
