如果一個程序在不同的計算機、或者在同一臺計算機上的不同時刻多次運行，對于相同的輸入能夠保證產生相同的輸出，則稱該程序的行為是確定性的，反之則稱該程序的行為是非確定性的。使程序產生非確定性的因素有很多，總結起來有以下幾種：
調用了非確定性的系統函數
一般在編寫程序的時候，開發者或多或少會調用一些系統提供的函數和功能以減少開發的工作量。這些系統函數中可能會存在一些非確定性的函數，比如生成隨機數、獲取系統時間等。一旦程序調用了另一個非確定性的程序并使用了它們輸出的內容，那么該程序自身的行為也可能會變為非確定性的。
使用了非確定性的數據來源
如果一個程序在運行時獲取數據，而數據源提供的是非確定性的數據，那么該程序也可能會變成非確定性的程序。例如，通過搜索引擎來獲取某個關鍵詞的前10條搜索結果——搜索引擎針對不同的IP地址來源可能會返回不同的排序結果。
動態調用
動態調用是指，一個程序在調用另一個程序時，如果必須在運行時才能確定被調用的目標，則稱該調用為動態調用；反之，如果在運行前即可確定被調用的目標，且在運行時無法變更該目標，則稱該調用為靜態調用。由于動態調用的目標在運行時決定，因此其行為是非確定的。
對于
區塊鏈上的智能合約，我們一般要求它的行為必須是確定性的，因為非確定性的合約可能會破壞系統的一致性。區塊鏈的作者必須考慮到這個問題，并在設計智能合約系統的時候，就想辦法把非確定性因素排除在外。那么我們來看看現有的各個區塊鏈是如何解決這個問題的。
比特幣內置了一套腳本引擎，用于執行鑒權腳本，它是區塊鏈智能合約的雛形。開發者可以基于這套腳本系統來開發一些簡單的應用，但由于其指令集非常簡單且非圖靈完備，能夠實現功能相當有限。這套系統既沒有提供任何系統函數，也沒有提供任何訪問數據的能力，更沒有動態調用的功能，甚至連靜態調用也沒有提供，因此比特幣的智能合約一定是確定性的。
以太坊的主要設計思想，就是提供一個圖靈完備的智能合約平臺，讓用戶可以編寫任意邏輯的程序。它專門開發了一個用于執行合約代碼的虛擬機EVM，并設計了一種類似于JavaScript的高級語言Solidity，以方便用戶進行開發。以太坊智能合約沒有提供任何非確定性的系統函數，可訪問的數據也僅限于鏈內數據，外部數據需要通過交易來發送到合約。但是，以太坊的CALL和CALLCODE指令的目標地址通過棧來傳遞，使得合約可以在運行時動態調用其它的合約代碼，使合約的調用路徑變為非確定性。好在合約可以訪問到的數據都是確定性的，使得所有節點在動態調用目標代碼時一定會獲得相同的目標地址，保證了系統的一致性。但是調用路徑的非確定性，會導致一個可擴展性上的重要性能損失，具體會在《重構智能合約（中）：平行宇宙與無限擴展》中詳述。
Fabric
Fabric是超級賬本中的一個子項目，它的智能合約采用了重量級的Docker作為執行環境。這可能跟大家的印象有點矛盾——“Docker不是一直被認為是一種輕量級的容器技術嗎？”。實際上，Docker的“輕”是相對于模擬物理機架構的重量級虛擬化技術而言。在
區塊鏈應用場景下，Docker是一個比較“重”的執行環境，這也是Fabric的性能瓶頸所在，目前只能達到每秒幾百TPS。由于Docker的特性，智能合約幾乎可以使用物理計算機上的所有功能，因此具有極高的非確定性。所以Fabric要求智能合約的開發者在編寫代碼的時候盡量避免使用到具有非確定性的功能，并計劃提供一套專門開發的確定性系統函數庫供開發者使用。然而，由于無法從底層機制上避免非確定性的產生，寄托于開發者遵守良好的開發規范難免有些一廂情愿。非確定性就像幽靈一般，平時似乎并不存在，在一些邊緣案例（corner case）上就可能會突然冒出來造成難以判斷的故障。
版權申明：本內容來自于互聯網，屬第三方匯集推薦平臺。本文的版權歸原作者所有，文章言論不代表鏈門戶的觀點，鏈門戶不承擔任何法律責任。如有侵權請聯系QQ：3341927519進行反饋。
