Back to all stories
Leveraging Trust for a Secure Blockchain Framework
Leveraging Trust for a Secure Blockchain Framework

Since the beginnings of Bitcoin, the blockchain ecosystem has continued to develop and improve on core components like consensus protocols, virtual machines, smart contract languages, cryptographic theories, and much more. While each advancement is important in building stronger blockchains, the industry is still waiting for the next big thing.

To understand why, we first must understand why security matters to blockchain, and why that security is critical for blockchain’s long-term growth.

Blockchain was built to be secure. In comparison to traditional computer and distributed systems, blockchains are built on sound and secure architecture––allowing them to operate as their own encrypted, decentralized and self-contained systems.

So, what’s preventing these secure blockchain from progressing into mainstream adoption


Ironically, while blockchain was created to solve for trust -- by allowing people to work in an encrypted, protected environment -- many still don’t trust the blockchain itself. High-profile heists have only added to uneasy public sentiment. And those hacks, made possible by the lack of end-to-end security, contributed heavily to public anxiety over blockchain safety–– a key factor restricting the current development of the blockchain ecosystem.

The Blockchain Environment

First, while the broader blockchain system is decentralized, (meaning no individual authority is in charge) each individual blockchain environment is essentially centralized by nature. Almost every blockchain has the same, or very similar, "mainstream" software implementation.

That commonality extends upwards. Each of these use the same operating system, which extends to the same master nodes, security protection settings, processor hardware and so on.

For all their encrypted diversity, the blockchain tends to have a common ground. That means, for all of their excellent protections, they all have the same problem: if you can crack the centralized software foundations, these blockchains are vulnerable.

This is also true if you look at smart contracts. The same contract may be called many times, causing a problem since most of these contracts carry immutable financial information.

At CertiK, we know that software, even at its best, is very difficult to guarantee for security and correctness. In this sense, no matter how good their external protections are, many of the currently established blockchain systems are inherently insecure.

Because blockchain is distributed––remember, it’s not centralized––any potential software problem could be amplified thousands of times in the blockchain ecosystem, resulting in huge economic losses and a breach of trust that could be hard to correct.

As alarming as it is, there is a startling amount of data to back this up. In 2017, hackers stole over $260 million in digital currencies worldwide. In 2018, this number more than quintupled to $1.7 billion in total thefts. And that number almost tripled to $4.3 billion US dollars––in the first six months of 2019 alone!

Some of this can be accounted for in the rising value and adoption of digital currencies. However, with higher value comes higher risk. And, with so many blockchains built on fundamentally unsound software, the question is when––not if––the next big hack will occur.

It doesn’t have to be this way.

Blockchain Needs End-to-End Full Ecological Security

From the perspective of ordinary users, the blockchain may be equivalent to node software plus smart contracts. But the blockchain and security goes far deeper.

If you were to look inside the blockchain software, you’d see the complexity firsthand. It can be explained as a simple stack of layers, similar to this top-down method:

Off-chain and cross-chain protocols

  1. Smart Contracts and Distributed Applications

    1. Programming language and compiler

      1. Smart Contract Execution Environment

        1. Blockchain Consensus Layer

          1. Operating system and storage system

If there’s a problem with any logical level of security and correctness, there’s a problem anywhere. And, as we discussed, with most of these blockchains built on the same Operating Systems, the very base layer, these systems have vulnerabilities potentially built into their very core.

Therefore, CertiK's high level view on blockchain security is that the blockchain needs end-to-end ecological security. At every technical level of the stack, it’s necessary to ensure its safety and correctness as much as possible.

To do so, CertiK recommends a few best practices.

  1. At the off-chain and cross-chain protocol level, semi-automatic theorem proving tools can be used to help verify the protocol mathematically.
  2. At the smart contract level, an automatic theorem proof tool can be used to verify contract codes, supplemented by manual security audits.
  3. At the programming language and compiler level, certified compiler technology can be used to ensure the correctness of the translation from original code to Byte-code.
  4. At the smart contract execution layer, deep security needs to be adopted for two-way security protection. On the one hand, the operation of the contract is protected from external attacks. On the other hand, the operating environment is protected from attacks by malicious contracts, which affects the overall security of the blockchain system.
  5. At the blockchain consensus layer, in addition to using a semi-automatic theorem proof tool to prove the consensus protocol, formal protocol verification technology is needed to verify the protocol implementation code.
  6. At the operating system and storage system level, a fully formalized operating system kernel is required to comply with common standards such as Posix. This is because mainstream operating systems like Linux have hundreds of serious kernel vulnerability CVEs every year.

If any one of them is unintentionally triggered by blockchain software or is attacked by a malicious network, the entire system can be compromised or even destroyed. As you can see, there is a lot of work to be done to achieve the overall goal of blockchain ecological security.

CertiK Chain's Layout of the Secure Blockchain Ecosystem

To fix this, we’d need to solve at the bottom layer––the operating system––with something we can formally prove as secure.

Fortunately, CertiK has worked on a potential solution: the CertiK Chain. The CertiK Chain is the world's first blockchain with complete security as its core with the following main design considerations.

DeepSEA, CertiK VM (CVM), CertiKOS

DeepSEA is a programming language designed for smart contract development, and was used to develop the world's first fully formalized concurrent operating system, CertiKOS.

DeepSEA has two major features. The first is that it can be used to verify the correctness and security of these codes while generating mathematical proofs that can be easily mechanically verified. The second is that its compiler, a fully certified compiler, ensures the generated bytecode and source code are consistent, thereby offsetting the security risks caused by compiler vulnerabilities.

The guarantee here is not just a sales pitch, but also a mathematical proof that can be mechanically verified. To develop this, CertiK has worked closely with Yale University, Columbia University and other research institutions.

CertiK VM, as a smart contract operating environment designed for CertiK Chain, has two main characteristics. The first is to introduce security as first-class value into the smart contract operation scenario. At present, the security of smart contracts only stays off-chain. For example, a contract is audited or formally verified. This is an off-chain knowledge that is not reflected on the chain at all, which leads to a variety of secure and insecure smart contracts running on the blockchain.

CVM introduces these security attributes into the operating environment of smart contracts, so smart contracts can monitor the security attributes of other contracts in real time and react differently to different situations. For example, a money transfer contract can allow a large amount of operations to a secure caller, while allowing only a small amount of operations to an unsafe caller.

Secondly, the CVM will be a smart contract operation sandbox, and will adopt the latest operating system virtualization technology to completely isolate the operation of smart contracts. The challenge here is how to balance security and efficiency to solve the tension between security and scale.

Here, the latest operating system virtualization technologies, such as gVisor, Kata Container, and FrieCracker, can help. There are many benefits to this approach, and in addition to important security isolation, there are several aspects. One is that CVM will not be limited to one or several specific VMs in the end, such as EVM, eWasm, etc., but can support any x86 code. The other is that CertiK Chain will provide more advanced virtualization services, such as allowing smart contract rollbacks.

Currently, CertiKOS is mainly used as a hypervisor, on which you can run Linux, etc., and then run node software, but CertiK Chain's long-term goal is to remove Linux to ensure secure system software such as CertiKOS can support node software directly. This will not only have efficiency benefits, but also greatly improve the overall security of the blockchain system. At present, DeepSEA, CertiK Chain, and CertiKOS are all under intense development and testing. The first official version is expected to be released in the first half of the year.

At present, DeepSEA, CertiK Chain, and CertiKOS are all under intense development and testing.

The first official version is expected to be released in the first half of the year. We hope you’ll join us in celebrating what promises to be a major step forward for a more secure blockchain environment.