ultrasoundmoney / oracle-client Goto Github PK

Currently there are a few println! statements scattered in the code but no proper logging.
We should change that.

It'd be cool if we had a ci workflow that:

1. Installs / builds gofer
2. Runs oracle-server instance
3. Runs / tests the oracle-client in integration with gofer and oracle-server

Currently the messages have the following format:
PriceMessage = { value: u64 } with the price being represented as a fixed point number with 6 decimals of precision.

This is likely not the final format we want so we should decide on a message format including:

1. Additional fields that we want to add (timestamp, slot number, validator public key)
2. Additional types of messages ("price is within x% of certain value", "price is above certain value")
3. Granularity of price data(especially if we want to efficiently bls-aggregate some of the messages mentioned in 2. we need a sufficiently coarse granualrity to ensure we have many messages with identical content)
4. Signature scheme: What parts of each message are going to be signed (timestamp?, slot number ? ). Are certain parts of the messages going to be signed individually or everything together ?

Why do we end up in this situation if slots are run with a 24s timeout?

Currently as a "slot_provider" we use a placeholder implementation that executes the oracle code for every mined block as returned by a ws connection to an json rpc provider.

Instead it should probably trigger the price reporting at the beginning of each slot, before the block is mined.
Also it should trigger the oracle even if a slot is missed and no block mined for that slot.

Options for implementing this:

1. Subscribing to a WS rpc method that has the corresponding cadence ( if it exists on any rpc / client method)
2. Determining the next slot number using the system time
3. Exposing an api endpoint that can be called from the outside to trigger each slots calculation
4. Listening to respective messages on the p2p network that indicate a new slot has started

We should add a Dockerfile that containerizes the application to make it easier to run.

In particular this Dockerfile should include installation of gofer and all required configuration.

Currently we interface with the gofer tool by executing a cli command from rust.
This is inefficient as well as brittle and probably should be changed.

One way to do it would be to call the json_rpc endpoint of the gofer agent service.
In this context we should also revisit the handling of gofer configuration / customization which is currently saved in config.hcl in the top level of this repo.

Currently there are way to many expect and unwrap calls in the code leading to panic / crash if anything goes wrong.

We should implement proper error handling that makes sure we recover from any recoverable error and enable transparent debugging.

Probably has some overlap with #5

Currently for the message_broadcaster we only have a dummy placeholder that just prints the messages to stdout.

Instead we need an implementation that reports the messages to our server (or some p2p network in the future).

This Probably depends on finishing #3 first