Security measure of DUO smart contracts

When DUO network is developing our stable coin product, we keep in mind that we need to ensure 100% security level to protect our users’ digital assets. In this article, we describe the security issues encountered and explain how we overcome such issues. When our code is released to public, the community members are welcome to review our code and raise your security concern if any.

On blockchain level

1. Random Number Generation

In our admin system, after each admin operation, new admin account needs to be set randomly. However, the Ethereum EVM does not provide opcode for random number generation. The naive way of generating random number is using block.timestamp. However, block.timestamp can be arbitrary altered by miner. A safer way is to use previous block’s block hash because previous hash cannot be altered by current block miner. However, previous block hash is publicly known although the block interval is only 15 seconds. We need something that is keeping varying and cannot be altered. A smarter idea is to use our user list. The user list length is keeping changing and the user address cannot be changed arbitrary. We combine block hash (from blockchain) and user list (from our product) to generate a random number.

The actual implementation is as following. Firstly, we take previous block’s block hash and convert the hash into a uint256 number, say a. if our user length, n is less than or equal to 255, we simply use a as the random number; if n is larger than 256, we will calculate a % n = b, and take the b-th user’s user addreses, addr(b). Then we take hash of addr(b) and convert it to a uint256 number. This will be the final random number used.

2. Pre-Reset Locking

In our product design, when navB goes too high or too low, both navA nad navB will be reset to 1. Reset process is the most critical process and we must ensure reset transactions are confirmed in the blockchain network. Miners will always build on the longest chain. Usually, it takes 6 block time for a transaction to be confirmed.

If the contract transits from trading state to reset state instantly, we cannot ensure that this state transition will eventually take place. The state transition triggering transaction to may not be accepted by the network. For example, at t0, the contract receives an ETH price and starts to reset. If the contract reset directly and follow chain B. At a later time t3, chain A becomes the longest chain. Because reset already happens in chain B, contract state in chain A is still trading. Users may have made transactions in chain A and there is no way going back to a state at t0. To ensure the contract state safely ans smoothly moving to reset state, we provide a buffer time of about 10 block times for the contract getting prepared for reset. During the buffer time, the contract state is pre-reset. In this period, the users are not allowed to do any transaction.

On contract level

The following security aspects are handled in our contract.

  1. Overflow and underflow: our contract employ the most well-know safteMath library in any computation. However, safeMath only avoid incorrect computation but cannot ensure the computation that going through as expected. Besides using safeMath, in our contract code, there is no three consecutive multiplications of numbers in wei and there is no small number divided by big number. We analyze each computations’ lowest and upmost bound and arrange the computation steps in a way to avoid overflow/underflow mathematically.
  2. Invalid address attack: the reason why short address attack can work is that solidity does not check the validation of address. Address is actually treated as a string. In our contract, there are multiples accounts can be assigned as different system admins. We design the admin system in a way to handle invalid address. For more details, please visit this article . For short address attack, it is actually the exchanges’ responsibility checking the size of input address. Solidity does not check address validation and we highly recommend every exchange doing proper validating prior to transferring token.
  3. Contract call contract: In most of the hacking examples, such as reentrancy, DOS and exception disorder, the core reason is that those contracts send ether/token to other address. The recipient can be a contract that has a unknown fallback function which brings lots of uncertainty to the contract execution. In our contract design, we do not send ether/token to any external account. All contract calling contract transactions are among our contracts. However, during redemption, we do not send ether to the user as the recipient can be a unknown contract.

Smart contract security remains the biggest concern in the community. DUO network, as an experienced team in developing DAPP, we are willing to share our knowledge in writing the most secure contracts. We also provide contract auditing service as a mission to safeguard crypto world against any form of hacking.