How to Improve the Security Level of Smart Contract Admin System

In the initial design of our contract admin system, there is one super admin managing all five roles. The five roles are price feed 1 (pf1), price feed 2 (pf2), price feed 3 (pf3), fee collector (fc) and operator (opt). pf1, pf2, and pf3 are the price feeding addresses that commit price to the contract. fc is the one that collects all transaction fees incurred during creation and redemption. opt is the one that is allowed to set contract parameters such as price tolerance, membership threshold, price update cool down etc.

To safeguard the custodian contract, we re-designed a specific admin system in a way that no single account can alter the contract and benefit from it. The new admin system is described as below.

Basically, the idea is to have more admin accounts so that losing one account will not damage the operation of the contract. In the new design, we will maintain a pool of account candidates. The number of accounts in the pool is always greater than 3. In contract inception, 4 candidate accounts and one adder account is created. Adder can add two new account candidates into the pool. Prior to addition, the adder account is set randomly from the account pool. The randomness is generated based on current block time. Then, the new candidates are inserted into the pool. At the same time, new adder is removed from the pool. An adder is not allowed to add any user’s accounts. Added accounts must be different. After adding candidates, the next step is to assign each candidate to a specific role.

To assign roles, an assignor is able to randomly select from the pool and assign it to any role. Any account in the pool is an assignor. As a rule, assigner cannot assign itself. Therefore, even when one assignor’s private key is exposed, the private key owner cannot benefit from assigning other accounts. Only when two accounts’ private key is owned by one person, is there the possibility that the new role is assigned to one of the owner’s address. However, since the assigning process is random, the probability is considered low. This probability is further reduced if the pool size is larger. After a new role assignment, both the assignor address and the new role address are removed from the pool list.

At this stage, the design seems to be good enough. However, there is still one issue regarding address validation. We can ensure that the accounts are all valid at inception. However, there is no way to ensure the added accounts are valid Ethereum account. Technically, the adder can enter any string as input address. As solidity does not provide any function to check the validation of address, this will ultimately make the contract vulnerable to attack. The short address attack is one example utilizing this to steal a great amount of ether. It makes us validate address validation off-chain. That being said, we will keep watching the pool accounts, once an invalid address is detected, there must be a way to remove the address from the pool list. Therefore, to make our admin system more fault tolerant to human mistake, we need to allow the removal of candidate address from pool list. To improve the design, the original adder is allowed to remove the address from the pool list. In the new system, it is renamed pool manager. Similarly, the pool manager is replaced randomly before each addition or removal. The final admin system diagram is as below.

As aforementioned, there is still possible that one role is controlled by the attacker if the attacker owns two or more pool accounts’ private key. To mitigate risk, the admin system has a cooldown time of 15 minutes. If there is one admin operation at current time, the next admin operation must be 15 minutes later. Furthermore, each admin operation will emit an event in the blockchain. When an attack occurs, DUO team can detect such hack activity immediately and have 15 minutes to disable the hackers’ account before the hacker take control of any role.

In conclusion, the new admin system provides more flexibility to the naive solution used previously. On one hand, we have more admin accounts to handle losing/exposing admin account. On the other hand, The admin system is more fault tolerant to an invalid address.


To find out more about DUO Network, visit our official website www.duo.network.
For any media inquiries, please email us at duo_pr@finbook.co.

Join us
GitHub: https://github.com/FinBook
Telegram: https://t.me/duonetwork
Telegram Announcement channel: https://t.me/duo_channel
Medium: https://medium.com/duo-network.
LinkedIn: https://www.linkedin.com/company/duonetwork/
Twitter: https://twitter.com/duo_network
WeChat:DUONetwork