如果您花了很多時間在傳統(tǒng)的軟件開發(fā)環(huán)境中工作，那么在以太坊這樣的平臺上處理智能合約是一個有趣的挑戰(zhàn)。一旦部署，智能合約就永遠(yuǎn)無法從網(wǎng)絡(luò)中刪除。

在早期，諸如“終止開關(guān)”之類的東西出現(xiàn)的目的是在出現(xiàn)問題時關(guān)閉合約。這些關(guān)閉開關(guān)不能由任何人激活，但通常需要由合約創(chuàng)建者 （即它們是集中控制功能）激活。

這些簡單的終止開關(guān)突出了分散計算中一個極其重要的權(quán)衡：可升級性與可信任性。

可升級性

可升級性可以定義為程序員在將來某個時候修改軟件行為的能力。

終止開關(guān)顯然符合這個定義。終止開關(guān)通常需要在合約中預(yù)先編程，因此對精明的用戶（但可能不是普通用戶）是透明的。更廣泛的可升級性包括發(fā)布額外或修改代碼的能力，這些代碼表示對系統(tǒng)的更改或增強。

升級智能合約的能力在更廣泛的意義上是可取的，原因如下：

· 修復(fù)代碼中發(fā)現(xiàn)的缺陷

· 當(dāng)出現(xiàn)新的標(biāo)準(zhǔn)或找到更有效的方法時，升級代碼庫

· 隨著需求的發(fā)展而改變代碼的行為

需要注意的是，這些方面在開發(fā)期間和部署之后都是需要的。當(dāng)一個完全不靈活的系統(tǒng)達(dá)到一定的規(guī)模時，開發(fā)起來就變得非常笨拙。常見的情況是，智能合約有成百上千條線。它們通常包含自己的數(shù)據(jù)存儲，數(shù)據(jù)存儲由同一合約中定義的業(yè)務(wù)規(guī)則操作。

我們在一段時間前開始嘗試將表示業(yè)務(wù)規(guī)則的代碼與僅管理數(shù)據(jù)的代碼分離成獨立的合約。為了有效，業(yè)務(wù)規(guī)則需要具有完全能夠修改數(shù)據(jù)的能力。因為區(qū)塊鏈編程環(huán)境的安全性（如可靠性）主要圍繞基于發(fā)送方的行為進(jìn)行限制。發(fā)送方將邏輯從處理數(shù)據(jù)的合約中分離出來意味著您需要的是保護(hù)的合約——不對外公開的合約。這些合約只能由已白名單的其他合約或地址調(diào)用。

將數(shù)據(jù)和行為分割成單獨的合約會引入幾個有趣的屬性。

首先，由于許多原因，在區(qū)塊鏈上遷移數(shù)據(jù)是有問題的。使用簡單的CRUD功能將數(shù)據(jù)存儲封裝在其自己的合約中，可以減少所包含合約需要更改的可能性。然而，將業(yè)務(wù)規(guī)則移動到它們自己的、獨立的合約中，允許我們升級系統(tǒng)的邏輯，而不需要重新創(chuàng)建數(shù)據(jù)的狀態(tài)。

此外，拆分?jǐn)?shù)據(jù)存儲和業(yè)務(wù)邏輯允許我們?yōu)樘囟ㄖ黝}定義穩(wěn)定的接口，同時保持實現(xiàn)的靈活性。

這很好，有幾個原因。

首先，不依賴于不使用的東西是一種良好的軟件實踐。所以，如果一個外部系統(tǒng)依賴于我們系統(tǒng)的一組特定的功能，如果它們僅僅依賴于功能的子集而不是系統(tǒng)中的所有東西，這是很有用的。

舉個例子，假設(shè)我們有一個智能的租車合約系統(tǒng)。我們決定把所有的代碼放在一個大合約中。我們的合約包含了很多邏輯，但是一個叫carp的第三方僅僅關(guān)注人們的租車歷史，以建立一個新的信譽系統(tǒng)。

瞧，我們需要升級汽車清潔記錄在合約中的方式，因此我們修復(fù)了這個問題并部署了一個新合約。當(dāng)然，我們修復(fù)了所有指向新合約的內(nèi)部應(yīng)用程序，并將變更通知（我們知道正在使用我們合同的人）。現(xiàn)在，carp必須改變他們的代碼，因為我們決定改變我們處理汽車清潔的方式。然而，如果我們溝通不好，我們就破壞了他們的系統(tǒng)。

如果我們把邏輯分解成不同的合約，carp就不必改變?nèi)魏螙|西了。

其次，如果我們定義指向業(yè)務(wù)邏輯實現(xiàn)的高級接口，那么carp只需要在我們更改高級公共API的情況下更改它們的代碼。如果我們在使用定義和命名之前非常小心，這些更改可能很少。這基本上與我們期望Stripe或Twitter等主要公共api版本能夠正常工作的方式相同。

最后，遵循我們所設(shè)置的模式允許我們的系統(tǒng)遵循開閉原則——我們可以向系統(tǒng)添加新的行為，而不需要修改源代碼。我們可以簡單地部署新組件，并在需要的地方將它們納入白名單，這樣它們就可以獲得與我們的系統(tǒng)交互的授權(quán)。

可信任性

關(guān)于智能合約的早期觀點之一是，它們具有約束力——因此有了“合約”這個詞。描述是這樣的：“Joe和我就誰將贏進(jìn)行打賭。協(xié)議一旦達(dá)成，就無法撤銷。一旦選舉結(jié)束，智能合約將獎勵獲勝者。從這個意義上說，智能合約也是“不可信的”，因為我可以完全依賴代碼來執(zhí)行指定的合約，而不需要中介。

這與之前關(guān)于需要升級合約的論點形成了鮮明的對比。如果我能獨自升級一份合約，那么我就能做各種惡意或有偏見的事情，而且我已經(jīng)重新引入了人們信任我的必要性。

這提出了一個基本的沖突。正如Robert Martin在他的書《潔凈建筑》中指出的，軟件必須是軟的——也就是說，它必須易于更改。“如果我不能修改代碼，就會出現(xiàn)各種各樣的問題。”另一方面，如果一合約同可以改變，還能說它是一個合約嗎？

部分問題可能在于“智能合約”一詞選擇不當(dāng)。有些東西肯定屬于合約的范疇，但是像以太坊上的solid這樣的通用編程環(huán)境允許創(chuàng)建各種各樣的東西，其中一些在本質(zhì)上不那么具有合約性一樣。

在我看來，這是一個遠(yuǎn)未解決的問題。然而，我將提供一些想法：

首先，在規(guī)模上，我希望有非常少的用戶能夠真正地閱讀代碼并理解他們所簽署的內(nèi)容。因此，從這個意義上說，他們通常會相信他們所接觸的公司、網(wǎng)站、平臺等并不是惡意的。

其次，在許多情況下，這個問題可以通過要求多個開發(fā)人員簽署正在部署的更改來解決。這將減少開發(fā)人員涂脂抹粉和搶劫的可能性。

第三，對于非常敏感的系統(tǒng)，在推出更改之前，可能需要外部審計人員在多個開發(fā)人員之外簽署更改。在需要完全去中心化的情況下，可以使用TCR來管理核準(zhǔn)的開發(fā)人員和審計人員名單。