# Notes on Arbitrum: reviewing the sequencer Arbitrum is a *classic rollup* on Etheruem that uses a Sequencer to collect user txs, order them and then submit batches of transactions to L1. Today, the Sequencers for Nitro and Nova operate as centralized entities maintained by the Arbitrum foundation. Despite this centralization, Arbitrum maintains a trust-minimized security model and censorship resistance. ![](https://i.imgur.com/XkFKdCj.png) In the common case, the Arbitrum Sequencer receives user transactions and orders them in a sequence with a FCFS (first-come, first-serve) algorithm serving as an input to the execution stage of Arbitrum. Upon receiving the transaction the Sequencer will execute it and deliver the user a receipt or soft-confirmation. Shortly thereafter the Sequencer will collect enough transactions into a batch and post them to L1 by calling the Inbox method `addSequencerL2Batch`. Only the Sequencer has the authority to call this method. As a result this allows the Sequencer to provide instant soft-confirmations. The transactions have L1 finality once the batch is finalized. In the cases where Sequencer acts malicious, users would need to submit an L2 message via L1 to the delayed inbox. After 24 hours,`forceInclusion` is called moving the L2 message from the delayed inbox to the core `SequencerInbox` and is then finalized. ### Current Drawbacks * Latency races * Centralized Sequencer ## Latency Races Recently the Arbitrum team proposed adding a “time boost” to the FCFS sequencing policy. This was a reaction to MEV searchers running 100,000-150,000 web socket connections to the Arbitrum Sequencer. Many of these sockets were opened purely to spam the network with transactions to be included first. At first the Arbitrum team proposed a new proof of Work like mechanism called add relay connection nonce, which would have required searchers to expend resources on hashing nonces with Keccack 256. Clients with the lowest nonce will then have their transactions broadcast first. This policy received much pushback from searchers and community members and was not implemented. The policy was unpopular because searchers will have increased operating overhead on the order of $10,000s daily, spent on GPUs and electricity for mining low nonces. Since then, the team has pivoted to the aforementioned “time boost” proposal. ### The stated goals of Arbitrum’s new ordering policy are: * Secret mempool where only user transactions are visible to the sequencer * Low latency - every transaction arrives in a short time interval, 500 ms * Short-term bidding - transactions can gain an advantage by bidding for position * Decentralized - policy works with decentralized sequencer If a transaction’s priority fee is $F$, it gets a time boost computed by this formula                                              $\Delta t = \frac{gF}{F + C}$ * Where $g$ is the maximum time boost, 500ms * $C$ is a constant (tbd) * $F$ is a transaction’s priority fee In exchange for the time boost, the L2 gas fee will be increased by $F$. Here as the $F$ increases as a multiple of c there are dimensioning returns as the fee goes up. Every transaction received is time stamped by the sequencer. A transaction can choose to pay a priority fee which will give it a boost up to 500ms. The 500ms parameter presents a tradeoff between incentivizing searchers to buy a boost while minimizing the impact of latency for non-boosted transactions. Upon receiving transactions, the Sequencer would apply the time boost formula above and sequence transactions in increasing order of the adjusted timestamp. This will increase latency for non-boosted transactions because the sequencer would need to wait to see if boosted transactions arrive after within the time interval. ## Looking Ahead to decentralized sequencing Arbitrum is building a fair ordering protocol that can be used in tandem with a decentralized Sequencer quorum. One iteration of this protocol is called Themis, a scheme for introducing first in first out fair ordering of transactions at the coarseness of network latency rather than at the scale of block time. Let’s unpack this a bit. In the context of distributed systems or p2p networks, *latency* is the delay between sending and receiving messages. Coarseness here means that the latency is not uniform and may have fluctuations, leading to inconsistency in the responsiveness of the network. So we can say then that Themis orders transactions at the coarseness of network latency rather than the scale of block time, it implies that transactions can be ordered faster in many cases as opposed to waiting for a pre-determined block time. This can lead to faster transaction processing and improved performance in certain scenarios, as it takes advantage of the variability of network latency rather than relying on fixed time intervals. The **Themis** protocol presents one possible solution. >Themis is a scheme for introducing fair ordering of transactions into (permissioned) Byzantine consensus protocols with at most $f$ faulty nodes among $n \geq 4f + 1$. Themis enforces the strongest notion of fair ordering proposed to date. It also achieves standard liveness, rather than the weaker notion of previous work with the same fair ordering property. Themis has the same communication complexity of the underlying protocol; it is a minimum modification to any existing partially synchronous leader-based protocol. Existing fair ordering protocols require replicas to gossip tx orderings to everyone else as their first step. This results in $O(n^2)$ or $O(n^3)$ communication complexity. Themis on the other hand requires replicas only to send fair ordering to current leader, achieving linear communication $O(n)$ in the optimistic case. The Leader uses $n-f$ of these to compute a fair proposal. The Leader computes a SNARK and provides this with a block proposal. Replica nodes check proofs to ensure fairness. Everything else can be taken as is from the underlying protocol. Themis can be paired with HotStuff or any other BFT consensus protocol. With the emergence of [Espresso’s decentralized sequencing service](https://hackmd.io/@EspressoSystems/EspressoSequencer) which builds a modified version of HotStuff, the two protocols could be combined to fill in the ordering and leader election modules of the current centralized Arbitrum Sequencer. One relevant question is how much decentralization of the sequencer quorum is enough to satisfy social consensus? Will this come at the cost of increasing network latency? Both questions are out of the scope of this analysis but may be enumerated on in future articles. ## Analysis For any rollup using a centralized Sequencer there exists a trade-off between fast soft-confirmations to users (UX) and decentralization. Can you have both? Can you have a low latency high throughput rollup that reduces networking latency close to its physical limits, ie. 250ms for a global round trip? It is suggested that indeed it is possible to get decentralized sequencing at $2-4$ $\Delta$ depending on how strong the synchrony assumptions are for the sequencer. However if the Sequencer uses a responsive protocol like Hotshot it can optimistically be very fast, [not the worst case $\Delta$](https://twitter.com/benafisch/status/1635417195449831428?s=46&t=vk76MlVgPdVEkmtoT5AOrA). Delta refers to a range of potential latencies in a decentralized sequencing system, with the actual latency depending on the strength of the [synchrony assumptions](https://medium.com/mechanism-labs/synchrony-and-timing-assumptions-in-consensus-algorithms-used-in-proof-of-stake-blockchains-5356fb253459) and the efficiency of the protocol used. This would seem to satisfy Arbitrum’s goals with time-boosted orders and maintain forward compatibility with a granular fair ordering protocol like Themis which is compatible with consensus protocols like Hotstuff. As Ethereum’s Data Availability capabilities are expanded both out of protocol with middleware like Eigen DA and in protocol with full data sharding (danksharding), rollups will not be bottlenecked by Ethereum’s DA throughput, only execution time of the rollup. ## References * [How rollups *actually actually* work](https://drive.google.com/file/d/1KOEKNDGLBiLbaUDnIxCV6L1aBJblGPJs/view) [rollup sorcerer, 2023] * [The Sequencer](https://developer.arbitrum.io/inside-arbitrum-nitro/#the-sequencer) [Arbitrum Docs, 2023] * [Sequencing, Followed by Deterministic Execution](https://developer.arbitrum.io/inside-arbitrum-nitro/#sequencing-followed-by-deterministic-execution) [Arbitrum Docs, 2023] * [Transaction Ordering Policy](https://research.arbitrum.io/t/transaction-ordering-policy/127) [Felton, 2023] * [Thoughts on Arbitrum’s Proposal to Score Connections by PoW](https://research.arbitrum.io/t/thoughts-on-arbitrums-proposal-to-score-connections-by-pow/8121?u=apriori) [zkstonks, 2023] * [Add a relay client connection nonce PR #1504](https://github.com/OffchainLabs/nitro/pull/1504) [PlamaPower, 2023] * [Time boost: a new transaction ordering policy proposal](https://research.arbitrum.io/t/time-boost-a-new-transaction-ordering-policy-proposal/8173) [Felton, 2023] * [Themis: Fast, Strong Order-Fairness in Byzantine Consensus](https://eprint.iacr.org/2021/1465) [Kelkar, Deb, Long, Juels, Kannan, 2021] * [The Espresso Sequencer](https://hackmd.io/@EspressoSystems/EspressoSequencer) [Espresso Systems, 2023]
Last changed by  
 
apriori
700

Read more

Coordination is Power : cross-domain MEV & decentralized sequencing for rollups

This note is a work in progress and should not be mistaken for a finished project

1/2/2024
Mapping the Labryinth

In this article we will briefly reveiw the general types of application deployments to choose from and different types of applications that are interesting to build. Then we will propose a debate game application called the referee, the heart of the article. Finally, we conclude with a succinct analysis. General Types of application deployments App-chain- You have an application or an idea for a suite of applications and would like to guarantee sovereignty or a notion of it for your community who can hard-fork via social consensus should conflict arise. The Cosmos SDK is battletested and comes with IBC & Tendermint, some of the most battletested protocols in crypto. This could also be a rational L3 deployment and benefit from Ethereum’s liquidity. Smart Contracts - SC dapps inherent the security and limitations of the chain you deploy on. As an SC dapp you can focus on a specific PMF for your product. There are also robust security frameworks for auditing and formal verification for more mature languages like Solidity. Cross-chain communication amongst different instances of your dapp fragments liquidity and introduces new trust assumptions. Universal L1 - High DA throughput for specific needs like CLOB, on-chain gaming, Social Media, et al. The death spiral risk is acute early on but persists through the chain’s lifetime. Unknown attack vectors. Difficulty boot-strapping a community. Difficult to bootstrap inital token liquidity without venture funding. Rollups - Rollups move computation (and state storage) off-chain, but keep some data per transaction on-chain. To date, much of the work here focuses on building EVM equivalent rollups though formidable alternatives exist. A key distinction of enshrined rollups aside from on chain da and proof verification is the censorship resistance mechanism. Users have the ability to exit enshrined rollups to L1 via forced inclusion txs, escape hatches, or proposing blocks. Soveriegn rollups rely on social consensus or some form of governance to upgrade via a hard-fork. Both types of rollups can use fraud or validity proofs to guarentee/enforce the validity of the rollup, that its execution is compliant with the state transition function, $\sigma'$ $=$ $\gamma$$($ $\sigma$$,$ $T$$)$where $\sigma'$ is the new state $\gamma$ is the state transition function $\sigma$ is the previous state $T$ is a transaction

4/28/2023
High Latency Governance

Ethereum governance is a delicate process that relies on rough social consensus of the community, core developers and EF researchers. Improvement proposals (EIPs) are the primary mechanism for proposing new features and communicating these proposed features with the Ethereum Community. EIP standardization process The EIP standardization process is a mechanism for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. ~EIP-5069 An EIP can be crafted following the EIP format (EIP-1). There are three types of EIPs, A Standard Track (core, networking, Interface & ERC), a Meta-EIP (process changes), and Informational EIPs (provides information or general guidelines). An EIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. ~ EIP-1 EIP Life-cycle

3/28/2023
based MEV-Share

If you have "smart searchers" they could read the different Mempools and match orders. Then match the orders, bundle them and send them to a builder. So basically MEV-Share for all rollup mempools. In this way you would not need a sequencer for ordering, though a local fallback is always helpful. This idea on the surface appears similar to the idea put forth by a couple of Jedis here. Perhaps this lends some credence to the technical feasibality of the following discussion. Disc-V5 supports topics and is used on both CL and EL, so we could create separate p2p channels at any granularity we want (e.g. shared_sequenced_chain1_chain2_slot5, see e.g. how EIP-4844 blobs are each on separate topics. ~ @gakonst I would caution the reader that the following proposal is reductionist and may be technically infeasible and/or too left curve. Feel free to correct any misconceptions or comment. 4337, Private Mempools & Match-Making MEV-Share inserts an intermediate role between searchers and Builders. The Match maker plays a similar role to that of a solver in the Anoma framework. Can you match make userOperations for all rollups?

3/21/2023
Read more from apriori
Published on HackMD