Derek Chiang | Ethlabs

Quick notes on 7702 to dispel fud and keep your funds safe.

First thing first -- 7702 itself isn't broken. Don't panic if you are using a wallet that supports 7702 (MetaMask, Uniswap, Ambire, etc.).

To recap, 7702 is an account abstraction EIP that allows an EOA to sign a special message, called a "7702 authorization," that would insert a smart contract into the account, which enables the account to do powerful things like transaction batching, e.g. doing "approve" and "transfer" in one transaction so you can swap on Uniswap with one click.

But unfortunately the same feature also allows a hacker to efficiently move all your tokens in one single transaction. In the Binance hack, the hacker moved ETH, USDT, and 62 other tokens in one transaction, whereas without 7702 they'd have had to send one transaction per token. In this particular case, many of those transactions would've failed because Binance was still using the hacked wallet for withdrawals, so all transactions sent by the hacker would've had to compete with the legit transactions for nonces. So using 7702 did help the hacker steal as much funds as possible, as quickly as possible. Ouch!

However, in order for the hacker to use 7702, they must have either 1) had access to the private key, or 2) tricked Binance into signing a 7702 authorization. The latter is very unlikely, as it's hard to imagine Binance being so incompetent as to expose an endpoint for signing 7702 authorizations or (even worse) for signing raw messages which the hacker could've repurposed for 7702 authorizations. But I can't rule that out until the official postmortem.

What does all this mean for you?

- If you are a wallet developer, do NOT, under any circumstances, expose a way for third parties to request 7702 authorizations. This is just handing your users a giant footgun to shoot themselves with. No wallets I know of do this, so don't worry if you are a user.

- If you are a user, use a well-known wallet. 7702 does let wallet developers screw up in more ways than before, so use only well-known wallets whose developers' competence you can trust.

- If you are a company (e.g. an exchange) operating hot wallets, do NOT, under any circumstances, expose an endpoint (even if it's an internal endpoint) for signing 7702 authorizations or raw messages.

As a contributor to AA, I feel partially responsible for hacks like this, since by increasing the power of accounts, we've indeed also empowered hackers (not unlike how any new technology empowers both the good guys and the bad guys). That said, it's important to note that 7702 was only a transitional EIP, and "endgame AA" such as Frame Transactions (EIP-8141) would allow wallet owners to set up their wallets much more securely. For example, if Frame Transactions were available today, Binance could've:

- Set up their wallets as multisig contracts only (not EOAs).

- Set up "post conditions" for their `transfer()` functions, so that even if the multisig got hacked, the contract itself would perform sanity checks such as "no transfers of more than 1000 ETH without additional signers."

In short, the endgame of Ethereum UX is one with both optimal security and optimal UX, and users never have to trade off between the two. But we still have a long way to go until we get there. Back to work!

I made a visualization of EIP-8288 aka "recursive mempool aggregation," my new favorite EIP of all time because it perfectly encapsulates the thesis of the "cryptographic world computer" -- a system whose scalability *increases*, not decreases, with the level of decentralization.

In a previous tweet I explained how EIP-8288 achieved this seemingly impossible feat, but one gif is worth a thousand words.

Essentially, EIP-8288 leverages Ethereum's decentralized mempool as a parallel ZK proving cluster. Clients send signatures and proofs to the mempool, which over multiple rounds progressively aggregate them into fewer and fewer proofs, until the block builder finally aggregates them into one SINGLE proof.

This design accomplishes five things at once:

- The more nodes we add to the decentralized mempool, the more signatures/proofs Ethereum can process as a whole. This is obvious if you look at the animation and imagine more nodes in the mempool ring, which would "fan out" to more signatures/proofs.

- By aggregating over multiple rounds (aka "recursive aggregation"), the bandwidth consumed by proofs remains constant for each node even as the network processes more proofs. As a result, the network stays decentralized even as capacity increases.

- By aggregating proofs before one final aggregation by the builder, as opposed to requiring the builder to aggregate everything, the network can process more proofs without increasing hardware requirements for the builder.

- By aggregating everything to a single block-level proof, validators can verify thousands of signatures/proofs by checking just one aggregated proof. Hardware requirements for validators can therefore stay low, keeping the network decentralized.

- By aggregating not just native signatures but also STARKs, Ethereum can support any signature scheme by wrapping them in STARKs.

So once again, this is how Ethereum will:

- scale to process tens of thousands of PQ and private transactions per second

- charge a tiny amount of gas to validate each txn, even though the original signature/proof may be huge (up to hundreds of KBs in size)

- all while decentralizing even MORE.

You are not bullish enough.

One would think that because blobs are almost free, L2s should have no problem landing blobs. But one interesting thing I learned from interviewing L2s is that they in fact have a lot of trouble landing blobs, EVEN WHEN there's no congestion. I want to explain why, as that reveals some very interesting facts about the protocol.

Recall that blob pricing works similar to gas pricing (EIP-1559), where there's a "base fee" which goes up or down each block, depending on whether the previous block hit the target number of blobs (14 out of 21). The idea is that in a well-functioning market, the base fee will track the "market price" of blobs, so that you can land blobs by just paying the base fee, with perhaps a little priority fee if there's congestion.

However, whereas this mechanism works well for regular gas, it turns out to be an issue for blobs, because blob demand is relatively inelastic to price. In other words, just because the blob price is low does not mean that L2 will send more blobs -- they still need to fill those blobs with L2 transactions, which may have low demand even when L1 blob fees are low.

As a result, blob usage has been consistently below target, such that the blob price sat at 1 wei -- the theoretical minimum -- for a long time. A later EIP raised the floor higher, but it's still so low as to be effectively free.

Why is this an issue? Normally it's not. People love free blobs! But at times of congestion, because the base price starts so low, it takes a HUGE amount of time for the base price to rise enough to discover the true market price. For example, if the base price is 1 gwei and the (hidden) market price is 40 gwei, it would take 47 consecutive full blocks (~10 minutes) for the base price to catch up. By the time it catches up, the congestion may already be over.

So what do L2s do during congestion? They bid with the priority fee, but without knowing what the true market clearing price is, they have to overbid in order to be sure that their blobs will be included. This is precisely the unreliability / wastefulness that EIP-1559 was set out to fix in the first place!

But price instability is not the only reason why L2s have trouble landing blobs. There's another more subtle and interesting reason -- MEV.

Blobs are large chunks of data, and as such they cost bandwidth to propagate. Since bandwidth is a finite resource, everything being equal a block with blobs will take longer to propagate than a block without blobs. This is an issue because a block builder only has a limited amount of time to propagate blocks before missing the attestation deadline, which would cause their block to be reorg-ed. Therefore, block builders play a timing game where they wait as long as possible so they can pack the most valuable (high MEV) transactions into their block, but not waiting so long that they miss the attestation deadline.

Therefore, blobs have a hidden cost -- because they make blocks larger, builders who include blobs must send out their blocks sooner, causing them to miss out on some MEV. As such, some builders refuse to include blobs EVEN WHEN there's no congestion in the blob market, so from the L2's perspective they just see their blob transactions being silently dropped, even though they appear to be paying adequate fees. To truly ensure blob inclusion, the L2 would have to include a high-enough priority fee to compensate for the lost MEV from the builder, but once again this value is hidden and hard to discover.

In short, there are at least two forces against L2s landing blobs reliably:

- The blob price being so low that it kills price discovery and causes bidding wars during congestion.

- Blobs cause builders to lose MEV, so they ignore blobs unless priority fees are high enough to compensate for the MEV.

So what can we do to make blobs more reliable? Good news is that things will already get better in Glamsterdam due to ePBS giving blobs more time to propagate, but more fixes are required if we want to completely fix these issues. Thankfully many researchers including @fradamt @potuz_eth @barnabemonnot are already thinking about this -- I may talk about some of their ideas in a future post!

I'm a Ethereum maxi, not a decentralization maxi. I believe the world needs only one fully decentralized / permissionless / trustless blockchain, and that is Ethereum. Every other chain -- whether they are stage 0/1/2, trusted, trustless, centralized, semi-centralized, etc. -- can and should be built on Ethereum.

In fact, the beauty of Ethereum is precisely that because it's itself maximally decentralized, other systems of various degrees of centralization can be built on top, and that they can interop with each other through Ethereum. As long as these systems provide real value to real people, they will strengthen the network effects of Ethereum and bring in more users and liquidity into the overall Ethereum ecosystem, which ultimately leads to a stronger L1 and stronger ETH.

Ethereum is the only credibly neutral, global settlement layer of the world. We are the hub. Let's celebrate the nodes that connect to us.