How is Hierarchical Consensus different from traditional L2 solutions?

[adlrocha]

This is a fair question that many people ask when they come across HC for the first time. The goal of this discussion is to debate how our proposals is similar or differs from existing L2 solutions. In the process we may collect a lot of references to related work, challenge our assumptions, and get inspiration with ways to improve the protocol.

The analysis will be populated in the next few days, feel free to contribute with your own.

[aakoshh]

My take on it was #155 (reply in thread)

[LefKok]

HC is a framework where depending on how we parametrize it we can get different L1/L2 constructions. The cool thing with HC is that the users can define the trade-off they go for and they can also communicate easily with other subnets flexibly as long as they trust the security of the other subnet. For example:

The obvious connection is that we can build sidechains using HC. In a bit more detail, when we spawn a subnet if we look from the perspective of the child subnet it is relying on the security of the parent (like a sidechain) for anchoring so, similar to sidechains, a light-client can check the periodical commitments on the parent for added security or trust the subnet. Additionally the parentnet can be used for fraud-proofs and zk-proofs in-case of an exit and also similar to the PoS sidechain paper the parent can be firewalled from the child. In HC this composes recursively but we can look at each pairwise relationship as a mainnet/sidechain pair.

However, we can also build rollups with HC. We can define a DA requirement for a subnet saying "need to post all blocks on parent" or "every block is a checkpoint". Then the child-net is actually the decentralized sequencer of the rollup. Pushing it even more two parties can start their own subnet as a payment/state channel and play chess. So all in all HC is a generalized framework for scaling a base chain and allows users to chose their preferred scalability/performance/security tradeoff.

Additionally, HC supports bridges between subnets, again here we have currently take one path for bridging through verifying the subnet decision but we can easily support other constructions (https://eprint.iacr.org/2019/1128.pdf)

[daviddias]

"HC is a framework where depending on how we parametrize it we can get different L1/L2 constructions."

This is very much my understanding as well. Which I believe begs the question: If we were to define the HC as API, can it be mounted on top of ETHs L2s? With that, what obviously is missing? (I'm sure a lot of things, but I personally struggle when there is no way to understand what gaps are and what has to be done at the protocol level vs. at the API/thin veneer level)

[adlrocha]

I think that we already have all the basic pieces for L2s to be implemented (or "be mounted") on top of IPC. In the end, L2s are comprised by a sidechain for execution, and a mechanism to commit (and optionally batch) these executions into L1 to anchor their trust. In IPC, subnets represent the execution sidechain (they can have their own consensus rules and economics), and our checkpoints are the "pipes" enabling this communication of commitments or batches to L1 (in our case subnets' parents or the rootnet). These pieces designs are general enough to support these use cases.

However, IPC has an advantage over existing L2s: it offers interoperability by design (there's no need to implement specific bridges to exchange assets from/to the execution (L2) and the consensus (L1) layers) as atomic executions between subnets are supported by design. Furthermore, all the subnets are force to implement the same interfaces, enabling a seamless interaction between them (if needed). I feel this basic but general architecture could open the door to more complex protocols built on top of it.

[anorth]

I think the terminology matter here, and in existing ecosystems sidechain != L2. A sidechain is responsible for its own security (e.g. through a consensus mechanism) while a real L2 inherits its security from the parent chain. A sidechain is not an L2. An L2 is meaningfully superior in that it's security cannot be compromised by the sequencer/validator(s) of the L2. This is very different to a sidechain, and what I understand of the proposals here, because users of a sidechain can be attacked by the validators of that chain, with no recourse to the parent chain.

If you wanted to say that HC is just a label for the pattern of independent execution environments, with various security anchors or not into higher level chains, I'd have no objection – we'd just be labelling an established pattern. But I suspect you want something different.

Interop is where I see there might be something new and valuable here. Rather than "there's no bridges" my impression is that you're designing in a generic bridge that chains can use. I would prefer to rephrase "subnets are forced to implement the same interfaces" to perhaps "subnets, sidechains and L2s that implement X interface can use this bridge". I think a really productive comparison would be against other bridging approaches (including interop protocols like Cosmos IBC), rather than other hierarchical execution approaches. Bridge design is really hard, IMO not securely solved yet anywhere.

[adlrocha]

A sidechain is not an L2. An L2 is meaningfully superior in that it's security cannot be compromised by the sequencer/validator(s) of the L2.

You are right. Sidechain may have not been the best naming for the analogy I was trying to make. I think what I was trying to convey is better described in your sentence: "HC is just a label for the pattern of independent execution environments, with various security anchors or not into higher level chains". I was focusing the comparison in this thread exclusively on L2s to answer to @daviddias' point, but I agree that we should also consider bridges and interop projects for the comparison and document it here (already added to our backlog).
And I really like how you summarise their relationship here: ""subnets, sidechains and L2s that implement X interface can use this bridge"".

🙏

[LefKok]

I agree that IPC does not build sidechains since the current design makes sure that IPC is secured by the parent but also protects the parent through rules such as conservation of value. This can become even stronger when IPC is integrated with Lurk as this will look closer to a zk-rollup with each own DA layer than a sidechain.