Unable to remove parachain lock on Relaychain with a Parachain owner. #760
Comments
|
This was done on purpose. If the parachain is controlled by some central entity, you can send the appropriate upward message to unlock it. In general the approach should be that teams are taking more care about what they are doing. |
Is this true even if the parachain is not producing blocks? |
claravanstaden
pushed a commit
to Snowfork/polkadot-sdk
that referenced
this issue
Dec 8, 2023
* Add nix env * foo * cowsay * Get working on MacOs * Get working on MacOs * fix * change * foo * Apply suggestions from code review Co-authored-by: David Dunn <26876072+doubledup@users.noreply.github.com> * Preserve local shell in nix-shell instructions * Set clang path for rocksdb * Set POLKADOT_DIR in envrc template We can use POLKADOT_DIR to get POLKADOT_BIN, but if we only set POLKADOT_BIN we'll end up rebuilding Polkadot with a fresh clone. * Use direnv to automatically enter nix-shell * Explain use of LIBCLANG_PATH * Lock nixpkgs hash * Avoid impure overlays & config on import * Remove redundant pkgs * Add initial flake definition * Add export to commented env vars Without export, uncommenting these lines silently does nothing. * Source root envrc in subdirectories * Tweak README * Move root envrc to an example file * Don't require .envrc in project root * Set up Rust and system compatibility * List supported systems explicitly * Remove clang package & comment out other unused dependencies * Suppress successful pre-commit hook output * Whitespace * added cacert and LD_PATH to flake.nix * Switch local eth env to ipv6 Gets rid of the /etc/hosts hack to prevent lodestar hanging. * Mark commands as shell in markdown * Use source_up_if_exists in envrc templates * Re-add some dependencies needed by a pure shell * Update packages & set HOME * REVERTME Use cargo install for polkadot binary * Remove commented exports * Default to locally installed polkadot binary * Add rust-toolchain.toml * Move polkadot install to parachain directory * Match Rust nightly used for polkadot 0.9.30 * Changed parachain build dir * Wrap all builds in single cd call * Fix path to polkadot binary * Add note for stable channel * Fix relay chain bin in zombienet config * Point lodestar directly to geth's ipv6 addresses * Whitespace & sorting * Switch eth services to ipv4 * s/localhost/127.0.0.1/g, except hardhat's localhost * Move `cargo install polkadot` into build script * Indent launch-config like example config files * Create polkadot version directories when absent * added ps to nix env for zombienet on linux * Add explanation for ps nix package * Add explanation for LIBCLANG_PATH * Remove unused packages * Remove redundant trues * Switch to nix-direnv * Add foundry overlay * Bump lockfiles * Bump workflow node version * Sync node versions to 18.13.0 * Bump node lockfile after merge * Use @zombienet/cli package * Increase logging in zombienet config * Add gpg for commit signing during foundry install * Track forge dependencies * Manual forge init Had to run `forge init . --force` because contracts/ isn't empty. The branch property was added to the submodule lib/forge-std, despite forge having just set up core/packages/contracts/lib/forge-std. Discarded the template github workflow & contracts. * forge install: ds-test * Remove shell.nix We're using flake.nix instead now. * Remove foundry Makefile This is already set up with Nix, except `forge test` which we can run ourselves. * Ensure forge dependencies are available * Use debug instead of release where possible For local, non-benchmark builds, use debug instead of release to compile faster. * Run Rust builds for host CPU only Binaries aren't portable, but build a bit faster. * Update all READMEs * Update test envrc template * Use debug builds of polkadot locally * Revert "Use debug builds of polkadot locally" This reverts commit 69586f64601656d9a548772b24828750c977c182. * Revert "Run Rust builds for host CPU only" This reverts commit d5fc39be237bcfae365cbb60fdae9871f7dad930. * Revert "Use debug instead of release where possible" This reverts commit ab1158b59e73b69beb8a7a464d2137d9b12685cb. * Clarify explanations in flake --------- Co-authored-by: David Dunn <26876072+doubledup@users.noreply.github.com> Co-authored-by: Alistair Singh <alistair.singh7@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This may be intentional, but I wanted to raise it here to clarify the reasoning behind this decision and my observation.
Issue paritytech/polkadot#5451 Manual Para Lock was created to allow teams to fix parachains by replacing validation code and other aspects at the early stages of a parachain without having to go through the Referendum process.
A prerequisite for this workaround which is due to be included in v0.9.31 of Polkadot is that the Parachain is unlocked first in order to perform tasks. A parachain is locked by default once it has been upgraded from a parathread to a parachain.
The procedure to apply a fix requires an upward message issued from the Parachain in order to release the lock as a first step.
https://github.com/paritytech/polkadot/blob/11221b5a5636e1896b63700767a5f2891643bbe7/runtime/common/src/paras_registrar.rs#L326-L335
However one of the aspects that teams have faced is that their parachains do not produce blocks. In other words they would be unable to execute an upward message from their parachain, which defeats the intention of the original issue. We have a slightly different issue, but essetially it prevents us from issuing an upward message even on a block-producing parachain.
The function should have the option to be executed directly on the Relachain side by changing this line
https://github.com/paritytech/polkadot/blob/11221b5a5636e1896b63700767a5f2891643bbe7/runtime/common/src/paras_registrar.rs#L332
to this:
It might be that one of the reasons for not allowing this, is so that parachain owners cannot simply unlock a parachain at will without some form of governance, and that Gov2 will allow shorter timeframes to resolution.
The text was updated successfully, but these errors were encountered: