6

I have observed that not in every scenario the manager of the para is able to deregister the parathread. So I would like to gather here what are the scenarios where we can hit this, and their reasons.

3 Answers 3

5

In the end, this behavior is a bit annoying, but follows the principles of decentralized networks.

The "parachain lock" is used to identify when a parachain elevates from something "owned" by a user to something that itself is a decentralized entity.

For example, when doing registration, there is a registration owner, and someone who can manage that paracahin. But once it is open to a crowdloan, then you have potentially millions of users backing a project with their own capital, and the project no longer is owned by just one person, but actually all the crowdloan contributors.

Additionally, once a parachain creates a block, then it becomes something that is again, a decentralized network, and not something that should just be owned or managed by a central actor.

This is why you have to go to governance. Why should any one person be able to shut down or delete a decentralized parachain (once it is live)?

1
4

There is one clear scenario where the account who registered the para will not be able to deregister it, which is if this para has been onboarded as a parachain. This one is clearly stated in the source of deregister itself, where it checks for the lifecycle of the para to be Parathread - link to the code.

At the same time, when a parathread is onboarded as a parachain we can see a lock is applied.

// Upgrade a registered parathread into a parachain.
    fn make_parachain(id: ParaId) -> DispatchResult {
        // -- snip --
        // Once a para has upgraded to a parachain, it can no longer be managed by the owner.
        // Intentionally, the flag stays with the para even after downgrade.
        Self::apply_lock(id);
        Ok(())
    }

source. This lock prevents the manager to deregister the parathread by its own.

We can find another lock being applied when creating a crowdloan campaign. The paraId involved in the crowdloan will be locked, and so under the same restrictions for the manager of such parachain. We can find the code where the lock is applied this time here.

/// Create a new crowdloaning campaign for a parachain slot with the given lease period range.
///
/// This applies a lock to your parachain configuration, ensuring that it cannot be changed
/// by the parachain manager.
        #[pallet::weight(T::WeightInfo::create())]
        pub fn create(
            // -- snip --

            // Add a lock to the para so that the configuration cannot be changed.
            T::Registrar::apply_lock(index);

            Self::deposit_event(Event::<T>::Created(index));
            Ok(())
        }
2

Currently we impose a restriction on deregistering if a parachain validation code upgrade is underway.

The reason for that is trying to save on the complexity of the design. Allowing deregistering if an upgrade scheduled would complicate the logic and on another hand this limitation does not seem to be very restrictive.

That said, with enough demand I think the restriction could be lifted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.