DeFiChain - Natively Vaccinated Against Exploits
Most of today’s DeFi projects run on blockchains like Ethereum, Binance Smart Chain — an Ethereum fork —, Tron or others. They all share the same architecture, where dApps run on virtual machines on a blockchain. Unlike native blockchains, Turing-complete blockchains offer greater flexibility for developers where code can be executed directly and freely on the virtual machine layer on a blockchain. While this design paradigm may seem useful for a lot of different applications, it is however very risky for decentralized financial applications.
In the following article, we will outline the differences, advantages and disadvantages of non-virtual machine blockchains. We’ll start by offering a short comparison between those two concepts, followed by an introduction about the building blocks of a virtual machine. We’ll then compare blockchains where transactions are done via a virtual machine to those done natively on the blockchain, before sharing a summary in closing.
Overview of Native DeFi vs. Virtual Machine DeFi
Since Native DeFi is rather new to the DeFi community, Table 1 gives an overview of the differences between these competing concepts.
What is a Virtual Machine
There are currently thousands of dApps running on the Ethereum blockchain — a Turing complete blockchain, which aims to facilitate a peer-to-peer general purpose worldwide computer on which anybody can virtually run anything, and where the limit is your imagination. Anyone who has ever tried to develop a smart contract on the Ethereum blockchain is already familiar with the term “EVM”, an abbreviation of Ethereum Virtual Machine.
A virtual machine essentially creates a level of abstraction between the execution of code on the one hand and the executing machine itself on the other. The EVM allows for code execution in a trustless ecosystem in which the outcome of the execution is guaranteed and is fully deterministic. Whenever instructions are implemented in the EVM, a system keeps track of the execution costs and assigns an associated Gas fee to those instructions.
Since anyone can build dApps on Ethereum, these Gas fees are essential in a way that they put a price tag on how long a dApp can interact with the virtual machine. Consequently, any execution on Ethereum requires the user to pay some Ether in the form of Gas fees. This mechanism guarantees a validator will receive the initial prepaid amount, even if the execution fails. On the other hand though, an execution can’t take any longer than the prepaid amount would allow for, preventing the possibility of an infinite loop.
Yet this architecture does not guarantee fast and cost-effective transactions. It’s no secret that Ethereum is suffering from astronomically high transaction fees, making it unfit to handle the significant load of new users. Most of DeFi is currently associated with Ethereum, which, in its current shape, can arguably be compared to calcified and constricted arteries in the human body. Though it may have made sense a few years ago, the Ethereum blockchain network has since become a bottleneck. Hence, new solutions have to emerge to tackle these immanent problems — via scalable, secure and cost-efficient transactions performed directly on the consensus layer of the blockchain.
When it comes to issues of security, it seems clear that different DeFi stakeholders will have different sets of preferences and approaches to tackling it. While developers look at it from a purely technical perspective, making sure code is executed correctly and is working smoothly, customers only care that DeFi projects work in their favour by mitigating hacks and malicious attacks.
At this point of conflict, DeFiChain comes into play. Unlike EVM or any other virtual machine blockchain, DeFiChain empowers users by providing a secure and safe DeFi platform, rooted deeply in the native blockchain itself.
Difference in Consensus Mechanism Between DeFiChain and Ethereum
In order to better understand why native DeFi is so much more secure than any layer-2 dApp, we’d like to explain how code is executed and where potential issues might arise on a blockchain, where DeFi transactions are native consensus vs. those run on an EVM.
DeFi on Ethereum
The workflow — from applying the code until its execution — is significantly different on Ethereum than DeFiChain. On Ethereum, most contracts are written in a high level program language called Solidity. This code then gets compiled via a solc compiler. Once a Solidity contract is compiled with solc, the resulting machine code must be run through an EVM followed by validation by the blockchain consensus (see Figure 1).
During this process of compilation, issues may arise. These can range from human errors and coding mistakes at each stage of the smart contract development and deployment process, to compilation and transpilation bugs with the compiler itself. One of the biggest problems here is that the compiler may produce arbitrary machine code which may open up unforeseen attack vectors to malicious actors.
Another issue that even experienced teams are facing, are language “gotchas” in the Solidity code especially for new or inexperienced programmers. Perhaps the most astonishing takeaway here is that not even audits help against these vulnerabilities. As a consequence, a multi-million dollar audit offers no guarantee that the project is safe and that it can prevent hacks to occur.
DeFi on DeFiChain
On native DeFi however, the consensus happens directly on the native blockchain layer — no application layer is needed. As a result, DeFiChain’s main blockchain layer is sufficient to process and validate financial transactions, making it much more secure than virtual machine blockchains. Most of the previously mentioned vulnerabilities with Turing-complete or virtual machine blockchains are completely disregarded on DeFiChain (as shown in Figure 2). Most importantly, the consensus happens directly on the DeFiChain blockchain.
DeFiChain’s interaction with the user happens — unlike on competing DEXs like Uniswap or 1inch — via an intuitive app. This approach guarantees utmost decentralisation whilst limiting a possible attack surface. As a result, DNS attacks, like the ones recently seen on CREAM Finance and Pancake Swap, become a thing of the past. The reason for this is that DeFiChain’s DEX is embedded directly into the app and is running completely peer-to-peer across thousands of computers, making an isolated website attack impossible.
Example
To better understand the distinctive steps required to achieve consensus, it is worth comparing how liquidity gets added on Uniswap (Ethereum) vs. on DeFiChain. For this purpose, let’s take a look into the following transaction, broadcasted to the Ethereum blockchain: https://etherscan.io/vmtrace?txhash=0xb51f3aedd963065f0b3c8cf2473a6fe929ba6803a9d87b55c36159f4e7f58abd.
Figure 3 shows all the distinct steps required by miners to validate transactions. It is apparent that, in the example below, there are more than three thousand different steps, where each single step has a potential attack surface. Each of these steps have to be actioned or input in order to perform even a simple transaction like adding liquidity to a pool. It is important to keep in mind that the EVM simply follows what it has been told to do, which is to perform more than three thousand steps without knowing what the outcome should be — the outcome is not checked for validity.
In stark contrast to this, the same transaction to add liquidity to a pool being performed on DeFiChain, looks like the one shown in Figure 4. The transaction hash on DeFiChain is: a767e065e2234615c465414bf76129335e9b4083711f56f83e256e91c943f0e3.
On DeFiChain, all you need to add funds to a liquidity pool can be written in a few lines of code. In Figure 4 it is shown that DFI (result parameter 0) and the respective amount of BTC (result parameter 2) are added to the DFI-BTC liquidity pool. As an immediate result, the liquidity token is then transferred to the address shown under “shareaddress”. That’s all you need to add liquidity to a pool on DeFiChain — no 3,700 instructions to perform a simple task like that, thereby greatly reducing the attack surface.
Summary
Native DeFi is a novel and long awaited concept in the DeFi space — aligning the interests of programmers and developers with those of the community. The maxim is no longer ‘we only care about our code’, but rather, taking a more customer and safety-centric narrative.
Especially in light of continued exploits and ‘rug pulls’ — even by audited projects — safety and security concerns of layer-2 projects on blockchains like Ethereum, remain a problem which can’t be neglected.
Some security firms have already predicted the worst year for DeFi data breaches and hacks ahead. Therefore, it’s all too understandable and just a matter of time until more users divert their holdings into Native DeFi projects like DeFiChain, simply to reduce exposure to vulnerabilities, while enjoying utmost decentralisation.
To stay up to date with the latest information and news, follow us on Twitter or join our Telegram group.
