[BUG] eth_subscribe from go-ethereum not working

[bruce-riley]

Seid version Using the public Sei EVM websocket, wss://evm-ws-testnet.sei-apis.com.

Describe the bug While adding support for Sei EVM to the Wormhole guardian, we are having problems listening to events from the Wormhole Core Contract on Sei EVM.

The Wormhole guardian watcher uses the go-ethereum library to connect to all EVM chains. That library handles subscribing to events and presenting them to our application level code.

We are not seeing any events generated on Sei EVM. This problem is seen both using the version of go-ethereum that the guardian as been using (v1.10.21) and the latest release (v1.14.12).

The go-ethereum code generates a subscription request as follows (and we have no real control over it):

{"jsonrpc":"2.0","id":1,"method":"eth_subscribe","params":["logs",{"address":["0xbb73cb66c26740f31d1fabdc6b7a46a038a300dd"],"fromBlock":"0x0","toBlock":"latest","topics":[["0x6eb224fb001ed210e379b335e35efe88672a8ce935d981a6896b27ffdf52a3b2"],null]}]}

It looks like the Sei RPC node has problems with the fromBlock and toBlock fields because if those are specified (which, again, we have no control over at the application layer), the subscription does not see any newly generated events.

To Reproduce

This problem can be reproduced using wscat and cast as follows.

First, run two instances of wscat.

The first one matches what go-ethereum uses and will not see events.

~$ npx wscat -c wss://evm-ws-testnet.sei-apis.com
Connected (press CTRL+C to quit)
> {"jsonrpc":"2.0","id":1,"method":"eth_subscribe","params":["logs",{"address":["0xbb73cb66c26740f31d1fabdc6b7a46a038a300dd"],"fromBlock":"0x0","toBlock":"latest","topics":[["0x6eb224fb001ed210e379b335e35efe88672a8ce935d981a6896b27ffdf52a3b2"],null]}]}
< {"jsonrpc":"2.0","id":1,"result":"0xca3eb290c5e074042caf487a41ddb896"}

The second is simplified and will see events.

~$ npx wscat -c wss:evm-ws-testnet.sei-apis.com
Connected (press CTRL+C to quit)
> {"jsonrpc":"2.0","id":1,"method":"eth_subscribe","params":["logs",{"address":["0xbb73cb66c26740f31d1fabdc6b7a46a038a300dd"],"topics":[["0x6eb224fb001ed210e379b335e35efe88672a8ce935d981a6896b27ffdf52a3b2"],null]}]}
< {"jsonrpc":"2.0","id":1,"result":"0xeeeb557691c95f579836cab0eafabf35"}

Once the two instances of wscat are running, generate an event from the Wormhole core contract using cast:

$ cast send --rpc-url https://evm-rpc-testnet.sei-apis.com/ --private-key <YOUR_PRIVATE_KEY> 0xBB73cB66C26740F31d1FabDC6b7A46a038A300dd "publishMessage(uint32,bytes,uint8)" 43 0xdeadbeef 202

The first instance of wscat (using fromBlock and toBlock) will not see the event but the second wscat (which does not include those parameters) will see it.

Expected behavior An eth_subscribe request that includes "fromBlock":"0x0","toBlock":"latest" should receive new events as they are generated.

Additional context Although we can work around this issue to deploy Wormhole to Sei EVM testnet, we will not be able to deploy Wormhole to Sei EVM mainnet until this issue is resolved.

[cordt-sei]

I imagine this is related to the fact that you are specifying an open ended range of blocks.. is this absolutely required?

[bruce-riley]

As I mentioned above, the subscription parameters are generated by the go-ethereum library so we have no control over them, other than specifying the contract address.

[bruce-riley]

I created a simple test app that uses the go-ethereum library to listen for events from the Wormhole core contract without needing to run the Wormhole guardian. It can be used to recreate the problem and also to verify a fix. See the PR description for how to use it. https://github.com/wormhole-foundation/wormhole/pull/4214

Reminder: The desired behavior is that only new events are streamed, not historic ones.

[cordt-sei]

Awesome thank you. I will test this as soon as I can get a node to actually sync here.

[hsnice16]

I was looking to contribute to the SeiNetwork and came across this issue to check if I can take a stab at it. But, it seems like this issue has already been resolved with this PR - https://github.com/sei-protocol/sei-chain/pull/2027

In that case, we should close this issue, as it will keep the repo clean.

[github-actions[bot]]

Thank you for opening this issue and taking the time to share your thoughts. We’d love to keep moving this forward, but we need a bit more information from you. Please add any additional details within the next 2 day(s) so we can continue collaborating on a solution together. If we don’t hear back, the issue will close automatically — but you’re always welcome to reopen it when you’re ready.

[github-actions[bot]]

We’re closing this issue for now as we haven’t received additional input. Please know that your effort is appreciated — and when you’re ready to revisit this, we’ll be here to pick it up again. Thank you for contributing and helping us improve Sei.