Assigned: Chainsight BNT-1 - Asset Rating Oracle

Developers Bounties & RFPs
41

No one on the Team saw this issue.
-vvv can be given to reduce the level of log output.

42

@darroze @megared @hawk

Do you have a completed example of the snapshot_indexer_evm logic?

For instance, how would this look when completed, based on the corresponding manifest: https://github.com/horizonx-tech/chainsight-showcase/blob/main/old/volatility_oracle/src/logics/uniswap_snapshotter_mainnet/src/lib.rs ?

1 Like
43

Sorry for the late confirmation.
How about this one?

For snapshot_indexer_evm, there is no need to modify the logics under “src”

44

OK. So should lib.rs in this folder just be an empty file?

45

It should not be a problem.
If something is written in logics, it will not be used in the canister code.
However, you must not leave a description that would cause a compile error.

46

We may have identified an event similar to this one.
Perhaps you have added some ic_cdk::query in logics?
If that is the case, it may fail at that log timing.
(Not sure why there is no error log, though.)

Also, try the following command

cd src && cargo build --target wasm32-unknown-unknown --workspace
47

Thanks for the advice. I didn’t have ic_cdk::query in there anywhere, but I’ll try re-generating the evm logic and leaving it unmodified as you’ve suggested.

1 Like
48

I’ve regenerated the logic from scratch. This required doing csx generate a few times with tweaks in between. I’ve edited the logic for the algorithm lens and http snapshots. My code is at GitHub - timk11/uniswap-edpr.

I’m now getting this set of errors when using csx generate.

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:17:50
   |
17 |     let fees_24h_usd = pool_fees_result.unwrap().result[0].fees_24h_usd;
   |                                                  ^^^^^^ unknown field

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:19:57
   |
19 |     let t0_price_usd  = pool_usd_prices_result.unwrap().result.t0_price_usd;
   |                                                         ^^^^^^ unknown field

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:20:57
   |
20 |     let t1_price_usd  = pool_usd_prices_result.unwrap().result.t1_price_usd;
   |                                                         ^^^^^^ unknown field

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:22:42
   |
22 |     let address = v3pool_result.unwrap().result.address;
   |                                          ^^^^^^ unknown field

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:23:57
   |
23 |     let current_tick_liquidity = v3pool_result.unwrap().result.liquidity;
   |                                                         ^^^^^^ unknown field

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:24:49
   |
24 |     let sqrt_ratio_x96 = v3pool_result.unwrap().result.sqrt_ratio_x96;
   |                                                 ^^^^^^ unknown field

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:25:47
   |
25 |     let tick_current = v3pool_result.unwrap().result.tick_current;
   |                                               ^^^^^^ unknown field

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:26:47
   |
26 |     let tick_spacing = v3pool_result.unwrap().result.tick_spacing;
   |                                               ^^^^^^ unknown field

error[E0609]: no field `result` on type `std::string::String`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:27:40
   |
27 |     let ticks = v3pool_result.unwrap().result.ticks; // might need to fix this
   |                                        ^^^^^^ unknown field

error[E0277]: the type `std::string::String` cannot be indexed by `{integer}`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:29:28
   |
29 |     let tick_cumul_28x6h = tc28x6_result.unwrap()[0];
   |                            ^^^^^^^^^^^^^^^^^^^^^^^^^ `std::string::String` cannot be indexed by `{integer}`
   |
   = help: the trait `Index<{integer}>` is not implemented for `std::string::String`
   = help: the following other types implement trait `Index<Idx>`:
             <std::string::String as Index<RangeFull>>
             <std::string::String as Index<std::ops::Range<usize>>>
             <std::string::String as Index<RangeFrom<usize>>>
             <std::string::String as Index<RangeTo<usize>>>
             <std::string::String as Index<RangeInclusive<usize>>>
             <std::string::String as Index<RangeToInclusive<usize>>>

error[E0277]: the type `std::string::String` cannot be indexed by `{integer}`
  --> logics/usdceth_0_3_algorithm_lens/src/lib.rs:30:26
   |
30 |     let tick_cumul_30m = tc30_result.unwrap()[0];
   |                          ^^^^^^^^^^^^^^^^^^^^^^^ `std::string::String` cannot be indexed by `{integer}`
   |
   = help: the trait `Index<{integer}>` is not implemented for `std::string::String`
   = help: the following other types implement trait `Index<Idx>`:
             <std::string::String as Index<RangeFull>>
             <std::string::String as Index<std::ops::Range<usize>>>
             <std::string::String as Index<RangeFrom<usize>>>
             <std::string::String as Index<RangeTo<usize>>>
             <std::string::String as Index<RangeInclusive<usize>>>
             <std::string::String as Index<RangeToInclusive<usize>>>

Some errors have detailed explanations: E0277, E0609.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `usdceth_0_3_algorithm_lens` (lib) due to 11 previous errors

It seems that the “_result” values in the algorithm lens code are being returned as strings, and therefore can’t be indexed. As far as I can see my code matches the examples, so can you advise what might have gone wrong here?

49

I have checked your repository and it seems incomplete to understand the situation.

I’d like to see .chainsight placed as well.

The manifest in project.yaml didn’t seem to be there (project.yaml may not be up to date)

I thought perhaps you were having trouble with the algorithm_lens generated by usdceth_0_3_algorithm_lens.yaml.

[1] Please check the function of the caller canister you want to specify in datasource.methods.

(is “get_last_snapshot_value : () → (text)” correct?)

If it is in your own project, you can check it in .did under src/canisters/(component_name). If you want to use a function that is already deployed on the chainsight platform, you can check the .did from the icp dashboard.

[2] The format of the manifest for type=algorithm_lens is also likely to be wrong.

At least algorithm_lens does not have an output field.

See around the following.

The manifest version also looks old.

Since we have recently updated management-canister, it would be helpful if you could update the cli and proceed.

50

Thanks @megared. That helped a lot! I’ve committed all my changes to GitHub now and updated the algorithm lens manifest to match the current specification. I did csx generate a few times, swapping the order of components in project.yaml to ensure that all the relevant pieces of code got generated in spite of errors, then updated the functions in usdceth_0_3_algorithm_lens.yaml based on the .did files as you described.

Those parts all work now, so I’m now just going through and fixing up the rest of the algorithm lens logic.

51

Great!
I also seemed to be able to generate except for usdceth_0_3_algorithm_lens.
Please feel free to contact me if you have any questions.

1 Like
52

I’ve now managed to fix all the remaining errors so that the full project generates and builds successfully, and updated the repo accordingly.

I’m having some trouble deploying chainsight-management-canisters in order to deploy the project locally. Here’s an abbreviated version of the dialogue showing what I’ve tried and the resulting errors:

:~/ic/chainsight-management-canisters$ dfx start --clean --background
Running dfx start for version 0.15.2
Using project-specific network 'local' defined in /home/timk/ic/chainsight-management-canisters/dfx.json
Initialized replica.
Dashboard: http://localhost:40285/_/dashboard

:~/ic/chainsight-management-canisters$ make local port=40285
Error: Failed while trying to build all canisters.
Caused by: Failed while trying to build all canisters.
  The build step failed for canister 'uh54g-lyaaa-aaaal-achca-cai' (_management_canister_registry) with an embedded error: Failed to build Motoko canister '_management_canister_registry'.: Failed to load package arguments.: Failed to invoke the package tool "vessel" "sources"
 the error was: No such file or directory (os error 2)
make[2]: *** [Makefile:14: build] Error 255
make[2]: Leaving directory '/home/timk/ic/chainsight-management-canisters'
make[1]: *** [Makefile:27: create-build] Error 2
make[1]: Leaving directory '/home/timk/ic/chainsight-management-canisters'
make: *** [Makefile:36: local] Error 2

[I followed the advice from https://forum.dfinity.org/t/hi-everyone-i-am-facing-this-error-please-help-me/16302 and steps in https://github.com/dfinity/vessel in order to solve this.]

:~/ic/chainsight-management-canisters$ vessel init
Error: Failed to initialize, there is an existing package-set.dhall file here

:~/ic/chainsight-management-canisters$ make local port=40285
The authenticity of host 'github.com (20.248.137.48)' can't be established.
ED25519 key fingerprint is SHA256:+-----------------------------------------.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Error: Failed while trying to build all canisters.
Caused by: Failed while trying to build all canisters.
  The build step failed for canister 'uh54g-lyaaa-aaaal-achca-cai' (_management_canister_registry) with an embedded error: Failed to build Motoko canister '_management_canister_registry'.: Failed to load package arguments.: The command '"vessel" "sources"' failed with exit status 'exit status: 1'.
Stdout:

Stderr:
[INFO] Installing 9 packages
[INFO] Downloading tar-ball: "base"
[INFO] Downloading tar-ball: "btree"
[INFO] Cloning git repository: "candb"
Error: Failed to clone the repo at: git@github.com:canscale/CanDB.git
with:
Cloning into 'repo'...
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

make[2]: *** [Makefile:14: build] Error 255
make[2]: Leaving directory '/home/timk/ic/chainsight-management-canisters'
make[1]: *** [Makefile:27: create-build] Error 2
make[1]: Leaving directory '/home/timk/ic/chainsight-management-canisters'
make: *** [Makefile:36: local] Error 2

The full dialogue is at https://cmc-dlg.tiiny.site/.

What could be going wrong here?

53

Sorry I’m late.
I cloned chainsight-management-canister again and ran dfx start followed by make local with no problems.
There may be something wrong with the local environment on motoko, or it may be a network setting.

Regarding the network settings, I have specified 127.0.0.1:8000 in the repo’s dfx.json. Why don’t you run the following?

dfx start --clean --background
dfx ping http://localhost:8000
make local port=8000

I also could not see the link to the log you attached.
It would be better to post the log as a file.

Thank you.

54

No problem, and thanks for the further advice.

I re-synced chainsight-management-canisters to the current version and ran it using port=8000 as you suggested. I’m still getting some similar errors. On the first try I got this:

Error: Failed while trying to build all canisters.
Caused by: Failed while trying to build all canisters.
  The build step failed for canister 'uh54g-lyaaa-aaaal-achca-cai' (_management_canister_registry) with an embedded error: Failed to build Motoko canister '_management_canister_registry'.: Failed to load package arguments.: The command '"vessel" "sources"' failed with exit status 'exit status: 1'.
Stdout:

Stderr:
[INFO] Installing 9 packages
[INFO] Cloning git repository: "candb"
Error: Failed to clone the repo at: git@github.com:canscale/CanDB.git
with:
Cloning into 'repo'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


make[2]: *** [Makefile:14: build] Error 255
make[2]: Leaving directory '/home/timk/ic/chainsight-management-canisters'
make[1]: *** [Makefile:27: create-build] Error 2
make[1]: Leaving directory '/home/timk/ic/chainsight-management-canisters'
make: *** [Makefile:36: local] Error 2

On the basis of this post I changed these lines in my local copy from
   , repo = "git@github.com:canscale/CanDB.git" , version = "beta"
to
   , repo = "https://github.com/ORIGYN-SA/CanDB" , version = "1.0.2".
(The version number is from here. I don’t know if I’ve understood this correctly.)

I then got much the same error, except for this part:

Stderr:
[INFO] Installing 9 packages
[INFO] Downloading tar-ball: "candb"
[WARN] Downloading tar-ball failed, cloning as git repo instead: "candb"
Error: Failed to checkout version 1.0.2 for the repo at: https://github.com/ORIGYN-SA/CanDB
with:
error: pathspec '1.0.2' did not match any file(s) known to git

@icme - I’ve tagged you here as well in case you have any advice on this. Any pointers would be gratefully received. Let me know if more context is needed.

Update

I have it working now. Within package-set.dhall I changed

  { name = "candb"
  , repo = "git@github.com:canscale/CanDB.git"
  , version = "beta"
  , dependencies = [ "base" ]
  },
  { name = "candy"
  , repo = "git@github.com:icdevs/candy_library.git"
  , version = "0.2.0"
  , dependencies = [ "base" ]
  },

to

  { name = "candb"
  , repo = "https://github.com/ORIGYN-SA/CanDB.git"
  , version = "beta"
  , dependencies = [ "base" ]
  },
  { name = "candy"
  , repo = "https://github.com/icdevs/candy_library.git"
  , version = "0.2.0"
  , dependencies = [ "base" ]
  },
1 Like
55

I had some further trouble with chainsight-management-canisters. It worked once only and then not again, so I moved on to deploying my single-asset prototype to the mainnet. csx deploy --network ic was successful. When I got to csx exec --network ic I had to run it a few times as cycles needed to be topped up. After topping up I got this error:

Error: Failet to do wallet call.
Caused by: Failet to do wallet call.
  An error happened during the call: 5: IC0503: Canister sftde-kqaaa-aaaag-qcwmq-cai trapped explicitly: Panicked at 'Already initialized', canisters/pool_usd_prices/src/lib.rs:1:68
occured on /home/timk/ic/csx/uniswap-edpr/artifacts/scripts/components/pool_usd_prices.sh [Line 3]
command: dfx canister --network ic call pool_usd_prices init_in '(variant { "Production" }, record {
                refueling_interval = 86400: nat64;
                vault_intial_supply = 1000000000000: nat;
                indexer = record {
                    initial_supply = 0: nat;
                    refueling_amount = 1000000000000: nat;
                    refueling_threshold = 500000000000: nat;
                };
                db = record {
                    initial_supply = 1500000000000: nat;
                    refueling_amount = 1000000000000: nat;
                    refueling_threshold = 500000000000: nat;
                };
                proxy = record {
                    initial_supply = 300000000000: nat;
                    refueling_amount = 100000000000: nat;
                    refueling_threshold = 100000000000: nat;
                };
        })' --with-cycles 2800000000000 --wallet $(dfx identity get-wallet --network ic)

(stdout at run time)
Run script for pool_usd_prices

This seems to suggest that the csx exec command is unable to pick up where it left off in the way that dfx deploy would. Is this something that needs to be fixed up at your end or is there something that I can do differently?

56

Hi.
In previous versions of cli this could happen, but it was supposed to be resolved now.

If you can provide me all the canister_ids in the project you deployed, I might be able to help.
(Or you could just update your github to the latest version.)

Also, have you already completed the other components?
You can use csx exec -c to specify components and run them individually.

57

I tried csx exec -c and that worked! I’ve also updated the cli.

I think I now have the full project ready to deploy to the mainnet. There are now 4 trading pairs to be snapshotted and I’ve updated the repo with this version. I deleted the canisters I previously deployed so as to get my cycles refunded, and I’ve now deployed and executed one component from the completed project as follows:

Current deployed status:
Canister Name: eth_usdc_price
  Canister Id: {"ic": "wgakw-caaaa-aaaag-qcwxq-cai"}

The full project consists of 21 components. Should I now just go ahead and run csx deploy and csx exec on all of them? It looks like deploying and executing combined cost 6T cycles per component. Is there a way to set this at a lower level so as to reduce the expenditure?

58

great!

If you want to reduce the amount of cycles consumed during deployment, you need to customize the operations performed on canister during exec execution.
I’m sorry that we are currently unable to provide a convenient function for this and that it is a relatively difficult operation…

If you look at csx exec --help, you will see the --only-generate-cmds and --only-execute-cmds options.
The general flow is in the following order
[1] csx exec --only-generate-cmd
[2] Execution command driven modification
[3] csx exec --only-execute-cmd

[2] Execution command driven modification

After step [1], (pr_root)/artifacts/scripts/components/(component_name).sh is generated.
The values set for vault_intial_supply, multiple initial_supplies, and --with-cycles in the arguments of the init_in function call in this command are directly related to cycle.
Since -with-cycles is the component itself that actually does the processing, it is better to leave a relatively large amount of -with-cycles, but overall, 1/2 (or even 1/3) may be okay. I think the default setting is to use about 1 canister 3T cycles, so 1/2 should be enough to keep it to that level.

59

No problem! I tried those steps, but there are still a few hitches along the way.

I ran csx exec --network ic --only-generate-cmds then went through all the .sh files and edited initial_supply (3 per file) and --with-cycles to half the original values.

csx deploy --network ic still required me to delete the eth_usdc_price canister that I had already deployed, and then worked fine but still used 3T cycles per canister.

I then ran csx exec --network ic --only-execute-cmds on each component but it kept telling me there was no wasm module:

Error: Failet to do wallet call.
Caused by: Failet to do wallet call.
  An error happened during the call: 3: IC0304: Attempt to execute a message on canister 6peu2-iqaaa-aaaag-qcxaq-cai which contains no Wasm module
occured on /home/timk/ic/csx/edpr_full/uniswap-edpr/artifacts/scripts/components/usdc_eth_0_3_v3pool.sh [Line 3]

I then did cd artifacts and dfx deploy --network ic.

csx exec --only-execute-cmds --network ic -c eth_usdc_price then gave me:

Error: Failet to do wallet call.
Caused by: Failet to do wallet call.
  An error happened during the call: 5: IC0503: Canister uo2vt-qaaaa-aaaag-qcw3q-cai trapped explicitly: Panicked at 'called `Result::unwrap()` on an `Err` value: (CanisterError, "IC0503: Canister xkzfe-fiaaa-aaaal-qcnuq-cai trapped explicitly: Panicked at 'called `Result::unwrap()` on an `Err` value: (CanisterError, \"Only the controllers of the canister uo2vt-qaaaa-aaaag-qcw3q-cai can control it.

I then added controllers and csx exec --only-execute-cmds --network ic -c eth_usdc_price (for which I had not edited any values) seemed to work fine.

Running csx exec --only-execute-cmds --network ic -c on each component then gave me:

Error: Failet to do wallet call.
Caused by: Failet to do wallet call.
  An error happened during the call: 5: IC0503: Canister vrsge-tyaaa-aaaag-qcw7a-cai trapped explicitly: Panicked at 'called `Result::unwrap()` on an `Err` value: (CanisterError, "IC0503: Canister xkzfe-fiaaa-aaaal-qcnuq-cai trapped explicitly: Panicked at 'Acceptable cycles are less than the specified in parameters.', src/canisters/initializer/src/lib.rs:48:9")', /home/timk/.cargo/git/checkouts/chainsight-sdk-ebe15f3a50378c5f/6e55b5e/chainsight-cdk/src/initializer/chainsight_initializer.rs:38:23

In spite of this, it still seemed to spend the number of cycles I had designated for each component.

I then re-ran csx exec --only-generate-cmds --network ic and edited only the --with-cycles value in each .sh file (from 2.8T to 1.25T).

I then ran csx exec --only-execute-cmds --network ic -c on a group of 6 components. Once again it spent the designated amount of cycles but did not seem to successfully execute the components. I’m still having the problem (mentioned in post 37 above) where the cli output seems to progress part way and then give up, so it wasn’t clear whether execution was succeeding for some of the components.

image
image1753×715 158 KB

Apologies for these very long posts, but I’m hoping that this might also help the team flag issues for attention as development progresses. In summary, the current problems are:

  • canister wasm’s not being generated or not being recognised as such
  • csx deploy won’t run in full if some canisters are already deployed
  • canister controllers are not being registered properly
  • csx exec --only-execute-cmds won’t tolerate manual changes to cycle expenditure
  • csx exec consumes cycles even when execution is unsuccessful

Also, is there a way for me to check which components have been successfully executed?

I don’t mind spending the full amount of cycles if that’s what’s needed, but is there a way to unlock and refund cycles that have been used in unsuccessful execution attempts? For now I’ll just press on. :slight_smile:

60

Completed project:

EDPR for Uniswap V3 pairs

This tool is intended to calculate an Estimated Daily Percentage Return (EDPR) for trading pairs on Uniswap V3, using a price range (set by the liquidity provider) approximately corresponding to the pair’s price range over the preceding week. Pairs currrently included are USDC/ETH, WBTC/ETH, RNDR/ETH and VRA/ETH.

Feedback:

  • Overall the CLI functions well and the documentation on this page is very well presented. However I would suggest making the documentation a bit more noob-friendly for the benefit of new users like myself.
  • In particular, it’s worth including all the cd commands in the set-up instructions in order to make it very clear which commands happen in which folders.
  • The team is obviously very active with developing and updating the CLI. Just be sure that the documentation examples keep up with this. (It’s very possible that they did, but it was just me not keeping up!) Also add snapshot_indexer_https to these, as this is used frequently and has changed a bit since I first used it.
  • A few misspellings in CLI output messages - e.g. “succeeded”, “failed”
  • I’m hoping that my various posts above can also serve as feedback on issues that I had trouble with, that might also be encountered by other users.
  • Happy to chat further about feedback if you would like.
2 Likes