To make sure that the ownership of Staking assets is always controlled by users, not by third parties, Stafi designed an intermediate address. And no one has the private key of this address. Stafi achieves asset neutrality of intermediate addresses through secure multi-party computing technology and threshold multi-signature technology, ensuring that only users with rTokens can execute signatures when they initiate a redemption. This intermediate address does not have a private key, nor is it stored on the Stafi protocol. It is only formed when signatures are required. At that time, the private keys of several SSVs will jointly sign.
Most chains support multi-signature on the underlying account structure. One account is set with multiple private keys, and each private key can be assigned a weight. When the total weight of the signed private key meets the critical value, the assets in the account can be operated. However, it is not convenient or safe for Stafi to reuse the multi-signature function at the bottom of the original chain.
Stafi's multi-sign accounts must ensure that signers can rotate. However, most of the multi-signature functions at the bottom of the original chain do not support rotation, or require a super private key (owner) to initiate the rotation.
For original chains that do not support rotation, the alternative is to transfer the assets in the current account to a new multi-signature account controlled by a new team of validators during rotation. However, doing so will make the assets in the account unable to be Staked steadily, and will also cost a big number of transaction fees.
It is even more unacceptable for Stafi to have a super owner who operates the rotation, because the owner’s private key will be the biggest security risk. Moral risks of that role is hardly ignorable and the assets are very susceptible to hackers.
Therefore, Stafi's multi-signature needs to be achieved through the contract layer. A multi-signature account is generated through a contract, and the account does not have an owner private key. The contract itself stipulates a list of public keys (also known as an account list), so that the account can be controlled by private keys mapped to the public key in the list. Also, the contract stipulates that a minimum percentage of the list's private key signatures are needed to operate account assets, and what how many private key signatures are required to update the list.
SSVs are those who control these private keys of a multi-sign account..
When M of N SSV signatures are in place, following operations on multi-signature accounts can be executed:
① When a user applies for the redemption of rToken, assets are transferred out from the multi-sign account to the address provided by the user
②Operate delegated Staking and canceling it.
In the specific implementation of multi-signature, there will be different strategies for different chains, for the method of writing multi-signature contracts on different chains may be completely different. Stafi needs to customize different tactics according to the chain. Of course, from the user's perspective, there will be no distinct difference when commissioning different tokens on Stafi. Stafi development team must faced up with complexity and packaging challenges and provide users with a uniformed experience and friendly interface.
As mentioned above, a multi-sign account is a safe intermediate account because:
① Free from the influence of a evil or neglect SSV
A single SSV cannot control the assets of multi-signature accounts. In addition, the system has an N-M/M fault tolerance rate so whether a single SSV sign or not do not affect the execution of related operations.
② Free from asset losses caused by collusion of multiple SSVs
The collusion is difficult because: collusion takes time, and SSV rotates regularly, so SSVs elected in the next term (Era) is random and unpredictable. Even if the collusion succeeds, it will face the loss of due rewards and severe punishment and deterrence, making the loss of collusion exceeds the gain.
③ Free from asset losses caused by hacker attacks
First, the amount of assets in a single multi-signature account is limited, so it is unlikely to be the target of hackers. Second, there is no owner private key in multi-signature accounts, so hackers cannot steal assets by obtaining a private key. A hacker must steal M SSV private keys from incumbent SSVs during a term, which is almost impossible. (In order to further improve security, Stafi will also require SSV to change their keys frequently.)