ScheduleUpgrade connectors message

[AStox]

Description

Adds the ScheduleRely message, intended for governance to rely and execute spells on EVM domain gateway contracts

Changes and Descriptions

• Adds a ScheduleRely(user: Address) message.
• Adds a schedule_rely function to lib.rs

Checklist:

• I have added Rust doc comments to structs, enums, traits and functions
• I have made corresponding changes to the documentation
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works

[NunoAlexandre]

One typo that's breaking the build (if I don't miss anything else) and apart from that we will then also need to run cargo fmt and taplo fmt.

Regarding the test, once the build is fixed the test will fail since it will try to compare the resulting hex the message encoded to against ""; we can then use that hex-encoded call and replace the "" with that.

[hieronx]

We renamed this to AddAdmin on the Solidity side, so we should do the same here.

[AStox]

Actually we mostly (but not fully) renamed this set of features in solidity to "scheduling relies". I've just pushed a PR to rename the rest of the addAdmin mentions in solidity to scheduleRely @offerijns

[NunoAlexandre]

and here we should ensure that the the DomainAddress is a DomainAddress::EVM, i.e, this should fail with an error when it's DomainAddress::Centrifuge since we don't want to be sending this message to the chain itself.

[NunoAlexandre]

A nit 👀

[NunoAlexandre]

I promise we are almost there 🙏

[NunoAlexandre]

Super nit but just a suggestion:

We don't need who until we call submit and it's only used there, so we could do:

Suggested change

	// get account id of this pallet
	let who = T::PalletId::get().into_account_truncating();
	ensure!(
	contract.domain() != Domain::Centrifuge,
	Error::<T>::InvalidDomain
	);
	T::OutboundQueue::submit(
	who,
	ensure!(
	contract.domain() != Domain::Centrifuge,
	Error::<T>::InvalidDomain
	);
	T::OutboundQueue::submit(
	T::PalletId::get().into_account_truncating(),

[mustermeiszer]

What will be triggered on the Solidity if this message is received?

[NunoAlexandre]

What will be triggered on the Solidity if this message is received?

@offerijns will explain this better but, afaik, this will schedule a contract upgrade (Solidity "spell") on the EVM side. the contract field of this new ScheduleUpgrade points to that upgrade/spell.

I guess a fair analogy would be to schedule a runtime upgrade and pass on the BLAKE2_256 of the new wasm (if the wasm was living somewhere in the network like a contract does)

[hieronx]

I guess a fair analogy would be to schedule a runtime upgrade and pass on the BLAKE2_256 of the new wasm (if the wasm was living somewhere in the network like a contract does)

Yes basically this, except the hash being passed is not the new code version itself, but rather a hash of the runtime upgrade that is executing the changes.

[mustermeiszer]

Re-approve

[NunoAlexandre]

@offerijns @mustermeiszer can we get another re-approval here? I had forgotten to include 49f68f9 in the last run

[wischli]

It would be great if we did not bump dependencies silently as part of new features. They can introduce silent errors and thus should ideally only be packaged with Substrate updates.