feat(PROTO-329): Implement Log Fetcher #11
Conversation
🟡 Heimdall Review Status
|
go-filler PR review suggestions
| ArbitrumSepolia: getEnvStr("ARBITRUM_SEPOLIA_RPC"), | ||
| BaseSepolia: getEnvStr("BASE_SEPOLIA_RPC"), | ||
| OptimismSepolia: getEnvStr("OPTIMISM_SEPOLIA_RPC"), | ||
| Sepolia: getEnvStr("SEPOLIA_RPC"), |
There was a problem hiding this comment.
Would recommend replacing this with a more robust flags library. There's the built in one: https://pkg.go.dev/flag. OP uses github.com/urfave/cli/v2 heavily, which also supports envvars (e.g. https://github.com/ethereum-optimism/optimism/blob/develop/op-batcher/flags/flags.go).
There was a problem hiding this comment.
Also might consider loading a toml file or something for the RPCs, given this is per-chain config. Perhaps can merge with the internal/chains/config.go file.
| } | ||
|
|
||
| func (l *listener) Start(ctx context.Context) error { | ||
| sub, err := l.outbox.WatchCrossChainCallRequested(&bind.WatchOpts{}, l.logs, [][32]byte{}) |
There was a problem hiding this comment.
This (and the previous implementation using SubscribeFilterLogs) only supports websocket RPCs, which tend to be more rare than HTTP RPCs. Would recommend generalizing this and supporting both, with a polling interval for the HTTP one.
| }, nil | ||
| } | ||
|
|
||
| func (l *listener) Start(ctx context.Context) error { |
There was a problem hiding this comment.
We need to somehow track which block we've processed, so we can always start at the most recent unprocessed block. Perhaps writing this metadata to the datastore would be best.
|
Review Error for dav3yblaz3 @ 2024-11-19 02:48:36 UTC |
|
Review Error for dav3yblaz3 @ 2024-11-19 02:57:13 UTC |
|
Review Error for dav3yblaz3 @ 2024-11-19 02:59:32 UTC |
|
Review Error for dav3yblaz3 @ 2024-11-19 02:59:53 UTC |
Description
The Log Fetcher serves as the first component in our fulfiller architecture. Its main purpose is to monitor events from
RIP7755Outboxcontracts on supported chains. When it ingests an event representing a cross-chain call request, it first parses the log into an ingestible format. It then validates the request by ensuring all routing information matches pre-defined chain configs for the source / destination chains. It then validates that the reward asset / amount represents a reward that would guarantee profit if this request were accepted by the system. If the request passes validation, the log fetcher passes it along to an SQS queue for further processing.