Ethereum 2.0 hits 1 million staked ETH as institutional products pile into the crypto space
OKEx Academy Talks Recap: DCEP – How to ensure security for DeFi investors?
DeFi, short for Decentralized finance, had become a buzzword in cryptocurrency space since 2019. As DeFi grows, we are heading a step further to the future of finance. Creating a global and more transparent framework for every financial service today: savings, loans, trading, and more.
OKEx Academy had put together an online Webinar with some special guests to share their insights on DeFi security and how DeFi investors can ensure that their investments are safe.
This article will guide you through the recap of the discussion.
Yu Guo - Founder of the SECBIT Labs
Dominik Teiml - Lead Ethereum Auditor of Certik
Zhengchao Du - Senior Security Engineer at Slowmist
Michael Gui - Boxmining
Michael: Decentralized finance is growing at a rapid pace, currently we have more than $800 Million dollars with of crypto locked away in DeFi Smart contracts. As these contracts are decentralized, creators need to ensure that the code behind these contracts is secure. Failure to do so can result in catastrophic hacks – for example, less than 2 weeks ago a hacker managed to “steal” $25 Million worth of crypto from dForce contracts. Security from hacks such paramount to ensure the long term growth of DeFi. Luckily today we have a panel of security experts.
Starting off with a critical quote from a DeFi Critic "I only learn about DeFi when a project fails and loses funds". What do you think are the biggest security risks to decentralized finance?
SECBIT: The DeFi is built on code, which is composed of many modules, which were developed by different teams. The misunderstanding of basic modules, building blocks would bring bigger losses. The interface of each module is not easy to clarify, specify, or formalize.
Certik: Apart from the off-chain stuff such as security of keys, hijacking front-ends and/or DNS servers, OpSec, etc. I think the greatest on-chain risks are execution incorrectness (Hegic bug) and interaction with other accounts, namely: manipulable oracles (bZx hack) and re-entrancy attacks (Uniswap & Lendf.me hack)
Slowmist: Decentralized finance brings us three main features: interoperability, programmability, and Composability. Owing to these three features, we are able to combine all kinds of smart contracts like combining lego blocks, which brings us abundant financial products and infinite possibilities. However, DeFi is such a complicated system that the risks will be amplified. In another word, for the centralized financial system, the possible risk scenarios can be controlled by working on standards and limiting the access permissions, while for DeFi, any of two contracts that meet the standards of the agreement can be combined together, which means many more possible scenarios and each new scenario brings potential new risks. And the most important of all, a feature of a standard can become a defect under any circumstances.
Michael: Can we ever achieve complete safety with DeFi?
SECBIT: It's a holy-grail. It is impossible to reach the goal, both theoretically and practically. Any security is based on assumptions. The more complex the system, the more security assumptions are relied upon. But the reliability of these safety assumptions is unknown. In many cases, these safety assumptions may come loose.
In theory, the definition of safety is rather vague. We may define specific safety, for instance, free of integer overflows. But it is generally incomplete. As the concept of DeFi keeps growing, the meaning of safety is growing as well. We don't how to define a complete concept of safety.
Finance is risky by nature. Conventionally, the profits come from risk-taking. Now, the financial risks are mixed with computational complexity, and thus the combined risks are harder to control. In practice, safety is hard to be spotted, hard to be verified. There are safety issues may occurring in different levels, security assumption, blockchains, virtual machine and compilers, libraries, the logic of the code, the interface of services. None of them are easy to achieve bug-free.
One of the promising features of DeFi is that the smart contracts are highly composable, even if the smart contracts were developed by different teams. But we have seen bugs found on the interfaces—for example, ERC777, ERC827, ERC 233. The composability will make the system more open and dynamic. Many traditional approaches are about making the static system secure wouldn't work for the new, open, dynamic, and huge system.
Certik: Safety is a matter of diminishing returns. We can never be sure any logical reasoning is valid because we could be making a mistake in the verification itself, the paradox of logic. In the same way, we can never be 100% sure something is secure. However, I am very optimistic we can achieve high-security guarantees with the proper measures. Extensive and intensive audits, formal verification, generous bug bounties…
The more interesting question is whether these scales. Can we find a tool that automates security? Nobody has achieved that yet; it is still an open question.
Slowmist: Complete security is impossible for any products including DeFi. We should realize that security involves countermeasures, for the purpose that the hacker would cost much more than the benefits he might get. And security is dynamic, new scenarios, new techniques, and the iteration of DeFi products could cause new security problems, so be secure once and for all is not possible.
Michael: With new programming languages adopted – Vyper (Ethereum), Haskell (Cardano) – do you think this will help with blockchain security?
SECBIT: Vyper is pretty much like solidity, most of the improvements. Haskell, on the other hand, is more mathematical. But, as I said, the biggest security issues are from logic level, not the language level. New attacks are not on the language level purely, and they came from the whole blockchain system, which is very complicated. The hackers keep inventing new attacks that we've never seen before. The new vulnerabilities are hard to detect by tools embedded in compilers. We cannot imagine that attacks would be prevented automatically. We are going to see more vulnerabilities rooted from the logic level, even if the language tools are improving. The code must be audited by experts.
I appreciate the work from the programming language community, where static typing prevents programmers from making silly mistakes. For example, the language proposed by Facebook, named MOVE, is running on the Libra chain. It borrows the idea from RUST of "move vs. copy", "ownership and borrowing". The static type system makes sure that the total amount of digital assets is unchanged, such that neither developers nor hackers can.
On the other hand, we do need formal specifications or formal verifications to ensure the "correctness" to some extent. Not 100%, but maximal safety we only depend on mathematics. However, the tools and practices are still on the way. I do suggest the work from the CertiK team.
Certik: Probably. I think we underestimated security in the early phases of our ecosystem. We made architectural decisions that are extremely difficult to change afterward. The EVM has dynamic jumps, which make any static analysis extremely cumbersome, and there are hardly benefits at all. Solidity since 0.5, in my opinion, has become security-focused, reversing some of what was with hind-sight poor language design decisions.
Vyper is better, but unfortunately, it is not production-ready for big projects and lacks a lot of important features.
I’m actually excited about DeapSEA, an EVM-targeted programming language that tries to overcome these EVM-imposed challenges and allow for easier formal verification of Ethereum smart contracts. It’s being developed by Certik and Yale, and we’ll hear more about it soon.
Although that’s on a longer horizon, I think the transition to eWASM will be great for security. Not only is wasm much more sec-focused, but we will also be able to tap into its ecosystem of security tools.
Slowmist: These languages have their own security features. For example, Vyper performs a lot of overflow checks applying to arithmetic calculations, and functional languages like Haskell can help with formal verification. But security is multidimensional, and apart from the programming language secure features, the product development security and business logic security are as important as languages.
Michael: What is the most devastating account hack you’ve ever encountered? Any personal experience that you can share?
SECBIT: Key stolen. A few hundred ETH from one of our clients. But, more cases coming towards us for help were key-lost. People just forgot the mnemonic code or password. It is yet another dilemma in the security world. How could we remember a safe password? A weak password is easy to remember but with low entropy. It is vulnerable to brute-forcing attacks. (eg. Rainbow Table Attack); while a more random password is deadly hard to remember. Write it onto a paper? We may forget about the paper the other morning.
Certik: I am fortunate that none of the projects I ever worked on was hacked.
Slowmist: The Ethereum Black Valentine’s Day, named by our team. This security incident was first observed in march of 2018. The hacker had stolen the eths and other tokens from the user’s wallet with the automatic script for two years before we first found it. By now, about 54864 ETH with the current value of 10 million dollars were stolen from 6679 wallets. This hack is very impressive considering its influence and the time of duration.
Micahel: If there was ONE security tip for our viewers - The tip that you think will save our viewers potentially thousands of dollars – what would it be?
SECBIT: Practice to remember the mnemonic code; I know it is hard. It is extremely hard. But, trust me, that's the only way to keep your digital assets safe. Ask service providers how much budget they've spent on the security and risk-control, what countermeasures they've been taking, and read the materials like audit report, system design documents on the website. I think the providers who seriously run a business on the blockchain should have strict policies on that.
Certik: Read reports. Read an audit report before using any decentralized application. From time to time we see vulnerabilities pointed out during audits, never corrected, and later exploited. Check if the last report issued mentions any critical or significant vulnerabilities.
Slowmist: For personal assets, we suggest protecting your private key from the Internet.
For cryptocurrencies in DeFi products, we suggest that when choosing the DeFi products and platforms, the user should pay attention to both the risk control mechanism and the endorsement of security audits reports from an outstanding third-party security team. Besides, security is dynamic so everybody should check on the security background of defi products and platforms from now and then.