場景簡介
? ? ? ? 對于合約來說愿卸，一般來說都是先被部署，然后才會才會發(fā)生相關(guān)的交易行為截型，進而產(chǎn)生數(shù)據(jù)和余額趴荸。但是有一種特殊情況，就是通過提前計算合約的地址宦焦，往里面轉(zhuǎn)賬发钝。這樣的話，如果合約創(chuàng)建后誤以為自己的余額是零波闹，以ether 余額去做一些邏輯處理酝豪，就會出錯。
? ? ? ? 合約地址計算邏輯：通過合約部署賬戶和交易nonce精堕，依次經(jīng)過 rlp 和 sha3加密算法孵淘，截圖如下
合約地址生成邏輯
攻擊場景
? ? ? ? ? ? 如果有這樣一個抽獎合約，通過計算當前的賬戶余額是否達到設(shè)定值決定獲獎用戶歹篓，則可能出現(xiàn)問題瘫证，截圖如下：
抽獎合約
? ? ? ? 該合約每次只允許用戶轉(zhuǎn)賬0.5揉阎，首先達到 1ether的話該用戶就會成為幸運用戶，正常情況下痛悯，第二個用戶就會成為幸運用戶余黎。測試代碼邏輯如下：
正常情況
但是如果一開始就有人繞過合約規(guī)則，在合約產(chǎn)生前就給合約轉(zhuǎn)賬载萌，那就永遠沒人可以中獎了惧财，測試代碼邏輯如下：
異常情況下
解決方式
? ? ? ? 解決方式其實也很簡單，就是合約邏輯中盡量不要以 ether余額做相關(guān)邏輯處理扭仁，可以用自己申明的一個變量代替垮衷。? ?
