Channel Factory

From lightningwiki.net
Jump to: navigation, search
TODO

You can help by adding more information. Suggestion: Rewrite to better understandable language.

Channel Factories allow multiple users to open unlimited intra-group channels.

A Channel Factory is a multiparticipant non-custodial cryptocurrency system that contains channels.

Blockchains as multiparticipant cryptocurrency system[edit]

A blockchain manages a state called the "UTXO set". The UTXO set is effectively a multimap from addresses (which may represent singlesig pubkeys or multisig pubkeys) to Bitcoin values. Each transaction deletes some entries in this multimap and creates new entries. For example, suppose ZmnSCPxj owes KEabZAYi 1.0 BTC. Suppose currently the UTXO set contains "ZmnSCPxj: 2.0". ZmnSCPxj can create a transaction and have the blockchain system process it, then the UTXO set then contains "ZmnSCPxj: 1.0, KEabZAYi: 1.0". Each blockchain transaction effectively is an update to the state of the UTXO set.

Blockchains have open membership sets (anyone can participate), but with the drawback that any increase in its processing capacity translates to a decrease in its openness and usability.

Channels as multiparticipant cryptocurrency systems[edit]

A channel is a multiparticipant cryptocurrency system which is similar to a blockchain, except with a fixed membership set. It can also only be updated if all participants are online and willing to continue updating (the rules of the channel are imposed by the participants by refusing to participate in invalid updates). Finally, a channel can fall back to a lower-level cryptocurrency system (such as a blockchain) in order to enforce any rules by forcing enforcement to a lower-level system.

For example, suppose ZmnSCPxj and KEabZAYi have a channel originally created by ZmnSCPxj. On the blokchain level, the blockchain sees something like "ZmnSCPxj+KEabZAYi: 2.0". However, inside the channel, both ZmnSCPxj and KEabZAYi have agreed that the state is "ZmnSCPxj: 2.0, KEabZAYi: 0.0". Suppose that ZmnSCPxj owes KEabZAYi 1.0 BTC. Then both of them can agree that new channel state is "ZmnSCPxj: 1.0, KEabZAYi: 1.0". After both of them agree on the update, however, only the channel state is changed; the state of the blockchain is not changed and there is no transaction made on the blockchain layer. The blockchain layer remains with the state "ZmnSCPxj+KEabZAYi: 2.0".

The security of a channel is dependent on each user looking out for its own interests and refusing to allow updates that it does not intend. For example, even if KEabZAYi proposes to change the state to "ZmnSCPxj: 0.0, KEabZAYi: 2.0" afterwards, if ZmnSCPxj is not intending to pay that, then ZmnSCPxj will simply refuse to sign the new state and the channel state does not change.

Because channel security is based on self-interest rather than trust in some custodian, there is no need for a large membership set (like those required for custodial systems like federated sidechains) in the hope that the majority of the membership set is honest (and without having to hope that the members are not sybils). Instead, simply being able to veto any invalid updates is enough. Thus, channels may safely have as few as 2 participants. In fact, 2 participants is ideal since every participant of the channel must be online in order to update the channel state; it is far more likely that 2 participants are online, than 3 or 4 or more.

Channel factories as channels within channels[edit]

Of note is that a channel itself, while needing some other cryptocurrency system to fall back to, imposes nothing else on the lower-layer cryptocurrency system other than the ability to assign money to a multisignature address.

Now suppose we have a channel with three participants, ZmnSCPxj, KEabZAYi, and AoywPQUw. At the blockchain layer, it might be represented as the UTXO "ZmnSCPxj+KEabZAYi+AoywPQUw: 4.0". However, inside this 3-participant channel, it might have the state "ZmnSCPxj: 4.0, KEabZAYi: 0, AoywPQUw: 0".

Now suppose ZmnSCPxj proposes to create two channels inside the 3-participant channel, and all participants agree that such an operation is valid. So now the 3-participant channel contains the state "ZmnSCPxj+KEabZAYi: 2.0, ZmnSCPxj+AoywPQUw: 1.0, ZmnSCPxj: 1.0, KEabZAYi: 0, AoywPQUw: 0".

The two sub-channels inside the larger 3-participant channels have their own state indepedently of each other and of the 3-participant channel. The ZmnSCPxj+KEabZAYi channel would have the state "ZmnSCPxj: 2, KEabZAYi: 0", while the ZmnSCPxj+AoywPQUw channel would have the state "ZmnSCPxj: 1, AoywPQUw: 0". The 3-participant channel, since it creates factories, is now actually a channel factory.

Suppose AoywPQUw goes offline (for example, went to sleep). In that case, the 3-participant channel (the channel factory) is "locked" and its state cannot change. Now suppose ZmnSCPxj wants to pay KEabZAYi 1 BTC. Since AoywPQUw is offline, ZmnSCPxj cannot change the state of the 3-participant channel to "ZmnSCPxj+KEabZAYi: 2.0, ZmnSCPxj+AoywPQUw: 1.0, ZmnSCPxj: 0, KEabZAYi: 1.0, AoywPQUw: 0". However, ZmnSCPxj can change the state of the ZmnSCPxj+KEabZAYi subchannel to "ZmnSCPxj: 1.0, KEabZAYi: 1.0". This is because this sub-channel only requires the participation of ZmnSCPxj and KEabZAYi to update.

Thus, channel factories, by splitting up a multiparticipant channel to multiple 2-participant channels, give the advantage of 2-participant channels (i.e. only need two participants to be online to work).

At the same time, even though there are two channels (the ZmnSCPxj+KEabZAYi channel and the ZmnSCPxj+AoywPQUw channel), at the blockchain layer, only one UTXO is needed ("ZmnSCPxj+KEabZAYi+AoywPQUw: 4.0"). This reduces the capacity used on the blockchain layer.

If a channel factory had even more members, there may be dozens of channels hanging off a single blockchain UTXO, greatly multiplying the capacity of the blockchain for Lightning Network operation.

Links / resources[edit]

https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf