Ethereum Oracle

[ezeike]

This PR implements an Ethereum transaction Oracle allowing for cross-chain transfers to Canopy.

• Added Ethereum blockchain interaction layer
• Implemented ERC20 token caching and validation system
• Created block provider with transaction monitoring
• Added order store for managing cross-chain transactions
• Included extensive test coverage and e2e testing framework
• Integrated oracle functionality with controller and configuration
• Added testing infrastructure with Anvil setup and utility scripts

[andrewnguyen22]

Initial Reveiw

Good

• Code looks really high quality
• Dynamically extracts the ERC20 info by using eth_call
• Testing is robust and well done
• Good abstraction

Concerns

• Inspecting every ERC20 before checking if it includes the lock order / close order bytes is expensive and dangerous. Could lead to the oracle falling behind. Why not skip any ERC20 transfer that doesn't have 'extra data'?
• "remove lock order from store if it was not found in the order book" is wrong - it should remove lock from the store if the order was 'locked'
• Safe block logic and potential re-orgs (non-actionable - just noting)
• Use of JSON file is non-atomic and very susceptible to corruption. Should use a badgerDB instance instead.
• Does err := <-sub.Err(): mean that the connection dropped? If not p.connectWithRetry() could potentially cause multiple simultaneous subscribers.
• I don't think a separate package at 'root' level for testing is necessary. Please move to the oracle package if possible
• Potentially too much abstraction at the ETH transaction level. Would like to see code footprint reduced a bit if possible

Missing logic:

• Marking orders included in a 'proposal' as 'pending' to not duplicate orders
• Smart 'resubmit' logic
• Smart 'waiting period' for preventing brand new locks and closes from being submitted to allow slow nodes to process orders on Ethereum
• Removal of native 'lock' and 'close' order logic

[ezeike]

Files are written atomically by writing to a temporary file then moving that file into place. This ensures only a successfully written file is moved into place.

This should be sufficient for safety guarantees and also lends itself to easier administration and debugging.

[andrewnguyen22]

Yes, but speed is a concern - as we can't have the oracle falling behind. Do you forsee this being a bottleneck?

[ezeike]

Yes, but speed is a concern - as we can't have the oracle falling behind. Do you forsee this being a bottleneck?

In general I do not. On my system a benchmark wrote, read and removed 80k orders per second with sync.

How many orders should we be prepared to handle on a node that is very far behind?

One advantage to using BadgerDB though is adding commands to the canopy binary rather than using standard shell tools to query & troubleshoot.