Ethereum Core Devs Meeting 85 Agenda

[Souptacular]

Ethereum Core Devs Meeting 85 Agenda

• Meeting Date/Time: Friday 17 April 2020, 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream

Agenda

1. Berlin EIPs
   • EIP-2315: Simple Subroutines for the EVM 

   • EIP-2537: BLS12-381 curve operations
2. Eligible for Inclusion (EFI) EIP Review
   • EIP-2515: Difficulty Bomb
   • EIP-2456: Time Based Upgrades

   • EIP-2046: Reduced gas cost for static calls made to precompiles
3. Berlin Timing
4. EIP-2565: Repricing of the EIP-198 ModExp precompile
5. EIP-2602: Disable null hash message verification for ecrecover precompile
6. EIP-2583: Penalty for account trie misses
7. Quilt Team's Account Abstraction Announcement
8. Testing updates
9. EIPIP Survey
10. Review previous decisions made and action items (if notes available)

Next call: May 1, 2020 14:00 UTC

[ineffectualproperty]

Hi @Souptacular - If there is room in the agenda it would be great to introduce EIP-2565 (ethereum/EIPs#2565). Thanks!

[Souptacular]

Hey @ineffectualproperty! Can you attend the meeting this Friday?

[ineffectualproperty]

@Souptacular yup! If there is a Zoom link that needs to be sent perhaps you can provide it to Justin Drake and he can share it with me over Telegram.

[sorpaas]

I'd like to add ethereum/EIPs#2602 to the agenda, if possible.

[Souptacular]

Added @sorpaas.

[timbeiko]

Added EIP-2046 to the agenda to follow up on the benchmarking discussions from last call.

[MadeofTin]

When we discuss The difficulty bomb changes please reference: https://github.com/MadeofTin/EIPs/blob/patch-16/EIPS/eip-2515.md

The Automerger isn't merging my changes, so this is the most up to date version.

[holiman]

If possible, I'd like to hear feeback from client devs on ethereum/EIPs#2583 .

[Souptacular]

@holiman Added.

[villanuevawill]

If possible, would like to just quickly announce that Quilt, a team of 4 is currently implementing account abstraction into geth. Our implementation/rationale doc: https://hackmd.io/y7uhNbeuSziYn1bbSXt4ww?both
Vitalik's MVP suggestion which we are following: https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020

[karalabe]

@villanuevawill Account abstraction as designed by V was dropped because it was not feasible implementation wise. Taking that exact spec and implementing it will not become viable.

Tx verification phase ends with a PAYGAS opcode. Transactions that do not call this opcode within a specified verification gas limit (e.g. 400,000 gas) are treated similar to normal transactions with invalid signatures and are dropped from the mempool.

The txpool in Geth contains on average 5000 transactions all the time. That means after each block at worse we'd need to rerun 5000 x 400K gas computations just to check what's still valid and what isn't. That's 200 blocks' worth of computation, which would take 40 seconds on average on mainnet.

Before calling PAYGAS, AA transactions cannot access external state or contracts (other than precompiles).

How will the contract check whether the user making the tx is authorized or not, if they can't pull state to check anything? With zero state access, the contract could only do pure computations based on tx input data, which is super limited. You could embed e.g. allowed senders into the source code itself, but is that flexible enough?

Only one pending transaction at a time to each AA account

Doesn't this make your user onboarding use case non functional?

Modify clients to support multiple transactions with the same hash

That will break many invariants and will break also all existing APIs that DApps rely on. I'm not sure this is something we can pull off on Ethereum any more.

[karalabe]

Just to expand a bit, if an account pushes in 50 txs, the txpool caches the required balance for those (the max) and as long as the account doesn't spend all it's funds, a single balance check can validate all 50 txs. With account abstraction, we'd need to actually revalidate all transactions after every block.

Also txs validation involves crypto and whatnot, which might "cost" 400K initially, but the validation remains valid forever (unless a hard fork passes in between). So in the current model, revalidating pooled txs cost 0. In the new proposed model, it would be 400K, infinitely more.

[vbuterin]

How will the contract check whether the user making the tx is authorized or not, if they can't pull state to check anything?

Will answer this first as it seems like a big misconception. AA transactions cannot read external state. That is, a transaction with target account T can read the state of T, but not the state of anything outside of T. The state of T would be able to store data representing nonces and the like. And yes, the source code itself would include public keys and the like.

The txpool in Geth contains on average 5000 transactions all the time. That means after each block at worse we'd need to rerun 5000 x 400K gas computations just to check what's still valid and what isn't. That's 200 blocks' worth of computation, which would take 40 seconds on average on mainnet.

The invariant that pre-PAYGAS code cannot access external state (ie. state other than the state of the account contract itself) means that you only need to re-process transactions for accounts that were modified by other transactions. This already puts a cap, though conceivably I suppose one could have a block that touches 5000 accounts.

However, it turns out that we can completely solve this problem. Because we're only allowing one pending transaction at a time, the only possible case where a transaction with some target account T would need to be reprocessed would be modifications that come from the outside (ie.some transaction with target T' that then calls into T). But account contracts are not allowed to accept external calls. Hence, the only case we need to worry about is T' sending ETH into T (including eg. through self-destruct). We make this a non-issue by simply banning pre-PAYGAS execution from using the BALANCE opcode.

(Needless to say this would also require banning environment opcodes eg. TIMESTAMP, DIFFICULTY....., though there are safe ways to modify the proposal to allow access to those too but that's not needed for v1)

So if we do this there would never be any reprocessing required; nothing other than transactions with some target would be able to modify the validity of other transactions with the same target, and the one-pending-transaction rule ensures that that only happens in a few edge cases involving eg. tx replacement to bump gas fees, rogue miners, etc.

That will break many invariants and will break also all existing APIs that DApps rely on. I'm not sure this is something we can pull off on Ethereum any more.

This should be discussed more. My proposal had a version that doesn't break the invariant. Also note that there are backwards-compatibility-preserving strategies, eg.the existing API could simply return only the data related to the first time some transaction was sent. Users acting "normally" should not run into cases where they generate duplicate transactions.

[Souptacular]

@karalabe see above comment ^

[villanuevawill]

@vbuterin already responded to the points on accessing state - it cannot access external state, and for AA accounts, there is a one pending tx rule initially.

That will break many invariants and will break also all existing APIs that DApps rely on. I'm not sure this is something we can pull off on Ethereum any more.

This would not affect current accounts and would only break AA accounts (which there are none that exist yet).

Doesn't this make your user onboarding use case non functional?

Why would it make it nonfunctional? It depends on the application. If an application maps a contract per user, then the contract could be deployed with initial gas to pay on behalf of the user. Also, lets say in an application such as bounties, each bounty may be its own contract with eth allocated for gas.

[timbeiko]

Closed in favor of #165