🛡️Security Properties & Risks

This page elaborates on the claimed security properties, as well as known risks, of the continuum model.

Risks unique to the continuum L1 architecure, boil down to the use of a single sequencer in v1 (we're exploring sequencer rotation for future version, but low latency remains a top priority). The sequencer is heavily constrained, cryptographically (VDF for timekeeping + blind order commitments), so the risk profile is different from naive single sequencer models (eg. L2s like Arbitrum, Optimism). Nevertheless its important to highlight two classes of risk, and what can be done to mitigate them over the long run. 1. Liveness Risk This is the first property that cannot be constrained by cryptography - if the sequencer goes down, the chain halts. This can be remidied by proper failover mechanisms in the design. For decentralised robustness in the long run, we can also have a mechanism for validators to elect a new sequencer if the first one. This is part of our roadmap for v2. Another mitigation for exit of funds v1 is to allow force inclusion of transactions on an external DA layer.

1. Indiscriminate Censorship / Griefing

This risk comes down to the fact that while the sequencer cannot perform targetted sandwiching, it could indisriminately drop transactions (eg. drop 20% of txns randomly). The crux of this risk is that a. its deterimental to the network but not beneficial to the sequencer (negative-sum), so a rational sequencer shouldn't engage in this. Secondly, it is more easily detetected than targetted censorship - thus can easily lead to slashing and rotation of the sequencer.

Other Properties

The design goal of the sequencing architecture is to ensure any misbehavior (reordering/censorship) is detected and can be proven. With that property, we feel reasonably confident starting with a single sequencer model, with "on demand" rotation and slashing when any misbehavior is shown or 2/3rd of the validators agree that the sequencer needs to be rotated. This provides the fallback safety guarantees in case of a malicious/failing sequencer, while preserving continued speed and efficiency of execution in the good case where the sequencer behaves as expected.