You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From a performance point of view, it would be a good idea to switch from loop-based-polling to event streams. For example, geth supports events via pubsub; it supports also fliters for logs.
This will eliminate the need to query in a loop and the CPU heavy mechanisms of loop speed and wait to poll for the next notifications.
It is possible to tokio::spawn a future at each event to keep the current future unblocked for the next event handling.
With these, a new procedure would be as following,
Spawn two futures - Fut_1 and Fut_2.
(Fut_1) Spawn the pubsub event subscription.
(Fut_1) Gather events but don't relay yet. Wait to resync with past events.
(Fut_2) Find the last_cosmos_event_nonce and last_block_height_with_last_cosmos_event_nonce from Cosmos validators.
(Fut_2) Start reading logs from last_block_height_with_last_cosmos_event_nonce till last_block_height.
(Fut_2) Process events from logs and relay to Cosmos if there is any.
(Fut_2) Signal pubsub event Future that resync is finished.
(Fut_1) Start processing live events.
(Fut_1) If pubsub fails, goto (0).
The text was updated successfully, but these errors were encountered:
rnbguy
changed the title
Switch to _pubsub based event streams_ from _event scanning from logs_ using geth
Switch to pubsub based event streams from event scanning from logs using gethOct 24, 2021
Surfaced from @informalsystems audit of Althea Gravity Bridge at commit
19a4cfe
severity: Informational
type: Restructuring proposal
difficulty: Medium
Involved artifacts
Description
These functions here poll on Ethereum events
orchestrator/orchestrator/src/oracle_resync.rs#L18
orchestrator/orchestrator/src/ethereum_event_watcher.rs#L23
Polling is very CPU intensive without providing any advantages compared to Event Driven programming.
Recommendation
Currently the Ethereum even watcher works as following,
last_cosmos_event_nonce
from Cosmos validators.last_block_height_with_last_cosmos_event_nonce
from reading old eth logs.last_block_height_with_last_cosmos_event_nonce
tilllast_block_height
.last_block_height_with_last_cosmos_event_nonce
with newlatest_block_height
.Recomendation 1
It would be nice to come up a way to get back the
eth_block_height
of thelatest_cosmos_event_nonce
(GetLastEventNonceByValidator
from Cosmos module).This will remove the need for performance-heavy
oracle_sync.rs
at step (2).Maybe something similar to this function
SetLastObservedEthereumBlockHeight
from Cosmos module?This is not implemented at Orchestrator side.
Recommendation 2
From a performance point of view, it would be a good idea to switch from loop-based-polling to event streams. For example,
geth
supports events via pubsub; it supports also fliters for logs.This will eliminate the need to query in a loop and the CPU heavy mechanisms of
loop speed
andwait
to poll for the next notifications.It is possible to
tokio::spawn
a future at each event to keep the current future unblocked for the next event handling.With these, a new procedure would be as following,
last_cosmos_event_nonce
andlast_block_height_with_last_cosmos_event_nonce
from Cosmos validators.last_block_height_with_last_cosmos_event_nonce
tilllast_block_height
.Future
that resync is finished.The text was updated successfully, but these errors were encountered: