From b9b187bccff8087a33cf3e9a99f8b96236f40382 Mon Sep 17 00:00:00 2001 From: fr0mano Date: Sun, 7 Dec 2025 12:15:56 +0800 Subject: [PATCH] Fix grammar errors in EIP-8079 --- EIPS/eip-8079.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-8079.md b/EIPS/eip-8079.md index 6a532be3b934f3..0fa118731dcb78 100644 --- a/EIPS/eip-8079.md +++ b/EIPS/eip-8079.md @@ -16,7 +16,7 @@ Expose the state transition function to the execution layer via a new `EXECUTE` ## Motivation -Today, EVM-equivalent rollups need to implement and maintain complex proof systems just to be able to replicate what Ethereum already provides on L1. Such complexity significantly increases the probability of encountering bugs and prevents projects from getting rid of security councils and from moving to Stage 2. EVM-equivalent projects are not similar enough and lack the proper incentives to benefit from each other efforts, significantly delaying multi-proof systems. +Today, EVM-equivalent rollups need to implement and maintain complex proof systems just to be able to replicate what Ethereum already provides on L1. Such complexity significantly increases the probability of encountering bugs and prevents projects from getting rid of security councils and from moving to Stage 2. EVM-equivalent projects are not similar enough and lack the proper incentives to benefit from each other's efforts, significantly delaying multi-proof systems. Moreover, to maintain feature parity with Ethereum, rollups need to implement bespoke governance systems that can't be forced to follow Ethereum's governance decisions, and thus are free to arbitrarily diverge from it. Because of this, the best that an EVM-equivalent rollup can do is to provide long exit windows for their users, to protect them from its governance going rogue. No finite (and reasonable) exit window can protect all use-cases, especially those that rely on timelocks (governance, staking contracts, vesting contracts). Longer exit windows protect more use-cases, at the cost of increase un-equivalence time. @@ -121,13 +121,13 @@ TBD: heavily depends on the ZK L1 design. ### Programmable "consensus layer" -The `EXECUTE` precompile allows rollups to define their own inputs and constrained their behaviour through smart contract. For example, in contrast to Ethereum's own consensus layer, a rollup can decide to: +The `EXECUTE` precompile allows rollups to define their own inputs and constrain their behaviour through smart contract. For example, in contrast to Ethereum's own consensus layer, a rollup can decide to: - Restrict the use of transactions that are sequenced by a permissioned entity, allowing for centralized sequencing and fast pre-confirmations, or leaving it open to everyone (based sequencing), or restrict it to a staked sequencer network; - Fix the `coinbase` address to be a DAO-controlled treasury, independent from the proposer address; - Tweak gas limits or prices based on specific needs; -This allows projects to preserve most of their configurations they already benefits from. +This allows projects to preserve most of their configurations they already benefit from. ### Gas tokens