You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Typically, multisig is a contract that has storage with 2 fields - a list of public keys and an int for threshold (how many signatures matching the public keys are required to accept a transaction). In some chains, it also has a counter for replay protection, which in Anoma is most likely going to be handled in the DKG wrapper txs and not by the inner transactions (the WASM level at which the multisig would be implemented).
When this contract is called, it requires the list of sigs as a parameter and the contracts goes through these, checks them against the public keys set in storage and once it counts signatures equal to threshold, it accepts the transaction (e.g. it executes a generic lambda, that is passed to the contract via another parameter).
To do similar thing in Anoma's validity predicate (a generic multisig that allows arbitrary actions on the account, as long as it’s signed by the threshold number of keys), we could have a VP that expects that the account it is attached to has the same storage values - threshold and a list of public keys. The validation logic of the VP we can do a similar thing - it would look for the signatures in the attached tx.data, look-up the storage values and check that the tx has enough valid signatures.
The multisig VP can be generic, it can change storage or even the VP of the account itself and as long as the signature validation passes, it will be accepted and applied (unless some other VP checking this tx rejects it).
The text was updated successfully, but these errors were encountered:
Typically, multisig is a contract that has storage with 2 fields - a list of public keys and an int for threshold (how many signatures matching the public keys are required to accept a transaction). In some chains, it also has a counter for replay protection, which in Anoma is most likely going to be handled in the DKG wrapper txs and not by the inner transactions (the WASM level at which the multisig would be implemented).
When this contract is called, it requires the list of sigs as a parameter and the contracts goes through these, checks them against the public keys set in storage and once it counts signatures equal to threshold, it accepts the transaction (e.g. it executes a generic lambda, that is passed to the contract via another parameter).
To do similar thing in Anoma's validity predicate (a generic multisig that allows arbitrary actions on the account, as long as it’s signed by the threshold number of keys), we could have a VP that expects that the account it is attached to has the same storage values - threshold and a list of public keys. The validation logic of the VP we can do a similar thing - it would look for the signatures in the attached tx.data, look-up the storage values and check that the tx has enough valid signatures.
The multisig VP can be generic, it can change storage or even the VP of the account itself and as long as the signature validation passes, it will be accepted and applied (unless some other VP checking this tx rejects it).
The text was updated successfully, but these errors were encountered: