Using CERES with controlled keyblocks generation time

VitalJeevanjot · July 29, 2022, 1:06pm

Greetings,

I am using ae_demode plugin as well. I was wondering what changes should i make in the plugin source code or aeternity node master code to use ae_devmode plugin to use operations available in CERES code.

Why ?
I want to control keyblocks from ae_devmode UI. And access it through ae-js-sdk

What tried so far ?

First I passed local_ceres_testnet as network id which runs the node but the keyblocks are generating so fast (100,000 in 10 minutes or something) which makes it useless for js-sdk as it gives error that waiting for 10 blocks for response (js-sdk is patched to recognize CERES as supported)…
I tried to change the consensus in aec_hard_forks.erl under protocols_from_network_id taking parameters <<ae_dev>> and (_ID) to pass CERES_VSN and then rebuilt it. The plugin integrated shows the UI perfectly but i got error error in poseidon: not_supported from the sdk script, which as Hanssv brings in to my knowledge that means i am not running CERES in this case.

Side Note: I will utilize unit tests when i look forward to implement MIMC in erlang but right now my focus is to use Poseidon in CERES to complete my ZKP Bounty, which requires availability of node for browser based…

The 2 paths i calculate now, if i am not mistaken any one can solve this:

Run CERES node but control key block generation from the code (time, like the height should increase by one after 3000 ms (3 sec) for example so running node shouldn’t full 1GB of hardisk instantly).
Use Ae_devmode plugin but not let it change the protocol to ae_dev or if it does then it should use ?CERES_PROTOCOL_VSN with correct changes in plugin erlang files or node erlang files.

(The node part here got nothing to do with docker anymore [just a side note]. I am just running node separately and js-sdk code to connect with it with a compiler with newer supported bytecode in different pod).

Please let me know if there is something useful information i can provide to follow this up apart from below.

Aeternity.yml file using to run node:

gist.github.com

https://gist.github.com/devindirt/31f4b358edfaf90ef527460d9c67c0a3

aeternity.yml

# chain:
#     persist: true
#     # db_path: ./my_db
#     hard_forks:
#       "1": 0
#       "6": 1

http:
  external:
    gas_limit: 60000000

This file has been truncated. show original

Most of the yml is from aeproject to assist with on_demand consensus.

VitalJeevanjot · July 29, 2022, 1:18pm

Please let me know where to make appropriate changes to make it work.

marco.chain · July 29, 2022, 1:49pm

I didn’t read the whole post but this statement is sth. I want to address. I don’t think your assumption here is correct. typically “waiting for 10 blocks” timeout in SDK is an indicator that your broadcasted tx is invalid and the node refuses it. to verify this please activate debug mode in the node and look into the node logs.

VitalJeevanjot · July 29, 2022, 4:17pm

You are right @marco.chain , but here the case is unusual with on_demand consensus and other parameters provided. After i increased the wait for block limit to 20k before giving transaction error (as blocks proceeding very fast), I started to get same NodeInvocationFailed, error in poseidon not_supported error.

That means even with setting local_ceres_testnet and other parameters, I still not running ceres.

Different aeternity yml which uses local_ceres_testnet as network id to run yaml for testnet ceres · GitHub

What should be done in this case ?