search

ethereum / pm

Project Management: Meeting notes and agenda items
Other
1.55k stars 313 forks source link

Execution Layer Meeting 186 #1016

Closed timbeiko closed 2 months ago

timbeiko commented 3 months ago

Meeting Info

Agenda

rmeissner commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

I would like to discuss at a higher level what is Ethereum's and the EIP process's core charter. Specifically around:

derekchiang commented 3 months ago

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

JKincorperated commented 3 months ago

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

ankurdubey521 commented 3 months ago

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 commented 3 months ago

Actually there are two proposals wrt 3074 that I'd like to discuss:

smartprogrammer93 commented 3 months ago

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 commented 3 months ago

I've updated the agenda will all of the above. Some context:

jflo commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

Correction, meant DELEGATECALL before AUTHCALL

etan-status commented 3 months ago

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 (https://github.com/ethereum/consensus-specs/pull/3668#discussion_r1560445851), 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 commented 3 months ago

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

timbeiko commented 2 months ago

Closed in favor of https://github.com/ethereum/pm/issues/1029