refactor(multisig)!: move from triggers to custom instructions

[s8sato]

Context

1. Calling a trigger with args as a multisig operation was not a clear interface
2. The multisig implementation as triggers introduced validation exceptions for registering and executing triggers to bridge the authority gap between the caller and the executor: feat: improve multisig utility and usability #5027

• Addresses Ergonomic MST #4930: encapsulate multisig operations
• Resolves as for multisig Dedup wasm blobs #5185

Solution

1. Assign dedicated custom instructions to the multisig operations
2. Switch to the executor context and package validation and execution logics as the custom instructions

• As a side benefit of removing triggers i.e. no event pools, recursive approvals immediately propagate without ticking time

Migration Guide

• Introduces MultisigRegister MultisigPropose MultisigApprove custom instructions that replace MultisigAccountArgs MultisigTransactionsArgs
• Removes CanRegisterAnyTrigger CanUnregisterAnyTrigger permissions that become useless and are unlikely to be used
• Though it becomes useless for multisig, retains the capability to register wasm triggers in genesis

Future Work

• #[derive(CustomInstruction)] or something for custom instructions #5221
• Unexpected Grant::account_role behavior in custom instructions #5222 infers potential bug
• Panics in custom instructions on registering a new account with metadata #5223 infers potential bug
• Concurrent MSTs of the same proposals? #5224
• Contrast /crates and /samples #5225

---

Checklist

• I've read CONTRIBUTING.md.
• All review comments have been resolved.
• All CI checks pass.

[github-actions]

@BAStos525

[s8sato]

context_mut here is only to indicate what authority is executing the instruction:

I've realized that host.submit() goes through no validation, which seems to me to be rather a correct behavior. That's why context mutations whose purpose is to pass permission validation are removed at 2e2dcd1

[mversic]

amazing stuff, so much better

[s8sato]

Self-reviewed and made fixes 4e4a6b9 0e4fc3a for now. I'm going to address your comments tomorrow @mversic

[s8sato]

Updates:

• rename to visit_custom_instructions
• move to {iroha_executor::default, iroha_executor_data_model}::custom::multisig
• minor updates since refactor(multisig)!: move from triggers to custom instructions #5217 (review)

Notes:

• Something happened on merging main branch and @outoftardis involved, but no effect on changed files. Never mind

[s8sato]

If we prohibited 0ms, why not also prohibit 1ms?

[s8sato]

What good is this type safety, since 0 doesn't lead to errors and there's no incentive for users to set quorum 0?

[s8sato]

The main topic here should be why Grant::account_role has passed but hasn't taken the expected effect, but okay,

authenticate intrinsics?

My understanding is that authentication by signature is required on facing extrinsic transactions and queries. Imo intrinsics should not be signed in cryptographic sense, especially in the case of multisig, proposals and approvals are extrinsic while automatically deployed multisig transactions themselves are intrinsic, and collecting sufficient signatures will be the authentication

Btw the concept of "keys of a multisig account" or "sign as a multisig account" will be removed by #5022 because keys should represent a personal identity

authorize intrinsics?

The only instructions that should be validated would be extrinsics which hasn't yet experienced authorization i.e. the contains of proposal. Other auxiliary instructions that compose the multisig logic itself should be infallible

[s8sato]

Previously it was the design that the registrant of a multisig account got equivalent to the domain owner, so as to register and configure a multisig account in the domain. Now that host.submit() from executor goes through no validation, there's no need to elevate the authority. There should be essentially no difference between assigning any desired authority and bypassing any validation

[mversic]

Suggested change

parity-scale-codec.workspace = true

why is it needed?

[s8sato]

Because multisig data models need to impl either Encode Decode or WrapperTypeEncode WrapperTypeDecode for IntoSchema

[mversic]

I'm a bit confused because none of the default permissions in executor_data_model/src/permission.rs implement Decode/Encode

[s8sato]

That's probably because the permissions are not listed in types!

[s8sato]

Updates:

• minor updates since refactor(multisig)!: move from triggers to custom instructions #5217 (review)
• nonzero quorum and transaction_ttl_ms
• replace host.submit with executor.visit_*
  • resolves Unexpected Grant::account_role behavior in custom instructions #5222
  • keeps Panics in custom instructions on registering a new account with metadata #5223

[s8sato]

Suggested change

	macro_rules! visit_seq {
	($executor:ident.$visit:ident($instruction:expr)) => {
	$executor.$visit($instruction);
	if $executor.verdict().is_err() {
	return $executor.verdict().clone();
	}
	};
	}
	/// Validate and execute instructions in sequence without returning back to the visit root,
	/// checking the sanity of the executor verdict
	macro_rules! visit_seq {
	($executor:ident.$visit:ident($instruction:expr)) => {
	$executor.$visit($instruction);
	if $executor.verdict().is_err() {
	return $executor.verdict().clone();
	}
	};
	}