Trait ParachainRegistrar

Source

pub trait ParachainRegistrar {
    type AccountId;

    // Required methods
    fn check_onboarding(head_len: u32, code_len: u32) -> Result<(), ()>;
    fn is_registered(para_id: ParaId) -> bool;
    fn register(
        manager: Self::AccountId,
        para_id: ParaId,
        genesis_head: Vec<u8>,
        validation_code: Vec<u8>,
    ) -> DispatchResult;
    fn deregister(para_id: ParaId) -> DispatchResult;
    fn setup_worst_case_deregister(para_id: ParaId) -> DispatchResult;
    fn check_head_data(head_len: u32) -> Result<(), ()>;
    fn set_current_head(para_id: ParaId, head: Vec<u8>);
    fn check_code_upgrade(para_id: ParaId, code_len: u32) -> Result<(), ()>;
    fn schedule_code_upgrade(
        para_id: ParaId,
        validation_code: Vec<u8>,
    ) -> DispatchResult;
}

Expand description

The parachain registry, as pallet-registrar-relay needs to see it.

Implemented by whichever pallet owns parachain registration, typically paras_registrar on the relay chain. Lives here so neither side of the protocol has to depend on the other.

Required Associated Types§

Source

type AccountId

The account id used to identify a registration’s manager.

Required Methods§

Source

fn check_onboarding(head_len: u32, code_len: u32) -> Result<(), ()>

Whether head data and code of these sizes could be onboarded right now.

Checked against the relay chain’s live configuration so a doomed request can be rejected before the user goes and uploads megabytes of code.

Source

fn is_registered(para_id: ParaId) -> bool

Whether the relay chain already knows this para id.

Source

fn register( manager: Self::AccountId, para_id: ParaId, genesis_head: Vec<u8>, validation_code: Vec<u8>, ) -> DispatchResult

Onboard para_id under manager.

No deposit is taken: the manager’s funds are held on the chain running pallet-registrar-para.

Source

fn deregister(para_id: ParaId) -> DispatchResult

Drop para_id from the registry.

Idempotent: a para already gone, or still being cleaned up, answers Ok(()) rather than refusing, so a second MessageToRelayV1::Deregister settles instead of telling the parachain the para is still there. Nothing here retries on its own: the parachain waits, and if no answer turns up the manager sends the request again. That second request is how the parachain learns the first answer never came, and it reports it as an unexpected event.

Source