Being able to collect signatures on-chain for a multisig proposal is an exciting feature that really highlights the strides towards usability and the user-focused design of EOSIO blockchains.
We at EOS Canada have put together a comprehensive guide to understanding multisig and permissions on EOSIO through our eosq block explorer and eosc command line tool, which has full functionality with the eosio.msig and permissions systems.
Multisig: Security to Protect dapps and Users
All dapp developers should leverage multisig and permissions to take full advantage of the security features built into an EOSIO chain to protect themselves, and their users’ funds. Users should also learn these features to increase the security of their own accounts.
If you’re interacting with a dapp and notice that their account only has a single key in the owner or active permissions, consider reaching out to them to ask them why, and sharing this article series with them.
What Is Multisig?
Multisig is shorthand for multiple signatures, which is also generally shortened to msig. It’s used to describe any situation in which you require more than one signing key to execute a transaction, whether it uses the eosio.msig account or not.
There is a system account, eosio.msig, which handles storing and execution of multisig proposals and their corresponding signatures on-chain.
Multisig is useful for increasing the security of an account, security of a smart contract, and is also the method by which Block Producers are able to affect changes within EOS. In this first article in our series on multisig and permissions, we will focus on multisig within a single account.
How Does Multisig Improve the Security of an Account?
When a new account is created, it will have an account structure similar to this example, with a single key for the owner permission, and a single key for the active permission. Some accounts, namely untouched genesis accounts, will have the same key in both the owner and active permissions.
So if you had an account that you wanted to increase the security on, you could hold one key, while someone else holds the other key. Any actions that this account takes would need both of you to confirm that this is an authorized transaction. For example, the active key here:
Notice the /2, which denotes that a threshold of 2 is required to pass the active permission. Since each of those keys was designated a weight of 1 (as shown by the +1), both signatures would be required.
The updateauth action needs to be invoked to change your permissions like this. If the key ending in ...zqLS was stolen or exfiltrated in in some way, it still could not sign transactions successfully, because the threshold would not be met.
Adding Nested Permissions
A nested permission is the child of a parent permission. Active is the child of owner, so owner can do everything within active, but active cannot do everything within owner. You could add a nested permission below the active permission for low-risk actions, such as voting for Block Producers or playing a popular game. You could create that nested permission to only require one of the two keys, by using a threshold of 1, then issuing a linkauth to only allow certain actions with that level of permission.
In the example below, either key ...zqLS or ...dnHZ can be used to vote for producers (the eosio@voteproducer action in the blue box). The active permission will still need to be satisfied for any other actions you might want to sign.
eosq is one of the rare block explorers that provide full linked permissions information.
Three Ways to Delegate Permission Weight
There are three things that can be used to control a permission:
- Keys represent public/private keypairs.
- Accounts represent another accounts’ authorities.
- Waits represent required time delays, measured in seconds.
Each account’s authority structure stems down from the owner permission and has nested child authorities beneath that.
Each authority also has a threshold that must be triggered to be used. This is done by having all keys, accounts, and waits that are assigned to a permission to hold a specific weight (the threshold).
Once the required cumulative weight used in signing a transaction has been met, the permission is authorized.
In the next article, we will demonstrate how to make all of these changes to your account using eosc so that you can begin to take advantage of the power of multisig. If you haven’t already tried it out, eosc is the most flexible & powerful command line tool for any developer to interact with an EOSIO chain.
