feat: add support for gas estimation on CQ messages #1238
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- #1892 Currently skyway send-tx transactions are described as "Send to Eth". It should be renamed to more generic. e.g. "send to remote chain" - [ ] test coverage exists or has been added/updated - [ ] tested in a private testnet - [ ] I have checked my code for breaking changes - [ ] If there are breaking changes, there is a supporting migration.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
maharifu
reviewed
Jul 31, 2024
Co-authored-by: Luis Carvalho <[email protected]>
byte-bandit
added a commit
that referenced
this pull request
Aug 2, 2024
# Related Github tickets - VolumeFi#344 - VolumeFi#1761 # Background > [!IMPORTANT] > This will only merged back to master after Pigeon changes and successful smoke tests on PTN This change adds the infrastructure for Paloma to support gas estimation. Most notably, it - changes the lifecycle of the consensus queue message - adds endpoints for Pigeons to query for and report gas estimation - uses an endblocker to process any estimated messages ## Lifecycle changes The current message lifecycle is very bare bone. Pigeons ask for messages to be signed, and ultimately relay it. There is little filtering or state processing done. A message will even be handed out for relaying long before it has reached consensus on signatures (Pigeon checks that, not Paloma). This change adds the concept of gas estimation to all consensus queue messages. It's not super pretty, since really only EVM messages will need the data. However, the CQ module is the main interface for managing the queue and message lifecycles. It's already grossly interwoven with the EVM module, and the whole idea of abstraction has not really paid off. We hope to address this in the future. Paloma will hand out messages for gas estimation once they have reached consensus on signatures. Pigeons will not relay a message that requires gas estimation and has not yet received one. Even though a message might have been fully signed, it won't be relayed until gas estimation is completed. For this, Pigeons will query the message, build the payload and estimate the gas using their configured RPC provider. They will send their estimate to Paloma, and Paloma will start tracking every estimate. We expect estimates to be different across RPC providers, and have settled to use the median value of all collected estimates, with a generous `1.2` multiplier for safety margins. Paloma will continuously monitor messages and check whether they have received enough estimates to calculate the estimate. IF the message happens to be an SLC message, Paloma will then proceed to automatically calculated the fees based on the relayer fee settings for this message. Once a message has been estimated, all signatures are removed from the message and the signing process starts again, this time using the embedded information (fees & estimates). After this second round of signatures, the messages will finally be sent. # Testing completed - [x] test coverage exists or has been added/updated - [ ] tested in a private testnet # Breaking changes - [x] I have checked my code for breaking changes - [x] If there are breaking changes, there is a supporting migration. --------- Co-authored-by: Luis Carvalho <[email protected]>
maharifu
added a commit
that referenced
this pull request
Aug 16, 2024
# Related Github tickets - VolumeFi#344 - VolumeFi#1761 # Background > [!IMPORTANT] > This will only merged back to master after Pigeon changes and successful smoke tests on PTN This change adds the infrastructure for Paloma to support gas estimation. Most notably, it - changes the lifecycle of the consensus queue message - adds endpoints for Pigeons to query for and report gas estimation - uses an endblocker to process any estimated messages ## Lifecycle changes The current message lifecycle is very bare bone. Pigeons ask for messages to be signed, and ultimately relay it. There is little filtering or state processing done. A message will even be handed out for relaying long before it has reached consensus on signatures (Pigeon checks that, not Paloma). This change adds the concept of gas estimation to all consensus queue messages. It's not super pretty, since really only EVM messages will need the data. However, the CQ module is the main interface for managing the queue and message lifecycles. It's already grossly interwoven with the EVM module, and the whole idea of abstraction has not really paid off. We hope to address this in the future. Paloma will hand out messages for gas estimation once they have reached consensus on signatures. Pigeons will not relay a message that requires gas estimation and has not yet received one. Even though a message might have been fully signed, it won't be relayed until gas estimation is completed. For this, Pigeons will query the message, build the payload and estimate the gas using their configured RPC provider. They will send their estimate to Paloma, and Paloma will start tracking every estimate. We expect estimates to be different across RPC providers, and have settled to use the median value of all collected estimates, with a generous `1.2` multiplier for safety margins. Paloma will continuously monitor messages and check whether they have received enough estimates to calculate the estimate. IF the message happens to be an SLC message, Paloma will then proceed to automatically calculated the fees based on the relayer fee settings for this message. Once a message has been estimated, all signatures are removed from the message and the signing process starts again, this time using the embedded information (fees & estimates). After this second round of signatures, the messages will finally be sent. # Testing completed - [x] test coverage exists or has been added/updated - [ ] tested in a private testnet # Breaking changes - [x] I have checked my code for breaking changes - [x] If there are breaking changes, there is a supporting migration. --------- Co-authored-by: Luis Carvalho <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related Github tickets
Background
Important
This will only merged back to master after Pigeon changes and successful smoke tests on PTN
This change adds the infrastructure for Paloma to support gas estimation. Most notably, it
Lifecycle changes
The current message lifecycle is very bare bone. Pigeons ask for messages to be signed, and ultimately relay it. There is little filtering or state processing done. A message will even be handed out for relaying long before it has reached consensus on signatures (Pigeon checks that, not Paloma).
This change adds the concept of gas estimation to all consensus queue messages. It's not super pretty, since really only EVM messages will need the data. However, the CQ module is the main interface for managing the queue and message lifecycles. It's already grossly interwoven with the EVM module, and the whole idea of abstraction has not really paid off. We hope to address this in the future.
Paloma will hand out messages for gas estimation once they have reached consensus on signatures. Pigeons will not relay a message that requires gas estimation and has not yet received one. Even though a message might have been fully signed, it won't be relayed until gas estimation is completed.
For this, Pigeons will query the message, build the payload and estimate the gas using their configured RPC provider. They will send their estimate to Paloma, and Paloma will start tracking every estimate. We expect estimates to be different across RPC providers, and have settled to use the median value of all collected estimates, with a generous
1.2multiplier for safety margins.Paloma will continuously monitor messages and check whether they have received enough estimates to calculate the estimate. IF the message happens to be an SLC message, Paloma will then proceed to automatically calculated the fees based on the relayer fee settings for this message.
Once a message has been estimated, all signatures are removed from the message and the signing process starts again, this time using the embedded information (fees & estimates). After this second round of signatures, the messages will finally be sent.
Testing completed
Breaking changes