CoinEx Institute | The Security Predicament of Blockchain Assets: Reasons Why Real-world Time is Required as an Additional Security Layer
Since the DeFi Summer of 2020, driven by the continued advancement of blockchain infrastructures, DeFi protocols have evolved from Swap to Lend to Yield Farming to increasingly sophisticated protocols, covering AMM (automated market making) Yield Farming strategies based on blockchain derivatives, structured lending platforms built on lending infrastructure, and on-chain lending protocols connecting real-world collaterals, etc.
One of the key factors behind the boom of DeFi innovation is a concept called composability. Most of time, when a new DeFi protocol is released, most of its source code is also made available to the public. This means that source codes of smart contracts from one or more DeFi protocols can be easily composed together to create a new one. They work like Lego blocks — blocks in different shapes can be used to build unique projects, significantly lowering the cost of innovation.
Surprisingly, in light of such massive innovations, the number of DeFi users has not seen any significant growth since 2020. Meanwhile, traditional institutions have not put liquidity into the blockchain space. One of the major causes for this is the security concern of DeFi.
Real-world finance comes with a well-established, secure system. For instance, when moving funds from Bank A to Bank B, cash trucks and armed police officers will be there to keep the funds safe, which is a reassuring process. Moreover, the banks will also be responsible for a client’s property and will offer compensation for any loss during the process.
DeFi, however, differs from the legacy financial system. Smart contracts are immutable by design. They are essentially black boxes that will not send readable logs, so people cannot get a clear view of internal processes. Most smart contract audits don’t help as they focus on known forms of attacks only, rather than new types of flaws that are highly likely to occur. Meanwhile, many DeFi protocols label themselves as a “use-at-your-own-risk” product. This can be scary for regular users and make them have no confidence to put most of their bank deposits into a DeFi ecosystem.
DeFi has not disappointed those who did not trust it. So far, DeFi has seen 82 security breaches, with an initial hacked amount of over $1.8 billion. In particular, flash loan is the most common attack, accounting for 33 cases. One of the security reasons behind a flash loan attack is the lack of the concept of accurate time and a confirmation mechanism in blockchains. We will go through the specific reasons in the following chapters.
I. Time & the Time Network of Computers
Let’s first look at how time works in conventional computer programs.
Time is an essential concept to computer programs. Without the concept of time, it’s impossible to access any TLS-enabled website, create entropy for certain algorithms, exchange secrets, or authenticate Windows licenses. We take timekeeping on computers for granted, but exchanging and keeping track of time is an incredibly difficult problem to solve when it comes to actual operations.
Time is essentially a representation of the universe’s current global state. This means that for any given moment, every single entity must share the exact same value. This is obviously a huge problem for computers: Let’s assume there is a huge, highly accurate atomic clock in the center of the universe, transmitting time data across the Internet. A problem during this process is that transmitting data takes time by itself. When a device receives time data over the Internet and applies it to its own systems, the universe’s global state (time) would have already changed. In other words, it is impossible for a networking device to be perfectly up to date with the actual global time value.
Another problem with networked timekeeping is that we cannot perfectly predict the time required for data transmission — network conditions constantly change, and no one can guarantee perfect reliability out in the wild. Combined with the first problem, this means that the recipient cannot perfectly replicate the time value either, leading to inconsistencies.
The Network Time Protocol (NTP) solves this problem through the mutual verification structure of timekeeping servers distributed across the globe (up to 15 stratums) and by constructing a Bellman-Ford shortest-path spanning tree (which reduces both latency and transfer time inconsistencies). This works perfectly fine for personal computers and centralized services, especially with applications that rely on accurate timing (e.g. encryption programs). Even though timestamps derived through NTP are mere estimates, they are accurate and mature enough for time-critical applications to rely on.
II. Time Mechanism in Blockchain Networks
The concept of time also exists on blockchains. Though some say that blockchain itself is a derivative of the concept of time, a blockchain network’s processing of time is extremely imprecise compared with the 64-bit accuracy of the NTP system. After all, this is also because the service targets of blockchain time are not time-sensitive smart contract applications like DeFi applications. Moreover, it aims to enable the secure, efficient execution of the consensus mechanism. Such a different goal also makes blockchain networks more tolerant of time inaccuracies. In the following paragraphs, we will discuss some popular consensus mechanisms and how they determine time. That said, it should be noted that the confirmation of time on blockchains is so generally imprecise that they cannot carry the financial operations and security checks for on-chain assets that are worth tens of billions of dollars.
1. Bitcoin
Bitcoin features the concept of time because it is required for its Proof-of-Work consensus mechanism. Without a valid timestamp, the network cannot verify whether a particular transaction being mined is trying to tamper with a previous one. Though each Bitcoin block contains a UNIX timestamp, a block time is not an accurate representation of a UNIX timestamp. This is because Bitcoin consensus only considers timestamps as a part of PoW security system, not as an actual tool to measure time on the blockchain.
To quote Bitcoin Wiki, each block contains a Unix time timestamp provided by miners and will be accepted as valid if it is 1) greater than the median timestamp of the previous 11 blocks and 2) less than the network-adjusted time plus 2 hours. Therefore, the difference between block times and real-word times ranges from one hour to two hours.
2. Ethereum
In the Ethereum network, timestamps are also directly submitted by the miners with great flexibility. Simply put, an Ethereum timestamp might be either true or false, and there is no way for the consensus mechanism to confirm its accuracy. According to a post on the Ethereum forum（source：https://ethereum.stackexchange.com/questions/413/can-a-contract-safely-rely-on-block-timestamp/428#428）, several mechanisms can be used to prevent the excessive deviation of Ethereum timestamps: 1) If the timestamp of a block significantly deviates from the real-world time, no one will be willing to generate more blocks with this block as the parent block; 2) The timestamp of the latest block cannot be earlier than the parent block; 3) The block difficulty will be the lowest when the block is not marked earlier than required. These mechanisms could allow miners to voluntarily submit timestamps they believe to be correct. However, when other external incentives exist, the Ethereum network does not have any rigorous mechanism to ensure that miners still submit the correct timestamp. Therefore, the network cannot ensure the proper running of time-sensitive protocols (e.g. yield farming, lending). As such, big institutions will not trust Ethereum with their money.
3. Polkadot
According to Substrate’s document, Polkadot also marks blocks with timestamps that are directly provided by miners. Meanwhile, there are no rigorous mechanisms that confirm or synchronize such timestamps. The document also states that though the time of a block cannot be proven, validators can agree that it is within some delta of their system clock.
4. Cosmos
Cosmos’s Tendermint is the only consensus algorithm that writes time into the consensus mechanism, which equips it with the most robust concept of time. To be more specific, the nodes of a block will vote on the time it has submitted to reach a consensus, and only the timestamp that nodes agree on will be included in the block.
III. The Lack of a Timestamping System in Blocks
Blockchains are not only imprecise in terms of the generation of timestamps but also lack a timestamping system or mechanism within blocks. Real-world transactions are sent and then confirmed one by one, each of which comes with a clear time and sequence. In this way, many false transactions cannot occur or get confirmed. In a blockchain network, on the other hand, transactions within each block are packaged together and are not marked with accurate timestamps one by one.
Although all transactions can be verified after block generation, it is impossible to determine the specific submitting time and sequence of each transaction. This partly explains why many attacks (e.g. flash loans or flash swaps) can be pulled off. If accurate marks of time are provided within blocks as the proof for verification, application protocols could develop more secure and stable algorithms. Meanwhile, owing to its intrinsic characteristics, time is a highly secure consensus network that is irreversible and immutable.
IV. Potential Solutions
The lack of time on blockchains can be solved internally or externally.
Internal solution: A consensus-level confirmation mechanism that checks the block time against the real-world time should be introduced, or an independent time system with greater accuracy should be established.
External solution: Blockchains need a decentralized network that uses an NTP-like time oracle network to add precise timestamps to network blocks and transactions within blocks.
In light of multi-chain collaboration, the external solution might be more suitable. Assuming, for example, Ethereum and Terra have their own clocks, if the timestamps provided by these clocks are different, it will be difficult for us to determine which one is correct during interactions between the two. For example, in a conventional computer network, ultimately, only one master clock tells everyone what time it is. Blockchains also need a master clock.
In the future multiverse enabled by multiple chains, we will face another challenge — the number of clocks on all the different computers is way higher than what is expected. For example, there are gaming clocks, DeFi interest accruement clocks, blockchain clocks, etc. Since these clocks will disrupt the time in the meta nodes, a single reliable source of time will be needed to unify and synchronize all transactions. When such a time oracle network is eventually widely adopted, it will provide an extra security layer, offering additional time confirmations to each transaction, just like what happens in the real world. Time will also become an additional security layer for blockchain networks.
Reference:
- https://medium.com/@gokhansengun/bilgisayarlar-zaman%C4%B1-nas%C4%B1l-do%C4%9Fru-tutar-78c1203397f0
- https://en.bitcoin.it/wiki/Block_timestamp
- https://ethereum.stackexchange.com/questions/413/can-a-contract-safely-rely-on-block-timestamp/428#42
- https://wiki.polkadot.network/docs/build-protocol-info
- https://wiki.polkadot.network/docs/build-protocol-info
