feat: Pigeon Feed #1262
Merged
feat: Pigeon Feed #1262
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
# 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]>
# Related Github tickets - VolumeFi#1761 - VolumeFi#344 # Background This change adds the needed building bricks for gas estimation to the Skyway module, which works independently from the consensus module and regular relay messages. Ideally, the Skyway stuff should be boiled down to only perform some additional logic on top of the CQ, but for now, we will have to live with this solution. # 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.
# Testing completed - [ ] test coverage exists or has been added/updated - [ ] tested in a private testnet # Breaking changes - [ ] I have checked my code for breaking changes - [ ] If there are breaking changes, there is a supporting migration.
# Background The fee manager smart contract will be independent from compass and the bridge. It will need to be deployed manually before compass, and ownership will have to be passed to compass after its deployment. > [!CAUTION] > There is no support yet for automatic compass upgrades, as they will require a handover of the fee manager just like ERC20 tokens. This will be added in a follow up MR. # 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.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
- VolumeFi#1891 Even if we don't want to move test tokens, since we have them set, paloma will still try to move them. This will fail since (new) pigeon won't be compatible with (old) compass, so we need to disable this functionality before compass 2.0 is deployed and re-enable it again afterwards. - [ ] 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.
# Related Github tickets - Closes VolumeFi#1042 # Background Before issuing a jit valset update, check the queue for existing valset updates with the same ID. # Testing completed - [x] test coverage exists or has been added/updated - [x] 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.
# Background Small change needed on the contract between Paloma/Pigeon. # 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.
# 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.
# Related Github tickets - VolumeFi#1848 # Background Reset skyway nonce everytime we redeploy compass. - When a new compass becomes active on a chain, emit an internal event - The skyway keeper receives this event and resets the last observed nonce - Skyway attestations from the previous compass are ignored This PR will be followed by a related PR to pigeon # Testing completed - [ ] test coverage exists or has been added/updated - [x] 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.
# Background Messages will now have different bytes to sign before and after including gas estimates, so we need `BytesToSign` to be more dynamic. This change computes `BytesToSign` on demand when needed, so we have the necessary flexibility. # Testing completed - [ ] test coverage exists or has been added/updated - [x] 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.
# Background This adds mutable BytesToSign to the skyway module, they get refreshed after gas estimate is attached to the batch. # 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.
# Background Include gas estimate and fee structure in turnstone messages hash. # Testing completed - [ ] test coverage exists or has been added/updated - [ ] tested in a private testnet # Breaking changes - [ ] I have checked my code for breaking changes - [ ] If there are breaking changes, there is a supporting migration.
# Background Adapt turnstone message attestation test code to the new compass ABI. # 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: Christian Lohr <[email protected]>
Merge master back to dev16 branch.
# Testing completed - [x] test coverage exists or has been added/updated - [x] 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.
Background
Things brings back the changes for Paloma
v2.0.0.Testing completed
Breaking changes