Ethereum Core Devs Meeting 115 Agenda

[timbeiko]

Meeting Info

• June 11, 2021, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/XYhN26UrJ5o
• Zoom: To be shared on #allcoredevs Discord server shortly before the call

Agenda

1. London Updates
   1. Calaveras status & next steps
   2. JSON RPC Specification London JSON RPC Specification #334
   3. Yellowpaper EOA clarification / EIP-3607 EIP: Reject transactions from senders with deployed code EIPs#3607
   4. Testnet Fork Blocks London Timing #245 (comment)
2. Other Discussion Items
   1. 3074 Audit report
   2. ECH Survey

[lightclient]

Hi, I'd like to request some time to discuss the result of the EIP-3074 spec audits. We can have the auditing firms available for a brief summary and questions if time allows.

Here is the published report from Dedaub: https://docs.google.com/document/d/1itvPn7BhZ9N8h27d1Ig5C86_FZpyG5_cdpsuPJYmb-o/edit?usp=sharing

Here is the published report from Least Authority:
https://leastauthority.com/static/publications/LeastAuthority_Ethereum_Foundation_EIP-3074_Final_Audit_Report.pdf

[lightclient]

Additionally, may be good to discuss what value clients plan to use for baseFeePerGas during eth_call.

[timbeiko]

@lightclient added. Here's a discord link re: eth_call & baseFeePerGas. Can you share a link to the audit here when it is available?

[MariusVanDerWijden]

Hey I would like to discuss a clarification to the yellowpaper that forces clients to check whether an account is an EOA before executing the transaction. This was previously unspecified behaviour. We should specify that a transaction is only valid if the sender account contains no contract code (Enforce EOA check). cc @holiman

[jochem-brouwer]

@MariusVanDerWijden what about accounts which have no code but do have storage?

[timbeiko]

@MariusVanDerWijden added to the agenda 👍

[holiman]

what about accounts which have no code but do have storage?

I think those can only exist through genesis-allocation. Or, possibly {?}, running init-code and returning empty bytes.
Anyway, let's consider the threats a bit.

• If I can create a collision between some init-code (which fetches code from an oracle, so I can deploy whatever) and a private key, then I can deploy some game / token / ethwrapper / crowdsale which people put funds into, after verifying that the contract code is legit and cannot steal the funds. If I have the private key for it, I can steal it anyway, though. IMO this violates a long-standing assumption/agreement that ethereum contracts can only perform what the code dictates.
  • This scenario is 'fixed' by preventing transactions where the sender has code.
• For "contracts with storage", I don't see any actual threat, or violation of assumptions.

Since the sender is loaded from the trie during tx validation, the cost of either check is basically free (checking codehash / storageroot against two different constants is sufficient). I don't really see a need for the latter case, but have no strong opinion.

[lightclient]

Can we discuss ethereum/execution-specs#206 as well?

[timbeiko]

Sounds good, will add @lightclient !

[timbeiko]

I've created an issue to keep track of the various JSON RPC-related topics: #334

[ryanschneider]

RE: JSONRPC changes, it'd also be good to have an understanding on whether client devs think having these RPC changes in place in actual clients will be a requirement for the testnet fork blocks or if devs are "ok" forking some of the testnets before these JSONRPC changes are all decided on. Personally I think whatever RPC changes are agreed upon should be ready before the mainnet fork, but can understand if they are all not ready for the testnets.

[timbeiko]

+1. I can see them coming after the first testnet forks, but they do feel pretty mandatory for mainnet, esp. eth_call and eth_maxPriorityFeePerGas / feeHistory.

[dankrad]

We should discuss this for inclusion in London: ethereum/EIPs#3607

It's a fix that prevents the following issue: Someone can create an address collision between a contract and an EOA (note this has to be done before deployment, cost is currently around $10b according to @khovratovich but this could easily be off by a factor of 10 either direction). Then after tricking users into moving funds into the contract, they can spend these funds in any way they like using the EOA key. By preventing sending any transactions from contract accounts we can stop this attack (some other more minor attack vectors remain, listed in the EIP)

Note this isn't super urgent (attack would need much time & resources to prepare) but since the fix is so simple it could make sense to include in London.