On-chain experience
User Experience (UX) is the process of creating products that provide meaningful and relevant experiences to users. This involves the design of the entire process of acquiring and integrating the product, including aspects of branding, design, usability, and function. This issue is not only related to the DeFi or Crypto space but has been a problem for several years.
1/ Wallet Management:
Wallet Management has been and still is a huge problem for the on-chain experience. Try giving a Rabby or a Metamask wallet to your mom and see what happens. Even though many people are trying to find solutions, whether with EOAs, Smart Wallets or auth provider, a lot of improvements are still possible.
2/ Fragmented market:
As a newcomer in the DeFi space, you immediately understand that different blockchains are as congested as an Indian street during peak traffic. Some aggregators and solutions take this issue seriously and offer cross-chain management, such as the Elastic chain of ZKsync or Layer0.
3/ Complex usability:
This issue has always affected newcomers to the DeFi/Crypto space and remains unresolved, including challenges like multiple signatures/approvals and general UX.
4/ Security Concerns:
DeFi and blockchains open the door to hacks or malicious actors. This work is a long-term journey where audit firms and third-party solutions have tried and are continuing to solve these issues.
Finally, these problems couldn’t be resolved at once. Zyfi chose to focus on the last one, gas management, which is a significant pain point in achieving an agreeable on-chain experience.
How many of you have found yourselves unable to withdraw liquidity from a pool, execute a trade, or make a simple swap due to gas fees? How many have had to rely on a CEX to get more ETH?
This problem must not continue, and it’s precisely what we will tackle in this article.
Account Abstraction
Account abstraction is a proposal to increase flexibility in the management and behavior of Ethereum accounts. This revolution didn’t start yesterday, and multiple (non-exclusive) approaches have been developed to achieve the goal of account abstraction (including, but not limited to, EIP-3074, ERC-4337, RIP-7560, etc.).
Here is a brief history of Account Abstraction: These discussions have been ongoing for a long time and are not yet finished due to the ongoing need to offer the best on-chain experience. (AA mafia telegram group is a great place to follow discussions on this topic.
One of the biggest improvements so far has been the release of EIP-4337 in 2021, which completely avoids the need for consensus-layer protocol changes. Instead, it relies on a separate mempool of UserOperation objects and miners either running custom code or connecting to a bundle marketplace. This marks a huge step in adoption with the proposition to address specific use cases such as:
- Privacy-preserving applications
- Atomic multi-operations (similar goal to [EIP-3074])
- Paying transaction fees with ERC-20 tokens, allowing developers to pay fees for their users, and [EIP-3074]-like sponsored transaction use cases more generally
- Supporting aggregated signatures (e.g., BLS), allowing for the use of smart contracts instead of EOAs.
However, smart accounts still face friction in their usage, such as:
- Requiring gas to deploy and usage of relayers
- Difficulty in migration and the need to transfer funds
- Lack of straightforward interoperability with other dApps.
As a result, the adoption of smart accounts has not been a success.
ZKsync and native Account Abstraction
On Ethereum there are two types of accounts:
On ZKsync Era, a smart move was made to integrate native account abstraction at the protocol level. Native Account Abstraction on ZKsync Era fundamentally changes how accounts operate by introducing the concept of Smart Accounts and Paymasters:
- Smart Accounts are fully programmable, allowing for various customizations such as signature schemes, native multi-sig capabilities, spending limits, and application-specific restrictions.
- Paymasters, conversely, can sponsor transactions for users, enabling users to pay transaction fees in ERC20 tokens. This innovative approach to account management significantly enhances user experience, security, and flexibility, paving the way for broader adoption of blockchain technology.
The design of account abstraction on ZKsync is very similar to the latest ERC-4337 with small differences.
“EIP-4337 introduces a separate transaction flow for smart contract accounts, which relies on a separate mempool for user operations, and Bundlers — nodes that bundle user operations and send them to be processed by the EntryPoint contract, resulting in two separate transaction flows. In contrast, on ZKsync Era, there is a unified mempool for transactions from both Externally Owned Accounts (EOAs) and smart contract accounts. On ZKsync Era, the Operator takes on the role of bundling transactions, irrespective of the account type, and sends them to the Bootloader (similar to the EntryPoint contract), which results in a single mempool and transaction flow”— ZKsync doc
This design has provided the opportunity not to separate the transaction flows between EOAs and Smart Contracts, allowing EOAs to interact with specialized Paymaster accounts.
Zyfi — Paymaster-as-a-service
A technology becomes interesting from the day it is used by real users. Even if ZKsync proposes a technology that is truly innovative, as Dapps you should still follow this complex implementation to use paymaster accounts:
1/ Create a custom paymaster with tailored gas sponsorship logic.
2/ Have audit firms review it to guarantee a deployment free of issues.
3/ Implement the paymaster on the network.
4/ Transfer funds to this paymaster.
5/ Regularly manage the paymaster’s funds to maintain smooth operations.
6/ Yet, it may not be completely adaptable to a Dapp’s specific needs.
That’s why we’ve created a seamless, flexible, audited API solution to enable Dapps to let their users pay with any ERC-20 tokens available on ZKsync as gas and satisfy any off-chain custom logic such as:
- Address whitelisting: Maintain list of addresses on frontend. Only sign for those address and sponsor gas for them. No need for on-chain transaction.
- Contract-based sponsorship: Sponsor all approve transactions of a token or any interaction with a new type of product on your frontend. Again, no need for any on-chain transaction, update your signing logic likewise.
- Exclusive events: Dapp’s anniversary, token launch party, real-life events, or even “office-hours” gas sponsorship. Every sort of custom logic can be created on the Dapp side, and the signer only needs to sign based on this logic.
To take a big step forward, we recently launched a public good, a “one-for-all” permissionless multi-signer paymaster.
No need to deploy a custom paymaster for gas sponsorship now.
1. Deposit gas funds -> 2. Add a signer -> you are done!- Only users with correct signature can utilise a Dapp’s gas funds based on respective business logic.
- You can always delegate the signature signing part to Zyfi’s API.
After those release, Zyfi paymaster on ZKsync received an important traction and become a leader in the industry.
- More than 150k Total Paymaster Users
- More than 1,180,000 Transactions
- More than 2,000 Daily Active Users
Conclusion
To answer the question, paymaster on ZKsync should be considered as a simple “add-on” or a priority “UX”?
Zyfi has big insight that users users are more than happy to use paymaster, especially with the good UX it provides. It is also seen that paymaster supported Dapps are re-used by users more.
At the beginning, the ZKsync tech wasn’t easy to leverage because of straightforward complexities. That’s why Zyfi has created the paymaster solution with both API and the permissionless paymaster to push the gas abstraction experience to another level.
The Elastic chain-of-chain concept recently release by ZKsync also give a new vision of an infinitely extensible network of ZK Chains (rollups, validiums and volitions), secured by math and seamlessly interoperable with a uniform intuitive UX.
Thus, there is no doubt that each Dapps should consider paymaster as priority UX for their users ⛽️
As a ZKsync Dapp or an Elastic Chain desired to integrate an easy to use solutions to offer gas abstraction experience to their users, don’t hesitate to send us a message on Twitter or contacted us on contact@zyfi.org
