-
Notifications
You must be signed in to change notification settings - Fork 14
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
feat: add websocket eth subscription to deposit tracker #4081
Conversation
Codecov Report
@@ Coverage Diff @@
## main #4081 +/- ##
=====================================
Coverage 71% 71%
=====================================
Files 376 377 +1
Lines 59875 59965 +90
Branches 59875 59965 +90
=====================================
+ Hits 42623 42718 +95
+ Misses 15013 15008 -5
Partials 2239 2239
... and 31 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 👍 I think it's a good idea to get at least ETH working and in first as there's also an infrastructure component, this will need to be setup as part of the web stack. As well as the web component itself, to actually use the tracker.
@@ -15,3 +15,17 @@ serde = "1.0.183" | |||
tokio = "1.29.1" | |||
tracing = "0.1.34" | |||
tracing-subscriber = { version = "0.3.3", features = ["env-filter"] } | |||
tempfile = "3.8" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should change the name of these files and the binary name now to ingress-egress-tracker
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to chainflip-ingress-egress-tracker
. I think I have updated all the scripts that used the old name, but maybe @ahasna could double check?
let vault_address = state_chain_client | ||
.storage_value::<pallet_cf_environment::EthereumVaultAddress<state_chain_runtime::Runtime>>( | ||
state_chain_client.latest_finalized_hash(), | ||
) | ||
.await | ||
.context("Failed to get Vault contract address from SC")?; | ||
|
||
let state_chain_gateway_address = state_chain_client | ||
.storage_value::<pallet_cf_environment::EthereumStateChainGatewayAddress<state_chain_runtime::Runtime>>( | ||
state_chain_client.latest_finalized_hash(), | ||
) | ||
.await | ||
.context("Failed to get StateChainGateway address from SC")?; | ||
|
||
let address_checker_address = state_chain_client | ||
.storage_value::<pallet_cf_environment::EthereumAddressCheckerAddress<state_chain_runtime::Runtime>>( | ||
state_chain_client.latest_finalized_hash(), | ||
) | ||
.await | ||
.expect("State Chain client connection failed"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we do this before starting any of the witnessing processes. As this is effetively configuration that if it doesn't exist, should start this process at all.
supported_erc20_tokens: HashMap<H160, cf_primitives::Asset>, | ||
} | ||
|
||
async fn get_env_parameters(state_chain_client: &StateChainClient<()>) -> EnvironmentParameters { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we could use this in the main witnesser too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The engine's code for this is a bit scattered. Do you want all of these to be read in engine's main? That's where the eth client currently created, for example.
settings: DepositTrackerSettings, | ||
witness_sender: tokio::sync::broadcast::Sender<state_chain_runtime::RuntimeCall>, | ||
) { | ||
tokio::spawn(async { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a reason we do this spawn? we also use a task::spawn
in the btc deposit tracker section. Would be good to make these consistent. We can do so by wrapping the whole thing in the task_scope and then calling each in their own scopes - as I think you may be suggesting in this TODO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the todo is for that. Should be an easy change, but would move a lot of code around, so figured it'd be cleaner to do it separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to push the comments I just left into issues/PRs so we can unblock any of the product/infra work, I'm ok with that
Yeah, I prefer making the changes in the next PR. Tested on localnet before merging. Actually looks like broadcasting returns error when there aren't any subscribers, so removed |
Pull Request
Partially addresses: PRO-868
Checklist
Please conduct a thorough self-review before opening the PR.
Summary
I ran into a few problems integrating other chains, so I thought it'd be better to merge eth tracking first so that the product team can start integrating this if they want and/or to get early feedback.
As discussed with @kylezs, I decided to copy just what's needed from the engine's witnessing rather than reusing the entire witnessing module. I did try the latter approach, but found that it would require a lot of changes to make it work for both binaries without unwanted side effects (just to name a few issues: (1) the engine requires a database, while the deposit tracker does not; (2) deposits are post-witnessed in the engine, but we want them pre-witnessed by the deposit tracker; (3) we don't want chain tracking in the deposit tracker etc). Copying individual witnesser components results in some duplication, but I don't think it is a problem (it is just initialisation code rather than logic), and I think we can do some refactoring to help with this too.
Changes:
subscribe_eth
subscription endpoint to the rpc client, which forwards all witnessed events substrate-codec-encoded (From our discussion I got the impression that this works for you @niklasnatter? If not, we can discuss other options.)FYI @niklasnatter
(Tracking of other chains will come shortly, but I might need to do some refactoring first)