[General] Need clarification regarding paymaster verification rule in future.

[hoshiyari420]

Environment

Mainnet

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

Description

I am currently building a new public good paymaster where multiple Dapps(precisely anyone) can connect to this single paymaster and provide gas sponsorship for their users without needing to deploy paymaster at all.

Since this paymaster can be used by anyone, I want to ensure that design is compliant keeping future perspective in mind. For this one of the clarification I need is regarding the topic: paymaster verification rule in future mentioned in the docs

I have checked ERC-4337 Account Abstraction and ERC-7562, although, it's way more informative and lot of ambiguity keeping ZKsync in mind. Hence, want some clarifications on the paymaster verification rule part as below:

1. Is there some close timeline regarding reputation implementation that I should be aware of?

2. Is there any further information that can be shared regarding verification rules and how ZKsync sees them?

3. As of now my understanding is, if a transaction with paymaster is rejected in the validation phase itself, it's reputation will not altered. Hence, in a scenario, where a Dapp creating failed transactions would not affect the this paymaster's reputation and other Dapps using this paymaster would not be affected at all.

4. Should I not worry about this right now as reputation implementation is far down the line?

Also if I can get some scenario, where a paymaster's reputation might be affected in future, would be quite useful.

To conclude, these clarifications would be extremely helpful in the design and development of this new paymaster. Looking forward to this discussion. Many thanks.

Repo Link (Optional)

No response

Additional Details

No response

[gleenai[bot]]

Hello,

Thank you for your detailed inquiry regarding the future implementation of paymaster verification rules in the zkSync ecosystem. Here’s a breakdown of the information based on the current documentation and future prospects:

1. Timeline for Reputation Implementation:
   Currently, there is no specific timeline provided for the implementation of a reputation system for paymasters in zkSync. The concept is still in the exploratory phase, and while it draws inspiration from EIP-4337, zkSync may implement its own unique features and timelines. It's advisable to keep an eye on official zkSync documentation updates or announcements for any new developments in this area.

2. Further Information on Verification Rules:
   As per the current documentation, the verification rules for paymasters are not fully enforced yet. However, it is mentioned that paymasters not complying with future rules may cease to function correctly. This implies that while the exact details of these rules are still under development, they will likely include mechanisms to prevent misuse and ensure the reliability of paymasters.

3. Impact of Failed Transactions on Paymaster Reputation:
   Your understanding is correct; currently, if a transaction with a paymaster is rejected during the validation phase, it does not alter the paymaster's reputation. This means that other DApps using the same paymaster are not affected by isolated failed transactions. However, this could change with the future implementation of a reputation system, where repeated failures might impact the paymaster's reliability score.

4. Concerns About Current Reputation Mechanisms:
   Since the reputation system and more detailed verification rules are not yet implemented, focusing on building a robust and compliant paymaster under the current guidelines is advisable. It's important to design your system with flexibility to adapt to future changes in the verification rules once they are established.

Scenario for Future Reputation Impact:
In the future, scenarios that might affect a paymaster’s reputation could include:

• High frequency of failed transactions due to invalid or malicious requests by a DApp.
• Consistent pattern of transactions that trigger security flags or violate smart contract best practices.
• Manipulation or gaming of the paymaster system to bypass costs or exploit other DApps.

For your project, it would be wise to design with an emphasis on security, scalability, and compliance with current best practices while staying updated with zkSync developments. This proactive approach will help ensure that your paymaster remains functional and compliant as new rules roll out.

Feel free to reach out if you need further assistance or have more questions!

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[hoshiyari420]

Hi @bxpana, the answer by AI was not upto the mark, would really appreciate if you could look into this :)

[bxpana]

Got it, let me find out more for you.

[bxpana]

Right now we don't have a timeline for when anything would be implemented here so it's still quite open. One of our engineers suggested that if you follow the EIP4337 rules/rules from our docs you should be fine. The reputation system plans to be similar to EIP4337, but we're still far out from implementing.