Tsuko - (PaaS): Extension feature

Hello txCitizens!

We're back with another exciting chapter in our innovative paymaster journey – a deep dive into txTsuko's Extension feature. But this isn't just a feature; it's a key innovation that's set to transform the ZKsync ecosystem! 🔥

We're genuinely excited about the potential of this concept to bring positive changes to the ZKsync ecosystem, especially in its interaction with Paymasters. The scalability of Extensions is a key aspect that holds promise not only in the near term but also in the long run.

So we've put together this dedicated blog post to explore the nuances of the entire Restrictions topic in greater detail.

Before we explain what are extensions, let’s step back to paymaster types we introduced earlier in previous post. As we mentioned, we consider two types of paymasters:

1. 1. Sponsored paymaster
2. 2. ERC20 paymaster

These paymasters enable you to:

• - not pay gas fees and
• - pay gas fees in ERC20 tokens instead of ETH

‍

But if you look at the examples, presentations or talks in the ZKsync ecosystem, there are multiple other “types” mentioned, explained or even already coded. For example, a common case is to explain “NFT-gated” paymaster - a paymaster that sponsors transactions only for the holders of a specific NFT collection. If you have that NFT in your wallet, you don’t pay for gas fee. Otherwise, your transaction is processed as a normal one, and you pay some small amount of ETH for gas.

Or what about the “Gasless Friday” paymaster where, for example, a DApp offers its users to pay for their transactions each Friday between 10am and 1 pm. Or, a paymaster that lets you trade in USDC token instead of ETH, and it subsidizes 80% of your cost.

All these examples show great use cases of what paymaster on ZKsync can do! But are they separate paymaster types? 🤔

You can see that from all these examples we talked about sponsoring your gas fees or enabling you to pay in some other token + some specific rule of when that can happen. They are not describing anything completely new compared to the two basic paymaster types, they are just adding an extra condition that has to be followed, in order for paymaster to be used and for transaction to be executed.

This is why we introduced Extensions in Tsuko!

How to create and see extensions

To build a special use case paymaster with additional constraints, the current approach involves reviewing the code of a basic paymaster example. From there, you determine the necessary modifications to optimize it for your specific use case. After implementing the changes, you proceed with validation, auditing, and finally deploying the paymaster.

You can create a new restriction by providing a name and selecting the desired type of restriction. That's all it takes!

When the restriction is created, you can connect it to your Tsuko following these steps:

• - Go to the Extension tab in Tsuko’s page
• - Click on the “+” icon

And that’s literally it!

The best part: Extension's flexibility

Extensions aren't just features; they're standalone smart contracts with their own addresses. This flexibility opens up a world of possibilities!

Why is this important?

Imagine a scenario where a talented artist published an NFT collection with different tiers on ZKsync. He collaborates with the developer to build a DApp for the holders of this collection. In that DApp, user can buy real world assets with different discount, depending on the NFT tier they bought. Let’s also imagine that the holders of the “Diamond Tier” of this collection have options to purchase two products from two different stores on this app, one that sponsors gas fees for Diamond holders, and the other that offers 75% discount for the same holders.

Let's compare how the process looks with traditional approach and with Tsuko:

• - Traditional Approach: Developer needs to code two separate paymasters, one Sponsored and one ERC20 type. Then he needs to add in the code the sponsored functionality for the first Store and deploy that paymaster, but also to the same for the 75% discount for the second store and their benefits. In both cases, he needs to list Diamond NFT holder addresses and to add them to paymasters. Those are now two paymaster smart contracts with two separate codes, that check for the same thing - if a user that connects to paymaster is a holder of a given NFT collection.

‍

• - Tsuko Approach:

1. 1. Create your Sponsored paymaster in 3 clicks
2. 2. Create your ERC20 paymaster in 3 clicks (actually 4, you need to chose the token too 😉)
3. 3. Create one extensions where you will specify the addresses of the NFT Diamond holders
4. 4. Connect this deployed restriction to both paymasters.

‍

And that’s it! Done! No further steps required.

The result? A more efficient, user-friendly process that saves time and energy!

Now each time the transaction goes through your paymaster, it will check if the restriction conditions are met, and if they are, the transaction will pass. Otherwise it will revert which means someone tried to use your paymaster, but they didn’t have permissions, and they were stopped.  

This extension usability is one of the main benefits Tsuko offers!

But that is not all! One paymaster can have multiple extensions!

One paymaster can also have multiple extensions, which means that you can set two or more custom rules for your paymaster and each transaction that goes through it will have to meet ALL the conditions specified in different extensions.

In summary: Extensions enable you to upgrade your paymaster in real time, without any additional code writing, deploying or extensive auditing. Every one of those actions is handled by Tsuko!

Currently Supported Restrictions in txTsuko

Now when we introduced the game-changing concept of extensions s and their incredible usefulness, let’s see which ones are currently supported in Tsuko:

1. User Whitelisting

In this extension, you can specify one or more account addresses for who you want to be able to use some paymaster benefit (gasless transactions or paying in ERC20 tokens). Then, you can use this account list in multiple paymaster - ideal when you have a user list that you want to receive different benefits. Only a transaction initiated from users in this list will be executed.

2. Contract Whitelisting

Imagine that you want only for specific contracts to be able to interact with your paymaster. Now you can! In the same manner as for the user whitelisting extension, you just add one or more smart contract addresses, click deploy, and that’s it.

3. Function Whitelisting

These extensions are similar to the previous contract restrictions, but instead of whitelisting the whole contract (which means every function in it), we specify which exact function will use paymaster. An obvious use case for this restriction is when you have a contact with multiple “actionable” transactions, but you want to sponsor or pay in ERC20 token just if some of them are used.

‍

The future of extensions in Tsuko

At txFusion, we're not just following trends; we're setting them. With Tsuko, our mission is to revolutionize how paymasters are created, customized, and monitored. Instead of adding new "paymaster types" – we're crafting a diverse universe of extensions, unlocking a spectrum of possibilities!

And this is just the beginning! Behind the scenes, our team is relentlessly pushing the boundaries, constantly innovating to expand Tsuko’s potential and user-friendliness.

✨Stay tuned for the final part of our blog series, where we'll unveil an in-depth tutorial on harnessing the full power of Tsuko.

As always, your insights are invaluable in this trailblazing journey. Join us on Discord, share your ideas, and help us shape a new frontier in blockchain technology!

‍

*This article is also published on txFusion Medium channel.