Dynamic Proof of Consensus via Composition of Multiple Bridging Protocols

This document seeks to describe a Proof of Consensus that is composed of different Proofs of Consensus for the Gasper protocol. The motivation behind this is because all the different Proof of Consensus protocols have varying tradeoffs that are different between them.

There is an assumption that the reader already has a very basic understanding of Proof of Consensus, Fault Proofs, and ZKP.

Proof of Consensus Properties

Bridges today can be catagorized by many different properties. The main properies that are important for DPoC are trustless, speed, cost, and permissionless. To establish common ground, let establish rough definitions of these properties:

Trustless describes someones ability to verify the validity of the state of the system. Trustless-ness can be described on a spectrum, ranging from fully trustful to partially trustful to optimistically trustless to fully trustless.
Speed describes how long it takes for someone to decide that some cross chain interaction will not reverted. This is can be very context dependant according to the users risk profile and will be examined more when investigating and catagorizing existing Proof of Consensus protocols.
Cost describes how much it takes to maintain the Proof of Consensus protocol.
Permissionless describes whether participation in Proof of Consensus is open or not.

Existing Proof of Consensus Protocols

Now that important properties have been established and roughly defined, it is useful to examine some existing protocols and see the tradeoffs between them. Generally, when talking about Proof of Consensus the two approaches that come to mind for most are Proof of Consensus via ZKP and Proof of Consensus via Fault Proofs (also known as the Optimistic approach).

To fully understand the tradeoffs between the two approaches, it will be more clear to exam their properies separately and in depth.

Trustless

One of the reasons for the recent interest and excitement about Proof of Consensus is the idea that these protocols are generally fully trustless or at least trust minimized.

In the ZKP approach, state from/about some source chain that has been posted onto a target chain can be known to be correct at the time of relaying. This is achieved through submitting a ZK proof showing that the posted state was computed correctly with respect to some previously posted state and some inputs. This approach is fully trustless because the proof is verified at relay time and proofs generally cannot be forged under cryptographic assumptions.

In the Optimistic approach, state from/about some source chain that has been posted on some target chain is assumed to be correct until shown otherwise. If someone watching the chain sees that the posted state is faulty, they initiate a challenge against the posted state and its submitter (to read about the challenge game, look elsewhere lol). Otherwise, after some challenge period, it is said that this state is finalized and therefore correct. This approach is trust minimized because there is the Single Honest Minority assumption whereby as long as there is a single honest participant issuing challenges on faulty states, the approach will continue to only finalize correct posted states.

Being trust minimized through assuming a single honest minority is generally considered as quite trustless. Looked at in isolation, being fully trustless is better on the spectrum of trustlessness. However, when looking at the other properties, the method in which these levels of trustless-ness are achieved will be shown to be a limiting or boosting factor.

Speed

Optimistic bridge speed is a function of challenge period which is a function of challenge game completion time. ZK speed is a function of how fast ZK proofs can be generated. So there is a clear tradeoff between … Will fill in the rest of this later

Cost

Optimistic cost is low over time in happy cases and high in SUPER rare cases when a challenge is initiated. ZK cost is constantly "high" ish 200k gas every time something gets posted. There is also an offchain gas cost to needing to have decent enough hardware the generate ZKPs promptly.

Permissionless

Both are permissionless because anyone can submit state. In ZK its impossible to forge proofs. In Optimistic, anyone can initiate a challenge game.

Sections above will be written in more detail later

Trusted Proof of Consensus

This might not even be widely accepted as an actual Proof of Consensus protocol within the general definition of Proof of Consensus, however, framing it as so in this context will make it easier to reason about.

Such an approch will throw away trustlessness and permissionless almost altogether in favor of speed and cost, not so dissimilar to how most bridging protocols work today, which is why this approach is inspired by existing bridges out there like Sygma.

This approach will be described only very briefly and in little detail because there is so much existing protocols out there that take this approach but in a slightly different context.

The idea is that some trusted permissioned (centralized or federated) entity will be the ones who post source chain data onto the target chain. It is not entirely trustful, because if a user can trust the entity posting these states, then they can with some level of certainty believe the posted state is valid.

Many will not consider this to be a Proof of Consensus protocol because there is no proofs or even public verifiability. However, the costs is very low and the speed is very high because there is no mechanism for challenging or verification.

The most important take away is, because there is no verifiability, there is no accountability. So if one day, this set of permissioned relayers go rogue, there is no way to punish them.

Dynamic Proof of Consensus (Zipline 3.0?)

Given the previous approaches and their tradeoffs, is it possible to design a new approach that minimizes or rebalances the tradeoffs? This design is inspired by Gasper and how it is a fork choice (LMD GHOST) algoithm with a finality gadget bolted on top.

Note: This is not a specification. So some parts of this idea may be described in more detail than others.

In Zipline, the current design focuses on Chain Finality. This means Zipline ignores the LMD GHOST portion of Gasper and subjecting itself to only a partial view of the chain up to the point of proven finalization.

The reason LMD GHOST is not considered in Zipline is because the challenge period would have to be shorter than the slot time (12s). This makes it practically infeasible to use Zipline to verify LMD GHOST chain in a reasonable time to make it useful.

Generally, it can be assumed that any descendant block of the latest finalized block can be forked away. That is to say, blocks after the finalized point cannot be fully trusted to be apart of the canonical chain.

Given that Zipline is a trustless protocol used to make guarantees about a Casper finalized chain, is it possible to use Zipline to eventually hold relayers accountable