BREAKING CHANGES:

• (api-changes) CanRegisterAnyTrigger CanUnregisterAnyTrigger permissions for system authority
• (api-changes) GenesisWasmTrigger in RawGenesisTransaction for genesis.json readability
• (api-changes) Multisig*Args for multi-signature operations
• (config-changes) genesis.json assumes wasm_triggers[*].action.executable is prebuilt under wasm_dir
• (config-changes) docker-compose service generates genesis.json by oneself instead of reading bind-mounted one

Major commits:

• feat: support multisig recursion
• feat: introduce multisig quorum and weights
• feat: add multisig subcommand to client CLI
• feat: introduce multisig transaction time-to-live
• feat: predefine multisig world-level trigger in genesis
• feat: allow accounts in domain to register multisig accounts

Context

• Partially resolves Ergonomic MST #4930

Opens:

• Deny external access to non-personal accounts #5022: essential to security
• Dedup wasm blobs #5185: essential to true utility
• Scope triggers by accounts #5160
• Unspecialize wasm trigger registrations in genesis.json #5178

Solution

Each commit is explained below, starting with the most recent. You can see the commit history here

feat: support multisig recursion

Allows multisig to function hierarchically, expected to be useful for e.g. automating organizational approval flows.

• When a multisig transaction proposed, every subordinate node (multisig account and corresponding transactions registry) automatically get ready to accept approvals that will be coming up from individual signatories
• Using CLI, individual signatories can query all pending multisig transactions they are involved in, not only those proposed to their direct multisig account

Tests:

cargo test -p iroha integration::multisig::multisig_recursion
bash scripts/tests/multisig.recursion.sh

feat: introduce multisig quorum and weights

Inspired by Sui's multisig. Allows for flexible, if not completely free, authentication policies beyond "m of n". For example, weight equivalent to quorum represents administrative privileges

feat: add multisig subcommand to client CLI

$ cargo build
$ ./target/debug/iroha multisig

The subcommand related to multisig accounts and transactions

Usage: iroha multisig <COMMAND>

Commands:
  register  Register a multisig account
  propose   Propose a multisig transaction
  approve   Approve a multisig transaction
  list      List pending multisig transactions relevant to you
  help      Print this message or the help of the given subcommand(s)

Options:
  -h, --help  Print help

You can see more usage in the testing script

feat: introduce multisig transaction time-to-live

Considers the latest block timestamp as the current time and determines timeout, when the transactions registry is called

feat: predefine multisig world-level trigger in genesis

Defines a global trigger in genesis that exercises authority over all domains. There will be three types of triggers on the system side related to multisig:

• Domains initializer has world-level authority and in response to a domain creation event, registers an accounts registry handled by the domain owner authority
• Accounts registry has domain-level authority and when called by a domain resident, registers a multisig account along with a transactions registry
• Transactions registry has account-level authority and when called by a multisig signatory, accepts proposals or approvals for multisig transactions, and is responsible for executing them

feat: allow accounts in domain to register multisig accounts

Accounts registry has authority of the domain owner, so access was previously restricted. This commit allows anyone to organize any multisig account within the domain.

This may be too lenient. Discussion

Review notes

To get an overview,

cargo test -p iroha integration::multisig::multisig
bash scripts/tests/multisig.sh

sequenceDiagram
    autonumber
    participant oo as etc.
    participant DI as Domains Initializer
    Note over DI: /world
    oo-->>DI: domain created
    create participant AR as Accounts Registry
    DI-->>AR: register
    Note over AR: /world/domain
    create actor s0 as signatory 0
    oo->>s0: register
    create actor s1 as signatory 1
    oo->>s1: register
    s0->>AR: request new ms account
    create actor 01 as ms account 01
    AR-->>01: register
    create participant TR as Transactions Registry
    AR-->>TR: register
    AR-->>s0: grant ms role
    AR-->>s1: grant ms role
    Note over 01,TR: /world/domain/account
    s1->>TR: propose instructions
    create participant tx as pending ms transaction
    TR-->>tx: deploy ms transaction
    s0->>TR: approve instructions
    destroy tx
    TR-->>tx: execute instructions

The dotted line indicates an automatic process

Checklist

• I've read CONTRIBUTING.md.
• I've written integration tests for the code changes.
• All review comments have been resolved.