Skip to content
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

Add VirtualRelayer #5

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Add VirtualRelayer #5

wants to merge 2 commits into from

Conversation

ernestognw
Copy link
Member

No description provided.

requestsValue += requests[i].value;
bool success = _execute(requests[i], atomic);
if (!success) {
refundValue += requests[i].value;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In cases of failed operations we could emit some event too, so we can handle that off-chain

Copy link
Member Author

@ernestognw ernestognw May 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be but it's going to cost us more. I feel the event is not needed if the off-chain actions are idempotent (e.g. marking a tx as succeeded in the database twice should result in the same).

Any example of what should be handled off-chain? 🤔

Copy link
Member

@MCarlomagno MCarlomagno Jun 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, if a user sends a tx bundle, when one of the transactions failed and the rest succeeded, in our database the tx will look as succeeded.
So the end client would not know if whether some tx of the bundle failed or not, so I think that by using an event, they can detect if some transaction of the bundle failed and retry the transaction if needed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean. Having the transaction status in the database read from RPC is a constraint of the relayer in the current design, but the idea behind a smart contract VirtualRelayer is to change the relayer nonce from the protocol's (ie. EOA nonce) to this contract's nonce so that execution is parallelized.

In this scenario, changing the nonce implies replacing the RPC getNonce call and look to a getter in the virtual relayer getter to know whether the transaction succeeded or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants