diadata-org / dia-oracle-anchor Goto Github PK

From the perspective of another contract that will be using the oracle data, it will have to add it (the oracle contract) as its dependency - ink_as_dependency feature in Cargo.toml - in its current state, the whole contract will be "pulled in" as dependency, including the "setters", all events etc.

You can consider splitting the interface into two traits - "getters" and "setters" - which would enable users to depend on just part of the interface.

Looking at the code, it's clear that only an "owner" or an "updater" can change the state of the Oracle. Access is based on the comparison of caller's public key (account ID).

This means that the design has a single point of failure which can lead to number of problems:

1. if that key is lost or binary/process/machine that updates the prices goes offline - the Oracle stops updating.
2. if single key is compromised the Oracle can get updated with wrong prices, cause liquidations or other problems

Do you plan on using a multisignature account here?

Please add an example usage of the Oracle contract - i.e. another contract that reads the feeds.

Why did you decide to index price field in the event here https://github.com/diadata-org/dia-oracle-anchor/blob/main/contracts/lib.rs#L36 ?

In line https://github.com/diadata-org/dia-oracle-anchor/blob/main/contracts/lib.rs#L108

you return precision from a function. The number is never used, can you explain what is it for? If it's required to stay, please extract to a const and add appropriate comments.

There is no continuous integration set up for this repo and it should be. You can't even tell if code is compiling or tests are passing after new changes are made to the contracts.

If we want to evolve the contract in the future, without changing its address, contract needs to be upgradable.

There are various patterns available:

• proxy
• diamond pattern
• set_code_hash

The first two require custom code (provided by library like OpenBrush) while the last one is built-in into ink! itself.

We, as Aleph Zero team, are of opinion that we should stick with set_code_hash as it seems like the safest of the approaches (OB hasn't been audited yet and has a track record of various patterns not working as advertised - especially the upgradeability ones).

For reference, you can check this file https://github.com/Cardinal-Cryptography/aleph-node/blob/main/contracts/simple_dex/lib.rs

Note usage of Lazy<_> in the pattern as below:

struct MyContractData {
   a: u64,
   b: Mapping<String, u64>,
}

#[ink(storage)]
#[derive(Storage)]
struct MyContract {
   data: Lazy<MyContractData, ManualKey<_>>,
}

This decouples contract's data from its logic and allows for upgrading the latter w/o need to migrate the data.

In https://github.com/diadata-org/dia-oracle-anchor/blob/main/contracts/lib.rs#L13 you're using Vec<(u64, u128)> as a value in the Mapping -- ink vectors don't work the same way they do in Solidity - they're (de)serialized as one big blog and stored as such. They should never be used for collections that can grow uncontrollably. Here, the vector represents price change over time and data is appended to the end of it. In the extreme case, you will grow vector so big that it won't fit into VM's sandboxed memory anymore and the contract will be bricked (until someone clears its storage via upgrade of some sort).

I'm not suggesting any specific alternative to this on purpose - leaving that decision to you. If you need help, reach out.