Still allows custom message hasher, but ties together the crypto
types used for private+public keys and the signature.
Signed-off-by: acatangiu <adrian@parity.io>
* pre-checking: Reject failed PVFs
* paras: immediately reject any PVF that cannot reach a supermajority
* Make the `quorum` reject condition a bit more clear semantically
* Add comment
* Update implementer's guide
* Update a link
Not related to the rest of the PR, but I randomly noticed and fixed this.
* Update runtime/parachains/src/paras/tests.rs
Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com>
* Remove unneeded loop
* Log PVF retries using `info!`
* Change retry logs to `warn!` and add preparation failure log
* Log PVF execution failure
* Clarify why we reject failed PVFs
* Fix PVF reject runtime benchmarks
Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com>
* `IntegrityTest` implementation should be feature gated
The initial implementation for the old declarative macros is still feature gating the
implementation. As we only call this in a test, there is no need to have this compiled for wasm.
* Don't assume that all "consumers" have a `std` feature
* Refactor do_mint()
* Track the depositor of item's metadata
* Revert back the access control
* On collection destroy return the metadata deposit
* Clear the metadata on item burn returning the deposit
* Address comments
* Fix clippy
* Don't return Ok on non-existing attribute removal
* Removed `has_duplicates` check form the `deposit_event`.
Removed the usage of `Error::DuplicateTopics`.
* ".git/.scripts/commands/bench/bench.sh" pallet dev pallet_contracts
Co-authored-by: command-bot <>
* Switch to state V1 and add state-trie-migration pallet with dummy manual
account.
* Initialize limit on runtime upgrade.
* add prelude
* sp_std prelude only for no_std
* Disable filter for signed migration
* revert hex dep
* use NeverEnsureOrigin
* fix
* correct fix
* check init state in try-runtime
Co-authored-by: parity-processbot <>
* Use primitives reexported from `polkadot_primitives` crate root
* restart CI
* Fixes after merge
* update lockfile for {"polkadot", "substrate"}
Co-authored-by: parity-processbot <>
* Update UI tests for 1.66
* Fix `test_enum` assertion for Rust 1.66
* Fix another `test_enum` assertion for Rust 1.66
* Fix another `test_enum` assertion for Rust 1.66
* Fix another `test_enum` assertion for Rust 1.66
* Refactor `validate_block`
This pull request changes the `validate_block` implementation. One of the key changes are that we
free data structures as early as possible. The memory while validating the block is scarce and we
need to give as much as possible to the actual execution of the block. Besides that the pr moves the
validation of the `validation_data` into the `validate_block` implementation completely instead of
using this machinery with putting the data into some global variable that would then be read while
executing the block. There are also some new docs to explain the internals of `validate_block`.
* No clone wars!!
* Integrate more feedback
* FMT
* Delay the header encoding
* avoid unintentionally canceling the scheduled crate publishing job
because publish-crates and publish-crates-manual share the resource group
"crates-publishing", any instance of publish-crates-manual cancels a running
instance of publish-crates, as demonstrated by
https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2212179
a workaround for that unintended interaction is to avoid creating instances of
publish-crates-manual and instead require pipelines to be triggered manually by
checking $CI_JOB_MANUAL == "true"
* check manual pipelines by $CI_PIPELINE_SOURCE instead of $CI_JOB_MANUAL
* make crate-publishing pipelines uninterruptible
* use conditional includes to work around interruptible limitations
* organize comments
* remove interruptible from common pipeline
* wip: check include
* wip: check include
* fix include
* fix include
* fix include
* fix yaml
* fix yaml
* remove shared common-pipeline
* wip: retry common-pipeline
* move .default-template to .gitlab-ci.yml
* fix the pipeline
add comments
* fix default-pipeline.yml
* revert publish-crates-manual to when: manual
* move "needs:" back to publish-crates
* avoid manual repetition
* improve previous commit
* try to avoid manual repetition
* fix indentation
* minor adjustments
* move defaults to top of .gitlab-ci.yml
* fix positioning on default in the diff
* comments
* indentation
* Apply suggestions from code review
Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>
Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>
* Replace async-std with tokio in PVF subsystem
* Rework workers to use `select!` instead of a mutex
The improvement in code readability is more important than the thread overhead.
* Remove unnecessary `fuse`
* Add explanation for `expect()`
* Update node/core/pvf/src/worker_common.rs
Co-authored-by: Bastian Köcher <info@kchr.de>
* Update node/core/pvf/src/worker_common.rs
Co-authored-by: Bastian Köcher <info@kchr.de>
* Address some review comments
* Shutdown tokio runtime
* Run cargo fmt
* Add a small note about retries
* Fix up merge
* Rework `cpu_time_monitor_loop` to return when other thread finishes
* Add error string to PrepareError::IoErr variant
* Log when artifacts fail to prepare
* Fix `cpu_time_monitor_loop`; fix test
* Fix text
* Fix a couple of potential minor data races.
First data race was due to logging in the CPU monitor thread even if the
job (other thread) finished. It can technically finish before or after the log.
Maybe best would be to move this log to the `select!`s, where we are guaranteed
to have chosen the timed-out branch, although there would be a bit of
duplication.
Also, it was possible for this thread to complete before we executed
`finished_tx.send` in the other thread, which would trigger an error as the
receiver has already been dropped. And right now, such a spurious error from
`send` would be returned even if the job otherwise succeeded.
* Update Cargo.lock
Co-authored-by: Bastian Köcher <info@kchr.de>
https://github.com/paritytech/polkadot/pull/6494 updates disputes
participation priority on Active Leaves update. This operation might
trigger participation in some cases and as a result some of the message
ordering is not as nice as it used to be.
As a side effect of this `resume_dispute_without_local_statement` was
failing occasionally. The solution is not to expect that `BlockNumber`,
`CandidateEvents`, `FetchOnChainVotes` and `Ancestors` messages are
executed after `FinalizedBlockNumber` and in any specific order.
This should be okay as the code is in helper function and doesn't affect
the actual test behaviour.
Fixes https://github.com/paritytech/polkadot/issues/6514
* Remove the `RelaychainClient` trait
It was just some historical trait that isn't really required anymore. Besides that this pr re-exports
types that are being used by the relay chain interface to make its usage easier.
* Fix warning