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

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

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

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?

One of the difficult things about technical writing is that you want to be accurate, succinct, and authentic. Accurate Accuracy is about the quality of the information you are sourcing from. Is the information legitimate, is it stale meaning out of date? Is the information even relevant to the processes or abstractions you want to describe? The temptation exists to embellish a fact without context. This may be because you either do not understand the subject well enough to actually write about it or your understanding of the abstraction is context dependent eg. you know that is an essential part of the process with which you are writing about. Succinct Succinct is about explaining the concept simply with the exact amount of precision required. You can say that a block chain is a state machine that is turing complete hosted on a distributed peer to peer network that is byzantine fault tolerant. Or you can say a blockchain is a decentralized p2p network which provides a virtual environment for any arbitrary application.

This is simply a list of interesting materials. The lists are not exhaustive. Your favorite paper or article may be missing. Feel free to comment. Table of Contents ZK-VM Non-EVM ZEXE ZK General Rollups VMs & Hardware Hardware Acceleration

Part I. Types of MEV Players of the game The block production supply chain The emergence of Flashbots Part II. Long-term solutions (CL & EL)

This notes document includes various resources I've come across over the last 4 months. These 'Notes' should help shine light on the dark forest with many of these topics worth investigating further. Unless stated otherwise writing is pasta. TLDRs pulled from various source materials linked in the subheading or at the bottom of the subsection. There is much research on the topic of MEV in the Ethereum and other ecosystens that I surely missed. Also the contents here are focused more on theory than practice, so there is clearly room to add practical information as well (eg. liquidation, stat arbs, LT strategies, etc). Ultimately I hope this notes document saves you time which you can re-allocate to writing or other endeavors. Thank you to all of the authors who have provided outstanding research to build upon. Distributed Builder Idea Notes from this talk by Vitalik: Builders that decentralize internally, where the builder accepts bundles from an open market of actors called searchers.

As the title suggests, what follows are various resources I found useful in researching Ethereum's consensus design. I hope that this aggregation of information saves you time. A great starter is Appreciating GASPER by Sreeram Kannan Research ETH2 Book LMD-GHOST Ethereum Reorgs After The Merge (Vitalik + Georgios) Proposer Boost Path towards single slot finality (Vitalik 2022)