-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reliable relayer #259
Comments
The core wiki should also be updated - many descriptions are now inaccurate given the vast amount of updates over the last few months |
polymorpher
changed the title
Business integration support and documentation
Reliable relayer and documentations for developers
Mar 18, 2022
Further fixed by 6449e58...b1f186a |
Removed documentation related items from this issue. Will create separate issues for those |
polymorpher
changed the title
Reliable relayer and documentations for developers
Reliable relayer
Apr 1, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current relayer operates in a serial mode, of which some burst, concurrent requests are denied until the blockchain finishes processing a pending transaction. As more users are getting onboarded at the same time in offline events, there are requests to support burst concurrent API calls. The implementation can be non-trivial. For example, nonces need to be manually tracked. Some transactions can be dropped by the blockchain silently, or not mined for unknown reasons.
In the initial design, clients are encouraged to share a relayer with only a small group users, which is operated and set up based on their own usage pattern. The reason is that a faulty or malicious relayer may cause denial of service to the clients, and gas fees are paid by the relayer account. Thus, a relayer should be a semi-private, semi-public layer that serves a small group of users. The clients are supposed to be switching between multiple relayers based on performance and reliability. This was discussed in page 2 and 11 in https://docs.google.com/document/d/1dExGu2FBQCj0KF5iX6ww1RAZrNN_fbDb1rmwmHe1jbE/edit#
Since client implementations (e.g. Timeless 1wallet) increasingly rely on the existing test relayer instead of operating their own, the test relayer's capability must be expanded. Several functionalities should be implemented:
The text was updated successfully, but these errors were encountered: