本文將從EOS DApp 攻擊事件出發，以科普角度闡述安全隨機數的標準及現行公鏈上隨機數的生成機制。

自去年6月EOS主網上線之后，陸續發生DApp的智能合約被黑客入侵的事件，其中泛隨機數攻擊事件占了大多數，以下是攻擊事件列表：

以上19起EOS DApp攻擊事件，總共造成了超過100萬美元的損失，其中14起為隨機數攻擊，另外5起為回滾攻擊，這些攻擊都直接或間接地與隨機數有關，可稱為泛隨機數攻擊。隨著這些攻擊事件的發生，區塊鏈上隨機數的安全性也越來越被廣泛關注。

什么是「安全」的隨機數？

先想想我們對隨機數的要求是什么，生活中很多地方會用到隨機數，當它至關重要時，我們才會要求它「公正」、「安全」。例如樂透彩開獎時，樂透公司讓大家的檢驗方式是租一個頻道，預先讓第三方背書數組公正的彩球，公開在頻道上取一組彩球，將彩球放到抽獎箱中打亂，再一顆一顆吸出彩球得到號碼，用意就是為了讓大家相信抽簽的過程是公正的。

然而，這也未必能真正達到公正，比如說，這第三方和樂透公司共謀時，可以在彩球裝上磁鐵，最后只有有磁鐵的彩球會被吸出來，讓這看似隨機的過程其實并不隨機。

至此，我們先做一個小結論，一個好的隨機數應該要滿足以下三個特質：

· 無法被操縱或預測（不能用磁鐵改變抽中的彩球）

· 可以被公眾驗證其隨機性（大家可以相信開球過程是真的隨機）

· 無需信任第三方（不需要找律師確認彩球沒問題）

除了現實生活中的樂透開獎之外，開發程式時也常會需要隨機數，譬如競猜、***、隨機分配任務等，我們先有了隨機數的概念后，再來看目前區塊鏈上的隨機數有什么問題。

區塊鏈上的隨機數是怎么來的？

目前EOS 跟Ethereum 都沒有提供官方的隨機數生成服務，如果開發者需要在智能合約上使用隨機數的話，他們有兩個選擇 — — 自己產生隨機數或是仰賴第三方oracle。

Ethereum 官方推薦使用Oraclize （一個第三方的oracle 服務）來產生隨機數，但去中心化的區塊鏈要仰賴中心化的第三方提供隨機數，完全就是本末倒置。而且對于一個熱門的DApp 來說，頻繁的調用第三方的oracle 是很昂貴的，可能還會增加完成步驟所需的transaction 數，而造成DApp 的latency 增加，所以大多數開發者都傾向自己產生隨機數。

問題來了，在官方不提供隨機數生成服務的狀況下，公鏈上的開發者只能自行根據公鏈上能取到的各種變量來作為隨機數種子，而這些變量往往來自于區塊的訊息，這么做很容易讓有心人士可以去預測隨機數。

舉例來說，前陣子被攻擊的EOSDice 就是采用了tapos_block_prefix（） 跟tapos_block_num（） 這兩個變量作為隨機數種子，而它們正是下注transaction的「前一個區塊」的資訊。

聰明的讀者可能已經發現哪里不對勁了，隨機數的種子居然在下注前就已經形成了！駭客正是看出了這個規則，才能預測出「必定中注」的隨機數，在不公平的狀況下贏走莊家的錢。

EOSDice在第一次黑客事件后，旋即修正了隨機數生成的方式，開發者改用雙重的deferred action延遲了開獎的時間，使得reference block變成下注時還未生成的區塊，如此一來就無法事先取得區塊資訊。但道高一尺魔高一丈，駭客直接寫了一個合約去模擬EOSDice合約的行為，只要兩種合約運行在同一個區塊，就會refer相同的block，進而得到相同的區塊資訊，于是乎EOSDice又被駭了第二次…

由于公鏈上的區塊資訊是公開的，現行在智能合約中采用「區塊資訊」生成隨機數的做法，其安全性不管再怎么設計都會有其極限。一個好的隨機數生成方式不應該仰賴第三方oracle ，且必須滿足「不可被預測」的特質，就這點看來， EOS 跟Ethereum 都還還做得不夠好。

當EOS的技術長Daniel Larimer被開發者問到隨機數安全性的問題時，他提出了一個「信任區塊生產者」的方案— —區塊生產者在打包交易時，在某個特定時機獲取特定訊息，以此作為隨機數種子來生成偽隨機數。雖說這是一個鏈上的解決方案，但這種做法其實跟仰賴oracle的本質并無不同，一樣都是由一個中心化的第三方來提供隨機數，EOS的DPoS制度已經賦予少數區塊生產者極大的權力，若他們還能直接參與隨機數生成的過程，那中心化的風險就更高了。

如果公鏈隨機數的安全性問題一直存在，那么任何需要「公平隨機數」的程式邏輯就無法安心地運行在公鏈上，這對整個區塊鏈生態系的發展都有不利的影響。