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.907 which 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.

Opening a Channel

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.

Creating a transaction

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.

Rejecting a transaction

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.

Closing a channel

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.

Conclusion

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.

Frequently asked questions:

I thought The Tangle could scale, why do we need Flash Channels?

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.

If my transactions usually confirms in 2 minutes, why would I need transaction speeds faster than that?

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.

Do I need special tokens to use Flash Channels?

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.

How much does opening a channel cost?

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.

How does routing work?

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.

Do you require special nodes or network updates for this 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 software to operate alongside the Bitcoin blockchain.

How fast are Flash Channels?

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.

How long does it take to Open/Close a channel?

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.

Wait, I thought that IOTA didn’t have timelocks or smart contract?

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.

How do economic incentives stop scammers and thieves?

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.

What are some of the use cases of Flash Channels?

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: