8000 Allow configuring initial validators in the HC config by dincho · Pull Request #4542 · aeternity/aeternity · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Allow configuring initial validators in the HC config #4542

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Feb 10, 2025

Conversation

dincho
Copy link
Member
@dincho dincho commented Feb 4, 2025

No description provided.

@dincho dincho requested review from hanssv and klercker February 4, 2025 13:43
klercker
klercker previously approved these changes Feb 4, 2025
Copy link
Contributor
@klercker klercker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks reasonable. I will let someone else decide if it's a good idea or not...

@hanssv
Copy link
Member
hanssv commented Feb 4, 2025

I think it would work. The best way to test it I guess would be to replace (part of) the validator config in hyperchains_SUITE with this.

However, this adds a third (fourth?) path for configuring validators, there is the web-app, directly through the NPM-thingie, and the directly with json file way already... 🤔

Comment on lines +465 to +467
Trees3 = initialize_validators(TxEnv, Trees2, initial_validators()),
Trees4 = init_epochs(TxEnv, Trees3, child_epoch_length(), pinning_reward_value()),
aect_call_state_tree:prune(0, Trees4).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The order here is debateable, but I guess the idea is to not have an overlap between json and config 😅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should work fine. Executing contracts.json first would keep the flexibility to have a custom contracts and initialize them before adding/initializing the validators from aeternity.yaml. That was my reason picking that order.

@dincho
Copy link
Member Author
dincho commented Feb 5, 2025

However, this adds a third (fourth?) path for configuring validators, there is the web-app, directly through the NPM-thingie, and the directly with json file way already... 🤔

The current workflow is indeed: web-app -> hyperchain-kit (CLI) -> contracts.json, while one can directly use the CLI.
The idea is to be able the get rid of the hyperchain-kit at all, web-app would mostly do "tokenomics"/configuration UI.
There are few ppl that can use the conracts.json directly. In general multiple configuration files lead to their own spectrum of issues.

That would dramatically simplify the process of initializing a Hyperchain, without any additional tools in a single configuration file.

Do you have any concerns adding this option in the node?

@dincho dincho force-pushed the initial_validators branch from 038052d to a2ed306 Compare February 5, 2025 13:42
@dincho dincho requested review from hanssv and klercker February 5, 2025 13:43
@dincho
Copy link
Member Author
dincho commented Feb 5, 2025

I wonder if I should add caller option as well to allow more flexible setups.
I could also make caller and sign_key optional defaulting to owner

@hanssv
Copy link
Member
hanssv commented Feb 5, 2025

Do you have any concerns adding this option in the node?

No, not at all!

@dincho dincho merged commit dd6f930 into master Feb 10, 2025
40 checks passed
@dincho dincho deleted the initial_validators branch February 10, 2025 09:22
mitchelli pushed a commit that referenced this pull request Feb 13, 2025
* Allow configuring initial validators in the HC config
* Add initial_validators test
@dincho dincho added the kind/feature Issues or PRs related to a new feature label Feb 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Issues or PRs related to a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0