Given the recent resurgence of interest in EIP-3074, I wanted to take a moment to highlight some of the important aspects of the EIP and how I imagine it will be adopted into the day-to-day usage of Ethereum users. image The same, but different EIP-3074 is usually framed as an alternative to ERC-4337. That isn't exactly true. In the case of EIP-3074, the main goal is to delegate control of your EOA to a smart contract. It quacks like Account Abstraction because it supercharges EOAs with smart contract wallet functionality, but at the end of the day, it is still an EOA. Stolen key means total loss (although there are some mitigations for lost keys). EIP-3074 makes no consideration for transaction sponsoring / relaying, which is the meat of ERC-4337. The idea being developers will build systems on top of EIP-3074 which solve this. It turns out ERC-4337 actually is that system, and the team has painstakingly addressed every edge case to deliver a robust user op relaying system that is safe for users and bundlers alike.

Guillaume Gajinder, Phil -- What is a light client? What is the light client summitHow do I apply to talk about my project? How did you first learn about light clients? And how did you engage with the technology over the years?

What: a conference about p2p, focused on DHTs, discovery, and gossip. When: Thu, Aug 31, right after SBC; 10am-5pm. Where: Fischer Conference Center @ Arrillaga Alumni Center, Stanford. Why: to improve the performance and security of permissionless protocols Brought to you by: Ethereum Foundation and volunteers. The recordings for 2022 can be found here. Registration The conference is currently full. Thank you for all your applications!

This is an rough outline of the major contributions to the topic of Account Abstraction over the years. Of course, it is not exhuastive and varies a bit on the exact domains of Account Abstraction (protocol, ERC, wallets, etc) that it touches. I hope you will find it useful. 2022 EIP-5003: Insert Code into EOAs with AUTHUSURP (Q) EIP-5792: Wallet Abstract Transaction Send API (M) A brief note on the future of accounts (Q) 2021

JSON-RPC Specification There are several opportunities to contribute to the JSON-RPC specification. A few examples are: Automated testing Mostly writing go to integrate into Hive. See the example JSON-RPC tests here. The idea is to intercept both the requests and responses and validate them against the spec schema. Improve documentation tooling There is a frontend for the documentation written in typescript that could use improvements. The code for that UI is here. It's using the React framework which is super popular and would be a great thing to learn if you want to do more frontend engineering. Improve documentation

Introduction EIP-3074 adds a powerful new primitive to Ethereum that allows EOAs to act as smart contract wallets. This will allow many new use cases, including transaction batching and account recovery. If you are unfamiliar with this EIP, please review this thread. Statement of Work (Part 1) The first portion of work is focused on learning how EIP-3074 can be used. The learnings+research from this stage will feed directly into the next stage where the production contracts and integrations are completed. Total grant ask = $18,000 proof-of-concept Uniswap integration = $12,000

Signing a malicious tx In this threat model, we'll assume that an adversary can trick a user into signing an invalid transaction. EOA: if a user secures their assets in an EOA and they sign an arbitrary malicious transaction, the worst that can be done is their most valuable asset will be compromised. Generally, there isn't the ability to "batch" actions together so the attacker will should go after the user's most valuable asset. In the future, it's likely that more contracts will support meta-txs and standards for batched actions will emerge or that the protocol will support batching for EOAs. This would make it possible for an attacker to appropriate more than one of a users assets. Smart Contract Wallet: if a user secures their assets with a smart contract wallet, they are vulnerable in a similar way as above. The exact vulnerability is dependent on the implementation of the wallet contract they are using. If the wallet contract mimics the same functionality as the protocol, the user can lose their single most valuable asset. If the wallet supports batching, they can have their account completely emptied. One advantage is that contracts can impose limits for transfers and fallback to multi-sig authentication for large transfers. This would require parsing the calldata to understand how much is being transferred (ether is trivial to check, other assets -- not as much). EIP-3074: in this case we'll assume the invoker contract is bug-free (this is the same assumption made above for smart contract wallets, we'll explore contract bugs later). By bug-free, we mean the user's transaction is not malleable. What the user signs is what will happen. In this case, the worst that can be done is equivalent to that of a smart contract wallet. In the simple case, the user will lose their single most valuable asset. The caveat here is that EIP-3074 does not permit value transfers from the authorized account. Therefore, the attacker would not have access to the user's ether stored in their account balance. If the invoker supports batching, one signature for $N$ actions, the user will lose every valuable asset in their account. Like smart contract wallets, it's possible for the invoker to impose transfer limits on an account -- minimizing the potential damage. EIP-3074 can potentially be made worse though. If a user secures their key with a hardware wallet and the hardware wallet supports arbitrary invoker addresses, an adversary could trick a user into signing an EIP-3074 message to a malicious invoker. This should be combated by the hardware wallet not allowing arbitrary invokers to be signed over. Only a trusted list of invokers should be preloaded onto hardware wallets. This could be updated overtime by updating the hardware wallet's firmware (if we can't do this securely, we have other problems). If hardware wallets impose this restriction, the vulnerabilities here are equivalent to using a smart contract wallet. Compromised computer In this threat model, we'll assume an adversary has complete control of a user's computer.

Core Development Migration to binary tree (EIP-3102) Optimal native batched transactions EIP-2711: Sponsored, expiring and batch transactions EIP-2733: Transaction Package EIP-2803: Rich Transactions EIP-2938: Account Abstraction EIP-3074: Sponsored Transaction Precompile

2020 EIP-2711: Separate gas payer from msg.sender Native meta-transaction proposal roundup EIP-?: CallWithSigner EIP-2585: Minimal Native Meta Transaction Forwarder EIP-?: Native Batched Transactions EIP-?: Rich transaction precompile Towards a meta-transaction standard

Relayer calls into AA Idea The general idea is that AAs support intra-transaction calls, after PAYGAS is executed. In this case, a user with no ether would submit a candidate transaction to a relayer. The relayer would decide if it would like to pay for the transaction. If they decide yes, they would craft a transaction, wrapping the user's transaction, and submit it on-chain. The relayer's account would verify their transaction and execute the PAYGAS opcode. Immediately after this, the relayer would call the user's account, passing in the user transaction. The user account would process the validity of the transaction. If valid, it would check to see if a PAYGAS has already been issued, and skip over it to continue the remaining execution if so. This would allow external call from the user account to properly hydrate msg.sender. Problem Imagine a user $A$ asks a relayer $R$ to relay $N$ transactions. $R$ also creates $N$ transactions, wrapping each of $A$'s transactions. Before $R$'s transactions are mined, $A$ submits a transaction with a much higher gas price than $R$, causing it to be included before $R$'s transactions. This creates a griefing vector against $R$ since $A$ can always submit transactions to $R$ which should pay out to them, and then front run them to drain $A$. Inversely, if $A$ submits a large number of transactions and then a single transaction which is relayed by $R$ and the relayed transaction is included, it could potentially invalidate all the transactions submitted by $A$. PAYGASFROM opcode Idea Introduce a new opcode PAYGASFROM whose arguments are gasprice, from, and calldata. Once executed, the from account will be called with the calldata to verify that it plans to pay for the execution of the transaction. Upon successful verification, it will update any replay protection mechanisms and then return control to the original entry point to continue execution.

# Ethereum 2.0 Merkle Proof Format The SimpleSerialize (SSZ) [specification](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/simple-serialize.md) defines how different types should be serialized and represented as a merkle tree. There has recently been discussions around the complexity of defining a merkleization method for dynamically sized objects, and the Ethereum 2.0 researchers have decided to avoid the complexity by forcing all dynamic types to i) specify a maximum capacity and ii

# Systems Engineer (Rust) Quilt is a research-focused team under ConsenSys R&D. We’re focused on pushing the Ethereum ecosystem forward — no strings attached to business functions. Our team is 100% remote and everything we build is open source. Some of the various projects we work on: * Infrastructure, simulations, and tests to build an end to end Ethereum 2.0 prototype and testnet ready for benchmarking and viability studies * Formalization of the Ethereum 2.0 VM (Web Assembly) * Execution env