Terminology a preconfirmation is not defined but is immediately used in the "preconfer" defintion a builder is responsible for providing a proof that constraints are followed, not "proving constraints are followed". slightly different and a small semantic nit pick "Relay: A trusted party", it feels quite arbitrary to add trust into this components definition when there is trust involved in each component to be honest. I have no idea what "an abstracted EVM RPC API" is. What is abstracted about it? it abstracts across many chains? that means its multichain. it supports preconf json RPC? well thats not abstracted, thats a new RPC API. API Notes why is /constraints/v0/builder/delegate seperate from the register validtor API? it feels like you should abstract that instead

Background The Ethereum Virtual Machine (EVM) is a transacton based state machine. The state of the system started with some genesis and was incrementally updated through executing transactions. The world state, $σ$, can be thought of as all state used in the virtual machine such as accounts, balances, and more. Transactions The state transition function can be expressed as: $$ (1) \sigma_{t+1} \equiv \Upsilon(\sigma_{t}, T)$$ $$ (2) \sigma_{t+1} \equiv \Pi(\sigma_t, B) $$ $$ (3) B \equiv (...,(T_0, T_1, ...), ...) $$

cowritten by Dan Marzec and Louis Thibault :::warning :warning: TL;DR: malicious actors can rely on eclipse attacks to win the "attestation race".We present an analysis of the exploit and summarize mitigation strategies. ::: Anatomy of an Unbundling Attack On April 3rd, 2023, an attacker used an exploit present in major mev-boost relays (mev-boost-relay, dreamboat) to extract $30M from front-running bots. The attack is outlined in the diagram below by Mike Neuder: A central concept underlying Proposer-Builder Separation (PBS) is that proposers must not be allowed to access the contents of a block before they "commit" to it (i.e. by signing the corresponding header). After a proposer has signed a block, they are susceptible to a slashing penalty if they sign a second one.

Motivation Recently I was pondering "How complex is Ethereum Core Protocol Software Development?" and the following picture popped into my head: Screenshot 2024-06-01 at 5.09.07 PM The thought process that spurred this was roughly: What is the least complex OSS development body? Probably a 2 person group chat. And Ethereum EIP and Core Dev is likely 75% away from 2 person group chat on the spectrum of complexity. But before I could start adding more OSS development bodies I realized this view is likely too limited, so I further decomposed it into two features, the number of contributors and the complexity of the "process". Screenshot 2024-06-01 at 5.17.56 PM

:::info This note provides a summary of PACELC, a framework for understanding the tradeoff between consistency and latency in distributed systems. ::: Table of Contents: What is the CAP Theorem In case you're unfamiliar, the CAP theorem states that any distributed data store can provide only two of the following three guarantees:

Overview Due to the public first-price nature of the MEV-boost auction, searchers have become incentivized to vertically integrate, becoming "searcher-builders" to bid "more strategically". This verticalization aimed at gaining an edge in the MEV-Boost auction has had the unfortunate consequence of considerably raising the barriers to entry for statistical arbitrage, and as a follow on consequence, has created an unfavorable market structure where new "searcher-builders" are bulk purchasing orderflow from other builders and subsidizing blocks as an effective "advertisement spend" to reach orderflow parity with incumbent block builders. Attempts to remove this edge from "strategic bidding" have primarily been focused on modifying the auction into a sealed-bid format, all of which have fallen short as they introduce new collusion vectors in the absence of private and credible commitment technology such as MPC, FHE, and TEEs. Greatly borrowing from distributed systems literature, this post sketches a proposal for enabling the ability to "lock state" in the mev-boost auction, with a follow-on feature of providing visibility into this "locked state". The ultimate outcome of this approach is that block builders are no longer effectively "pipeline stalled" via uncertainty in constructing the rest of the block, which opens the door for "Collaborative Block Building". In distributed systems terms, we are creating a "boot leg" decentralized multi-version concurrency control system for the ethereum distributed state machine by leveraging visibility. The main advantages of this approach are that it maintains basic privacy and bid update-ability to searchers competing in these high-velocity arbitrages, supports more generic arbitrage compared to previous "laned" approaches, and is easily deployable into the current market. The main drawbacks are its creation of a "pseudo-enshrinement" of single transaction arbitrages at the top of the block and offering a new censorship and griefing vector. As this proposal is merely a sketch, there are still large unknowns around how to effectively price the cost to lock state, the effects on searcher's bidding strategies, and how to generalize the auction past the ability to lock a single set of states. Desirable Properties for a State Lock Auction While not exhaustive, some immediately apparent favorable properties:

This work can be seen as a type of hierarchical consensus where each sub component implements causal broadcast instead of total order broadcast. Set Up and Goals Establishing a total order of transactions is one of the main scalability bottlenecks in blockchain networks. There have been numerous attempts at scaling blockchains, exemplified by the Lightning Network, Optimistic and ZK roll ups, sharding, and many more. Here we outline an approach for scaling built upon the observation that a total ordering is not required for all applications looking to achieve consensus faster than their base chain. SUAVE After Flashbot's successfully isolated the centralizing effects of MEV to the block builder role in Gasper PoS using a PBS design, the next goal became to decentralize the block builder role itself. In attempt to do so, the MEVM was released, a modification of the EVM with precompiles to support MEV use cases, all running on top of a network of Trusted Execution Environments (TEEs). This architecture allows users to send bids to an encrypted mempool and allow their bids to be processed by MEV applications written as smart contracts in Builder Solidity. By offering a higher level blockchain where these programs live, users are guranteed that the rules of the orderflow auction they grant premission to, are verifiably run over their bids. One of the most powerful parts of the MEVM design is that components that are common between OFAs, Solver Networks, RFQs, and Block Building can all be reused. Below we can see an example of what an early MEVM ecosystem might look like and how the components interact.

https://medium.com/@VitalikButerin/safety-under-dynamic-validator-sets-ef0c3bbdf9f6 - understand: - synchronous, - partially asynchronous - fully asynchronous network model, - simple faults, - Byzantine faults - accountable faults - How do faults relate to the goal of a distributed system?

modifications need to mev-boost ecosystem mev-boost - add ProposerCommitmentAddress to cli flag (probably a check on start up that the ) relay - add ProposerCommitmentAddress to cli flag block builder - add new block building algo which obeys a certain proposer commitment Then someone can deploy a proposer commitment using Emily.

Intro The MEVM, an adaptation of the EVM, is tailored with specialized precompiles to support MEV use cases, allowing developers to craft MEV applications as smart contracts within an environment akin to the conventional EVM. As a cornerstone of the SUAVE chain, the MEVM not only significantly reduces barriers to devising new MEV applications, but also facilitates the transformation of centralized infrastructures into decentralized blockchain-based smart contracts. To get a better understanding of how the MEVM works, let's delve into the deployment of a simple version of mev-share, a protocol for orderflow auctions, defined via smart contract on SUAVE. Our journey below will guide you through the steps of deploying simple mev-share and block builder contracts, interacting with them, and ultimately seeing a block land onchain. Prerequisites 🛠 This walkthrough will be based on a script located inside the suave cli tool so don't worry about copying over all of the code. To follow along and use the tool you will need: SUAVE node and SUAVE execution node setup. Basic knowledge of the Ethereum's Golang libraries and the Ethereum RPC methods.

:::info :bulb: This document provides a summary of 🔗 Original Source: "Content Censorship in the InterPlanetary File System" as well as provides an extended background on DHTs and how they operate in IPFS. ::: Abstract From, 🔗 Original Source: "Content Censorship in the InterPlanetary File System": Abstract—The InterPlanetary File System (IPFS) is currently the largest decentralized storage solution in operation, with thousands of active participants and millions of daily content transfers. IPFS is used as remote data storage for numerous blockchain-based smart contracts, Non Fungible Tokens (NFT), and decentralized applications. We present a content censorship attack that can be executed with minimal effort and cost, and that prevents the retrieval of any chosen content in the IPFS network. The attack exploits a conceptual issue in a core component of IPFS, the Kademlia Distributed Hash Table (DHT), which is used to resolve content IDs to peer addresses. We provide efficient detection and mitigation mechanisms for this vulnerability. Our mechanisms achieve a 99.6% detection rate and mitigate 100% of the detected attacks with minimal signaling and computational overhead. We followed responsible disclosure procedures, and our countermeasures are scheduled for deployment in the future versions of IPFS.

:::info :bulb: This document provides a summary of the cometBFT ABCI++ spec as well as draws comparisons to the ethereum consensus and execution layer. ::: Table of Contents: ABCI++ and CometBFT Cosmos' ABCI (Application BlockChain Interface) allows the consensus mechanism (e.g., Tendermint, and more recently CometBFT) and blockchain applications to work together while remaining agnostic to each other's specifics. The new ABCI++, compared to the original ABCI, provides the application with more opportunities to interact with the consensus algorithm, allowing it to influence proposal creation, proposal validation, and precommit voting. CometBFT is a recent adaptation of the Tendermint consensus algorithm, designed to protect safety under any network conditions, as long as less than 1/3 of validators' voting power is byzantine. The expected behavior of CometBFT in benign conditions and its interaction with the Application using ABCI++ is described in detail in the subsequent sections.

. Research Architecture Ethereum L1Protocol DesignsEnshrined Proposer-Builder Separations (ePBS)TODO summary: seperate the proposer and the builder ePBS-PTC: relay is replaced with in-protocol committee Protocol-Enforced Proposer Commitments (PEPC) Original proposed here, PEPC is an alternate version of in-protocol PBS (IP-PBS) wherein the proposer entirely gives up their right to create the block. This differs from the traditional MEV-boost model, where a proposer could lose an opportunity to create a block if a relay fails to publish on time. The post raises questions regarding the IP-PBS system's ability to handle scenarios like the advanced selling of block creation rights, arguing that this could undermine trust and encourage out-of-band agreements. The author concludes that rather than attempting to create a single, prescriptive mechanism, Ethereum might be better served by establishing a system for general "credible signaling" that allows for the possibility of new protocol duties that proposers could outsource in the future.Open Questions and Future Discussions:

PBS Proposal Popery :::success Popery not potpourri because this is a vision to head towards, not a fully fleshed out plan. ::: The vision for eth v2.5 is a dynamcially available protocol that can: handle block auctions natively, burn majority of MEV, and come to finality within a slot. While daunting, each of these pieces compliment each other in interesting ways. Table of Contents Diagram

The Hitchhiker's Guide to P2P Overlays in Ethereum Co-written by Louis Thibault and Dan Marzec Abstract The p2p topology of the beacon network is uncommon knowledge. In this post we dissect it's underlying components, and review some of the subtleties and optimizations at play. Using this knowledge we go through specifics to the beacon chains instantiation. If anything, consider this a poor man's GossipSub + consensus spec explainer. Table of Contents Motivation

:::info :bulb: TLDR; In OFAs such as mev-share, wallet-boost, Rook, and more, events are sent to searchers which represent economic opportunities in the form of information needed to extract MEV. When trying to design an information sharing protocol to optimize for some notion of "fairness", i.e. access to events is indepdent of resources, it seems likely that you end up stuck between a rock and a hard place, that is between needing a consensus free delay function like construction (PoW, VRDFs) or needing a blockchain on top of your blockchain. Is my logic faulty? Is there related literature or posts? Did I just rephrase the MEV problem at large in the context of OFA info reveal? LMK! :) ::: Introduction Order Flow Auctions are on the rise, with 12 in prod, 2 more in the pipeline, and reasoning to suggest tens(hundreds?) of others in the near future. A recent analysis breaks the OFA design space into ordertype, permissioning, information shared, bid selection, and settlement rights. The information shared portion of the design space is the subject of this post, and it questions an assumption implicit in both partial and full info sharing, mainly, is there a "fair" way to do so. Whether or not an OFA chooses to reveal full or partial information, the goal of most OFAs nonetheless is to eventually expose that information to searchers in a permissionless manner. Because the information being shared has economic value, we can expect to see similar dynamics as latency games that have already developed in TradFi and mempools. David's recent post does an awesome job at illustrating the cost/benefit structure of latency arm races. The main difference in what is explored here is not FCFS for transaction ordering but FCFS for information reveal (which does not include settlement). And we don't need to look far to see this info reveal problem in the wild: see the arbitrum sequencer fiasco that happened a few weeks ago, which architecturally is fairly equivalent to information reveal in OFAs.

Rough Overview $ PEPE/$ETH LPs deposit NFT into APP_MEV smart contract APP_MEV sweeps fees into paymaster contract Paymaster receives requests for user op sponsorship and only accepts if:first userop from this account user op is a swap for any token to $PEPE userop within gas used range paymaster has enough eth User submits userop to user op pool

This document outlines orderflow sharing objectives, potential design goals, initial ideas, and research areas, providing a preliminary implementation to explore the design space and uncover unknowns. Table of Contents Intro The central aim of orderflow sharing is to boost the confirmation rate of transactions traversing private mempools (e.g., Flashbots' Protect and MEV-Share) by dissociating from any single party's orderflow. Broadly, two approaches exist to achieve this objective: sharing the orderflow externally with others, and aggregating other builders' orderflow internally. Feasibility, competition maximization, and SUAVE compatibility act as guiding principles in evaluating these strategies. Furthermore, this design is intended to be a living, iterative product that will evolve in the wild over the next six months. Design Goals Some possible design goals and a discussion:

:::warning ⚠️ TLDR; A blocknative proposer payment for slot X (mev-boost) was found in slot X + 84 (non-mev-boost) and detected in the public mempool. The validator for both slots belong to the same pool according to beaconcha.in. ::: working backwards Blocknative monitors noticed a non-authorized payment transfer hash 0xbae... from our builder address 0xbaf.. at slot = 6260437account balance delta > excess transfer gas, only triggered when purposefully removing funds blocknative procedure requires multiple approvals and records of intent for such a transfer and none were found in our system Blocknative relay data API shows we did not win this block

Notes on Casper "Casper does not specify details on how blocks are constructed. We merely need that the concepts of blocks and attestations exist, and then LMD GHOST defines an algorithm to find a block given a view." TLDR: Message Types The main type of message proposes a block, which is a piece of data, to the network. Other messages can be: bookkeeping notices such as voting for blocks (“attestation”)