Comments (18)
I would like to discuss what is necessary to get EIP-5003 included in Pectra, additional to EIP-3074. To be able to fully facilitate the opportunities given by EIP-3074 for smart accounts and AA it would be extremely beneficial to also have EIP-5003 available. Especially since this will otherwise be delayed for quite a while.
from pm.
I would like to discuss at a higher level what is Ethereum's and the EIP process's core charter. Specifically around:
- Ethereum's transition to a rollup centric roadmap and priorities, goals, and non-goals for protocol level changes.
- The decoupling between EIP processes and RIP processes, and on the longer tail, the ability for rollups to innovate protocol level changes without standardization with respect to frameworks and objectives for what needs to be standardized everywhere, what needs to be standardized on rollups, and what doesn't need to be standardized.
from pm.
I've updated the agenda will all of the above. Some context:
- We'll start by covering anything relevant to devnet-0
- 3074 makes sense to cover after as changes may or may not be included in the devnet
- We can discuss the various proposals, but more broadly it's worth getting a feel from client teams about their ability to commit to more EIPs while we still have not implemented the ones already included
- If time permits, we can have the L1/L2 conversation, but if all of the above takes up the full call we may have to bump it to another ACD, or perhaps RollCall
from pm.
Actually there are two proposals wrt 3074 that I'd like to discuss:
-
Update AUTH message to
keccak256(MAGIC || chainId || nonceManagerAddress || nonceManagerNonce || invokerAddress || commit)
-
Remove
nonce
from AUTH message but add an opcode for gettingnonce
from pm.
I would like to discuss this possible improvement to EIP-3074.
from pm.
I would like to discuss this possible improvement to EIP-3074.
As one of the authors of this suggested improvement, I would also like to propose this as a possible improvement to EIP-3074
from pm.
I would like to discuss the inclusion of 7212 secp256r1 precompile.
I would also like to discuss the behavior of 3074 with delegatecall before an authcall.
from pm.
Would like to decide if the versions of EIP-6110 and EIP-7002 that will be implemented on pectra-devnet-0 should depend on EIP-7685. I believe they should, but it results in minor rework on the EL side for each.
from pm.
Correction, meant DELEGATECALL
before AUTHCALL
from pm.
Not making it to this call myself, but would like to get the SSZ transition highlighted once more, as described in https://notes.ethereum.org/@vbuterin/purge_2024_03_31#Moving-to-SSZ, https://hackmd.io/@philknows/ryMFFQUpT, and https://hackmd.io/@etan-status/electra-lc:
These allow JSON-RPC API servers to include correctness proofs in their responses, eliminating the current requirement to trust them. It is ridiculous that a network as decentralized as Ethereum can only be practically used from wallets, phones, smart contracts and so on by either running a full node (not always feasible), or trusting a centralized entity (some of which are known to have concerning privacy policies when it comes to logging / associating queried wallets with IP addresses etc). With correctness proofs, anyone will be able to serve data without requiring reputation and trust. This then allows a decentralized server infrastructure that is more secure and privacy preserving.
The EIPs also introduce the concept of forward compatibility, which is vital when applications don't share their update cadence with Ethereum. For example, mobile phone OS system services, bridges, decetralized staking pools and so on, they all benefit when their Merkle proof verifiers don't keep breaking when unrelated changes are made to Ethereum. With Electra, the BeaconState
is re-indexed (ethereum/consensus-specs#3668 (comment)), already triggering breakage. By pushing these EIPs into Electra, we can avoid future breakage as new features get added and old features get deprecated, at least until the data structures change fundamentally (e.g., SNARK-friendly hashes, far future).
For user adoption, Ethereum should reach a state where it is possible for Apple/Amazon/Google/Cloudflare to run additional full nodes in the cloud that can be trusted for data availability, and for iOS/Android to run a light client as a system service that uses them to stay up to date about relevant events in a battery and privacy preserving way. All these current approaches with messy browser extensions and random apps have to eventually go, they are not securely usable by the masses.
Note that the SSZ EIPs primarily benefit users, application developers, etc, while the effort has to be done by Ethereum core client teams. The effort is non-trivial, but also not a huge hurdle. I did a PoC of the changes discussed in the EIPs myself over at https://eth-light.xyz - the EIPs serve as the basis to unlock all of what's described above, and maybe even benefit environmental concerns in that Bitcoin PoS EIP ;-)
Electra should be the time for it, Geth already has a beacon light client so supports SSZ. Erigon also has it. We only need to add StableContainer to the various SSZ libraries, and change some hashing / serialization for a few data structures. Mostly mechanical changes at this time.
Even though I can't make the call tomorrow, at the very least, I'd appreciate getting some comments on the EIPs Ethereum-Magicians threads.
from pm.
I would like to have a discussion on including EIP-7623 in Pectra.
There is a discussion thread in the Eth R&D discord:
https://discord.com/channels/595666850260713488/745077610685661265/1228262613239201804
As well as a short summary of the EIP on ethmagicians:
https://ethereum-magicians.org/t/eip-7623-increase-calldata-cost/18647/17
from pm.
Can we also discuss EIP-7636 as it regards an addition to the ENR.
from pm.
@jflo I believe we had agreed to this on last week's CL call, but yes, that's why I have 7685 first on the agenda. Will explicitly call out the impact on 6110/7002 👍
from pm.
Regarding the two EIP-3074 nonce proposals, I want to put my stake in the ground that what I care about is an in-protocol revocation mechanism to revoke an EIP-3074 AUTH signature, with a revocation economy no worse than one action per signature. (i.e. 100 actions to revoke 100 separate signatures is fine, but 100 actions to revoke 1 signature, not fine). Deferring your nonces to another contract weakens the guarantees and moves them out of the ethereum protocols.
from pm.
Regarding the two EIP-3074 nonce proposals, I want to put my stake in the ground that what I care about is an in-protocol revocation mechanism to revoke an EIP-3074 AUTH signature, with a revocation economy no worse than one action per signature. (i.e. 100 actions to revoke 100 separate signatures is fine, but 100 actions to revoke 1 signature, not fine). Deferring your nonces to another contract weakens the guarantees and moves them out of the ethereum protocols.
@shemnon i believe the nonceManager
idea will address your concern. A user can always set nonceManager
to their own EOA to get the same behavior as the spec specifies today. But it also gives users the flexibility of using a contract as the nonceManager
if they want to avoid accidentally revoking AUTH sigs.
Anyways, looking forward to discussing it more tomorrow.
from pm.
I would also love to discuss if it should be possible to allow signing 0
as the chainId
for 3074 to allow replayablility across chains. Having an explicit way would be very powerful for cross-chain dynamics (especially in conjunction with 5003)
Edit: This would fall under AUTH message updates
from pm.
I plan to oppose EIP-7623, which creates free gas, in Meeting 187.
from pm.
Closed in favor of #1029
from pm.
Related Issues (20)
- EOF Implementers Call #42 HOT 3
- Ethereum Sequencing and Preconfirmations Call #6
- MaxEB Breakout Room #7
- EOF Implementers Call #43 HOT 4
- Verkle Implementers Call 17 HOT 1
- RollCall #5 HOT 5
- EOF Implementers Call #44 HOT 1
- Verkle Implementers Call #18 HOT 3
- Execution Layer Meeting 187 HOT 7
- Consensus-layer Call 133 HOT 3
- Future of EOA/AA Breakout Room #2 HOT 5
- EOF Implementers Call #45 HOT 7
- Ethereum Sequencing and Preconfirmations Call #7 HOT 1
- EOF Implementers Call #46 HOT 1
- RollCall #6
- Execution Layer Meeting 188 HOT 14
- Ethereum Sequencing and Preconfirmations Call #8 HOT 1
- EOF Implementers Call #47
- Ethereum Sequencing and Preconfirmations Call #9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pm.