A cyclic superhub is simply a group of three or more nodes that have specifically arranged their channels to form a cycle.
A--->B ^ | | | | v C<---D
The concept applies to such topologies that have been deliberately set up to form cycles, not simply those, that happen to arise as happy accidents.
Here are a few important observation, about cyclic superhubs:
- Any member of the superhub can pay any other member.
- As a consequence, any member of the hub can send via an outgoing channel of any other member.
- As another consequence, any member of the hub can receive via an incoming channel of any other member.
Organizing by cyclic superhubs has the advantage that it reduces centralization of the network, and allows any member to send and receive, for only the cost of setting up a channel.
Suppose a superhub member goes down permanently or even temporarily, or closes one of its channels. This breaks the topology and prevents payments from an arbitrary member to an arbitrary member.
A--->B ^ | | | | v C D
Even so, such broken superhubs still allow some connectivity among the other members. Superhubs may be more likely to have breakdowns than using a central hub, but superhubs “fail gracefully”; if a member breaks down, some transfers can still occur. Compare this to a central hub, where a breakdown of the center prevents all transfers.
Nodes are incentivized, to join as many superhubs as they can afford to open channels with. This is because, if a node is a member of two such superhubs, then it serves as a bridge between them, earning fees for transfers between members of one superhub to members of the other superhub.
In addition, joining multiple superhubs improves the chances that a node can successfully send or receive payment, in case, one of the superhubs it is a member of becomes broken.
Finally, if a node joins multiple superhubs, it is likely to effectively form a superhub “by accident”. Consider the case where we have 6 nodes below, 3 of which join only one superhub, but 3 of which join two superhubs:
A-->B D-->E B-->C ^ / | / ^ / | / | / | / |L |L |L D F E
If we combine the above to their overall topology:
A-->B-->C ^ /^ / | / | / |L |L D-->E ^ / | / |L F
Nodes B, D, and E joined only two superhubs, but have also managed to form a superhub, by accident, between them.
B /^ / | L | D-->E
Note also that even the “edge” nodes A, C, and F now become members of a larger superhub of 6 members. This is relevant in case of a “graceful failure” of a superhub: if for instance the channel between B and D is closed, A can still pay D via the longer route A->B->C->E->F->D.
Thus, nodes will want to join as many superhubs as they can afford to put into channels, as it makes it more likely they can earn, and more likely that their sends and receives succeed.
Unfortunately some amount of coordination is needed to form superhubs in the first place. The nodes who want to form a superhub need to agree on which node creates channels to which other node.
One can imagine that websites specifically for coordinating the formation of superhubs can be made. They would look at the existing known topology and allow users to request to join superhubs, then create plans for superhubs (who funds channels to who) for users who do not already have channels to each other.
Such coordination services are not centralizing. It is very cheap and not so inconvenient to simply post on some Lightning Network-focused forum and say “come form a cyclic superhub with me!”, with the rule that the first 5 or so replyers form the superhub with the original poster, and funding channels to the previous poster and with the original poster funding a channel to the fifth replyer.
Encouraging cyclic superhubs encourages the formation of a grid-like network, which has the major advantage of having many alternate routes between different points. Thus we should encourage all sorts of nodes — consumers, employees, merchants, etc. — to become members of superhubs, instead of encouraging “hub and spoke” models.