NO-TICKET: add example config file#68
Conversation
|
Just realized about yet another thing necessary to have the node running – passing in the chainspec data to the Contract Runtime. |
resources/example/chainspec.toml
Outdated
| # 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 |
There was a problem hiding this comment.
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.
resources/example/chainspec.toml
Outdated
| 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. |
There was a problem hiding this comment.
| # 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. |
That's already implemented. We have a separate |
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>
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
[storage.path]handling to accommodate env vars in the path string (e.g.$HOME/.local/...)