CoinEx研究院 | 區塊鏈資產安全困境：為何需要現實時間作為額外的安全層

從2020年夏天DeFi爆發以來，依託區塊鏈基礎設施的持續發展，DeFi協議已經從簡單的兌換（Swap）、借貸（Lend）、生息（Yield Farming），到衍生出了更多更複雜的協議，比如各類基於鏈上衍生品的自動化做市生息收益策略，基於借貸基礎設施的結構化借貸平臺以及連接真實世界抵押的鏈上借貸協議等。

DeFi 創新繁榮背後的關鍵因素是一個稱為可組合金融的概念（Composability）。當一個新的DeFi協議發佈時，它的大部分源代碼也會向公眾開放。這意味著來自一個或多個 DeFi協議的智能合約源代碼可以很輕易地組合在一起並創建一個新的源代碼；這就像樂高積木一樣，用不同形狀的底層積木就可以搭建成一個個不同的獨特的作品，而這顯著降低了創新的成本。

令人意外的是，在這種大規模創新的背景下，從2020年到現在，DeFi的用戶並沒有呈現出下一個階梯式的大增長（即沒有更多的個人用戶參加DeFi的金融世界），而傳統的大機構也沒有把流動性放入區塊鏈中。出現這一局面的其中一個主要原因是DeFi的安全性問題。

現實世界的金融有著一個非常完善而安全的體系。比如從銀行A調集資金去銀行B，會有運鈔車及持有真槍實彈的員警護送，這是一個很讓人安心的流程；而且銀行本身也會對用戶的財產負責，即使在運輸中被劫了，也會賠償用戶損失。 而在DeFi中則不然。智能合約在設計上是不可變的，它們本質上是黑盒，每次不會發出可讀的日誌，這也讓人無法清晰地看到內部的流程。大多數智能合約審計也無濟於事，它們更多的是針對已知形式的攻擊的檢查，而很難發現極有可能出現的新型攻擊漏洞。同時，由於很多協議在使用的時候就標上了use-at-your-own-risk的標籤，這也讓更加普通用戶望而止步，沒有信心把大部分自己的銀行存款放入DeFi生態中。 而DeFi也沒有讓對它沒信心的人失望，迄今為止DeFi一共發生了82起安全事故，起始被盜金額超18億美元。在這裏面，閃電貸是駭客最常用的手段，占到了33起。閃電貸攻擊的其中一個安全原因，就是區塊鏈中缺少了準確時間的概念以及確認機制，下文會詳細說明其原因。

一、時間&電腦的時間網路

我們首先來看看在傳統電腦程式中時間是怎麼運作的。

在電腦程式中，時間也是基本概念。如果沒有時間的概念，就不可能訪問任何啟用 TLS的網站、為某些演算法創建熵、交換秘密或驗證Windows許可證。我們在常識上已經認同了在電腦上計時是理所當然的。不過在實際操作中，交換和跟蹤時間實際上是一個非常難以解決的問題。

時間本質上是宇宙當前全球狀態的代表。這意味著在任何給定時刻，每個實體都必須共用完全相同的值。對於電腦來說，這是一個巨大的問題：假設宇宙中心有一個巨大的、高度精確的原子鐘，通過互聯網傳輸時間數據，而在這中間，傳輸數據本身就需要時間。當設備通過Internet接收時間數據並將其應用到自己的系統時，宇宙的全局狀態（時間）就已經發生了變化。換句話說，網路設備不可能完全與實際的全球時間值保持同步。

而網路計時的另一個問題是，人們無法完美地預測數據傳輸所需的時間——由於網路條件不斷變化，沒有人能保證在野外完全可靠。結合上面的問題，這意味著接收方也不能完美地複製時間價值，從而出現時間不一致。

網路時間協議（NTP）通過分佈在全球（最多15個層）的計時伺服器層的相互驗證校對結構，以及構建Bellman-Ford最短路徑生成樹（減少延遲和傳輸時間不一致）解決了這個問題。這個方法對於個人電腦和中心化的服務非常有效，尤其是對於依賴精確計時的應用程式（例如加密程式）。儘管通過NTP導出的時間戳只是估計值，但它們已足夠準確和成熟，足以讓時間關鍵型應用程式依賴。

來源： 

https://medium.com/@gokhansengun/bilgisayarlar-zamanı-nasıl-doğru-tutar-78c1203397f0

二、各類區塊鏈網路中的時間機制

區塊鏈網路中同樣有時間的概念，也有人說其實區塊鏈本身就是時間概念的衍生，但是實際上，相比於NTP系統64位秒比特的精確度，區塊鏈網路對於時間的處理是非常不嚴謹的。歸根結底，這也是因為其服務對象並不是那些對時間非常敏感的智能合約應用（如DeFi應用），它的目的是讓共識機制可以安全有效地執行。在目的上的區別也決定了區塊鏈網路對時間確定的寬容屬性。以下會舉例一些流行的共識機制以及其對時間的確定方法，但總的來說，區塊鏈網路中的時間確認都非常粗糙，無法承載百億級別的鏈上資產的金融運作以及安全性檢查。

1.Bitcoin

比特幣網路有時間的概念，是因為它基於工作量證明共識機制所必需的：如果沒有有效的時間戳，網路就無法驗證正在挖掘的特定交易是否在試圖篡改之前發生的交易。網路在每一個比特幣區塊中都包含一個UNIX時間戳，但是這個區塊時間並不是UNIX時間戳的準確表示。這是因為比特幣網路僅使用時間戳作為確保PoW安全的輔助來源，而不是作為衡量鏈上時間的實際工具。

引用比特幣維基的說法，每個區塊的時間由礦工提供，當滿足下麵兩個條件時，它會被認為是有效的：1.大於前11個區塊時間戳的中位數；2.小於其他節點提交的時間戳的中位數加上2小時。綜上，我們理解為區塊時間和現實時間可以相差1到2小時。

來源：https://en.bitcoin.it/wiki/Block_timestamp

2.Ethereum

以太坊網路的時間戳也是由礦工直接提交，而礦工的時間戳可以由礦工自由提供（即可真可假，共識機制並沒有任何確認時間是否準確的機制）。根據以太坊論壇的回答（來源：https://ethereum.stackexchange.com/questions/413/can-a-contract-safely-rely-on-block-timestamp/428#428），有幾個機制可以防止區塊的時間戳偏離過遠：1.如果區塊時間偏離太遠，沒有人會願意以這個區塊作為母區塊繼續出塊；2.最新區塊的時間不可以早於母區塊；3.當不過早地標記區塊，出塊難度會最低。這幾個機制使得礦工自願提交他們認為最正確的時間戳，然而當有其他外部激勵出現的時候，網路沒有任何更強硬的機制保證礦工依然提交正確的區塊時間戳，這會讓那些時間敏感的協議（如生息借貸等）的正確運行難以得到有效的保證，也難以獲得大體量資本的信任。

3.Polkadot

在Substrate的文檔中，波卡也是用時間戳對出塊進行標記，但同時也是由礦工直接提供時間戳，並沒有任何強硬的機制對時間進行確認或者同步。在其文檔中也說到，區塊的時間無法被證明，但是驗證者們可以在一定的時間delta範圍內同意這個時間。

來源：https://wiki.polkadot.network/docs/build-protocol-info

4.Cosmos

Cosmos的Tendermint系統是目前主流網路類型中唯一把時間寫入了共識機制的，因此它也有著最穩固以及可靠的時間概念。區塊的節點會對提交的時間進行共識投票，只有投票通過了才能成為區塊的時間，進而寫入區塊中。

來源：https://docs.tendermint.com/master/spec/consensus/bft-time.html

三、缺乏區塊內時間標記

區塊鏈不僅在對區塊時間戳的生成方面不嚴謹，同時也缺乏一個區塊內的時間標記系統或機制。真實世界的交易是一筆一筆發出然後確認，每一筆交易都會有明確的時間順序。這讓很多虛假的交易無法發生以及確認，因為我們可以從時間發生的角度一筆一筆地追溯然後驗證真實的交易、拒絕虛假的交易。但是在區塊鏈網路中，每個區塊的交易是打包在一起，這些交易並沒有被一一掛上準確的時間標記。

出塊後的交易雖然每一筆都可查，但是卻無法得知每一筆交易的具體下單時間以及先後順序。這也是很多駭客攻擊（如Flash Loan或Flash Swap）可以成功的原因之一。如果有了區塊內的時間作為對賬，應用協議就可以根據其開發出更加安全穩固的演算法。而時間由於其本身的自然屬性，是非常安全的共識網路，不可逆也不可篡改。

四、潛在的解決方案

區塊鏈缺乏時間的問題其實可以被內部或者外部解決。

內部：需要從共識機制的層面引入外部世界時間確認的機制，或者自己創建獨立的精度更高的時間系統。

外部：需要有一個去去中心化的類似時間語言機的網路，其採用類似NTP的精準時間喂值機制（Time oracle network）給網路區塊以及區塊內的交易加上精准的時間標記。

在考慮到多鏈協同的問題時，外部的解決方案可能會更合適。假設太坊有自己的時鐘，Terra有自己的時鐘，如果這些時鐘不同，當鏈與鏈的交互發生時，我們就很難驗證哪個時鐘是正確的。這個邏輯就像平常我們在普通電腦網絡中，最終只有一個主時鐘告訴每個人現在幾點了，區塊鏈也需要同樣的東西。

在今後多鏈並行的多元宇宙中還有一個問題，那就是實際上所有這些不同電腦中的時鐘比我們意識到的還要多得多，比如有遊戲時鐘、DeFi計息伺服器時鐘和區塊鏈時鐘等。這些時鐘混淆了在元節點中的時間，因此需要擁有單一的可靠時間來源來幫助統一和同步交易。當其廣泛適用後，最終，這個時間喂值網路（Time oracle network）將會提供額外的安全層，讓每一筆交易得到額外的、類似真實世界交易的時間順序確認，而時間也成為了區塊鏈網路中額外的一個安全層。

引用：

1. https://medium.com/@gokhansengun/bilgisayarlar-zamanı-nasıl-doğru-tutar-78c1203397f0

2. https://en.bitcoin.it/wiki/Block_timestamp

3. https://ethereum.stackexchange.com/questions/413/can-a-contract-safely-rely-on-block-timestamp/428#42

4. https://wiki.polkadot.network/docs/build-protocol-info

5. https://wiki.polkadot.network/docs/build-protocol-info