# Resilient Shared Sequencers

## Introduction
Current shared sequencer solutions like Espresso use a pipelined BFT algorithm(HotShot) for achieving consensus among the several sequencer nodes.

There are significant challenges in MEV (Maximal Extractable Value) extraction in blockchain systems using pipelined BFT algorithms to achieve consensus. This detailed analysis explores the nuances of these challenges and proposes innovative solutions to ensure liveness of the network.

## Problem Statement
### Understanding Pipelined BFT Consensus Algorithms
- **Mechanism of Pipelined BFT**: In pipelined BFT consensus algorithms, each block(n^th block) contains a Quorum Certificate (QC) or a Timeout Certificate (TC) for the previous block((n-1)^th block). The QC represents a majority of yes votes, while the TC indicates a majority of no or timeout votes. Alongside this, the block includes a list of transactions proposed by the current leader, Alice, for the n^th time slot.
- **Roles in Block Propagation**: The (n+1)^th block proposer, Bob, is responsible for gathering the QC/TC for the transactions proposed by Alice. This sequential responsibility is crucial for maintaining the integrity and order of transactions.


### Identifying the Attack Vector
- **Scenario Analysis**: An attack vector emerges when Alice, the block proposer, discovers an MEV opportunity and proposes a specific transaction order. If Bob, the proposer of the next block, times out without proposing any block, the opportunity for MEV theft arises.- **Collusion and MEV Theft**: In this scenario, Charlie, the proposer of the (n+2)^th block, gains access to Alice's transaction order. If Bob and Charlie are Byzantine nodes, they can collude, allowing Charlie to steal the MEV. With BFT assumptions of 1/3^rd faulty nodes, we expect two consecutive faulty actors every 2.25 blocks.


### The Magnified Problem in PBS Model
- **Transaction Flow in PBS**: In a Proposer-Builder Separation (PBS) model, this problem is exacerbated. The builder sends the block content to the proposer Alice along with the fee for including the transaction. If the proposer of the next block(Bob) times out, the block content remains in the network, vulnerable to exploitation by Charlie(the proposer of the (n+2)^th block).
- **Losses to Builders**: The builder not only loses the MEV opportunity but also incurs financial loss, having paid some amount to Alice for the initially including the transaction. This disincentivises the builders to capture MEV.


### The DoS Vector
- **Issues with Sequencers**: With MEV disincentivised, sequencers lack an up-to-date view of the state. This raises the risk of them including transactions from accounts that have depleted their gas, creating a Denial-of-Service (DoS) attack vector.

## Proposed Solutions
### Implementing a Security Deposit Mechanism
- **Addressing DoS with Security Deposits**: The introduction of a security deposit mechanism is primarily aimed at tackling the issue of Denial-of-Service (DoS) attacks. In cases where sequencers might include transactions from accounts that have exhausted their gas, leading to potential network clogging, the security deposit serves as a preventive measure.
- **Operational Mechanics of Security Deposits**: Users are required to make a one-time security deposit payment, a portion of which is charged when their transaction is included in a block. This deposit is again deducted at the time of transaction execution. If the transaction fails or is found invalid, the user loses the deposit, thus bearing the cost of the transaction inclusion. This mechanism ensures that users are more vigilant about the transactions they initiate, significantly reducing the likelihood of frivolous or malicious transactions clogging the network.
- **Sequencer's Role in Maintaining Deposit State**: The security deposit state can only be updated by direct user intervention or requires a Quorum Certificate (QC) from the sequencers. This maintains a single, verifiable state of the security deposit, ensuring that sequencers include only valid transactions.

### Introducing FIFO Ordering to Prevent MEV Extraction
- **Challenges with MEV in Current Model**: Even with the security deposit mechanism in place, there remains a potential for MEV extraction by sequencers themselves without a builder network. This could lead to decreased throughput due to MEV stealing wars among Byzantine actors.
- **Implementing FIFO to Eliminate MEV Incentives**: To address this, we propose a verifiable FIFO (First In, First Out) ordering at the protocol level. Under this system, non-faulty nodes will only sign blocks that adhere to FIFO ordering, effectively removing any incentive for sequencers to engage in MEV extraction.
- **Benefits of FIFO in Maintaining Network Integrity**: By ensuring that transactions are processed in the order they are received, FIFO ordering not only promotes fairness but also significantly reduces the likelihood of MEV-related manipulations. This approach stabilizes the throughput of the network by preventing MEV stealing attacks, thereby maintaining the network's liveness and integrity.

### Compatibility with L2 Protocols
- **Integration with Existing Protocols**: Importantly, the introduction of security costs does not alter the underlying L2 at the protocol level. It's an additional layer, implemented through a smart contract, enhancing the system's robustness without disrupting existing operations.

## Roadmap for Future Work
### Researching Flexible Network Modeling
- **Objective**: The primary goal is to research various network models that permits MEV extraction without enforcing a strict ordering, thereby addressing the challenges currently faced by builders.
- **Approach**: A promising approach involves investigating network structures that allow for more flexible transaction processing. This includes examining different methods of ordering and sequencing that maintain network integrity while enabling MEV opportunities.

#### Naive Fragmentation Strategy
- **Concept of Network Fragmentation**: A naive yet promising solution is to fragment the sequencer network based on the chain IDs of the L2s. This would involve dividing the sequencer network into distinct proposers such that each proposer can propose blocks that have transactions from a set of chain IDs. We can use this and devise a mechanism such that byzentine actors can't collude to steal the MEV.
- **Implementation of Fragmentation**:
- Define Sets: In every epoch(say, one epoch is the time for all sequencers to propose at least once) L2s with specific chain IDs will be grouped into sets. A proposer *P_i* can propose a block that have transactions belonging to the set *S_i*.
- Ensure Disjoint Sets: The key to this strategy is to ensure that the intersection between *S_i* and *S_i+2* is a null set. This means that the set of transactions proposed by a Alice and the set proposed by the Charlie do not overlap.
- Although this doesn't solve the problem with *k* colluding actors. We can generalise this for *k* colluding actors by ensuring $S_i\bigcap S_{i+2}\bigcap S_{i+3}\bigcap... S_{i+k} = \varnothing$.
- Worst case *k = n/3* under byzentine assumptions. Although this number can be brought down to a smaller number and relying on a more probabilistic approach.
- **Advantages**:
- Using this design ensures that even if Bob times out Charlie can't steal, as they would be dealing with completely disjoint sets of transactions. This can be generalised for *k* colluding actors.

- **Drawbacks**:
- Although this ensures builders can extract MEV of a single network, the fragmentation can lead to lower access to cross chain MEVs.
- Cross chain conditional transactions can have lower throughput due to fragmentation.

### Implementation
After a thorough investigation of how we can model the network, I hope to build and benchmark the different approaches.
I have currently started implemention the first approach(Verifyable FIFO + Security Deposit) discussed and it can be found on my [GitHub](https://github.com/RohanShrothrium/sequencer-node).

## PS
I would love to get in touch with and chat with interested folks.
You can get in touch with me on my [twitter](https://twitter.com/0xshrothrium) or drop a comment bellow. My TG is @trojan0x.