Skip to content

NO-TICKET: add example config file#68

Merged
Fraser999 merged 5 commits intocasper-network:masterfrom
Fraser999:NO-TICKET-config
Jul 10, 2020
Merged

NO-TICKET: add example config file#68
Fraser999 merged 5 commits intocasper-network:masterfrom
Fraser999:NO-TICKET-config

Conversation

@Fraser999
Copy link
Contributor

@Fraser999 Fraser999 commented Jul 10, 2020

  • added a commented example config file along with a test which parses it to try and ensure it is kept updated
  • added a commented example chainspec file along with a test which parses it to try and ensure it is kept updated
  • updated the README to match the current required command line args
  • updated the [storage.path] handling to accommodate env vars in the path string (e.g. $HOME/.local/...)
  • made some config file fields optional
  • enabled all tests and cargo audit in CI
  • various other cleanups

@goral09
Copy link
Contributor

goral09 commented Jul 10, 2020

Just realized about yet another thing necessary to have the node running – passing in the chainspec data to the Contract Runtime.

# 172800000 ms = 2 days.
voting_period_duration_millis = 172800000
# Alternative voting duration based on the finality level of the switch block; effective if it's non-zero.
voting_period_summit_level = 0
Copy link
Contributor

Choose a reason for hiding this comment

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

The current code finds all summits of any level*, so I'd remove this option for now. We can add it back if we have to limit this for performance reasons, but I hope we won't.

(*) Well, up to level 64, but higher levels make a negligible difference.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK - thanks

voting_period_duration_millis = 172800000
# Alternative voting duration based on the finality level of the switch block; effective if it's non-zero.
voting_period_summit_level = 0
# Integer between 0 and 50 representing the fault tolerance threshold as a percentage, used by the internal finalizer.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
# Integer between 0 and 50 representing the fault tolerance threshold as a percentage, used by the internal finalizer.
# Integer between 0 and 99 representing the fault tolerance threshold as a percentage, used by the internal finalizer.

@Fraser999
Copy link
Contributor Author

@goral09

passing in the chainspec data to the Contract Runtime.

That's already implemented. We have a separate initializer reactor which runs on startup instead of the validator one. It reads in the chainspec, stores it, and calls commit_genesis on the contract runtime. Once that's completed, the validator reactor is started, and normal operations begin.

@Fraser999 Fraser999 merged commit 0807ff0 into casper-network:master Jul 10, 2020
@Fraser999 Fraser999 deleted the NO-TICKET-config branch July 10, 2020 09:47
dwerner pushed a commit to dwerner/casper-node that referenced this pull request Apr 4, 2022
68: ZH-ENG-I2767: Wire up upgrade scenario 10 for nightly. r=TomVasile a=TomVasile

Changes:
- adjusts path selection to LMDB files for using an older starting version (1.3.0 in this case).
- renames `regression_scenario_01.sh` -> `upgrade_scenario_10.sh`
- adds  `upgrade_scenario_10.sh` to nightly NCTL tests
- removes unneeded client function and `accounts.toml` from `upgrade_scenario_10.sh`
    - looks like it was a copy paste issue

Unrelated Change:
- `upgrade_scenario_01.sh` & `upgrade_scenario_03.sh`: Ties in with the last point above, code is no longer needed.

Ticket: https://app.zenhub.com/workspaces/engineering-60953fafb1945f0011a3592d/issues/casper-network/casper-node/2767

Co-authored-by: TomVasile <43349666+TomVasile@users.noreply.github.com>
rafal-ch pushed a commit that referenced this pull request Sep 11, 2024
The instruction executors are duplicated into different implementations
that either support the interpreter storage or don't. The latter is used
for predicate verification since contract opcodes, the only ones that
performs storage calls, aren't allowed.

This duplication will lead to harder long-term maintenance and should be
avoided.

The alternative introduced in this PR is to have a concrete storage
implementation that will deny any storage call, and introduce a check
for each instruction to evaluate if its predicate verification and if
the opcode is allowed for predicates.

This is sub-optimal because we introduce an extra branching per VM
cycle, but it can easily be refactored later to perform a couple of
bitwise operations after fuel-asm #68 is done.

Closes #133
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants