In the last month, users spent $23,830,482 on ERC-20 approvals. EIP-3074 would reduce that number by at least 30%, saving users millions while freeing up block space (thread).
Anyone whose nonce is greater than ten has likely experienced the approve+transfer flow that defi applications use to interact with ERC-20 tokens. The approve method is a relic of the original ERC-20 design.
There have been many attempts to alleviate the burden of token approvals, but none have succeeded. We believe EIP-3074 will resolve the issue because it addresses the two problems that have beleaguered other approaches.
Issue #1: there is a long tail of ERC-20 tokens that can't/won't upgrade to a new token standards. EIP-3074 allows msg.sender to be set artificially based on a signature, so it is perfectly compatible with old tokens.
Issue #2: previous attempts at native support were simply too complicated to integrate into the protocol. EIP-3074 is *very* simple to implement in clients (we've already done it in geth & openethereum).
How does EIP-3074 save users gas? Today, an ERC-20 approval typically costs around 43,000 gas and a transfer costs 37,000 gas. Of course, if you're sending a transfer you'd just do that without the approval, but let's pretend it's a placeholder for something more interesting.
All in, that's 80,000 gas for the operation. However, only 38,000 gas is doing relevant computation. Over half is the "intrinsic cost", equaling 21,000 per tx. If you could do approve+transfer in the same tx, you'd only have to pay the 21,000 once!
This is exactly what EIP-3074 allows users to do. Suppose there is a contract written specifically to facilitate approve+call interactions. It would take in an ERC-20 token address, the amount, the subsequent call, a signature, and it would cost around 7,000 gas to execute.
Adding it up:
21,000 intrinsic cost
7,000 EIP-3074 contract
1,200 EIP-3074 extra calldata
38,000 approve+transfer
---------------------------
67,200 gas
Compared to 80k above, we saved 16% overall & 37% on the approval operation (i.e. disregarding the intrinsic cost).
Scaling up, what if we approve+transfer ten different tokens? Normally that would be 800,000 gas, but with EIP-3074 it's:
How can this be? Well, ten approve+transfers requires 20 txs. That's 20*21,000 = 420,000 gas just for the intrinsic cost. Because EIP-3074 *batches* operations together into a single tx, the 21,000 cost is only paid once.
Although these numbers are rough estimates, and there is a lot of nuance in EIP-3074, the potential gas savings for users is significant.
Only exploring the gas savings EIP-3074 provides doesn't do it justice though. It will drastically simply UX for users and allow complex interactions that were not feasible before.
Todo list:
i) retweet thread head for awareness
ii) join community call 4/26 @ 16:00 utc
iii) review the EIP text & if you support it, signal your support publicly
iv) dm me!
How much does the storage refund need to decrease before you start using a different value to represent 0?
The London hard fork in July will almost certainly modify the behavior of refunds. There have been several iterations, but the latest is EIP-3529: Reduction in refunds.
I recommend reading the EIP as it is very thorough and explains the past proposals, however the main case we care about for this thread is setting a nonzero storage element to zero and the refund that incurs.
Ethereum wallets may be getting a significant upgrade soon. With the proposed change, EOAs will immediately be able to send batch txs, expiring txs, unordered txs, and more. (thread)
My colleagues, @_SamWilsn_ and @adietrichs, and I have been working on improving the UX of interacting with Ethereum. After many iterations, we've come up with EIP-3074: AUTH and AUTHCALL opcodes.
To use these opcodes, an EOA signs a message off-chain, provides the message to a relayer, the relayer passes the signature and calldata to a contract on-chain (called an invoker), the contract verifies the signature using AUTH, and then relays the EOA's call with AUTHCALL.
so far, the most interesting IMO (as a non-dapp dev) are EIP-2535 Diamond Standard (@mudgen), EIP-3009 Transfer with Authorization (@petejkim), EIP-3000 Optimistic enactment of governance (@izqui9), and EIP-3156 Flash Loans (@acuestacanada)
but i feel like there are interesting conversations happening in some lower number EIPs that I'm just not following. any standards to improve the readability of tx data when signing (or signing standards in general)?
Yesterday's chain split will be cemented in Ethereum's history as an inadvertent hard fork. Let's look at exactly what the vulnerability was & how this transaction exploited it (thread): etherscan.io/tx/0x57f7f9ec3…
I also want to preface that this is completely an outsiders account of the incident & therefore everything posted here is only to the best of my knowledge. I look forward to the go-ethereum team's full disclosure of the vulnerability!
On 2019-11-07, Geth v1.9.7 was released. It contained a few fixes and optimization, including PR #20177 titled "core/evm: avoid copying memory for input in calls".
Geth's transaction pool (aka mempool) can be boiled down to a few key data structures and processes. Transactions are the main building block. They are stored on the heap while references to them populate four objects: "all", "priced", "queue", and "pending".
The "all" object is a mapping of the transaction's hash to the actual transaction object on the heap. It is the canonical source of transactions in the mempool and is used to build (and rebuild) the "priced" object.
The "priced" object is a heap (data structure) that orders the transactions in the mempool highest to lowest priced. When the mempool is completely saturated, "priced" is asked to find the N cheapest transactions so that they can be fully evicted from the mempool.