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

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

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

可升級(jí)性

可升級(jí)性可以定義為程序員在將來某個(gè)時(shí)候修改軟件行為的能力。

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

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

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

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

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

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

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

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

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

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

這很好，有幾個(gè)原因。

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

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

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

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

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

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

可信任性

關(guān)于智能合約的早期觀點(diǎn)之一是，它們具有約束力——因此有了“合約”這個(gè)詞。描述是這樣的：“Joe和我就誰將贏進(jìn)行打賭。協(xié)議一旦達(dá)成，就無法撤銷。一旦選舉結(jié)束，智能合約將獎(jiǎng)勵(lì)獲勝者。從這個(gè)意義上說，智能合約也是“不可信的”，因?yàn)槲铱梢酝耆蕾嚧a來執(zhí)行指定的合約，而不需要中介。

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

這提出了一個(gè)基本的沖突。正如Robert Martin在他的書《潔凈建筑》中指出的，軟件必須是軟的——也就是說，它必須易于更改?！叭绻也荒苄薷拇a，就會(huì)出現(xiàn)各種各樣的問題?！绷硪环矫妫绻缓霞s同可以改變，還能說它是一個(gè)合約嗎？

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

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

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

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

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