Skip to content

Update EIP-8079: Refine wording motivation and rationale #10826

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+4 −4
Open

Update EIP-8079: Refine wording motivation and rationale #10826

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions EIPS/eip-8079.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@

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.

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.
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 increased unequivalence time.

This EIP provides a way for rollups to reuse Ethereum's state transition verification infrastructure, and as a consequence massively simplify their infrastructure and upgrade processes. This enables projects to better redirect resources towards user-facing features and products.

Expand All @@ -26,7 +26,7 @@

### Parameters

<!-- TODO -->

Check warning on line 29 in EIPS/eip-8079.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn` 

warning[markdown-html-comments]: HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn`
   --> EIPS/eip-8079.md
    |
 29 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
 43 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
116 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
148 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
157 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
162 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
167 | <!-- TODO -->
    |
    = help: see https://ethereum.github.io/eipw/markdown-html-comments/

Check warning on line 29 in EIPS/eip-8079.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn` 

warning[markdown-html-comments]: HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn`
   --> EIPS/eip-8079.md
    |
 29 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
 43 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
116 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
148 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
157 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
162 | <!-- TODO -->
    |
   ::: EIPS/eip-8079.md
    |
167 | <!-- TODO -->
    |
    = help: see https://ethereum.github.io/eipw/markdown-html-comments/

| Constant | Value |
| - | - |
Expand Down Expand Up @@ -121,13 +121,13 @@

### 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 contracts. 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;
- 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 (permissionless 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 the configurations they already benefit from.

### Gas tokens

Expand Down
Loading