Skip to content
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

Execution Layer Meeting 186 #1016

Closed
timbeiko opened this issue Apr 11, 2024 · 18 comments
Closed

Execution Layer Meeting 186 #1016

timbeiko opened this issue Apr 11, 2024 · 18 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Apr 11, 2024

Meeting Info

Agenda

@rmeissner
Copy link

rmeissner commented Apr 15, 2024

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.

@nerolation
Copy link

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

@noam-alchemy
Copy link

noam-alchemy commented Apr 17, 2024

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.

@derekchiang
Copy link

I would like to discuss this possible improvement to EIP-3074.

@JKincorperated
Copy link

Can we also discuss EIP-7636 as it regards an addition to the ENR.

@ankurdubey521
Copy link

ankurdubey521 commented Apr 18, 2024

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

@derekchiang
Copy link

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 getting nonce

@smartprogrammer93
Copy link

smartprogrammer93 commented Apr 21, 2024

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.

@timbeiko
Copy link
Collaborator Author

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

@jflo
Copy link

jflo commented Apr 23, 2024

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.

@timbeiko
Copy link
Collaborator Author

@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 👍

@shemnon
Copy link
Contributor

shemnon commented Apr 24, 2024

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.

@derekchiang
Copy link

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.

@rmeissner
Copy link

rmeissner commented Apr 25, 2024

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

@smartprogrammer93
Copy link

smartprogrammer93 commented Apr 25, 2024

Correction, meant DELEGATECALL before AUTHCALL

@etan-status
Copy link

etan-status commented Apr 25, 2024

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.

@wjmelements
Copy link

I plan to oppose EIP-7623, which creates free gas, in Meeting 187.

@timbeiko
Copy link
Collaborator Author

Closed in favor of #1029

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests