iroha icon indicating copy to clipboard operation
iroha copied to clipboard

Multisig dedicated tables

Open s8sato opened this issue 1 year ago • 2 comments

The current multisig implementations, which fully utilize metadata for storage, may lead to inconsistencies between roles and account metadata.


Suppose that there are:

  • multisig account msa01 whose signatories are sig0 and sig1
  • accounts sig0 and sig1, each has the multisig role for msa01

They can be inconsistent e.g. multisig account can include/exclude some signatories by democracy without granting/revoking their roles. To prevent this, we should rely on either of them to know the relationship between a multisig account and its signatories:

  1. multisig account metadata
  2. multisig roles

One approach needs an complemental implementation to the other:

  1. e.g. participates_in key-value as a multisig account metadata, to know the multisig account from the signatory
  2. new query e.g. FindAccountsByRole, to know the signatories from the multisig account

Concerns of each approach:

  1. self-modification:
    • by self-modifying signatories, an account can pretend to be a multisig account and have any signatories
      • problematic unless multisig accounts are supposed to be able to reorganize its signatories
      • needs a way other than checking the signatories existence to discern a personal and a multisig account
        • #5022
    • by self-modifying participates_in, an account can pretend to be a signatory of any multisig account
      • not so much harm unless the multisig account recognizes the account as a signatory
  2. the domain owner can break everything as usual, other than that I see no specific problems atm

So my current outlook is 2. -- remove signatories metadata and introduce FindAccountsByRole or something

s8sato avatar Nov 11 '24 14:11 s8sato

Updated concerns of each approach:

  1. membership by account metadata
    • as long as taking either account's perspective, there would be two-way references, which would lead to inconsistency, unless controlled by some super authority over both accounts
  2. membership by roles
    • needs to retrieve each signatory's weight from somewhere non-writable by either account

s8sato avatar Nov 18 '24 09:11 s8sato

Introduce dedicated tables in the World. Composite keys will enable bidirectional references, solving this issue.

s8sato avatar Mar 16 '25 19:03 s8sato