# Coordination is Power : cross-domain MEV & decentralized sequencing for rollups ::: danger ***This note is a work in progress and should not be mistaken for a finished project. In Particular, most of the rolllup section is wrong and I'm too lazy to make changes at the moment*** ::: **TLDR ~ Build a better sequencer. Cross-domain MEV is coming.** Cross-domain MEV refers to the ability of players to coordinate their activity across multiple domains (rollups, layer 1, cex) in order to extract both $EVsignal$ & $EVordering$. On the one hand there are some benefits. The idea of a meta-builder or one cross-chain block builder to rule them all could allow users to enjoy the benefits of cross rollup composability with low latency and high confirmation assurances. These meta-builders could offer soft confirmations or guaranteed tx inclusion if the user pays a given fee, perhaps even free in an Order flow auction prior. This Meta Builder could be at worst a proof of authority quorum with only a handful of actors or a quorum of every single Ethereum validator at best. The meta-builder could act as a prime brokerage for block space supplying flash loans on demand. ![](https://i.imgur.com/ajCS20I.png) The existential risk is apparent in this sketch. The drawing attempts to show this so-called Meta-builder interacting with a hypothetical all powerful agent called JPM Goldman. This highly sophisticated agent has managed to position itself to dominate order flows while making markets across three domains; the Chicago mercantile exchange, Centralized exchanges, and decentralized exchanges on chain. The Meta-builder is connected to all blockchains across the galactic empire of decentralized trust. This agent can guarantee cross-domain arbitrage atomicity. In this hypothetical future, JPM Goldman has decided to collocate with Meta-Builder nodes in data centers throughout the world. In such world JPM Goldman could also decide to run block producers across all on chain domains and park them in the same data centers allowing for the lowest latency possible. They would have the resources and maybe regulatory advantage over crypto native operators and eventually have significant influence over all relevant on-chain domains as they can capture MEV at significantly higher rate than the existing actors. If this type of centralization with respect to block production is inevitable as the Endgame article suggests, is there nothing to be done aside from reinforcing the base layer with Data Availability Sampling, and consensus upgrades? Should researchers and developers burn their valuable time on solving decentralized Sequencing? In this article we attempt to answer the question in the affirmative, that yes it is worth exploring the design space of rollup sequencers to gain a better understanding of their core competencies and associated trade-offs. Below we discuss rollups by unpacking the sequencer, then examine the types of decentralized sequencing models that can exist, and finally conclude with some analysis and a proposed research track, based on our analysis. ## Rollups Modular blockchains uncouple execution from data availability and consensus. This means that each of these abstractions can be built separately and composed like Lego blocks. As it turns out, one promise of modular blockchains is next generation execution layers, rollups. This is a path dependent outcome which was influenced by Ethereum’s pivot to a [rollup centric](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) roadmap in 2019 and the emergence of Lazy ledger blockchains like Celestia which do not have enshrined execution [z]. Rollups are specialized blockchains that scale the execution of a parent chain by moving execution off chain. Rollups [compress](https://research.arbitrum.io/t/compression-in-nitro/20) transactions and post these batches of data to a parent chain for data availability and ordering (Parent chain). *Rollups move computation (and state storage) off-chain, but keep some data per transaction on-chain* [n]. Fraud (fault) and validity proofs are verified on the Parent chain to prove the correctness of the rollup’s execution [b]. These proofs can be verified on chain or settled over a peer to peer network of rollup nodes [z]. ![](https://i.imgur.com/jwhxnRO.png) Rollups come in two instantiations, classic or sovereign. A [classic](https://drive.google.com/file/d/1KOEKNDGLBiLbaUDnIxCV6L1aBJblGPJs/view) rollup cannot fork away from the parent chain easily. Censorship resistance is achieved by forced inclusion transactions (L1→ L2), escape hatches, and permissionless block proposing [z]. A [Sovereign](https://eprint.iacr.org/2018/087.pdf) rollup is another type of rollup. It is a sovereign blockchain that does its own dispute resolution over a p2p network but relies on another blockchain for data availability & ordering. Validity rollups post proofs in the [Block Header](https://blog.celestia.org/sovereign-rollup-chains/). This way light clients can easily verify the SNARK. Sovereign rollups have both full nodes and light nodes. Both node types run light clients on the parent chain to participate in relevant [data availability sampling](https://arxiv.org/pdf/1809.09044.pdf) [z]. ## The Sequencer A sequencer or rollup coordinator is sometimes used as a catchall to define multiple roles of rollup nodes. If we unpack the sequencer into its key competencies we can see there are three distinct sub roles that can be seperated out or internally sand-boxed and defined. We will look specifically at how to separate out transaction *ordering* from *inclusion*. ![](https://i.imgur.com/nuTN56s.png) * **Leader Election** refers to the method with which a block producer is selected to produce the next block. The [Leader](https://a16zcrypto.com/content/article/leader-election-from-randomness-beacons-and-other-strategies/) is responsible for including user transactions. * **Ordering** refers to methods with which transactions are packed in a block. Ordering includes auctions, fair ordering protocols and hybrids * **Coordinating** refers to additional tasks or roles the sequencer takes on such as communication with the parent chain or rollup nodes. We will not spend time analyzing the coordinating activities. Typically posting state diffs or transaction call data to the L1 `SequencerInbox` as well as processing deposits. # Leader Election A centralized sequencer is the singleton leader. All user transactions are touched by the single sequencer. The sequencer is trusted. This comes at the cost of censorship resistance. Both OP Labs and Off-Chain Labs run centralized sequencers. A decentralized sequencer requires some type of mechanism to choose who has the right to sequence transactions for a given slot. There are several mechanisms to choose from: * Sequencer burn auctions * Traditional consensus * Outsourced sequencing ## Sequencer Selection via Burn Auctions Sequencer burn auctions are interesting, because on the surface they appear to make the rollup protocol more censorship resistant. The censorship resistance comes from the fact that block proposing is open and permission-less, and the leader is selected based on an auction where everyone bids the amount of transaction fees they are willing to burn in order to win the right to sequence the next block. In this [scenario](https://ethresear.ch/t/spam-resistant-block-creator-selection-via-burn-auction/5851), the sequencer makes a credible commitment that has three properties they publish when bidding [k]: * `targetProfit` bidder wants to make from proposing a block * `txList` to be included such that `sumTotalFees = (txf_1, txf_2, txf_3, …txf_n)` * `burnBid` such that `burnBid = sumTotalFees - TargetProfit` If there is a tie and all of the bidders provide the same `sumTotalFees` the bid that has the lowest `targetProfit` is selected. `targetProfit` is a fallback mechanism here. If bidders have a different view of `sumTotalFees` the highest overall bid wins [k]. One school of thought suggests that the downside to permissionless block proposing is that MEV could leak down to L1 as an L1 proposer could postion themselves to delay block proposals on Ethereum if they are waiting to propose a more valuable rollup block first. Layer 1 Ethereum is well versed in MEV management and in fact has the most transparanet, decentralized, and mature marketplace today. While its possible that the above scenario may become common in the future, I'm not sure its enough of an argument to outweigh the positive properties of permissionless proposing with a sybil mechanism like Burn Auctions. Ultimately, This mechanism makes censorship of transactions particularly difficult as it may be in the sequencer’s best interest not to censor transactions [r]. Burn auctions for sequencer selection potentially eliminates several dos attack vectors as well. ## Traditional Consensus Known leader based consensus protocols all have different ways of choosing who gets to propose the next block. * Tendermint uses a weighted round robin function influenced by total voting power [d]. * Gasper assigns leaders one epoch in advance using a randomness accumulator, RANDAO, which every proposer contributes randomness to when they propose a block [g]. * Algorand uses verifiable randomness functions to choose leaders and committee members [f]. Next generation consensus protocols like Hotstuff inspired Espresso's design for [Hotshot](https://hackmd.io/@EspressoSystems/EspressoSequencer#III-Espresso-Sequencer-Design-Principles-and-Requirements). The emphasis of this protocol is on achieving high throughput and rapid finality rather than focusing on dynamic availability. It integrates aspects of HotStuff, recent advancements in Pacemakers, verifiable information dissemination (VID), random beacons produced by VDFs, and concepts from DAG-based transport layers [i]. A key objective of HotShot is to maintain high performance without limiting the validator set's size. The protocol ideally can scale to all 14,000 unique Ethereum staking adressess[i]. One argument against Consensus protocols for rollups is reintroducing Attacks in proof of stake systems. For example if the leader is determined to buy up an outstanding amount of rollup tokens to acquire the most stakeweight they could mint empty blocks to stall the network at the cost of MEV and the staked value of their tokens. The rollup users could be charged a ransom to migrate funds as well [l]. Recall smart contract rollups can not hard fork to recover from failure mode to fork out the malicious stake [i]. Hotshot adressess these issues by leveraging the Eigen Layer. By having Ethereum validators opt in to their shared sequencer service. This extends the trust and accountability of Ethereum via slashing conditions to the shared sequencer set. ## Outsourced sequencing The original Lazy Ledger (Celestia) white paper proposed a minimal data availability blockchain which applications could connect to and rely on for data availability and ordering. The applications would define their own business logic and handle dispute resolution. These applications are what we think of today as Sovereign rollups on Celestia. Celestia envisions a future of millions of rollups. Often, one of the bottlenecks for launching a blockchain is putting together a consensus quorum. This comes at a cost which requires issuing an inflationary token and paying heavily for empty block space while the network builds applications and acquires users. A solution to this problem is sequencing as a service.  The idea is that the rollup protocol could pay for a specialized sequencing service. These services could be both generalized and bespoke depending on the rollup’s needs. For example an L2/3 application validium may only require a centralized sequencer, while an Ethereum rollup may prefer re-staked Ethereum validators. The sequencer service could be a feature of Interchain security, Eigen Layer type of solution briefly described above, or something else entirely [x]. Its fair to say that the profotability of this "shared sequencer" would need to be greater than the cost to operate. This space is new. I suspect the Celestia ecosystem and Ethereum ecosystems will be first to market with products. While out of the scope of this article, further analysis on Avalanche subnets may inform predictions about early market trends.    Some of the benefits of sequencing as a service include ease of access, division of labor with specialized skill sets, cross rollup composability, custom ordering protocols and shared slashing conditions. Trade-offs include creating sequencing cartels whose formation is a function of future cross-domain MEV, ease of deployment making disposable rollups or abandoned projects trivial as the barriers to entry for inexperienced developers or grifters decreases.  # Transaction Ordering Ordering refers to methods with which transactions are packed in a block. Ordering includes types of MEV auctions, fair ordering protocols from the Aequitas, Wendy, and Themis family, Threshold Encryption protocols, and Hybrids like FBA-FCFS. Here Ordering could also be outsourced to a protocol that specializes in block-building like SUAVE. ## Block Auctions (MEVA) MEV or MEV auctions simply auction off the right to reorder transactions within an N-block window to the highest bidder. That is the winner of the auction has the right to reorder submitted transactions and insert their own, as long as they do not delay any specific transaction by more than N blocks [j]. This notion of MEV auctions would be similar to competing for the right to build the next block. The winner could further delegate tx ordering to searchers similar to what we see on Ethereum with the searcher-Builder auctions. It may also be possible to create rollup blockspace derivitives in this way. More analysis would need to be done about the risks associated with a [design](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/WKa3GFC03uY34d2MufTyD0c595xVRUEZi9RNG-dHNKs). One concern is auction collusion. Bidders colluding to reduce competition and keep the auction price artificially low breaks the ability to accurately discover and tax the MEV. ### Trade-offs Below is a summary of Trade-offs associated with MEV auctions and solutions to these trade-offs as put forward by Chitra [here](): * Added latency: **The MEVA system introduces latency between transaction selection and sequencing**. Solution: Run sequencer auctions ahead of block production time or use a distributed priority queue to minimize communication rounds between transaction selectors and sequencers. * Optimizing the auction: **Constructing an optimal auction for sequencing is complex**. Solution: Borrow techniques from the online advertising auction design playbook, separating participants into passive and active categories, and optimizing the social welfare function. * Impact on inflation: **The auction's fees distribution impacts inflation**. Solution: Choose between pro-rata redistribution, burning, or concentrated redistribution to balance inflation and fairness. Each option has trade-offs and implications for network participants. * Other sources of MEV: **Transaction censorship can be another form of MEV**. Solution: Assuming 50% honest, rational agents, a transaction entering the mempool at block h will eventually be included in the chain, with the probability of inclusion decaying exponentially in relation to the number of blocks (MEVA) Block auctions create a straightforward way for the protocol to capture revenue, and then redistribute it back to users or the community for funding public goods or other incentive compatible redistribution mechanisms. ## Threshold Encryption Threshold encryption is a cryptographic technique that allows a message to be encrypted and then divided into multiple parts, and distributed to the threshold committee members. The unique feature of threshold encryption is that a minimum number of shares, called the threshold, is required to decrypt the message successfully. If the number of shares falls below the threshold, it becomes computationally infeasible to reconstruct the original message. Threshold encryption falls within the family of encrypted mempools. The idea is that a user's transaction is encrypted, committed to, and then decrypted. This protects the users from various front-running attacks and censorship. * **Ferveo** - a validator set can generate a distributed private key where each validator’s share of the private key is weighted proportionally to their staked amount. The distributed key generation (DKG) is efficient enough to perform once per epoch and the underlying cryptographic schemes allow for real-time decryption of encrypted transactions. Ferveo allows the validator set to commit to encrypted transactions prior to threshold decryption, preventing public visibility of pending transactions and helping prevent transaction front-running.Ferveo is a collaboration between Anoma & Osmosis Labs. * **Shutter** - is a commit-reveal mechanism, a front-running protection plugin for rollups based on threshold cryptography. The threshold committee is assumed to be online and honest, 1/2 or 2/3 threshold, ideally large enough to justify threshold assumption. Keepers run distributed key generation protocol - Linear rounds, one message per committee member, only need to have initial setup. Keepers provide the key everyone in the network can use to decrypt. Keepers changed in batches, key generation DKG process can be limited. Not all transaction fields can be encrypted. Gas amount, gas price, and envelope signature are plain text. * **Chainlink FSS** - FSS is a framework for implementing ordering policies, which includes non-threshold based fair ordering protocols like Themis and Aequitas. FSS can support threshold encryption as well. It will also support various policies for inserting oracle reports into a stream of transactions. (It can even support MEV auctions, if desired. Why entertain threshold encryption? Threshold encryption attempts to limit $EVordering$ leakage from users. Front-running protection is a notable feature in addition to censorship resistance. The latter is significant in that it is difficult to censor a transaction If there is not an ability to publicly see the transaction before it is decrypted [aa]. If threshold encryption reduces an agents ability to gain an edge in $EVordering$ games, a positive externality may exist such that encrypted mempools reduce the risks of sequencer collusion with respect to cross-domain MEV [w]. ## Fair Ordering Protocols 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 predetermined 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≥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(n2)$ or $O(n3)$ 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 which builds a modified version of HotStuff, the two protocols could be combined to fill in the ordering and leader election modules of any rollup Sequencer. ## FBA-FCFS (Frequent Batch Auctions First Come First Serve) The idea was initially put forth by Sexy Sun and Flashbots in the Arbitrum research forum. FBA-FCFS idea builds on Themis but includes auctions. Also see arbitrum's recent time boost proposal as an example. FBA-FCFS (frequent batch auction first come first serve) proposal is strctly better than the original FCFS in two ways: * The fairness of the ordering protocol is more robust (in the sense of network latency tolerance) than the vanilla version, allowing the domain to provide a smoother UX * The protocol is more fair because it removes the negative externality caused by inefficient resource allocation and increases the welfare (an upper bound on ordering efficiency) of users, thus allowing the domain to attract much more future users (who aren’t visible currently) Potential concerns of this proposal include: * FBA-FCFS incurs negligible latency overhead * FBA-FCFS validators have no incentive to coarsen the fairness granularity ## Latency 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Δ$ 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 refers to a range of potential latencies in a decentralized sequencing system, with the actual latency depending on the strength of the synchrony assumptions and the efficiency of the protocol used. Is it better to have slow block times with multiple auctions that ensure MEV sharing across the supply chain or transaction propagation at the speed of light? Is it preferable to move the auction to physical resources vs. information edge. Can low latency achieve fairer pricing on decentralized exchanges and reduce losses for passive LPs? These questions are critical in building towards more performant and fairer MEV supply chains. 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. # Proposal ~ Unity is Strength Cross-domain MEV is the maximum of the sum of final balances across all considered domains into a single base asset (canonically the first domain considered), when some mix of actions across all those domains are executed together[q]. **As defined by Obadia et al** [q]: $mev_{_B}^{a}(P,s) = \underset{a_1,\dots,a_n \in A_i \cup A_j}{\max}\left\{ \sum_{b \in B} {\{ e_{v_i}(P,s,a_1,\dots,a_n) + p_{j\rightarrow i} e_{v_j}(P,s,a_1,\dots,a_n) \}}\right\}$ Informally, cross-domain MEV refers to the ability of players to coordinate their activity across multiple domains in order to extract both $EV$$signal$ & $EV$$ordering$. Domains could include, rollups, Layer 1s, centalized exchanges, and maybe even fiat on-ramps. *Unity is Strength: A formalization of Cross-domain MEV* was ahead of its time in predicting cross domain MEV. This formalism was an early *hint* which predicted SUAVE, a multi-chain block-builder, one solution to cross-domain MEV. The other side of the coin which the paper presents; rollup sequencer collusion will happen because you can prove that combining domains produces more MEV than present in isolated domains. It should be possible to simulate cross-domain MEV outcomes and what it means for decentralization by predicting [Endgame](https://vitalik.eth.limo/general/2021/12/06/endgame.html) scenarios and then working backwards. * **Step 1**: take a defined engame scenario like one outline in Vitalik's post; Cosmos vision with many L2/L3s or just one dominant rollups. You should be able to naively simulate the median protocol [revenue models](https://barnabe.substack.com/p/understanding-rollup-economics-from) for each rollup's sequencer into the future in these three endgames. * $Revenue = Tx Value - Costs$ * $Tx Value = (MEV + User Value)$ * $Costs = (Operations + Data Publication - congestion fees)$ * **Step 2** take the simulations and cross reference against existing data on cross-domain MEV. With these data points you should be able to make some inferences about the amount of cross-domain MEV in the system. * **Step 3** take your projections of cross-domain MEV for each endgame scenario and again work backwards using the projections to inform forward simulations of 2 distinct sequencing models. **Outcome of Research:** identify correlations of statistical significance between sequencing models and MEV. This would allow you to loosely predict cross-domain MEV based on the inputs to the endgame simulations. Ultimately, the intuition is to use the simulations as a means to support decision making when building a rollup sequencer. # Closing Remarks In this article we introduced the existential risk of cross-domain MEV. While the analysis is insufficient it helped frame the discussion about Sequencer design by reviewing what the available ordering and leader election protocols have to offer. Leader Election protocols which guarantee order inclusion of transactions offer a three distinct choices by relying on a tradition consensus like Tendermint, using a next generation consensus like Hotstuff to build a shared sequencer set for multiple rollups or proposer Burn auctions which mitigate the risk of known DOS attacks in proof of stake protocols. Its unclear which direction is the best here. While the middle path recently proposed by Eigen Layer and Hotshot pairing may be the most well positioned to win the market, it is still too early to say. Burn auctions have been proposed for rollups and Layer 1 and on the surface appear to be the most censorship resistant choice. Indeed, rollup teams will grapple with these decision over the next 1-2 years as the design space is better understood, trade-offs and all. Hence, we used our learnings to propose a research track that could inform design choices of building a cross-domain MEV-aware rollup sequencer. ## References [a] Christ, Valeria Nikolaenko and JosephBonneau, Leader Election from Randomness Beacons and Other Strategies, 2022 https://a16zcrypto.com/leader-election-from-randomness-beacons-and-other-strategies/ [b] McCorry,Buckland,Yee, Song, SoK: Validating Bridges as a Scaling Solution for Blockchains, 2021 https://eprint.iacr.org/2021/1589.pdf [c] Scroll, An Overview of Scroll’s Architecture, 2022 https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k [d] Buchman, Kwon, Milosevic, The latest gossip on BFT Consensus, 2018 https://arxiv.org/pdf/1807.04938.pdf [e] Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2009 https://bitcoin.org/bitcoin.pdf [f] Algorand Developer Docs, Algorand Consensus, 2023 https://developer.algorand.org/docs/get-details/algorand_consensus/ [g] stu, RANDAO: Under the Hood , The Block Doc, 2022 https://blockdoc.substack.com/p/randao-under-the-hood [h] Gottumukkala, Sabet, Konstantopoulos, Generating Secure Randomness on Ethereum using SNARKs, Paradigm.xyz, 2023 https://www.paradigm.xyz/2023/01/eth-rng [i] Brooker, Leader Election in Distributed Systems, Builder’s Library, 2019 https://aws.amazon.com/builders-library/leader-election-in-distributed-systems/ [j] karl, MEVA: Auctioning transaction ordering rights as a solution to MEV, 2021 https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788 [k] barryWhiteHat, Spam resistant block creator selection via burn auctions, 2019 https://ethresear.ch/t/spam-resistant-block-creator-selection-via-burn-auction/5851 [l] barryWhiteHat, Against proof of stake for [zk/op] rollup leader election, 2020 https://ethresear.ch/t/against-proof-of-stake-for-zk-op-rollup-leader-election/7698 [m] barryWhiteHat, POA transition to optimistic rollup VM, 2020 https://ethresear.ch/t/poa-transition-to-optimistic-rollup-vm/7983 [n] V. Buterin, An incomplete guide to rollups, 2021 https://vitalik.ca/general/2021/01/05/rollup.html [o] V. Buterin, Decentralizing the builder role, SBC, 2022 https://hackmd.io/@vbuterin/distributed_builders#/ [p] Goes, Yin, Brink, Anoma: A unified architecture for full-stack decentralized applications, 2022 https://github.com/anoma/whitepaper/blob/main/whitepaper.pdf [q] Obadia, Salles, Sankar, Chitra, Chellani, and Daian, Unity in Strength: A Formalization of Cross-Domain Maximal Extractable Value, 2021 https://arxiv.org/pdf/2112.01472.pdf [r] Nisan, Roughgarden, Tardos, Vizarani, Algorithmic game Theory, Definition 16.5, 2007 https://www.cs.cmu.edu/~sandholm/cs15-892F13/algorithmic-game-theory.pdf [s] Kelkar, Lebb, Deb, Long, Juels, Kannan, Themis: Fast, Strong Order-Fairness in Byzantine Consensus, 2021 https://eprint.iacr.org/2021/1465 [t] Drake, Encrypted Mempools and Crypto Meets Decentralized Mechanism Design, Columbia CryptoEconomics Workshop, 2022 https://business.columbia.edu/dfi/dfi-past-event/encrypted-mempools-and-crypto-meets-decentralized-mechanism-design [u] Boneh ,Bonneau, B ̈unz, Fisch, Verifiable Delay Functions, 2018 https://eprint.iacr.org/2018/601.pdf [v] Buterin, Endgame, 2021 https://vitalik.eth.limo/general/2021/12/06/endgame.html [w] Drake, MEV Roast: Encrypted Mempools, 2023 https://www.youtube.com/watch?v=XRM0CpGY3sw [x] EigenLayer Team, EigenLayer: The Restaking Collective, 2023 https://eigenlayer.xyz/whitepaper.pdf [y] Williams, Sybil-resistant Network Identities From Dedicated Hardware, 2016 https://docs.google.com/document/d/1eRTAe3szuIoZEloHvRMtZlrU7t2un4UVQ8LarpU3LNk/edit [z] Tas, Adler, Al-Bassam, Khoffi, Tse, and Vaziri, Accountable Safety for rollups, 2022 https://arxiv.org/pdf/2210.15017.pdf [i] The Espresso Team, The Espresso Sequencer, 2023 https://hackmd.io/@EspressoSystems/EspressoSequencer#III-Espresso-Sequencer-Design-Principles-and-Requirements
Last changed by  
 
apriori
709

Read more

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
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. 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

3/21/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