FLIP 243: Flow EVM Gateway #235
Conversation
m-Peter
changed the title
| If this were to happen, the storage index could end up corrupted, and we would | ||
| return incorrect data for things such as account balances, nonces etc. | ||
|
|
||
| In the code snippet below, we specify a heartbeat interval of `1` and check |
There was a problem hiding this comment.
I would say this would be good to change in the future as a performance improvement, ideally we would get multiple events and still preserve the order and integrity, however this currently might not be possible yet due to API not providing the heights, but it might be worth linking to an issue and keeping a promise to improve it.
There was a problem hiding this comment.
Just to clarify, even with a heartbeat interval of 1, we still get all the events emitted within the transactions of a single block. You are right though, I guess it will improve performance if we use a larger heartbeat interval when the backend introduces the sequence number field. Quoting the original message from Peter Argue in onflow/flow-evm-gateway#11 (comment)
The SubscribeEvents endpoint has a heartbeatInterval request parameter:
https://github.com/onflow/flow/blob/b7ed2c3e452b5e44561399afc6b5e868e8957117/protobuf/flow/executiondata/executiondata.proto#L140-L148This is used to set how often the backend will return a response message. If you set it to 1, it will return a response for every block. If the block has no events, the list is empty. If you check the block height from each message increases sequentially, you can verify that you received all messages, and thus all blocks were searched.
The API is currently missing an important sequence number field, which would let you get the same guarantee with larger heartbeatIntervals without receiving a response for every block.
Given missing any events may corrupt your index, I'd recommend using the 1 block heartbeat for now.
| We should have some end-to-end tests, perhaps with the usage of the Flow Emulator. | ||
| As well as some benchmarks, to assess the service degradation with regards to the | ||
| increase of the storage, the incoming requests and possibly the emitted events. | ||
|
|
There was a problem hiding this comment.
I would also create stress tests that could be run as part of the Flow benchnet, with good metrics on the gateway side we could measure performance. The metrics should also be used in production for monitoring. It would be also worth exploring tracing with OTEL.
|
|
||
| ## Questions and Discussion | ||
|
|
||
| - Do we expect to have one official EVM Gateway run by the Flow team and |
There was a problem hiding this comment.
We expect the community to maintain the EVM Gateways the same way as currently are for AN.
There was a problem hiding this comment.
Sounds good, I guess I should introduce more flexible config options then.
|
|
||
|  | ||
|
|
||
| ### Storage Integrity |
There was a problem hiding this comment.
The integrity mechanism outlined below is a good start though we may need to build in more logic to recover missed events. While the goal is to not miss events we should plan for a reality where it will eventually happen.
There was a problem hiding this comment.
Yes, certainly. Back-filling of past events is something we should account for.
Co-authored-by: Gregor G. <[email protected]>
…rence to MetaMask Co-authored-by: j pimmel <[email protected]>
Co-authored-by: j pimmel <[email protected]>
Co-authored-by: j pimmel <[email protected]>
Co-authored-by: j pimmel <[email protected]>
|
Marked this FLIP as proposed |
|
This proposal has not been approved yet, so should have a proposed status, not implemented |
Co-authored-by: Bastian Müller <[email protected]>
Co-authored-by: Bastian Müller <[email protected]>
Co-authored-by: Bastian Müller <[email protected]>
FLIP #243