概要

• 一個有效的 transaction 必須要被它的所有 input 和 output states中的 contract 接受
• Contracts 需要使用 JVM 程式語言編寫（java 或者 kotlin）
• Contract 的執行是一定要有一個確定性結果的，並且它對於一個 transaction 的接受是僅僅基於 transaction 的內容

Transaction 驗證

一個 transaction 僅僅當被所有要求的簽名方提供了簽名之後才會被認為是有效的。但是，除了獲得到所有人的簽名之後，還必須要滿足合約有效（contractually valid）才會被最終認為有效。

合約有效（Contractual validity）的定義包含以下幾點：

• 每個 state 都指向了一個合約（contract）
• 一個合約（contract） 將一個 transaction 作為輸入，並且介於合約的規則來宣告一個 transaction 是否被認為是有效的
• 一個 transaction 會在每個 input state 和每個 output state 中定義的合約都認為它是有效的情況下，才會被認為是有效的

我們可以用下圖來描述這個關係：

Contract code 可以用任何的 JVM 語言編寫，並且具有該語言的所有能力，包括：

• 檢查 inputs，outputs，commands 的數量，時間，和/或者 附件
• 檢查這些元件中的任何一個的內容
• 迴圈一個結構，給變數賦值，呼叫方法，幫助函式等等
• 將一些類似的 states 分組來驗證（比如對於所有的現金 state 的組合定義一個規則）

一個 transaction 如果不是合約有效（contractually valid）的話，是不會被視為一個對賬本的有效更新，也就不可能被提交至賬本。通過這種方式，合約會通過定義規則來不斷地更新 states 的狀態，並且每次更新必須要獲得所有相關的簽名。

The contract sandbox

Transaction 驗證必須是一個確定性的結果 - 一個 contract 必須或者總是接受，或者總是拒絕一個給定的 transaction。比如 transaction 是否有效不能夠取決於你在什麼時間做的 verify 或者是基於某一方具有的資訊量的多少來決定是有效的還是無效的。這是一個很重要的條件來確保網路上的相關節點能夠在這個對賬本的更新的操作達成共識（consensus）。

為了實現這一點，contract 來判斷 transaction 是否有效是在一個具有確定性結果的 sandbox 中進行的。這個 sandbox 有一個白名單（whitelist）能夠用來防止引入一些會造成不確定性的外部庫。這些庫包括提供當前日期的，產生隨機數的，提供訪問系統檔案的或者訪問網路的。本質上來講，當驗證一個 transaction 的時候，對於 contract 的資訊只應該來自於 transaction 自身的資訊，不應該引入除 transaction 意外的任何資訊。

Contract 的侷限性（limitation）

因為 contract 沒有辦法訪問到外部的資訊，它只能檢查 transaction 自身的有效性，比如它不能夠檢查確認當前這個 transaction 是不是已經同其他相關方達成了共識取得了其他方的確認。

所以在各方提供最終的簽名確認之前，各方應該對transaction 的內容進行檢查來確定他們是否同意這個對賬本的更新，即使這個 transaction 是合約有效（conceptual valid）的。任何一方是不會因為 transaction 是 contractually valid 就能夠去提供簽名。比如他們可能不願意去提供一個鉅額的借款，或者可能不會同意購買一個資產花費的錢的金額，雖然這些能夠正常地通過 contract code 的驗證，即 contractually valid，但是還是不會去接收這個 transaction 的。

Oracles

有的時候 transaction validity 需要取決於一些外部的資訊，比如兌換匯率。這種情況下就需要使用 oracle 了。

Legal pros

每一個合約也會引用一個 legal prose 文件，這個文件中定義了合約中規定的內容，legal prose 也會被傳統的法律系統所接受。這個文件會在發生法律糾紛的時候被用來進行判定依據。