From b5a69c62332595dc9d8e6d2bed54043cc50f846b Mon Sep 17 00:00:00 2001 From: lightclient <14004106+lightclient@users.noreply.github.com> Date: Thu, 18 Mar 2021 14:07:05 -0600 Subject: [PATCH] Automatically merged updates to draft EIP(s) 3074 (#3413) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft, Review, or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-3074.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-3074.md b/EIPS/eip-3074.md index 2da03e1f..3203391c 100644 --- a/EIPS/eip-3074.md +++ b/EIPS/eip-3074.md @@ -11,17 +11,17 @@ created: 2020-10-15 ## Simple Summary -Creates two new EVM instructions that authorize (via an ECDSA signature) a contract to act on behalf of an externally owned account. +Allow externally owned accounts (EOAs) to delegate control of their account to a contract. ## Abstract -This EIP introduces two EVM instructions `AUTH` and `AUTHCALL`. The first sets a context variable `authorized` based on an ECDSA signature. The second sends a call as the `authorized`. +This EIP introduces two EVM instructions `AUTH` and `AUTHCALL`. The first sets a context variable `authorized` based on an ECDSA signature. The second sends a call as the `authorized`. This essentially delegates control of the EOA to smart contract. ## Motivation Adding more functionlity to EOAs has been a long-standing feature request. The requests have spanned from implementing batching capabilities, allowing for gas sponsoring, expirations, scripting, and beyond. These changes often mean increased complexity and rigidity of the protocol. In some cases, it also means increased attack surfaces. -This EIP takes a different approach. Instead of enshrining these capabilities in the protocol as transaction validity requirements, it provides developers with a flexible framework for developing novel transaction schemes for EOAs. A good way to think about this is that this EIP allows any EOA to become a smart contract wallet *without* deploying a contract. +This EIP takes a different approach. Instead of enshrining these capabilities in the protocol as transaction validity requirements, it allows users to *delegate* control of their EOA to a contract. This gives developers a flexible framework for developing novel transaction schemes for EOAs. A good analogy for the benefit this EIP provides is that it's similar to allowing any EOA to become a smart contract wallet *without* deploying a contract. Although this EIP provides great benefit to individual users, the leading motivation for this EIP is "sponsored transactions". This is where the fee for a transaction is provided by a different account than the one that originates the call.