Imagine an impenetrable fortress. Walls towering high, seemingly lifting the clouds. A true modern wonder. A testament to human invention and ingenuity.

Suddenly, down near the ground, you notice a little wooden door held shut by padlock.

Given the amazing tamperproof characteristics introduced by blockchain technology, the security of first generation Ethereum smart contracts has been something of a blackeye on this nascent industry. Malicious attacks from external agents have been far too common an occurrence during blockchain’s short history. The DAO Hack… Parity’s Wallet Hack… the Etherparty hack… you’ve heard them all. These attacks lead to serious economic losses, privacy breaches and limit the willingness of the mainstream to adopt blockchain solutions. The damage caused has also been incredibly difficult to rollback and has resulted in industry-shaking hard forks.

Unsurprisingly, each security breach sprouts a new wave of security measures. These measures largely attempt to locate vulnerable areas in smart contracts as early as possible. However, because of the lasting contradiction between precision and scale, these measures have tended to fail. This has created an environment of mistrust as it remains difficult for the layman to say with any level of certainty that there are no security threats lurking in a smart contract’s darker corners.

A commonality between most existing security measures is that they are conducted off-chain. While the more reliable of these external security measures certainly have their place and value, the MATRIX team has leveraged their artificial intelligence expertise to introduce an innovation sorely lacking in the blockchain space: an intelligent, adaptive, on-chain security measure.

The team has dubbed this the MATRIX Secure Virtual Machine.

The MATRIX Secure Virtual Machine: Error Detection and Correction

MATRIX’s Secure Virtual Machine can detect attacks on transactions by providing AI-backed vulnerability detection with fault-tolerant protocols. In other words, the MATRIX team has introduced formal verification technology during transactions to detect security vulnerabilities.

Before a transaction is initiated, the MATRIX Secure Virtual Machine proactively selects a safe checkpoint in anticipation of a complication. If an issue does emerge, the MATRIX Secure Virtual Machine is easily able to perform a rollback to ensure that the address and state of the Intelligent Contract is as it was prior to the compromised transaction. This avoids malicious consequences.

To better illustrate this error detection and correction mechanism, MATRIX R&D team member Hu ZhiKun has prepared two quick examples. A brief write-up is included here. Alternatively, scroll to the bottom and watch the video!

Example 1: The BEC Smart Contract Loophole

Some may remember the BEC Smart Contract security loophole. While this article will not provide a technical dissection of this security breach, suffice to say that a simple coding oversight resulted in a data overflow bug following the execution of a BatchTransfer function.

MATRIX has recreated a simplified version of the compromised BEC contract.

A simplified BEC smart contract used by the MATRIX team

When this contract is deployed in a native, unmodified virtual environment (ie. without the MATRIX Secure Virtual Machine), the balance of the transferor is reduced by 0 while the balance of the two payees, which are added into the contract Storage, increases. This indicates that this transaction has been compromised by an overflow attack.

When deployed in a native, unmodified virtual environment, an overflow attack occurs

When this same contract is deployed using the MATRIX Secure Virtual Machine, MATRIX’s AI-backed security mechanisms identify that the last line is a duplicate operation. The MATRIX Secure Virtual Machine does not confirm this transaction and rolls back to a previous, secure, state.

The MATRIX Secure Virtual Machine detects the overflow attack and rolls back the transaction

Example 2: DAO Smart Contract Loophole

The DAO Hack is perhaps the most infamous hack ever to damage the blockchain industry. However, as with the previous example, in-depth technical analysis of the DAO Smart Contract security loophole can be found elsewhere.

To oversimplify, Ethereum’s first Decentralized Autonomous Organization, the DAO, was exploited by creating a smart contract which first transferred funds before updating balances. Additionally, due to a design oversight, the attackers were able to recursively repeat this process multiple times before the code confirmed account balances.

The MATRIX team has recreated a simplified version of a DAO contract. This particular DAO contract is vulnerable to reentrancy attacks. The single withdrawal limit is 11. The attacking party is an attacker contract.

A simplified DAO smart contract used by the MATRIX team

When this DAO contract is deployed in a native, unmodified virtual environment (ie. without the MATRIX Secure Virtual Machine), a call function triggers a withdrawal function. A fallback function is then automatically pulled when the DAO contract transfers funds to the attacker. This causes the balance to be withdrawn again and again. In this case, the attacker’s balance increased from 1000 to 4454 — the funds were transferred 314 times (in increments of 11). This is a reentrancy attack.

When deployed in a native, unmodified virtual environment, the reentrancy attack increases the attacker’s balance to 4454

When this same contract is deployed using the MATRIX Secure Virtual Machine, the reentrancy attack is captured, and the corrupted transaction is rolled back.

When deployed in the MATRIX Secure Virtual Machine, the reentrancy attack is detected. Note that the attacker’s balance increases only by 11.

The MATRIX team invites you to watch a short demonstration of the above two examples. Enjoy!