Conversation
- explicitly fail when found higher event_id than next_event_id - warn when next_event_id is not 0 but wasn't found during full scan
packages/kolme/src/core/types.rs
Outdated
| /// will both remain pending. | ||
| pub pending_events: MerkleMap<BridgeEventId, PendingBridgeEvent>, | ||
| /// Last known location of an external-chain event log for this chain. | ||
| pub last_event_location: Option<LastEventLocation>, |
There was a problem hiding this comment.
This doesn't look correct. The chain state itself shouldn't be tracking information related to the processing handled by the listener itself. The listener should know what event to look for based on:
next_event_id- Which proposals for new events are pending
There was a problem hiding this comment.
This is the best way I've found so far to avoid full chain scan while catching up missed events during listener startup.
There was a problem hiding this comment.
I also thought about scanning backwards, but Ethereum is badly suited for that, and we'll have to make lots of RPC calls. This can be optimized with binary search, but it will still be less effective than using this cursor information.
If you know about something I miss here (some Ethereum mechanism that can be helpful, etc) - please let me know.
Also, apparently there is a thing I didn't know about - ethereum reorgs. To adapt to that we may also want to store block hash along with other cursor info to verify it wasn't a subject of reorg.
There was a problem hiding this comment.
I don't know what problem you're trying to solve for. Can you clarify?
There was a problem hiding this comment.
If Ethereum is a series of blocks G..D..L..C, where
- G - genesis
- D - bridge contract deployment block
- L - block containing last event that was processed by kolme
- C - current (last) block in the chain
When listener starts, and it has non-zero next_event_id it has to scan blocks in L..C to find:
- event with
next_event_id - all events that has been emitted by bridge since that for catching up
Right now, we don't have a way to know location of L or D - only G. Storing location is D is to be implemented in a milestone 3, but the most efficient strategy would be to know L and start scan from it.
So, I've added last_event_location that stores L's block height and log index of the event in it, to the kolme state.
There was a problem hiding this comment.
- Is there an Ethereum method for searching for an event based on its metadata?
- The problem is storing the last block info within the Kolme chain itself. Introducing a listener storage mechanism is possible, though it would be better if there's a way to query "find the event for this contract with ID X".
There was a problem hiding this comment.
Is there an Ethereum method for searching for an event based on its metadata?
Yes, and we use it. It's not O(1).
On second thought, I could set event id as indexed topic1, which will make it more efficient. Still - the best efficiency(as far, as I understand) would be to limit a search with L, but I can implement the "topic1 way" in a couple of hours, likely.
There was a problem hiding this comment.
- changes that added location info to the sidechain state reverted (I think it would be worth to keep them in history)
- I've added event id to indexed topics and use it to sync listener on startup
- Search's lower bound is genesis block at the moment, I plan to fix that and start from contract deployment block in milestone 3.
Revert "feat(listener): ethereum: store event location in Message" This reverts commit 9df3665. Revert "feat(ethereum): resume listener from last processed event location" This reverts commit 91987ea. Revert "feat(listener): maintain event location in the state" This reverts commit 59307b6. Revert "feat(tests): core::types: cover location's versioned [de]serialization" This reverts commit ca9204e. Revert "feat(types): Message::Listener: add location field" This reverts commit fed06f9. Revert "feat(types): core::PendingBridgeEvent: add location and create serialization v1" This reverts commit 02a2949. Revert "feat(types): core::ChainConfig: add last_event_location" This reverts commit c888b0c. Revert "feat(types): core::ChainState: add last_event_location and create serialization v1" This reverts commit b18b775. Revert "feat(types): add LastEventLocation" This reverts commit 3786ee9.
Deploying kolme with
|
| Latest commit: |
2bf2d70
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://e765e512.kolme.pages.dev |
| Branch Preview URL: | https://ethereum-bridge-1-5-get-resu.kolme.pages.dev |
2 participants
Depends on #504
event_idhigher thannext_event_idin the internal statenext_event_idis not0, but during sync scanning listener didn't find a matchingevent_id