SMT finds similar security loopholes with BEC, how can ASCH ensure DAPP development security? ASCH Follow Apr 26, 2018 · 4 min read

In the early hours of this morning, the world’s mainstream trading websites, Huobi Pro and OKEx, issued a notice about the suspension of SMT, which caused uproar. Immediately, many digital currencies fell today.

The reason is that there are serious loopholes in the Ethereum smart contract of SMT, which is caused by the overflow problem caused by the program’s lack of parameter restriction.

Similarly, in the past few days, hackers exploited data breaches in the BatchOverFlow vulnerabilities in Ethereum’s ERC-20 smart contract to attack the smart contract of the US-based chain BEC, and transferred a large number of BEC tokens to two addresses, resulting in the sell-off of massive BECs in the market, which brought a devastating blow to the BEC market transactions.

According to blockchain security firm PeckShield, in addition to BEC Token, there has been a BatchOverFlow integer overflow loophole in more than 12 project Token smart contracts, which can be used by hackers to generate “non — existent” virtual currencies and make profits.

The media joked that Cai Wensheng’s BEC needs to kill a programmer to sacrifice heaven. At the same time, we must also reflect on why the development of DAPPs based on Ethereum is prone to security problems.

Weibo’s vice president (Weibo: Tim Yang) believes that Ethereum is just a blockchain that records the results of DAPP execution. It does not itself have the utxo model needed for cryptocurrency double-entry bookkeeping. Ethereum’s own tokens are controlled by balance. There is an obvious defect in the blockchain with the balance, which is vulnerable to replay attacks (transaction requests are sent again). Ethereum uses tricky techniques such as nonce to avoid replay of the main chain currency, but for DAPP-based tokens, developers need to rely on their own to safeguard their security logic.

Double-entry bookkeeping used by utxo requires all input sources for transfer checks. If the source has been used once, it means that this transfer is a double-spend attempt. Bitcoin’s main architectural design logic such as PoW and long-chain winning is used to prevent double-spend attacks.

The general process of the Ethereum smart contract operation is that the node writing block runs DAPP and records the result of the operation to a new block. When this result is verified by other nodes, the new block is recognized by the entire network. The method of verification is also the execution of the contract script, and the design constraint of the smart contract is deterministic, but there are no other mechanisms to ensure the safety and correctness of the implementation. Even if there is a bug, as long as the bug can be run by other nodes with the same result, the records will be on the chain. ERC-20 or ERC-721 is an agreement of a smart contract interface, so that the universal wallet can access these contracts.

In the era of digital currency, important token assets require monetary level security. Ethereum’s current design is more suitable for the results of contract operations such as game points. Important token assets are not suitable for building on ERC-20. It does not have any consideration for currency security design.

As we all know, ASCH is a decentralized application development platform based on the sidechain architecture and security is one of the most important features. Are there any integer overflow loopholes in ASCH?

ASCH senior R & D personnel said that in dealing with large integers, the bigint module is used for all asset issuance and transfer in ASCH. Bigint directly avoids the problem of integer overflows. No matter how large or small the number is, there will be no overflow problems. Therefore, the issue of assets in ASCH will not encounter similar problems similar to the BEC, and there will be no similar loopholes.

Let’s take a look at ASCH’s trading information:

Transaction {

required VARCHAR(20) id;

required VARCHAR(20) blockId;

required TINYINT type;

required INT timstamp;

required VARCHAR(21) senderId;

optional VARCHAR(21) recpientId;

required BIGINT amount;

required BIGINT fee;

required BINARY(64) signature;

optional BINARY(64) signSignature;

optional TEXT signatures;

required BINARY(32) senderPublicKey;

}

The bigint module is used for both account balance and handling fee. This type of data will not overflow. As a result, there will be no similar problems when making transfers on ASCH.

At present, all DAPPs and all assets on ASCH are performing well without any security issues.