This note is a work in progress and should not be mistaken for a finished project
1/2/2024Ethereum 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/2023Arbitrum 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/2023If 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/2023or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up