However, this approach has limitations, such as the inability to use Paymaster in conjunction with EOA under EIP-4337.
Paymaster - a smart contract that can pay gas fees in the native currency for users. It can have any payment logic: deducting ERC20 from the user, performing additional checks, or simply sponsoring any transactions without requiring anything in return.
This is problematic because implementing gasless transactions will require integrating a separate service, such as GSN (by the way, this EIP was developed based on its experience).
Another challenge is the complexity of developing such abstract accounts; you will need to choose one of the infrastructure solutions (e.g., Alchemy) and deal with their APIs to implement your wallet logic. Moreover, the architecture itself built on EIP-4337 is far from trivial.
EOA and Smart Account Transactions in zkSync
Now let's see the path a transaction takes in the zkSync solution. In this case, developers had the opportunity to implement native support for Abstract Account and Paymaster without the need for third-party services. Here, all accounts are smart contracts (even EOAs), and in zkSync, any accounts are "first-class citizens," meaning they are collected in a unified Mempool and processed equally.