或許你會覺得硬件與區(qū)塊鏈風馬牛不相及。畢竟，從比特幣到以太坊，區(qū)塊鏈都是軟件為王，基于硬件的解決方案往往有中心化的嫌疑。其實，在隱私保護領(lǐng)域，引入硬件是常規(guī)操作。硬件是實現(xiàn)實用化的基礎(chǔ)，軟硬結(jié)合的方案可以實現(xiàn)一加一大于二的效果。通過巧妙組合，Phala 可以在讓其去信任化的同時，讓解決方案在可拓展性和保密性之間達到絕佳的平衡。

#1 基于TEE的區(qū)塊鏈保密

Phala Network運用了保密智能合約來實現(xiàn)區(qū)塊鏈保密。與傳統(tǒng)合約不同的是，它運行在 CPU 內(nèi)一個特殊的硬件區(qū)域（可信執(zhí)行環(huán)境）內(nèi)。這個區(qū)域與其他部件高度隔離；未經(jīng)授權(quán)，包括惡意攻擊在內(nèi)的任何嘗試都無法讀取TEE中的數(shù)據(jù)，也無法干預其中程序的執(zhí)行。

Phala將運行在 TEE 中的程序稱為pRuntime。 pRuntime 在 TEE 內(nèi)維持礦工和 Gatekeeper 節(jié)點運行，并負責處理 TEE 遠程證明、鏈上注冊、密鑰管理和保密合同執(zhí)行。

然而，如何讓用戶相信智能合約運行在 pRuntime 里，而不只是一個偽造的 TEE環(huán)境？這個時候，我們需要了解什么是“遠程認證”（Remote Attestation）。

“An application that hosts an enclave can also ask the enclave to produce a report and then pass this report to a platform service to produce a type of credential that reflects enclave and platform state. This credential is known as a quote. This quote can then be passed to entities off of the platform， and verified…”

“特殊安全區(qū)（enclave）里的應(yīng)用程序也可以要求安全區(qū)生成報告，然后將該報告?zhèn)鬟f到平臺服務(wù)以生成反映安全區(qū)和平臺狀態(tài)的憑證。這樣的反饋憑證被稱為“引報”（quote）。之后，引報就可以作為信任源向外界驗證安全區(qū)內(nèi)應(yīng)用的可信性……”

遠程認證是確保 TEE 系統(tǒng)處于安全和可信狀態(tài)的關(guān)鍵。來自英特爾的 Quate 可以證明這段代碼（以哈希值確定）和需要用到的某些數(shù)據(jù)都確確實實運行在最新版本的 SGX 安全區(qū)內(nèi)。

#2 Secret Provisioning

遠程認證是保密智能合約的靈魂。但如果我們無法在 TEE 和第三方之間建立端到端加密的通信，應(yīng)用范圍就會受到限制。所以，英特爾 SGX 還運用了 Secret Provisioning協(xié)議來優(yōu)雅地解決這個問題。

借助 Secret Provisioning 協(xié)議，我們可以建立從用戶到 pRuntime 的信任鏈：

區(qū)塊鏈上公示了合法 pRuntime 代碼的哈希；

pRuntime 運行遠程證明協(xié)議，獲取遠程認證報告，報告中含有：被證明代碼的哈希值（pRuntime本身）； 身份認證密鑰對的公鑰（有時效性）

遠程驗證報告在鏈上提交，并在鏈上進行驗證；

區(qū)塊鏈比較遠程報告返回的哈希值（旨在證明：參與方確實是TEE中運行的合法 pRuntime）

身份認證公鑰完成鏈上注冊（以后只有目前正在運行的 pRuntime 可以使用此密鑰對）

注冊完成后，但凡是由這個身份簽名的消息，都一定是由此 pRuntime 生成的。用戶可以使用已注冊的身份公鑰進一步和 pRuntime 建立類似 TLS 的連接。

需要與 TEE 進行通信時，用戶可以從區(qū)塊鏈獲取已注冊的 pRuntime 的公鑰，并用 Substrate 賬戶和公鑰進行 ECDH 迪菲赫爾曼協(xié)議密鑰協(xié)商，并獲得用于和 pRuntime 進行通信的密鑰。

信任鏈建立后，該身份密鑰將唯一地表示 pRuntime 的身份。理論上，只要TEE沒有硬件漏洞（在后文我們會繼續(xù)討論這個點），則一次成功的遠程認證就可以確保所有與 pRuntime 往來的通信處于安全和可信的狀態(tài)。

#3 鏈上升級

鏈上升級可以極大地降低硬件升級硬分叉帶來的風險，所以非常重要。Substrate 天生支持 Runtime 鏈上升級，在治理模塊即可完成。同理，TEE 里的 Runtime 也是可以升級的。

升級 pRuntime 時，需要將新的哈希提交到區(qū)塊鏈上。之后便可由社區(qū)通過類似于 Substrate 的鏈上治理流程來審查代碼、討論并投票贊成升級。

鏈上一旦有升級，Phala 的守門人（Gatekeeper）和礦工都必須第一時間升級 pRuntime。這個過程對礦工來說會相對容易一些，因為他們不用 24 小時在線，只用暫停挖礦，升級，然后繼續(xù)挖礦即可。守門人則肩負可用性重任，需盡可能在線，因此他們要么運行另一個新版本的TEE客戶端等待下一次選舉期間的自然切換，要么對狀態(tài)數(shù)據(jù)進行緊急加密轉(zhuǎn)儲，然后將其恢復到新的 pRuntime。

雖然后者有狀態(tài)數(shù)據(jù)丟失或暴露的風險，但在緊急情況下也不失為一種選擇。 SGX 有一個“密封至安全區(qū)（Seal to Enclave）”功能，可以生成只能由同一安全區(qū)解碼的密鑰。這個密鑰可以確保數(shù)據(jù)不被任何第三方查看或遷移。為了降低硬件安全漏洞被利用的可能性，Gatekeeper 中的密鑰是通過 Shamir 密鑰共享方案分發(fā)的。即使 sealing 崩壞，如果沒有網(wǎng)絡(luò)中的多方合謀，主機也無法獲取密鑰。

#4 攻與守

Phala 的威脅模型首先假設(shè)TEE廠商是部分可信的。原因有二：一，TEE 廠商在制造芯片的時候并不知道這些芯片會被用在什么地方；二，即便遭受“零日漏洞攻擊（Zero-day Attack）”，其他所有運行在芯片上的程序都會有風險，而不單單是TEE承受風險。

雖然秉持上述假設(shè)，不可否認的是，硬件漏洞攻擊仍然時有發(fā)生。好在，有以下幾種方法可以解決或處理硬件風險問題。

首先，硬件漏洞是可以修復的。一個常見的誤區(qū)是，只有軟件漏洞可以修復，而硬件漏洞不能修復。事實并非如此，我們可以通過微碼來修復硬件漏洞。英特爾為 SGX 設(shè)計了一種特殊的架構(gòu)，大多數(shù)漏洞都可以被及時修復。比如，最近新出現(xiàn)的一種名為 SGAxe的攻擊就已經(jīng)通過微碼升級和密鑰組輪換被修復。密鑰經(jīng)過轉(zhuǎn)置和撤回后，所有非最新版 SGX 設(shè)備的請求都將被遠程認證駁回。

其次，隨機性是一柄利器。有人會問，零日漏洞攻擊怎么應(yīng)對？——礦工擁有硬件訪問權(quán)限，就可能會利用零日漏洞攻擊盜取數(shù)據(jù)，有作惡的可能。針對這種情況，我們可以活用“隨機性”，讓區(qū)塊鏈把保密智能合約在一個時間段隨機分配給不同的礦工，這樣，每個時間段的礦工都不同。這樣一來，攻擊者必須在不同時間段持續(xù)控制大多數(shù)礦工的TEE設(shè)備才能成功，作惡成本會非常高。

最后，保密合約可以通過副本保證執(zhí)行的正確性。即使在極端情況下，安全區(qū)完全被攻陷、機密數(shù)據(jù)完全暴露在攻擊者面前、TEE 內(nèi)程序可以被任意改寫，合約的“正確性”（correctness）仍然可以得到保證。在 Phala 的設(shè)計中，保密合約可以有一個或多個副本并行運行。副本不會影響合約的執(zhí)行，因為所有輸入都來自區(qū)塊鏈。并行狀態(tài)下，會有多個 TEE 同時嘗試向鏈上提交狀態(tài)數(shù)據(jù)。此時就會有一個簡單的鏈上投票過程，狀態(tài)數(shù)據(jù)的“最終確認”（finalize）將遵循少數(shù)服從多數(shù)的原則。

副本的設(shè)計讓這個過程變成了類似 Polkadot Validator選舉的過程。要想攻擊“正確性”，攻擊者必須控制絕大多數(shù)TEE礦工。——這還是在完全被攻破的極端情況下。

#5 結(jié)論

過去，區(qū)塊鏈僅限于軟件范疇。發(fā)展至今，完全公開性已成為大范圍落地的桎梏。而有了可信硬件和精心設(shè)計的協(xié)議支持，Phala將證明和構(gòu)建出一個可信、可保密、可大范圍落地的區(qū)塊鏈世界。