Account Abstraction Proposals Comparison

[gretzke]

Rationale

PIP-22 was proposed to add account abstraction capabilities to the Polygon PoS network. Discussions emerged within the community around safety and account abstraction alternatives. This dissection discusses the most prominent AA proposals and evaluates their advantages and disadvantages.

The overall goal is to enhance the user experience when interacting with the Polygon network through batching (e.g., approve + swap in one transaction), transaction sponsoring and more advanced account abstraction applications.

Overview

EIP-3074: AUTH & AUTHCALL

EIP-3074 introduces two new EVM instructions: AUTH and AUTHCALL. Using a ECDSA signatures, an EOA can delegate control over itself to a smart contract. The smart contract can then execute arbitrary code on behalf of the EOA.

EIP-5806: Delegate transaction type

EIP-5806 introduces a new transaction type that operates similarly to DELEGATECALL within a smart contract. This allows an EOA to delegatecall a smart contract which can execute arbitrary code on behalf of an EOA.

RIP-7560: Native Account Abstraction

RIP-7560 proposes to enshrine account abstraction while remaining backwards compatible with ERC-4337 and allowing existing smart contract wallets implementing this standard to upgrade to native account abstraction.

Pros

All three proposals enable UX improvements for users in one way or another such as batching capabilities or gas sponsoring.

EIP-5806, through the delegatecall transaction type allows a user to execute arbitrary code using a smart contract. This allows for batching capabilities for example where a smart contract could accept multiple transactions from an EOA and execute them back to back, like an approval transaction and a swap on a DEX, without the need for multiple transactions. Most functionalities that can be achieved by a smart contract (except for data storage and deployment of new smart contracts) can be achieved by EOAs too with EIP-5806.

EIP-3074 expands upon the functionality of EIP-5806 by supporting gas sponsoring, meaning under EIP-3074, an EOA no longer needs to hold the native gas token in order to pay for transactions. Instead of delegating control over itself to a smart contract using a transaction, this proposal uses a signature. This allows for far more advanced use cases such as signing over control of an EOA to a video game for the duration of 30 minutes while only allowing the executing smart contract to manage in game assets of the account. EIP-3074 is also built in a future-proof way to enable more advanced functionalities like alternative signature schemes, smart contract accounts and the ability to send native gas tokens in the future.

RIP-7560 builds on top of ERC-4337 so advanced account abstraction features like key rotation or social recovery are already available using ERC-4337 today. RIP-7560 acts as an intermediary step to full account abstraction and adds two main functionalities, gas sponsoring for EOAs and a decentralised mempool for account abstraction transactions.

Cons

For both, EIP-5806 and EIP-3074, allowing a smart contract to execute arbitrary code on behalf of the EOA comes with their own set of risks. Wallet drainers have become the primary choice of scammers and phishers because they rely on the user to blindly hand over assets by signing a transaction or message. Usually, a single signature is required to steal one specific asset. With arbitrary code execution, all assets held in a single account could be compromised with a single signature of a transaction or message.

When it comes to functionality, EIP-5806 does not allow for gas sponsoring, so EOAs still always need to own the native gas token in order to be able to pay for transactions. While RIP-7560 offers advanced functionality to EOAs like gas sponsoring and validity time ranges, it’s missing a lot of additional functionality like batching.

Mitigations

Mitigation of drainer risk is being tackled by wallets already today. Many wallets already alert users of phishing sites and simulate transactions in advance to display users the in and outflows of funds as a result of the transaction. Additionally wallets display reputation scores and associate risks with smart contracts a user wants to interact with. The capabilities of wallet applications will only get better over time, mitigating a lot of the risks for EIP-5806 and EIP-3074.

Blind signing is already prohibited by most wallets due to security concerns, so special support for EIP-3074 would be required. As detailed in the EIP choosing invoker contracts that execute transactions on behalf of the EOA should be treated like choosing smart contract wallet implementations. They should be thoroughly reviewed, tested and accepted by the community. Wallet applications can leverage their existing infrastructure to warn or block users from interacting with untrusted smart contracts.

As for the limited functionality of account abstraction transactions in RIP-7560, EOAs can migrate their assets to an ERC-4337 wallet that enables the full account abstraction functionality. However, this is something that can already be done today and does not require RIP-7560.

Implementation challenges, maintenance & DevX

Each account abstraction proposal comes with their own set of changes to the EVM that need to be implemented, maintained as well as might affect developers building non AA use cases on top of Polygon. These changes can also affect infrastructure providers like block explorers and wallet applications.

Client modifications

EIP-3074 only requires changes to the EVM execution environment to handle the new opcodes AUTH and AUTHCALL.

EIP-5806 requires changes to the client to support the new delegatecall transaction type. An alternative mempool is not required most likely, due to the similarity of delegatecall transactions to type 2 transactions.

RIP-7560 requires the biggest changes to the client by far. A new decentralised mempool is required for the introduced AA_TX_TYPE transaction type. Additionally, RPC endpoints need to be modified to support the new transaction type and new RPC endpoints need to be added.

Devtooling and Wallet interaction.

EIP-3074 should not affect the majority of developers, as the standard Solidity compiler should still work for all applications. For developers building on top of EIP-3074 a Solidity version needs to be patched that implements both new opcodes. With every new release of Solidity it is recommended to release new patched versions supporting EIP-3074. When it comes to testing smart contracts, the local nodes used by Hardhat and Foundry do not support EIP-3074 yet. A patched version could be offered to developers as well or efforts could be made to work with Foundry and the Nomic Foundation to enable this functionality. When it comes to wallet interactions, ECDSA signatures are already supported by all wallets. As previously mentioned additional safeguards should be added to protect users.

EIP-5806 and RIP-7560 introduce new transaction types that are not supported by common libraries to interact with EVM networks such as web3.js and ethers.js. To support the new transaction types, developers would need to call RPC methods manually to submit transactions until the libraries support the implemented proposal natively.

Infrastructure

Infrastructure like block explorers and indexers would most likely not support the proposals out of the box and would need custom implementations to support them.

Transactions utilising EIP-3074 should not really affect existing infrastructure, as there are no major changes to the execution of transactions. Emitted events and calls which are mainly used to index data on chain would remain the same. Block explorers would need to add support for patched Solidity versions in order to be able to verify smart contracts using the new introduced opcodes.

The new transaction types introduces in EIP-5086 and RIP-7560 would require custom implementations by block explorers in order to display these transactions properly to the user.

Potential future conflicts with Ethereum

The addition of new transaction types and opcodes could conflict with future EIPs implemented on Ethereum. If there is an overlap, this could create issues with infrastructure providers like wallets, that need to implement special edge cases for the Polygon network. This section analyses changes made to the execution environment of each proposal, their potential conflicts and mitigation plans.

If Polygon implements EIP-3074 there is a risk that Ethereum implements another EIP before EIP-3074 that uses the same opcodes as AUTH (0xf6) and AUTHCALL (0xf7). This would mean that compiling a smart contract targeted at Ethereum would behave differently on Polygon. Fortunately, new opcodes are rarely introduced in EIPs, only two EIPs (2997 & 5478) use the same opcode slot and both are stagnant, so the risk of this happening is low.

There are multiple EIPs proposing new transaction types with the ID ≥ 0x04. If Polygon were to implement EIP-5806 with transaction type 4 for example, but RIP-7560 would be accepted first on Ethereum, this would likely break many different integrations for Polygon. Similarly, if Polygon tried to avoid such a scenario by assigning a different transaction type identifier but EIP-5806 would be implemented on Ethereum using transaction type 4, the same transaction type would use two different identifiers on different networks likely causing similar problems.

Rollback the upgrade

Regardless of what proposal will be implemented on Polygon, a scenario where a different proposal becomes the standard across the EVM ecosystems might become reality. In such a scenario the selected proposal might see little to no usage on Polygon and add overhead over time. In this case it might make sense to remove the support for the proposal again to align with the wider Ethereum ecosystem and reduce complexity for future upgrades. This section explores potential issues that could arise from such a rollback of functionality.

Should EIP-3074 become obsolete, the implementation of AUTH and AUTHCALL could likely be deleted from the EVM implementation without a larger impact. Smart contracts using EIP-3074 would no longer work and revert, but because EOAs delegate execution to these smart contracts only, no funds would be at risk.

If EIP-5806 functionality is removed, smart contracts used for transaction delegation would still be functional and could be called normally. Depending on the implementation of the contracts, regular transactions to these contracts might still succeed but result in stuck funds, because the call is no longer delegated.

Due to the complexity of RIP-7560 as well as the ability of smart contracts to send AA_TX_TYPE transactions, it is likely not feasible to roll back the upgrade and might result in stuck funds.

Functional evaluation

In the quest to seamlessly integrate the next billion users into the crypto ecosystem, the interface and interaction layer must evolve to become so intuitive and user-friendly that users may not even realise they are using a wallet. While EIP-5806 and RIP-7560 offer significant improvements for current users, they seem to primarily cater to this existing audience, improving their experiences rather than revolutionising access for new entrants. EIP-5806’s lack of gas sponsoring capabilities requires applications to continuously ensure their users’ wallets are sufficiently funded with gas tokens. For RIP-7560 to unleash its full capabilities, it requires applications to deploy ERC-4337 smart contract wallets on behalf of their users to leverage the advanced features offered by RIP-7560.

EIP-3074 stands out by enabling straightforward transaction sponsorship, effectively removing a significant barrier for end-users. It provides flexibility in execution, which is important for the development of non-custodial applications across various domains, such as investment platforms or gaming, that might employ MPC wallets integrated with social logins. In such scenarios, the conventional concerns regarding blind signing diminish, as the application assumes complete oversight of the user’s assets during their active session.

In summary, while EIP-5806 and RIP-7560 enhance the experience for current blockchain users by addressing specific limitations, EIP-3074 presents a more holistic solution aimed at broadening crypto’s appeal and accessibility.

[ankurdubey]

I would say another option worth considering is the inclusion of the leaner EIP7377: Migration Transaction which allows deploying code to an existing EOA.

EIP7377 solves the crucial problem of fund migration faced today by all Smart Accounts. EIP7377 coupled with the existing 4337 infrastructure can take things a long way from a UX perspective.

[alexf]

Hello @gretzke and thank you for a comprehensive overview of the current Account Abstraction EIPs landscape.

While I agree with most of it, there are some missing pieces and misconceptions that I would like to try to address here.

1. EIPs that add features to EOA accounts are not directly comparable to Native Account Abstraction design proposals.

This is a comparison between green apples, red apples, and oranges. It makes sense to compare EIP-3074 and EIP-5806, while RIP-7560 probably belongs in a different category, and if RIP-7560 is treated as a way to add some features to an EOA while ignoring its effects on Smart Contract Accounts, then it is indeed an inferior proposal. However, improving EOAs is not what RIP-7560 aims to do.

An analogy for such comparison can be a person in 2007 looking to update his ancient Nokia 2120 phone. He’s looking at a Motorola StarTAC, a Razr, and an iPhone, and complains that making a phone call is harder on the iPhone because there is no physical keyboard and you need to launch an app for dialing. All the while ignoring the capabilities of smartphones and thinking about it as a tool to make a phone call. The iPhone is inferior to the other options when compared in that category alone.

2. Next billion users writing down seed phrases? God, I hope not.

This comparison starts from the base assumption that the next billion users will use EOAs, while Account Abstraction remains a niche used by existing sophisticated users. I’d like to challenge that assumption. The next billion users are not going to use an EOA, even if it is given some additional features like batching and gas abstraction. These features address the needs of existing users who are already technical enough to use an EOA, and would just like some flexibility. Account Abstraction is the only way we will be able to accommodate the needs of the next billion users. With EIP-3074 we can’t even accommodate modest requirements like recovering the account when the key is compromised. If someone steals your bank password, not all is lost. As long as the same isn’t true on the blockchain, the next billion users are not coming.

Your conclusion is that “RIP-7560 offers significant improvements for current users, it seems to primarily cater to this existing audience”. I would say it’s exactly the other way around. EIP-3074 and EIP-5806 were written with current users in mind, whereas RIP-7560 focuses on the next billion users.

Our strong belief has always been that private key creation, backing up seed phrases, and inability to perform any meaningful key rotation is the main obstacle to the new users in the crypto ecosystem. It is also the process where the threat of complete loss of funds is the highest.

ERC-3074 does not seem to address that in any way. Users’ accounts are still ultimately controlled by a private key and nothing can be done about it. Arguably even worse, reusable authorisation may allow a newbie user to issue an “authorisation”, send it to a dapp or relay service, lose the private key, and not even be aware of that until the authorisation expires months from now and the dapp stops working.

The main objective of the RIP-7560 is to shift the narrative towards treating Smart Contract Wallets as first-class citizens. Smart Contact Wallets should become the default type of account, instead of an opt-in option for advanced users, since most users don’t know what they need initially when they are only starting. We must end up with a user onboarding experience and continued security that is better than what we had since BIP-39 in 2013.

3. RIP-7560 is supposed to be “Native Account Abstraction” endgame, not an intermediary step

One of the biggest differences between RIP-7560 and other current “Account Abstraction” proposals is that instead of only adding more facelift features to ECDSA private key controlled EOAs, is that it enables replacing the transaction validity function with running a certain EVM code on-chain.

Chains implementing RIP-7560 can reasonably abandon EOAs and embrace full Native Account Abstraction, which includes:

• Execution abstraction - batching, delegation, conditional execution, atomicity etc.
• Gas abstraction - arbitrary logic, enabling gas sponsoring, pay gas with ERC-20, etc.
• Validation abstraction - any signature scheme, authorization logic, recovery, key rotation, etc.
• Decentralized and permissionless mempool of AA transactions. No gas relay infrastructure required.
• Computationally feasible and profitable block building strategy.

Of course, ERC-4337 is already able to achieve most of these features without a protocol change.

Its usefulness and popularity, however, is a good argument to embrace this approach natively, gaining EOA Gas Abstraction, efficiency and user confidence by doing so. ERC-4337 gained >3M accounts and >13M UserOps since launch - many of them from new users who wouldn’t be using the blockchain otherwise. We need to make it more efficient and bring more of them.

4. EIP-3074 “invoker” contracts pose a dilemma between a permissioned system and users safety

It is important to balance the utility of a proposed feature with its effects on the safety and its “permissionlessness“. Given that the authorized invoker basically gets an unrestricted control of the account’s assets, the harm malicious invokers can do is hard to overstate. And while EIP-3074 supporters often compare selecting an “invoker” to selecting a Smart Contract Account implementation, in reality it feels more like handing all your crypto over to a random contract every time you need to make an AUTHCALL transaction. Whether it is a simple “approve & transfer” batch or a Gas Sponsored transaction.

Given AUTHCALL does not increment user’s nonce, it is possible for an EOAEOA address to be simultaneously authorized to an unlimited number of “invokers”, increasing a potential attackable code surface. Note how all these authorization signatures will be reusable and public once they are used on-chain. Additionally, revoking an authorization requires users to hold ether and create a paid transaction, which is also an obstacle for users trying to protect themselves.

With that in mind, wallet developers will be really cautious about allowing users to sign authorizations. This is likely to end up with a whitelist of a few known invokers de-facto controlled by a single dominant Ethereum wallet, whoever that is.

With RIP-7560, Account implementation is in fact selected only once. It may be upgradeable but this is a separate administrator-level operation. And Paymasters are completely isolated from account funds, so using Gas Abstraction does not require full trust in the “invoker” contract.

5. Gas sponsoring is harder than it looks. Specifically, ERC-3074 suffers from the same issues that OpenGSN had since its conception.

As the team behind the OpenGSN project, we have dedicated many years trying to achieve decentralized Gas Abstraction on Ethereum. In fact, the main building block of meta-transactions, the ERC-2771 Forwarder-Recipient scheme, can be seen as the EIP-3074 “AUTHCALL” equivalent without the protocol change.

However, the ability to separate signature validation from gas payment is not by itself a Gas Abstraction solution that scales well beyond centralized gas relay services.

Consider the following popular use-case for Gas Abstraction: paying gas fees with an ERC-20 token.

In Solidity pseudocode, the invoker may look something like this:

contract TokenAuthInvoker {

    ERC20 token;

    function invokeTarget(address target, address authorizedSender, bytes calldata, bytes authdata){

        AUTH(sender, authdata);

        // AUTHCALL token precharge
        token.transfer{from: authorizedSender}(address(this), preCharge);

        uint256 gasBefore = gasleft();

        // AUTHCALL target - actual transaction execution
        target.call{from: authorizedSender}(calldata);

        uint256 gasUsed = gasBefore - gasleft();

        // compensate gas relay
        token.transfer(msg.sender, preCharge - refund);

        // refund user
        token.transfer(authorizedSender, refund);
    }
}

The issue here is that the wrapper invokeTarget EOA transaction is valid (as in, will be included in a block and sender will be charged for gas) regardless of authorizedSender’s token balance. However, if the balance is below preCharge the entire transaction reverts. This means that a gas relay may be grieved, either accidentally or intentionally by a malicious sender, or front-run by a competing relay server, or even the block builder.

Notably, “accidental front running” of mutually exclusive transactions will be a common case with enough adoption. It’s not an edge case for almost all relayers to revert except one.

While there are ways to mitigate this risk, we believe that the only reliable way to protect the relay server at a scale chains like Polygon or Ethereum require is to run the relay server in close cooperation with the block builder.

6. DoS on EIP-3074 block builders

If our risk assessment is correct, block builders will perform the relaying for EIP-3074 transactions. This theoretically guarantees that relays will be protected from front-running.

However, the task of filling a block with profitable EIP-3074-wrapped transactions becomes a bottleneck itself. Consider an attacker spamming the relay with transactions that invalidate each other. The block builder under attack will not be able to find profitable EIP-3074 transactions to relay in a reasonable time frame.

Of course, the relays may start white-listing the known trusted “invokers” that have no way to revert without paying for gas. That doesn’t seem feasible for most use-cases, and such invokers will need to whitelist trusted relay servers operators as well to prevent grieving. However, this will result in a centralized and permissioned ecosystem.

By the way, this is related to the reason EIP-3074 does not allow authorized accounts to transfer Ether. This restriction prevents technically invalid transactions from occurring in a block, but does nothing to prevent economically loss-making transactions.

It is my honest opinion that EIP-3074 does not reduce complexity as much as it hides complexity by sidestepping the problems and moving it “out of scope” of the EIP. No solution offered for Gas Abstraction means more added complexity for solving it later.

7. EOAs using RIP-7560 transactions could support batching with Gas Abstraction, and more

We made a point of making RIP-7560 modular and extensible. There is a common behaviour inherent to all RIP-7560 transactions, and there is a way to extend it.

This is done with “transaction subtypes” - RIP-7560 transactions whose differences are not significant enough to require a separate mempool, but have some specific “superpowers”. Each “subtype” RIP can be adopted by a chain individually.

Signature aggregation, EOA delegations and transaction batching have been listed among potential future RIPs. The difference from the other proposals is that it is done in a future compatible way, as part of moving the ecosystem to full AA, rather than sporadically add features to EOA.

8. We expect ERC-4337 tooling to work with RIP-7560

While adding a new transaction type is indeed a complex task for the dev tooling and infrastructure, there is a notable amount of ERC-4337 compatible tools. These will almost certainly be ready to use RIP-7560 on day one, closing the gap until generic tools like Web3.js and Ethers.js catch up.

---

In conclusion, it certainly seems like a problem as complex and multifaceted as Account Abstraction should not be solved by small incremental tweaks to the protocol. Instead, we should define the end goals and compare the ways to fully achieve them. When making incremental changes along the way, we should evaluate whether they are directionally aligned or misaligned with it.

[gretzke]

We did not consider EIP 7377 because it is stagnant

[gretzke]

Let me go into your points one by one:

@alexf

1. EIPs that add features to EOA accounts are not directly comparable to Native Account Abstraction design proposals.

The main goal we are trying to achieve is add batching and gas sponsoring capabilities to EOAs with this upgrade. The three compared proposals were suggestions from the community so I compared them, even though I agree that you can’t really compare RIP-7560 to the others. So looking at that goal (improving capabilities of EOAs) I mainly also only looked into the enhancement to EOAs that RIP-7560 includes. Additionally, EIP 3074 and RIP 7560 are not mutually exclusive. Just because we pick one, doesn’t mean we are not going to implement another proposal in the future, I see room for both, because they also serve entirely different purposes. But like I mentioned, the first step is about enhancing EOA functionality only.

@alexf

2. Next billion users writing down seed phrases? God, I hope not.

We don’t only want to improve the UX of existing end users but also infrastructure providers who were very vocal, especially about the requirement for batching capabilities. These providers could already chose to deploy a ERC-4337 wallet but they are looking for enhanced functionalities for EOAs. Additionally, gas abstraction through EIP-3074 already massively aids account abstraction when using an MPC wallet for example. Here the user also does not need to handle private keys, but uses social logins instead to authenticate and receives an application specific wallet from an MPC provider. This already provides the user with a web2 like experience and just further enabling more functionality for these users. ERC-4337 can already be used today without RIP-7560, so we weren’t really looking at this type of account abstraction, as it already exists.

@alexf

3. RIP-7560 is supposed to be “Native Account Abstraction” endgame, not an intermediary step

The intermediary step part specifically refers to the part in the proposal that explains why EOAs can send the new AA_TX_TYPE (See here). Basically saying that allowing to send these transactions from an EOA is an intermediary step until there is a path for EOAs to upgrade to smart contract wallets.

@alexf

4. EIP-3074 “invoker” contracts pose a dilemma between a permissioned system and users safety

We are committed to work with the team behind 3074 to see if we can add further security features such as an expiration to a signature (e.g., the ability to set a deadline and also ensure in the AUTH opcode that the deadline of a submitted signature cannot be more than a week in advance). This would realistically limit how longs signatures could be used for. There are other ideas as well that we would like to consider.

@alexf

5. Gas sponsoring is harder than it looks. Specifically, ERC-3074 suffers from the same issues that OpenGSN had since its conception.

Gas sponsoring does not have to be decentralised to be useful. A game for example could chose to sponsor all transactions of their users in a convenient and permissionless way, or a platform like reddit could use gas sponsoring for a much more streamlined operator experience. Oftentimes platforms need to fund the wallets of their users with gas tokens in order for them to be able to transact, a central EOA controlled by the platform that can pay on behalf of all users is a lot more convenient.

@alexf

6. DoS on EIP-3074 block builders

I’ll have to look deeper into this issue

@alexf

7. EOAs using RIP-7560 transactions could support batching with Gas Abstraction, and more

I have only considered RIP-7560 in it’s current form and the current improvements offered to EOAs. Like I mentioned before, integrating another proposal does not mean that RIP-7560 or other RIPs will not be considered later.

@alexf

8. We expect ERC-4337 tooling to work with RIP-7560

My point here was that if a dApp would want to use 3074 signatures they could do that today using Ethers.js and Web3.js. To support the AA_TX_TYPE devs would need to use separate RIP-7560 compatible tools which is more of an entry barrier, while 3074 works out of the box.

[lightclient]

@alexf

Its [ERC-4337] usefulness and popularity, however, is a good argument to embrace this approach natively, gaining EOA Gas Abstraction, efficiency and user confidence by doing so

These are the wrong reasons to enshrine something into the protocol. ERC-20 tokens are “useful” and “popular”, but not enshrined. So are AMMs.

• EOA Gas Abstraction – this is possible with EIP-3074, which is simpler than RIP-7560.
• Efficiency – this is constantly thrown around, but what is the efficiency gain? I’m interested in improving EVM semantics and gas schedule to alleviate costs to ERC-4337, but enshrining something obviate an inefficient design is not an acceptable reason.
• User confidence – same argument can be made for any popular application. It’s not a reason to encumber the protocol.

RIP-7560 needs stronger motivation before it should be considered for enshrinement. In the meantime, let’s not compare apples to oranges. EIP-3074 can drastically improve the UX for users today and catalyze better wallet interface standards for ERC-4337 wallets and the next billion users.

@alexf

It is my honest opinion that EIP-3074 does not reduce complexity as much as it hides complexity by sidestepping the problems and moving it “out of scope” of the EIP. No solution offered for Gas Abstraction means more added complexity for solving it later.

Core changes should be minimal and facilitate development at other levels. Complexity at each layer should be minimized and pushed to the next. This creates a system which is resilient and a framework which is flexible to develop for.

This is the entire premise of Ethereum. We could be continually adding new, bespoke applications to the protocol but instead we provide a virtual machine and allow developers to design the world as they see fit.

@gretzke

We did not consider EIP 7377 because it is stagnant

EIP-7377 has been moved back to draft: https://github.com/ethereum/EIPs/pull/8319

[dror]

@gretzke

Gas sponsoring does not have to be decentralised to be useful.

1. That’s true, but with with 3074, gas sponsoring is not only centralized, but also extremely insecure:
   The user has to sign a dApp-specific invoker, essentially fully trust the application with its entire account, just to get free gas.
2. Saying “X doesn’t have to be decentralized” is something we don’t want to enshrine at the core of a [decentralized] network. We want a strong decentralized core, and centralized use-cases will surely emerge. Decentralization is complex, and it is not something you can add as an afterthought into a protocol such as 3074.
   Specifically, we understand the separation of validation and execution (as in erc-4337 and eip-7560) is critical for decentralized protocol.

[tqs]

Like the points made in mitigations, If I may expand on it as an end user.

When giving over control to a third party (be it a game, another contract, chain etc):

1. Is there a way to cap out maximum cumulative value transacted via a end user smart account (be it any of the above xIPs)? In a real world scenario that could already solve the majority, think Pareto, of the issues?

• This could be max transacted value per session, per account, per contract transacting with, other factors and perhaps combinations thereof

2. Would it be possible to discourage if not penalize malicious contracts/apps to be deployed?

• A malicious contract would want to maximize return on per contract deployed. Would it be possible to enforce a condition where any contract that accrues more than a certain total value should perform

  This should be especially true for:
  a. New apps/contracts < X days - discouraging malicious upgrades, increasing pay back period for those playing long cons
  b. For apps without a DAO

• Privacy driven ID solutions should be taken advantage of - seems like institutions are already using the tech

3. Would it be possible to leverage arguments such as ‘commit’ that seem to allow for additional conditions?

4. Value can be an assets price, NFT floor price.

5. Value denominated in USD/ETH/other token
   a. Gets tricky when regional currencies start gaining traction
   b. Can be dealt with with like it is today in web2 apps, perhaps easier to do in web3?

Phishing and other attacks exist in web2 today. I’d assume it would be difficult to eliminate them entirely in web3, at the least in the near future as well.

Agree with @alexf as well, would not prefer to have to manage seed phrases. If we can find a way, eventually if not immediately to abstract away/get rid of them, none the better. This would be the ideal.

[lightclient]

@dror

That’s true, but with with 3074, gas sponsoring is not only centralized, but also extremely insecure:
The user has to sign a dApp-specific invoker, essentially fully trust the application with its entire account, just to get free gas.

Stop spreading incorrect information about EIP-3074. We have discussed this multiple times before.

EIP-3074 is an authorization mechanism which allows EOAs to initiate calls within a transaction. That is it. Gas sponsoring can be built using this tool.

There is absolutely no reason it cannot be done in a decentralized manner.

[tqs]

@tqs

A malicious contract would want to maximize return on per contract deployed. Would it be possible to enforce a condition where any contract that accrues more than a certain total value should perform

Missed some things here:

A malicious contract would want to maximize return on per contract deployed. Would it be possible to enforce a condition where any contract that accrues more than a certain total value should perform:

**KYC, zk driven respecting privacy if possible, dox themselves before claiming profits (whatever form this may tak), any other action that would increase risk to the malicious actors

[gretzke]

Enforcing maximum value transfers is impossible to enforce on chain so your proposed solution would not be feasible

[probablynoam]

Would this be the same proposal that in turn gets adopted by Polygon zkEVM and Polygon CDK? There’s an argument to be made that certain solutions might be better for certain environments. I think there’s room to streamline RIP-7560 to be more rollup-centric in which case it might make sense for zkEVM and CDK but not PoS. I do think it also solves for and is not mutually exclusive from 3074 (good writeup on that here: https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy). In general zkSync has a 7560-esque model that is working well for native smart accounts in that ecosystem (for feedback on that model I’m happy to facilitate intro’s to team building on native AA within an EVM).

An axis to consider here is timelines too. There’s a good chance Polygon will be able to piggyback off of the work done by RollCall for L2 as well as the broader EIP process. I don’t think any of these solutions will have sufficiently mature tooling and infrastructure out of the box right now.

[alexf]

@gretzke

Enforcing maximum value transfers is impossible to enforce on chain so your proposed solution would not be feasible

What about allowing AUTH signature to specify a limited set of authorised destination addresses, if the user wants to, does this make some sense from a security standpoint? And for the wallets like MetaMask, to be able to present the user with a description of what the Invoker can interact with, instead of choosing between a ban on 3rd party Invokers or a blind signing with a scary warning message?

For example, a blockchain game can request an AUTH for its gas sponsoring Invoker that only allows interactions with the game’s own contracts and therefore signing this AUTH is basically completely safe for the user’s non-game assets.

My preference would be to make the targets list a requirement, but technically an empty list may be treated as a wildcard, retaining the current EIP-3074 capabilities.
And this can be combined with the signature expiration that you’ve suggested:

@gretzke

We are committed to work with the team behind 3074 to see if we can add further security features such as an expiration to a signature (e.g., the ability to set a deadline and also ensure in the AUTH opcode that the deadline of a submitted signature cannot be more than a week in advance). This would realistically limit how longs signatures could be used for. There are other ideas as well that we would like to consider.

It is surprising how EIP-3074 ended up with such an all-powerful AUTH, see:

Removal of targets from AUTH specification

There is this statement in the EIP-3074:

Earlier iterations of this EIP included mechanisms for replay protection, and also signed over value, gas, and other arguments to AUTHCALL . After further investigation, we revised this EIP to its current state: explicitly delegate these responsibilities to the invoker contract. A user will specifically interact with an invoker they trust.

However there is little what the investigation was. A reference to that decision in the discussion that I could find says:

This has a certain elegance to it, and since you already have to trust the invoker for replay protection, why not trust it for everything?
…
The downside is that a broken/vulnerable/malicious invoker can have nearly total control over an EOA, and writing a safe invoker will take a significant amount of care.

Link here

And this post:

@adietrichs

The whole point of signing over the invoker address is that the sponsee has to trust the logic of the particular invoker contract. Given that this is already a requirement, we might as well make the most out of it and get as much flexibility out of it as possible.

Link here

It was also debated for a long time in this parallel thread:
https://ethereum-magicians.org/t/a-case-for-a-simpler-alternative-to-eip-3074/6493

[gretzke]

This proposal is for the PoS network only at the moment. But you mention zk rollups which is a great point. As the PoS network will transition to become a Validium using the Zero prover, we need to make sure that whatever proposal is implemented also can be proven by the zk prover. 3074 is a lot easier to prove as only two additional opcodes need to be supported.

[gretzke]

I like the target list approach, I will add it to our considerations. Thanks for the input!

[probablynoam]

I will also say that there’s two axes of “easy” to consider. One is from the client team in terms of implementation. The other is from developers in terms of adoption. There is a ton of 4337 infrastructure that easily transfers over to 7560 that makes it significantly easier for developers to adopt these primitives. See https://github.com/4337Mafia/awesome-account-abstraction for a partial list. I would highly recommend soliciting more Polygon developer feedback on this proposal too.

Is this proposal to be sequenced before the PoS migration to the zkEVM validium? Both proposals add more overhead in what is already a complicated undertaking.

[gretzke]

The AA upgrade is planned before the transition to the Validium zkEVM. We have internal confirmation that 3074 can be proven, however 7560 is more complicated to prove due to an additional transaction type and other factors. So we don’t have confirmation here when this would even be possible. Worst case scenario would be implementing a proposal that would severely delay the zkEVM transition because of issues with proving the proposed AA solution. So developer adoption is irrelevant if there isn’t even the possibility to implement the underlying proposal in the first place.

[probablynoam]

Curious the rationale for this sequencing? This might be a bit tangential, but would Polygon Labs consider the following?

• Reducing scope for the PoS to zkEVM transition.
• Designing AA for zkEVM natively instead of PoS

[gretzke]

The zkEVM transition will take a bit of time to complete, so we are looking at EVM+ before transitioning.