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.
AUTHCALL behaves almost identically to CALL *except* it sets CALLER (e.g. msg.sender) as the EOA address that was recovered via AUTH. This allows users to interact with Ethereum with no ether. In other words, their transaction can be "sponsored" by a relayer.
This scheme may sound familiar. In fact, this is nearly identical to how meta-txs work. The one (large) caveat is that meta-txs cannot set msg.sender at will. Therefore, contracts must explicitly support meta-txs. EIP-3074 aims to eradicate meta-txs, reducing contract complexity.
To dig into exactly how this works, let's understand what we're trying to build. We want a mechanism that allows an EOA with no ether to *trustlessly* send a tx. "Trustless" is the key word. Users should not grant relayers any special privileges that could be exploited.
EIP-3074 allows trustless systems to be built by carefully choosing what parameters are included in the signature from the EOA. Users sign over keccak(0x03 ++ invoker_address ++ commit_hash). 
The type byte is an EIP-2718 constant byte with a value of 0x03. This is used to avoid collisions with other signature schemes like EIP-2930 access list txs, EIP-1559 fee market txs, EIP-191 0x19 signed msgs, etc.
The invoker address binds the user's call to a specific contract. The signature is only valid for that contract, aka the invoker. This allows the user to choose an invoker that they trust -- just like choosing a smart contract wallet to trust assets with.
We expect only a small number of invokers to exist, because their users can be compromised if they're implemented incorrectly (note that invokers are opt-in). Developing a safe invoker will be expensive. It should be audited by multiple parties and statically proven to be sound.
This is not too different than the status quo though. Smart contract wallets should have thorough audits and proofs before they are entrusted with significant funds. Many large defi projects do the same.
The final signed parameter is commit_hash (or just commit from here on out). This is what provides invoker designers so much flexibility, and what allows for so many different schemes to be developed.
The commit binds the invoker to only perform certain actions and creates certain validity requirements to process a call. Users can trust the invoker will follow this procedure, because the code can be verified on-chain. This is the nice property of blockchains.
Let's look at a simple case. A user wants to send a call through an invoker. To avoid their call being relayed, they provide a nonce. They also provide other non-malleable values. Users hash these values to get the commit and use that commit in their signed message for AUTH.
The commit hash would be regenerated by the invoker using the values passed in. This way, if a sponsor changes a value, the invoker will compute a different commit hash than the EOA signed, causing AUTH to recover a junk address. That might look something like this:
Hopefully now you're convinced that the invoker is like a smart contract wallet that any EOA can use. Now let's look at how even more interesting schemes can be built using commit.
Generally, the rule of thumb is "one signature per action". This is a simplistic way to view things. A signature is created over the hash of a transaction, why not hash N transactions? It turns out this is possible with EIP-3074.
Once an account has been validated using AUTH, the invoker can make as many AUTHCALLs as that account as it likes. Because we trust the invoker to execute its code faithfully, this is fine. We can design schemes where commit is the hash of multiple calls.
In the scheme above, the invoker would take all the values (nonce1, nonce2, etc) and hash them together to generate the commit. It would call AUTH with that commit and the user's signature. AUTH would verify that the user did sign over those parameters.
The invoker would then loop through each call and verify the nonce and other parameters, then send the authenticated calldata to the authenticated address.
There are many more schemes that can be built on top of this. For example, suppose you add a new parameter "expiration". This parameter would be hashed into commit and during validation, the invoker would check if `expiration < block.number`. Now EOAs have expiring transactions!
EIP-3074 is a powerful primitive that will open the door to more seamless UX without additional trust assumptions. If you wish to read the EIP in full, you may find it here: eips.ethereum.org/EIPS/eip-3074
A prototype implementation in go-ethereum is being maintained here: github.com/quilt/go-ether…
We're working with several teams who are interested in using this mechanism. If this is something that you would find useful, let us know and let's work together! Feedback on the proposal is also welcome & greatly appreciated. Please direct feedback here: ethereum-magicians.org/t/eip-3074-spo…
Finally, if this type of work excites you, our team is hiring. We work heavily on medium to long term improvements of the Ethereum core protocol. Please send me a DM for more information.
s/relayed/replayed
• • •
Missing some Tweet in this thread? You can try to
force a refresh
