需要注意的是，這些方面在開發期間和部署之後都是需要的。當一個完全不靈活的系統達到一定的規模時，開發起來就變得非常笨拙。常見的情況是，智慧合約有成百上千條線。它們通常包含自己的資料儲存，資料儲存由同一合約中定義的業務規則操作。
我們在一段時間前開始嘗試將表示業務規則的程式碼與僅管理資料的程式碼分離成獨立的合約。為了有效，業務規則需要具有完全能夠修改資料的能力。因為區塊鏈程式設計環境的安全性(如可靠性)主要圍繞基於傳送方的行為進行限制。傳送方將邏輯從處理資料的合約中分離出來意味著您需要的是保護的合約——不對外公開的合約。這些合約只能由已白名單的其他合約或地址呼叫。
將資料和行為分割成單獨的合約會引入幾個有趣的屬性。
首先，由於許多原因，在區塊鏈上遷移資料是有問題的。使用簡單的CRUD功能將資料儲存封裝在其自己的合約中，可以減少所包含合約需要更改的可能性。然而，將業務規則移動到它們自己的、獨立的合約中，允許我們升級系統的邏輯，而不需要重新建立資料的狀態。
此外，拆分資料儲存和業務邏輯允許我們為特定主題定義穩定的介面，同時保持實現的靈活性。
這很好，有幾個原因。
首先，不依賴於不使用的東西是一種良好的軟體實踐。所以，如果一個外部系統依賴於我們系統的一組特定的功能，如果它們僅僅依賴於功能的子集而不是系統中的所有東西，這是很有用的。
舉個例子，假設我們有一個智慧的租車合約系統。我們決定把所有的程式碼放在一個大合約中。我們的合約包含了很多邏輯，但是一個叫carp的第三方僅僅關注人們的租車歷史，以建立一個新的信譽系統。
瞧，我們需要升級汽車清潔記錄在合約中的方式，因此我們修復了這個問題並部署了一個新合約。當然，我們修復了所有指向新合約的內部應用程式，並將變更通知(我們知道正在使用我們合同的人)。現在，carp必須改變他們的程式碼，因為我們決定改變我們處理汽車清潔的方式。然而，如果我們溝通不好，我們就破壞了他們的系統。
如果我們把邏輯分解成不同的合約，carp就不必改變任何東西了。
其次，如果我們定義指向業務邏輯實現的高階介面，那麼carp只需要在我們更改高階公共API的情況下更改它們的程式碼。如果我們在使用定義和命名之前非常小心，這些更改可能很少。這基本上與我們期望Stripe或Twitter等主要公共api版本能夠正常工作的方式相同。
最後，遵循我們所設定的模式允許我們的系統遵循開閉原則——我們可以向系統新增新的行為，而不需要修改原始碼。我們可以簡單地部署新元件，並在需要的地方將它們納入白名單，這樣它們就可以獲得與我們的系統互動的授權。
可信任性
關於智慧合約的早期觀點之一是，它們具有約束力——因此有了“合約”這個詞。描述是這樣的:“Joe和我就誰將贏進行打賭。協議一旦達成，就無法撤銷。一旦選舉結束，智慧合約將獎勵獲勝者。從這個意義上說，智慧合約也是“不可信的”，因為我可以完全依賴程式碼來執行指定的合約，而不需要中介。
這與之前關於需要升級合約的論點形成了鮮明的對比。如果我能獨自升級一份合約，那麼我就能做各種惡意或有偏見的事情，而且我已經重新引入了人們信任我的必要性。
這提出了一個基本的衝突。正如Robert Martin在他的書《潔淨建築》中指出的，軟體必須是軟的——也就是說，它必須易於更改。“如果我不能修改程式碼，就會出現各種各樣的問題。”另一方面，如果一合約同可以改變，還能說它是一個合約嗎?
部分問題可能在於“智慧合約”一詞選擇不當。有些東西肯定屬於合約的範疇，但是像以太坊上的solid這樣的通用程式設計環境允許建立各種各樣的東西，其中一些在本質上不那麼具有合約性一樣。
在我看來，這是一個遠未解決的問題。然而，我將提供一些想法:
首先，在規模上，我希望有非常少的使用者能夠真正地閱讀程式碼並理解他們所簽署的內容。因此，從這個意義上說，他們通常會相信他們所接觸的公司、網站、平臺等並不是惡意的。
其次，在許多情況下，這個問題可以透過要求多個開發人員簽署正在部署的更改來解決。這將減少開發人員塗脂抹粉和搶劫的可能性。
第三，對於非常敏感的系統，在推出更改之前，可能需要外部審計人員在多個開發人員之外簽署更改。在需要完全去中心化的情況下，可以使用TCR來管理核准的開發人員和審計人員名單。
更多區塊鏈資訊：www.qukuaiwang.com.cn/news
