vnavascues / direct-request-coordinator Goto Github PK

This way each node operator could use either an existing one (very generic) or a customised one.
This probably requires another approach with FeeType enum at DRCoordinator level, making it just an internal uint8 (with its external getter/setter).

• Include filename in logger template (parentLogger -> child logger approach).
• Make sure datetime is displayed as ISO 8061 (e.g. YYYY-MM-DDThh:mm:ssZ) instead of UNIX timestamp.

This task should be split into several-sub tasks:

• Remove unnecessary tests (i.e. fallback ones once DRCoordinator inherits from Operator).
• Evaluate which existing ones should be unit tests and convert them.
• Consider adopting the approach of 1 assert per test.
• Add missing ones
• Run a fuzzer
• Fix coverage

Something along these lines:

contracts/
    - chainlink/
    - drcoordinator/
    |    - v0.8/
    |    |    - consumers/
    |    |    - dev/
    |    |    - interfaces/
    |    |    - libraries/
    |    |    |    - external/
    |    |    |    - internal/
    |    |    - tests/

Custom type bignumber is already supported, but bignumberArray not. Do it.

Few may be subject to gas costs and/or redundancy reading events. By topic:

• LINK:
  • LINK in escrow (pending requests)
• Spec:
  • Number of requests per Spec and/or last time it was requested
  • Whether the Spec has a dynamic result (a boolean in the Spec struct)

Making DRCoordinator derive from Operator implies:

• Extend parent contract with the genuine DRCoordinator logic (e.g. config, Spec management, LINK payment amount, subscription).
• Implement drcoordinatorRequest(). Explore getting rid of validateFromLINK() and the necessity of LINK.transferAndCall() thanks to subscription support. Try to be consistent and still emit an OracleRequest event, which means gasLimit, minConfirmations and any other future on-demand param should be CBOR encoded in data. Alternatively consider using a specific event (i.e. event DRCoordinatorRequest(...) that may include a struct).
  • DRCoordinator could also support processing DRCoordinator requests via LINK.transferAndCall(), however it wouldn't be a priority. It would require though a bytes4 private constant DRCOORDINATOR_REQUEST_SELECTOR = this.drCoordinatorRequest.selector;, etc.
• Rename fulfillData() as fulfillDRCoordinatorRequest() (aligned with fulfillOracleRequest() and fulfillOracleRequest2()), and finally have a strong reason to remove all the fulfill-via-fallback() implementation. Off-chain and on-chain fulfillment steps will be simplified. TOML spec won't need the double encoding used on the fulfillData() case, and will call fulfillDRCoordinatorRequest() on the ethabiencode task. On-chain implementation will very much be like fulfillOracleRequest2().
• The relationship shifts from 1 DRCoordinator..N Operator to 1 DRCoordinator..1 Operator. Which means:
  • Spec struct does not need to store operator nor externalJobId. DRCoordinatorConsumer does not need to send Operator address, and DRCoordinator does not need to generate and check a Spec key. A Spec key is now externalJobId.
• DRCoordinatorConsumer library (which should currently be an abstract contract) will be affected too. Sending a DRCoordinator request via LINK.transferAndCall() won't be needed on subscription model. But again, for flexibility reasons, it may be supported as well.

Advantages:

• No hops/bouncing/middle-man.
• A single "operator" contract to deploy, which supports standard oracle and operator requests as well.
• Simpler TOML specs. DRCoordinator address will be set in contractAddress, and not in requesters (free to use/properly whitelist msg.sender(s)). And no need for double encoding.
• Simpler JSON specs: operator is not needed.
• Allegedly cheaper deployments, requests, requests fulfillment and CUD specs (less data stored on-chain).

Disadvantages:

• I have to prove no LINK transfer is needed to initiate directrequest jobs (e.g. he CL node does validate that an OracleRequest event proceeded a LINK.transferAndCall()). Also testing other events than OracleRequest.
• Without a LINK.transferAndCall() between the requester and the DRCoordinator (and even cheaper requests), it would be good to have a more thorough thought with regards to TOML spec payment and spamming protection. Just as an extreme example, in the most defensive scenario DRCoordinator could charge the whole MAX LINK payment and make a refund after fulfilling the request.

This issue relates to #12

After making DRCoordinator inherit from Operator (#6) the easiest & cheapest way of whitelisting callers per Spec will be via the TOML Spec requesters field.

Consider whether an on-chain whitelisting would be interesting:

• A new property in the JSON Spec: configuration.requesters (an Array).

For sure not all the indexed parameters are needed, nor all the parameters.
We'll only know after plug it into the monitoring system and observe for a while.

Deploy & setup scripts (incl. docs), tests, etc.

Calculate weiPerUnitLink via LINK / USD + TKN / USD on networks where the LINK / TKN price feed is not available yet. Consider enabling this mode at constructor level (and flag it). Make variable names generic, e.g. PRICE_FEED_1, PRICE_FEED_2 as the former will be used either as LINK_TKN_FEED or LINK_USD_FEED.

Fetch Chainlink Price Feed addresses via ENS integration

Current logic is:

• Very Infura & private key specific.
• There is no fallback/rotation mechanism for providers.
• HD Wallet config is hard coded

If they are included into the mix, the first approach would be that either way it should end up returning the fallbackWeiPerUnitLink