Skip to content

Add EIP: Block-Level Access Lists #9580

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.

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

Merged
merged 23 commits into from
May 6, 2025
Merged

Conversation

nerolation
Copy link
Contributor

No description provided.

@nerolation nerolation requested a review from eth-bot as a code owner April 1, 2025 10:32
@github-actions github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-core labels Apr 1, 2025
@eth-bot
Copy link
Collaborator

eth-bot commented Apr 1, 2025

✅ All reviewers have approved.

@eth-bot eth-bot added e-consensus Waiting on editor consensus e-review Waiting on editor to review labels Apr 1, 2025
@eth-bot eth-bot changed the title Add EIP: Block-level access lists Add EIP: Block-Level Access Lists Apr 1, 2025
@github-actions github-actions bot added the w-ci Waiting on CI to pass label Apr 1, 2025
Copy link

github-actions bot commented Apr 1, 2025

The commit ecad749 (as a parent of 4c8e46e) contains errors.
Please inspect the Run Summary for details.

@github-actions github-actions bot removed the w-ci Waiting on CI to pass label Apr 1, 2025
@benaadams
Copy link
Contributor

For parallelization would be better if read and write are distinguished (if in write list doesn't need to be in read list as SSTORE both reads and writes)

This is as multiple txs that only read can happen at same time; is only ones that write that enforce a specific ordering of tx order

@nerolation
Copy link
Contributor Author

nerolation commented Apr 1, 2025

For parallelization would be better if read and write are distinguished (if in write list doesn't need to be in read list as SSTORE both reads and writes)

This is already done by having an optional second value for the tuple of values. If there is only one, it's a read. This is early design though and not something I've spent much time further optimizing for practical and worst case use.

@benaadams
Copy link
Contributor

For parallelization would be better if read and write are distinguished (if in write list doesn't need to be in read list as SSTORE both reads and writes)

This is already done by having an optional second value for the tuple of values. If there is only one, it's a read. This is early design though and not something I've spent much time further optimizing for practical and worst case use.

Ah ok, I didn't pick that up

Copy link

@octavio12345300 octavio12345300 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

List

Copy link
Member

@jochem-brouwer jochem-brouwer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love the work on this! Left some lengthy thoughts. In general, I think that besides storage slots we also need to track accesses to balances of accounts, and we also need to know if new contracts are created. Such that if Tx A creates contract Z, then if Tx B calls Z it thus has to "wait" before Tx A has executed. The nice property of https://eips.ethereum.org/EIPS/eip-6780 is that we know that if a contract is creatd, it will now stay there, and can't be deleted anymore 😄 👍

General other question: is there also a discussion chat about this topic?

nerolation and others added 2 commits April 10, 2025 17:27
Co-authored-by: g11tech <develop@g11tech.io>
Copy link

@bomanaps bomanaps left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation of parallelization is mentioned in your motivation but not detailed in specification.

nerolation and others added 4 commits April 15, 2025 09:43
Co-authored-by: Ignacio Hagopian <jsign.uy@gmail.com>
Co-authored-by: Ignacio Hagopian <jsign.uy@gmail.com>
Co-authored-by: Ignacio Hagopian <jsign.uy@gmail.com>
Co-authored-by: Ignacio Hagopian <jsign.uy@gmail.com>
Copy link
Member

@jochem-brouwer jochem-brouwer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more comments! 😄 👍

Copy link
Member

@jochem-brouwer jochem-brouwer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two comments on the latest changes 😄 👍

@nerolation
Copy link
Contributor Author

Great, incorporated all the feedback - thanks everyone!

Would be great to have it merged now. It's ready for a first draft.

@eth-bot eth-bot enabled auto-merge (squash) May 6, 2025 13:30
Copy link
Collaborator

@eth-bot eth-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All Reviewers Have Approved; Performing Automatic Merge...

@eth-bot eth-bot merged commit 1ee4cac into ethereum:master May 6, 2025
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c-new Creates a brand new proposal e-consensus Waiting on editor consensus e-review Waiting on editor to review s-draft This EIP is a Draft t-core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants