Jason @0xbbbb_eth
Account Abstraction Developer
MEV Researcher
Core Contributor of @ETHconomicspace
Account Abstraction
ERC-4337 Account Abstraction Core Devs Call #30 and #31
Core Devs Call #30:
Need spec for conditional endpoint for Scroll & Linea to prevent fund loss
Concerns on EIP-3074’s impact on AA & security
Waiting for EIP-3074 testnet inclusion
Focus on refining EIP-4337 & evaluating EIP-3074
Core Devs Call #31:
Shared Mempool testing on Sepolia
Single client bundler live on Arbitrum Sepolia
Estimation method update underway
EntryPoint v0.7 support implementation in progress
EIP-7562 docs overhaul for testing alignment
Everything About Account Abstraction: Vitalik Buterin's EIP-7702…
Vitalik Buterin Proposes EIP-7702 to Enhance EOAs
EIPs/EIPS/eip-7702.md at 9e04cf1094eae64172ce04e0a04ec40f1edbdc5d · ethereum/EIPs
EIP-7702 introduces a contract_code field and a signature feature that temporarily converts EOAs into smart contract wallets to perform complex transactions.
The goal of EIP-7702 is to address forward-compatibility concerns and avoid the creation of separate invoker contract ecosystems, aiming for a unified smart contract wallet approach.
EIP-7702 faces challenges similar to those of EIP-3074, including trust in code and the risk of centralization.
simplifies 3074 by removing invoker infra requirement gets 5806 batch functionality in simpler way
users would transiently deploy smart contract (or delegatecall, which is a subset) logic to their own accounts for a single tx scope
Integration with 4337 bundles, batching, and sponsorship seem more straightforward with 7702 than with 3074’s invoker contracts.
Vitalik further explains that the contract code for EIP-7702 could use the existing ERC-4337 wallet code, ensuring a smooth transition and compatibility with future Ethereum standards.
Safe co-founder Lukas Schor has endorsed this approach, appreciating its potential to simplify complex wallet operations while aligning with Ethereum’s long-term goals.
The 3074/7702 saga left me concerned with ETH governance.
Viem experimental support of EIP-6492
sig verify for not yet deployed smart account
EIP-5792 website
new JSON-RPC methods for communication between apps and wallets
ERC-7677 allows app developers to sponsor their users' transactions via an EIP-5792 capability.
3074 → 4337 & 7702 → 4337
AA roadmap (2024/05)
RIP-7560 for L2
4337 and native co-exist for years
make some part of RIP-7560 optional as separate standard
EOA extension RIP (extracted from RIP-7560) provides several benefits over EIP-3074
This app is an experiment in using Coinbase's Smart Contract Wallet for real world in-person purchase experiences.
I think computers can be safe AND in a user's control. Some of the EIP-3074 criticism has seemed to be stuck between claiming it would either be "unsafe" or "gatekept", so I wrote a post about a way to avoid either trap
ERC-7579 vs ERC-6900
MetaMask Smart Transactions
Protocol
Arbitrary size limits set by builders impose additional rules on apps that go beyond the 30m gas limit.
Blobs were excluded here
Prove that a validator has been slashed or has never being slashed
leveraging EIP-4788 beacon block root in EVM
EIP-7706: Separate gas type for calldata
The timing games
How to Raise the Gas Limit
summary of the latest eth dev call, acde #187
pectra devnet incoming possibly next monday
eip 7702 possibly replacing eip 3074 in pectra
ssz transition not likely to be included in pectra
eof, eip 7623, and eip 7705 TBD for inclusion in pectra
Layer 2
OPStack plasma mode
challenge DA provider to post full data
https://l2beat.com/scaling/projects/redstone#data-availability
StarkNet L3 appchain can leverage Celestia Blobstream
Blobstream contract on L1 but L3's DA verification happens on L2
so L2 needs to access L1 (Blobstream) data -> Herodotus storage proof
This state diff approach is undoubtedly beneficial in terms of cost compared to the raw transaction data publishing approach since it can skip out storing the intermediate transactions, reducing the storage cost in L1. However, although not commonly an issue, there is an underlying drawback here: this approach doesn’t allow for a restoration of the full L2 transaction history, which can be an issue for some DApps.
L2BEAT - The state of the layer two ecosystem
A friendly reminder that if the L2 chain shuts down, it may not be possible to withdraw funds.
Based Rollup
Developer
Reth AlphaNet and forge-alphanet
Paraswap vulnerability: Post Mortem: Augustus V6 Vulnerability of March 20th, 2024
The vulnerability was related to a specific function called uniswapV3SwapCallback(). It’s used as a callback to UniswapV3 direct functions, such as swapExactAmountInOnUniswapV3(). The purpose of these direct functions is to save gas on swaps by significant amounts; they’re basically a gas-optimized replacement to the native UniswapV3 Router. UniswapV3SwapCallback() is called back by a Uniswap pool, but it didn’t implement a proper caller check in some cases, which meant that an attacker could create a fake pool and call that function on behalf of the user in order to drain the tokens they approved for Augustus V6.
Compiling for the EVM: Codegen for Stack Machines
Solidity stack too deep error and compiler codegen
Solidity puts local variables to the same stack
Export Shadow logs to Dune
what's the trust assumption?
prompt cheatcodes in forge-std 1.8.2
Test your blob contracts now on Foundry
Others
https://openai.com/index/reimagining-secure-infrastructure-for-advanced-ai/
TEE & AI
New Threshold Encryption Schemes for Mempool Privacy and Timelock Encryption - HackMD
Silent Threshold Encryption: user picks committee before encryption, and no interaction needed
Batched Threshold Encryption: communication complexity independent of batch size
Aligned Layer
soft (economic) finality, faster (economic) bridging for zk dApps/protocols