前言
本文為萬向區塊鏈蜂巢學院線上公開課第15期的分享。本期公開課邀請了Web3.0訓練營中專注隱私保護的三個入營項目Maskbook、Advanca、Phala的代表，來分享他們的技術和方案落地的可行性。
錯過上次直播的小伙伴，添加小助手微信號：fengchaoxueyuan，進入公開課學習群，及時獲取每週直播入口。
張衛（主持人）
大家晚上好，我是萬向區塊鏈通用架構技術部負責人張衛，今天很高興作為蜂巢學院線上公開課直播間第十五期的主持人。歡迎大家來到直播間，很高興邀請到了web3.0 Bootcamp的三個項目：Maskbook、Advanca、Phala進行隱私保護的專題探討。
歡迎今天的三位論壇嘉賓：Dimension CTO劉懌斯，Advanca聯合創始人Deli以及Phala隱私協議創始人尹航。
我們今天要探討的主題是《區塊鏈如何實現隱私保護？ 》，在開始討論之前，首先請三位分別介紹下Maskbook、Advanca、Phala這三個項目。大家很好奇你們的項目解決了什麼樣的場景需求？挖掘了什麼樣的痛點？使用了什麼樣的技術去解決需求等？
我們先從Maskbook的劉懌斯開始。
劉懌斯
感謝介紹，大家好！我們在Web3.0 Bootcamp裡帶來的是Maskbook產品。這個項目的想法誕生於2016年Facebook“總統大選門”事件，這個事件暴露了很多的隱私洩漏問題。 Maskbook的名字因此而得名，我們想的東西是“We want to put mask on face”，所以就叫Maskbook。
這幾年隱私洩漏問題頻繁發生，Maskbook通過瀏覽器插件的形式在大平台上增加了一層layer，把用戶們發出的帖子都利用密鑰加密起來，現在支持Facebook和Twitter，只有安裝了Maskbook 插件的人才可以解密出真正的內容。簡單來說，我們就是做了一個運用了密碼學的插件，用來Hide from no one but Facebook 。
Deli
大家好！我是Deli，我是Advanca的聯合創始人，非常榮幸今天能參加Bootcamp隱私保護專場的討論。 Advanca是為分佈式應用打造的具有隱私保護功能的基礎設施，可以滿足開發者在計算和存儲方面對高隱私的需求。
在隱私保護方面，大家會有很多不一樣的需求，其實已經有很多項目做出了嘗試。比如Z-cash項目利用零知識證明試圖隱藏賬戶資產、交易記錄；Enigma、Oasis項目用了可信執行環境（TEE）來做私密計算。相比零知識證明這樣的技術，使用TEE這種比較通用的技術不僅可以提供更通用的場景支持，在性能上也會略勝一籌。但是使用了這樣的技術也會有隱私洩漏的可能性，尤其是在現在大部分公鏈的環境下，假設各個節點部署了TEE技術，但節點運營者不一定被人信任。所以即便是運行在TEE裡的智能合約，節點還是有可能獲取到對加密數據的訪問模式的。
這個問題要怎麼解決？學術界已經給了一些答案，比如說有一個技術叫ORAM，全稱是“Oblivious RAM”，就是用來混淆應用數據訪問模式的一種法。它的基本思路是擾亂攻擊者收集到的應用訪問信息。比如本來應用的真實意圖是對數據塊A訪問很多次，但攻擊者觀察到的是沒有任何含義的完全隨機訪問，可能看起來是在訪問數據塊B或者其他位置，這樣就使得攻擊者沒法通過推理得到信息。
以上就是Advanca在試圖解決的問題和使用的技術，總結一下就是結合TEE 和ORAM來提供平台，使得應用可以直接享受到高隱私帶來的好處。
尹航
大家好！我是尹航，Phala Network的主要技術負責人，其實我不是CTO，因為我更偏研究，我們的CTO會更偏工程一點。 Phala Network是在2018年成立的團隊。
區塊鏈能夠解決去信任化的問題，但是如果要用區塊鏈，很大的問題是所有東西在區塊鏈上都是公開的，可能會有像Z-cash、門羅這樣的鏈可以實現轉賬的隱私。但是如果想實現更複雜的隱私保護，比如以太坊智能合約的隱私保護的話就沒有那麼容易了。
除了零知識證明之外，MPC、TEE等技術也可以實現隱私保護。我們選擇TEE，因為TEE是唯一一個在性能上比較可行的落地方案，用來實現通用的保密智能合約概念。 MPC在某些特殊的環境下比較可行，但是並不適用於比較通用的智能合約，採用MPC有可能會導致百萬級別的overhead。
張衛（主持人）
非常感謝三位對各自團隊的介紹，那區塊鍊是如何幫助解決這些問題的？
劉懌斯
區塊鏈在我們的場景裡沒有特別明顯地參與，我們就是做密碼學相關的事情，畢竟是用密碼學設計的插件。但我們也做了一些區塊鏈相關的應用，也算是想要鏈接傳統互聯網和區塊鏈世界的橋樑。把加密本身當成權限系統來用，誰能解密就代表誰有權限。
我們今年年初和MakerDao在Twitter上發起了“領區塊鏈紅包”的活動。這個活動類似微信紅包，比如你在某個群裡發紅包可以設置金額和數量。 Maskbook插件裡也做了同樣的事情，我們有明確的確權系統，只有能解密這段話的人才能領到紅包。紅包算是我們第一個在區塊鏈裡的嘗試，之後計劃會做更多和區塊鏈相關的應用。
大平台也限制了我們能做的事情，比如Twitter本身不能發起投票，投票的功能是在去年或前年才被加進來的。用戶沒辦法在想發起投票時就發起。但我們賦予了用戶這樣的權利，這也是賦予用戶想幹什麼就乾什麼以及他們想做任何事情的自由，這也是我們插件比較認同的想法。
張衛（主持人）
有沒有什麼突破和創新以及難點。
劉懌斯
第一，說到創新，我覺得我們的產品就挺創新的，開玩笑。我們面臨的很大問題是整套加密算法都是現成的標準，我們用到了SECP256K1和AES 256 GCM mode。我們所做的事情是如何把它們高效地組合在一起，這是比較大的挑戰。想要高效地把它們放在一起完成這套加密scheme還是要花比較多時間來做的。
第二，我們用了去中心化的數據庫——GunDB，我們用GunDB來進行密鑰分發。既然是去中心化的數據庫，其實就沒有中心化的狀態，狀態同步是其中很大的問題。如何解決不同機器間的狀態同步問題，並且還能保證比較好用的用戶體驗，在我們這邊是非常大的挑戰。
我說完了，請其他幾位介紹一下。
張衛（支持人）
接下來請Deli講一下區塊鍊和Advanca項目的關聯。
Deli
區塊鏈在我們項目裡的用處和平台的結構是有關的，設計中Advanca平台上會有比較多不同類型的節點。主要是有控制層面的節點，另外是計算層面、存儲層面的節點。
區塊鏈應用主要是在控制層面，控制層面的節點會形成公開賬本，目前我們使用的是Substrate的技術。賬本上包含了平台核心信息以及核心邏輯。比如說有哪些節點已經註冊平台；有哪些任務發佈在平台上等待分配給節點運行；如何分發獎勵；如何維護節點的聲望。基本上是把鏈當成是一個分佈式的控制中心。
控制層面重點利用了區塊鏈本身的特性：數據高度透明；系統可用性非常高；擴展性比較好（節點可以很方便地加入控制層面，從而使控制層面的處理能力得到水平的擴展）。另外，所有數據都是不可篡改且已經保存在鏈上的賬本中。
當然，區塊鏈技術與其他層面的聯繫就是：計算層面、存儲層面的節點需要直接連通到鏈上。在這個架構下他們相當於是鏈的用戶，持有一些自己的私鑰並簽發交易到鏈上。
關於在項目中有哪些突破以及創新：
難點一：比較核心的一點是如何把對隱私的保護從系統的各個角度都做起來，盡量避免短板出現。需要安全性的系統一旦有一個地方可能是不安全的，其實會影響整個系統的安全性。
難點二：是如何兼顧高隱私性和性能之間的平衡。比如說我們引入了ORAM算法，實現對訪問模式的隱匿。但其實這樣的算法會引入比較大的開銷，這就是高隱私保護的代價。如果我們想把把這個技術應用化的話需要進一步做優化，減輕對實際使用用戶的影響。
張衛（主持人）
在設計的流程裡一般的用戶使用流程是什麼樣的？數據是以什麼樣的形式離開本地，在哪裡進行什麼樣的計算？以及鏈上的交互是怎麼樣的？
Deli
比如說一個節點有TEE的可信執行環境，它想加入到計算層面成為worker，首先他需要做remote attestation，就是跟Intel拿到證明（report），然後向其他所有人證明確實是可信環境，這樣就可以成為註冊節點。如果開發者應用需要部署的話，開發者也是通過在控制層面發布任務信息，各個worker節點可以通過競爭爭取到任務。
之後，任務的發布者可以和worker節點建立起聯繫：直接通過鏈下的通道進行端到端的加密通信，由此實現數據流的傳送。比如說用戶就可以直接聯繫到worker節點，把私密數據傳送進去。基本上就是這樣的流程。
張衛（主持人）
接下來請尹航介紹一下Phala Network項目中應用到的區塊鏈技術。
尹航
回答這個問題之前想先簡單介紹一下，我們在做Phala時並不是做出基礎設施就丟給大家去用這麼簡單，我們還是有非常大的責任去先告訴大家，拿著強保護隱私的系統能做點什麼。
我們做了一個Pilot產品，叫Web3 Analytics。不知道大家有沒有用過Google Analytics，如果你是站長的話多半你是知道這個東西的。簡單來講，基本上全世界70%以上的網站都會在每一個網頁、App裡加一個插件，插件會統計看你訪問了哪些頁面，以及你在哪些頁面停留了多長時間，按了哪些按鈕，看了哪些內容，其實是為了收集用戶的數據，是所有用戶數據收集的“第一站”。所有的數據都收集到了Google那裡，是不是Google拿著數據想做什麼都可以？
我們認為這是一件非常不好的事情，用戶的隱私應該由用戶控制。所以我們做了Web3 Analytics的項目，項目的目的是可以照樣讓用戶的數據被收集起來被統計，但是我們可以保證它完全地被去中心化，用戶可以控制被收集到的數據被誰用了，允不允許他用。有點像你的手機裡有控制每一個app能否訪問你的攝像頭、麥克風一樣會有開關，你希望被別人用就打開，不希望被別開用就關掉，這是我們的應用。
張衛（主持人）
區塊鏈在裡面到底解決的是什麼問題？怎麼解決？
尹航
隱私保護，本質上是保護數據，數據到底是怎麼被處理的？現在的情況是數據直接被大互聯網公司收集起來了，所以用戶沒有數據的所有權。然而數據又很特殊，因為數據特別容易被複製，哪怕你把數據給了一些人，他在背後復制了拿去做一些你沒有授權的事情，你也沒有任何辦法。因為數據的這一點問題，所以很難被確定數據的所有權。
另外，如果我們鼓勵數據的流通，鼓勵數據被更多人用起來，並不是說把數據公開的越多越好。如果要產生高效的市場一定要有“供”有“需”，如果數據拿出來後所有數據都在鏈上被隨便複製的話，數據就缺少了稀缺性，因為沒有所有權，所以也沒有稀缺性，因為供給是無限量的，也不可能形成市場。
我們做的保密智能合約怎麼解決這個問題？本質上是把數據放進了保險箱，只有經過了用戶同意才能以一種用戶同意的方式來使用數據。通過這樣的設計把數據所有權重新還給了用戶。
網站開發者只可以來使用，並且要經過用戶的同意，而不能把數據複製走了想拿它做什麼就做什麼，所以它是為了避免公地悲劇的一種設計。
張衛（主持人）
在設計這套系統的時候有哪些突破和創新？
尹航
我們最大的突破創新在於可互操作，以及可組合性，如果大家對DeFi比較有了解的話。
TEE有一個特點，是和普通區塊鍊網絡很不同的性質，TEE的所有節點是非拜占庭的。什麼是非拜占庭？如果你是普通節點可以修改節點的代碼讓它去作惡，但是TEE可以保證運行在TEE裡的程序是沒有辦法被篡改的，所以是非拜占庭的。在以太坊這樣的系統裡，為了實現去信任化的做法是讓全世界所有節點都運行同樣的程序，其實這是很強的冗餘。每執行一筆交易，這筆交易在所有的節點上都執行一遍，大家會互相驗證，通過共識算法保證去信任化。但是在TEE沒有了這個限制，有什麼好處？可以實現合約級別的並行。
什麼叫“合約級別的並行”？每個智能合約都可以部署在不同的TEE上，也就是說有一個節點可能可以執行一個合約，但是有一百個節點就可以同時執行一百個合約。
這樣可以帶來兩個好處：
1、安全性會比全冗餘更好，全冗餘意味著一個節點被攻破，所有合約的數據都在節點裡，就可以都拿到了。如果讓每個節點只運行部分合約的話，那麼你沒有辦法拿到所有的數據，這是安全上的考量。
2、可以讓性能變的非常好，基本上是你有多少TEE的節點，可以實現線性的性能增長。這就類似於做互聯網系統，從雲服務裡租服務器，如果服務器性能不夠可以買更多的服務器解決問題。
但是這裡遇到了非常大的挑戰，大家知道智能合約和雲服務器還是有很大區別的，因為智能合約突出可組合性。在DeFi的應用場景下大家都知道有MakerDAO、DYDX、以及各種DEX等獨立的項目，才能有繁榮的DeFi系統，背後依賴著以太坊平台，在平台上合約和合約之間可以無縫組合。
但如果說每一個合約都執行在自己的TEE裡，那每一個TEE其實只知道自己合約中的信息，並不知道其他合約現在是什麼狀態，這就涉及到特別複雜的一致性、可用性問題。這個問題非常複雜，所以這裡我們就不會展開了。基本上我們最主要的突破是設計了一套讀寫分離的設計，並且利用區塊鏈補足TEE的不足之處，利用區塊鏈充當時間戳服務，並且為所有TEE提供可用性的保障。所以，可以把系統理解成鏈，有點像波卡的Relay Chain，每個TEE有點像波卡里的平行鏈，每個TEE和TEE之間都實現了強一致性可互操作與組合性。這是Phala Network主要的與眾不同之處。
張衛（主持人）
聽起來挺酷的。我有一個小問題，一段程序在TEE裡執行一段input（輸入），有辦法向外界證明確實是按照預設的預期代碼邏輯去執行出來的結果，TEE本身有能力給出這樣的proof嗎？
尹航
有的，Deli也提到了，確實TEE提供了硬件上的保證，就是我往裡面放什麼程序就會怎麼執行。但是如果不能對外生成任何證明的話就是本地的TEE，那應用場景就小很多了。
本地的TEE最常見的應用場景是什麼？就是蘋果手機、安卓手機的指紋解鎖，不需要向外證明任何東西，只是把秘密保存在TEE裡。但是對我們來講，我們需要向外證明在TEE內部發生了一件什麼事情，而且是按照預期的方式發生的。核心技術叫做Remote Attestation（遠程認證）。
遠程認證的原理大致是這樣的，在CPU裡會有硬件廠商燒錄進去的一段密鑰，按理來說這個密鑰是硬件廠商以及其他任何人都不知道的。硬件廠商知道公鑰，私鑰是寫入在硬件裡的，而且沒有任何方法能直接訪問到私鑰。
在硬件裡實現了Remote Attestation的模塊，可以把在內部執行的程序進行校驗。校驗的內容，以及硬件當前運行的狀態（比如說運行了什麼版本的固件，運行在什麼樣的系統裡），這些信息都會被硬件內部私鑰簽名吼發給Intel，Intel經過校驗發現沒有問題的話會產生report。這個report，任何第三方都可以驗證，不需要有特殊的硬件，手機也可以做驗證，report裡包含的內容：
1、有一段程序運行在合格的TEE裡；
2、程序確實是預先確定的某一段程序。所謂的“某一段程序”是程序的哈希，哈希可以提前公示在區塊鏈上，所以任何人都能確定的確在TEE執行的是大家約定好的程序；
3、因為輸入以及執行程序都是已經可以被證明的了，那輸出一定是deterministic的，只要程序本身沒有引入任何的不確定性。
它是一個信任鏈條，從源頭——硬件——Intel——用戶端，可以做端到端的驗證，確定在一個TEE裡按照約定的方式執行了一個程序。
張衛（主持人）
本質上通過硬件加上Intel的商業背書實現了這一點。現在硬件加上Intel本身的商業背書做這件事情，如果最終把intel換成去中心化多個機構組成的聯盟，會不會進一步提高硬件的大眾接受度？畢竟Intel是獨立的商業企業，如果某一天通過聯盟、去中心化組織提供商業方面的保證，有對立博弈的多個廠商參與，是不是可以進一步迭代安全性？
今天的三個項目，各自都有自己的特點。接下來分別針對三個項目探討一下各自的特點。
我在看Maskbook功能設計時，一直有一個小的疑問。比如說我們用微信，第三方廠商接入微信的時候不可能拿到微信的好友鏈，我發Twitter，雖然我的好友也安裝了插件，但是Maskbook應該是讀不到Twitter裡的好友鏈，是怎麼讓好友能看到解密之後的數據但是其他人看不到呢？
劉懌斯
這個問題是真的是用過我們產品會問的問題，大家應該都比較好奇這樣的事情，畢竟我們不是Twitter也不是Facebook，但我們怎麼能知道一個人是一個人呢？我稍微講一下原理，每一條Tweet、post都是由對稱密鑰加密的，我們是用AES GCM mode來做加密。每一條加密好的數據其實會被po到Twitter上，因為這是general的，由一個AES Key來加密的。我們現在需要做的事情是什麼？你想要誰來解密到這條消息，你就需要把他的AES Key給它加密地分享出去。
我在Twitter上選的是要加密給所有的好友，我們定義的好友是相互關注的人。這怎麼判斷？因為沒有辦法知道好友是誰，因為不會存你的Twitter關係列表。其實我們做的是一個on demand的思想。
一開始分享的時候只會把已經記錄到的好友分享給他們。所有的公鑰都po在一條Twitter裡，或者Twitter的profile裡的。公鑰只要訪問到你的主頁，其實我就可以知道你的公鑰了，這種是已知的好友，但還有一些是未知的好友，我們做的是On demand。
比如說你發一條被Maskbook加密過的Twitter，我作為另外一個人看到這條Twitter的時候，碰巧我也裝了Maskbook的插件，我會先判斷一下我有沒有資格解密。我做的事情是模擬用戶打開作者的主頁，然後判斷關係是否是你follow我或者我follow你，或者我們互相follow。找到了關係後，再來確定是否符合作者設置好的範圍。這個機制比較繞，叫做“好友發現機制”。因為這條Twitter的密鑰是不會存在任何一個第三方，只會存在有資格解密這條Twitter人的電腦上。
當任何一個有資格、有密鑰的人在線的時候，我們就會通過他來P2P地傳給我，讓我來解密這條Twitter。但是如果萬一沒有擁有這個密鑰的任何人在線的話，必須要等到有任何一個擁有密鑰的人上線才能解密這條Twitter。
這也是去中心化的問題，說實話，如果我們是中心化的服務，完全不需要思考這個問題，只需要把密鑰存在上面就可以。但因為是去中心化的，沒有辦法保證所有人都時刻在線，所以並不能保證服務24小時在任何場景下都能夠work。這也是一個trade off，畢竟用戶想要隱私、安全就必須得犧牲一些。
這是我們的技術原理。
張衛（主持人）
確實這樣能解決大部分場景下的問題。
劉懌斯
其實我們在線用戶還蠻多的，現在比較活躍的用戶圈子都比較小比較緊密，確實能夠保證穩定性。
張衛（主持人）
我個人感覺做了一個非常酷的插件。剛才講到了AS對稱、隱私密鑰。 AS是加密這條Twitter，每一條Twitter都有可能生成加密密鑰，或者一個人一個用戶所有的Twitter。
劉懌斯
每條Tweet都會有獨立的AES key來加密，保證一個密鑰被crack之後不會導致所有其他的加密Tweet被同一個key解密，這也是為了保證前向安全性（Forward Secrecy）。
張衛（主持人）
信息安全性。這是在不同好友關係鏈裡流轉的。剛才還講到了公私鑰對，這個是屬於user的？
劉懌斯
對的。我們用公私鑰對的用途是加密對稱密鑰，我們做的事情是要把對稱密鑰安全地share給你想要share的人，這時候需要用到非對稱加密的方式。比如我想給你加密或者你可以解密我的消息，就必須用你的公鑰對AESK做加密，這樣你就可以用你的私鑰解密出來，是比較輕量級的分享方式。
張衛（主持人）
不然的話效率可能會是問題。剛才說這些是放在插件裡？那會有安全性上的風險嗎？
劉懌斯
對的，其實現在都保存在插件的indexed db裡，是瀏覽器自帶的DB。設計還是安全的，但是也有一些paper講到有被bridge的風險。我們也做了很多的考慮，考慮過把所有密鑰做加密，先加密再存在indexed db裡。等到用戶想要用的時候再用密碼解密。但是這個用戶體驗非常差，所以我們最後做了妥協，還是會把密鑰直接放在indexed db裡。這也是我們不得已而為之的做法。
私鑰是用戶最大最重要最concern的安全的問題，我們在這方面是比較無能為力的，又要保證安全性、又要保證用戶體驗性，所以我們做了trade off，還是比較相信indexed db本身還是比較安全的。
有些論文講到了indexed db被bridge的風險的case。我們所有代碼都是開源的，也不會做任何的網絡請求，唯一的網絡請求都是跟GunDB （音）去中心化數據庫做交互。所有人都會知道網絡請求是什麼，保障了不會對你的私鑰做任何的危險舉動。
稍微多說一點，設計最重要的就是安全性，有三大設計原則：
1、不依賴於任何平台的API。我們是不信任平台的，如果平台知道我們在做的事情，他們完全可以操縱我們的API請求，而且我們也比較害怕哪一天平台突然關閉/限制了API的使用，不希望這樣的事情發生，我們算是比較追求自由的產品，所以完全沒有用到任何平台/官方所提供的API，都是自己做了用戶模擬的操作。
2、沒有任何中心化的服務，這也是我們保障用戶安全性很重要的地方，所有網絡請求都和去中心化數據庫進行交互，不用擔心有任何中心化服務做所謂的惡碼。其實去中心化數據庫所有人都可以隨意進來、退出，我們也沒有辦法在裡面做任何的不好事情。因為會被任何想要all date我們代碼的人都可以捕捉到我們所干的不好的事情。
3、不信任平台，有用過我們插件的知道我們在Facebook和Twitter上做了很多代碼注入的東西，畢竟我們希望把界面做的好看一些。我們所注入進去的代碼都是在shadowroot下的，完全不用擔心平台會知道代碼的存在，因為shadowroot本身在設計上就是不會被本身代碼所能夠探知到的shadow的隱形代碼。
通過這樣的方式來隱藏在Facebook、Twitter上的舉動，盡可能地保護到用戶使用插件安全。
回到私鑰存儲問題，希望提供又安全又好用的插件，但是由於用戶體驗實在是太差，每次都解密都要輸新密碼，用戶肯定是不願意的，所以我們不得不在這裡做了妥協。如果有人真的希望用比較高級的模式，每次解密，每次用到私鑰都輸一次密碼的話，我們也可以推出相應的功能，都是比較願意傾聽大家的想法。
張衛（主持人）
謝謝劉懌斯。因為這是社交網站上行為，是不是以後可以跟Facebook或者Twitter聯合做校驗？雖然我們發的內容Facebook和Twitter解不開，但是通過Facebook或者Twitter本身的登錄校驗等流程和機制去解開插件裡的相應問題。
劉懌斯
我覺得這個問題蠻好的，因為對用戶體驗是比較好的幫助。問題就在這裡，我們建了“去中心化身份”的概念，從最早的設計開始就相信Decentralized ID。用戶想創建1000個身份、10000個身份都可以，沒有任何的平台設計，但我們完全希望能夠擺脫平台對於用戶的限制。一開始的想法是不信任平台，不希望自己依賴於平臺本身的，希望依賴於ID，我們對ID負責，而不是平台對任何事情負責。這是我們的設計理念。
張衛（主持人）
謝謝劉懌斯。接下來有些問題想要請教Deli，看到官網上對TEE重度使用，TEE其實是用了市面上大廠現成的一些設備硬件，還是自己有這方面的研發計劃？如果有這方面的計劃，相對於現在目前的大廠有什麼樣的優勢？
Deli
其實主持人說的非常對，現在我們用的確實是比較成熟的技術，Intel SGX。原因是它已經有比較大的生態了，包括開發環境、硬件以及對應的Attestation服務的支持，確實已經比較成熟了。就像之前另外幾位嘉賓有提到的，它是落地且已經可以實現應用的技術了。
在學術方面有很多論文也在關注Intel SGX，正是因為有很多人關注，它可能在安全性上會有更好的提升。至於新的TEE技術，我們的看法是會保持關注，因為這個技術的基本原理是相通的。
比如大家知道蘋果最新的MacBook有一個T2 chip，上面有secure enclave，被用來處理一些需要高安全和高隱私的任務，即便kernel被攻擊了enclave保護的數據也是安全的。但它的問題是不夠開放，因為它的接口只對自己系統級的應用進行開放，作為開發者如果你想用到這些功能的話是比較難的。再比如說ARM平台上的TrustZone，大部分ARM平台應該都是移動端的，我們目前重點還是看服務器端，所以用Intel還是比較直接的辦法。
還有更新一些的技術，有一個項目叫做Keystone，是UC Berkeley的一些教授主導的項目，他們其實是想做open-source 的嘗試。目前他們還在不斷更新、發展中，官網也有自己的roadmap大家感興趣可以自己看一下。
我們的看法是一旦新技術可以真的落地，我們肯定會考慮應用。只要節點能提供可信環境、計算能力、存儲能力，它都可以連接到我們整個平台上的。
最後還有一點，現在Intel也意識到了，如果要求大家都依賴於它的attestation服務的話，是不現實的。所以後來Intel開放了第三方attestation的接口，相當於每一個組織、公司可以自己設置attestation服務，從而在這方面可以和Intel割離。
張衛（主持人）
Intel提供service其實是給第三方在上面註冊attestation服務，然後發放認證的attestation設備。
Deli
其實相當於給每個enclave發一個證明，然後大家可以驗證之後再把私密數據放進來。
張衛（主持人）
剛剛講到了ORAM技術，能跟我們進一步介紹下ORAM技術的特點和應用嗎？
Deli
ORAM技術一開始針對的場景和現在可信計算的場景非常類似。它討論的是一種攻擊，假如我看不到你的CPU在做什麼，但是可以看到CPU對內存的訪問，那我其實是可以推斷出你在試圖做什麼。
ORAM怎麼解決這個問題？要求CPU按照他的算法，依照一定的模式去訪問內存，這樣即便攻擊者觀察到了訪問模式，但其實看起來就像在隨機訪問一樣，是拿不到任何額外的信息的。
我舉個簡單點的現實例子，比如說有一個間諜要通過儲物櫃來傳遞情報，儲物櫃就好比是加密的存儲，只有有鑰匙的人可以打開拿東西。在看不到櫃子里東西情況的時候是不能確定他是不是間諜的。但如果他很有規律每週去固定號碼的櫃子拿東西，這麼做肯定是會被懷疑的。或者他稍微變通一點，他放進去，但是不自己去拿，而是找另外一個人接頭。可如果接頭這個人被認出來，他還是可以被聯繫起來的。
如果想要類似於ORAM的思路來解決要怎麼做呢？比如說可以開始僱人去訪問櫃子，可以先放到櫃子裡，然後再找一個人幫他轉移。因為觀察者也不知道幫忙的這個人到底拿了東西還是沒有拿。找很多幫忙的人去幫他進行轉移，最終觀察者拿到的都是已經混淆後信息，都很混亂，推斷不出他是不是最可疑的人。
所以基本思路是增加額外的訪問讓觀察者無法去推斷，使他不可能再和已有的信息聯繫起來，也不可能單純通過訪問來判斷是不是同一個人在做。
張衛（主持人）
剛才例子裡面，間諜情報移動到另外一個地方是能被觀察到，但是多個進行混淆的移動能不能被觀察到呢？
Deli
其實每一個訪問都是可以觀察到的。回到可信環境裡面，CPU每一次對加密內存的訪問也都是可以被看到的，但是如何隱藏真實意圖呢？有一些訪問是沒有任何實質性作用的，但是卻增加了信息量，給攻擊者提供了過多的信息，導致他沒法精確地推斷到底發生了什麼。
張衛（主持人）
謝謝。可以通過這種方式規避掉用戶監測CPU對內存訪問的行為，提煉特點，來形成攻擊？
Deli
對，基本是可以這樣。
張衛（主持人）
關於Advanca相應角色設置上的小問題，worker在建task的時候，是每個worker建一個task，還是會有多個worker建同一個task？在早期的某些區塊鏈場景裡是通過多個worker交叉對比，去抑制worker作惡，這些機制去保證算力任務放到鏈上或者鏈外圍一些相應的worker上可以得到正確的執行。在Advanca的技術設計裡，會有類似於這樣機制的設計嗎？就是多個worker去進行對比。
Deli
對，這個場景其實是存在的。我們現在可以說一個worker只建一個，也可以多個worker合作完成task。具體的細節我覺得可以暫時不用介紹，重點是說worker怎麼互相進行對比，有了Attestation保證我們是可以知道worker運行的代碼是一樣的，進一步只要保證他們拿到的輸入是確定的，我們其實就可以相信worker不會作惡。
多個worker執行同樣的任務，其實是一種冗餘，但也非常有必要。比如將來Intel SGX技術出現了漏洞，如果只攻擊到一個enclave，其他的enclave還沒有受影響，這種情況下還是能保證正確性的。
張衛（主持人）
謝謝Deli。接下來有些問題想諮詢一下尹航，剛剛尹航聊到了保密智能合約，能不能給我們更詳細地介紹一下現在保密智能合約大概能實現哪些功能模塊？
舉個例子，現在要生產一個proof，鏈上的共識節點去驗證，比如說轉賬，轉出的金額和轉入的金額是相等的，兩個都是明文。還有其他的proof，怎麼保證隱私體系沒有受到影響，總額是一定對的，有足夠的餘額去做轉出。這個例子是典型的Z-cash方式的流程。
Phala裡提供的保密智能合約大概有什麼樣的流程、原理能和我們分享一下嗎？
尹航
剛才主持人描述了很典型的基於零知識證明的隱私保護，從用戶端到區塊鏈端的流程。
可以看到，這個過程裡是比較複雜的過程，因為每個環節都是和密碼學做了很緊密的結合，畢竟是基於純密碼學的設計。保密智能合約，因為採用了和TEE結合的方式，保密性是由TEE提供的。我們可以把系統變的非常非常簡單，可以簡單到什麼地步呢？類似於和你做以太坊的合約完全一樣，只不過在以太坊合約內所有存在的數據，輸入、輸出都是在鏈上可見的，或者可以通過執行得到。
但是在保密智能合約這邊，所有的輸出、輸入、中間狀態都是完全加密的。具體用戶怎麼去使用保密智能合約呢？首先，會讓開發者把智能合約編譯好之後提交到鏈上，類似於在以太坊上部署合約。部署到鏈上的合約大家都能看得到裡面每一個操作是什麼，有點像EVM的字節碼一樣。當然，我們採用的是WASM，會把WASM的代碼載入到TEE內。從它載入到TEE內開始的這一刻，所有在內部產生的數據、輸出/輸入都直接對外不可見了。
如果用戶想要調用合約，為了讓輸入保密，TEE和用戶都有自己的公私鑰對，所以就可以執行ECDH協議（迪菲赫爾曼協議）來做密鑰協商。其實就是和HTTPS的原理非常類似。用戶把自己的交易輸入加密之後提交到鏈上，鏈上的交易會被讀入到TEE內部做解密，所以說實現了用戶到TEE之間的端到端加密，可以保證輸出、輸入都是完全保密的。
比如說在以太坊上如果你想查詢內部的狀態，是可以做任意查詢，只要你知道合約的ABI就可以查詢到數據庫裡所有的數據，但是保密智能合約很大的區別是因為內部的狀態對外不可見了，需要額外定義query，只有經過驗證的請求才能回答。這就類似於中心化服務器上的開發，例如向微信發一個query，要先發給微信正確的密碼，才能允許登錄，在我們這裡也是一樣的道理。
我們和以太坊很大的區別是，用戶如果發一個query到TEE來，就需要對自己的query做簽名。 TEE收到query之後會先驗證用戶的身份。開發和在合約內部，可以通過代碼自己來定義用戶在什麼情況下能訪問哪些數據。 TEE只有先做了身份的驗證，驗證通過了才會把對應的數據返回給你，如果身份驗證沒有通過，就只會返回一個錯誤信息。
現在我們做了一個非常簡單的demo，用戶可以以自己的身份來查詢自己的餘額，或者以自己的身份來查詢別人的餘額，如果去查詢別人的餘額就會返回not authorized錯誤，我覺得這是和以太坊最直觀的差別。
與此同時，如果你看這個過程，會發現它跟以太坊的合約開發，以及和大家熟悉的中心化後端開發是很類似的，在中間沒有涉及到特別複雜的密碼學，像零知識證明或者MPC等密碼學工具。所以它對於開發者、用戶來講門檻都是相對比較低的。
張衛（主持人）
通過尹航剛才的介紹，我確實能感覺到這裡面會有一系列的優點，比如說它是相對輕量級的，冗餘並不高。
我有一個小的疑問，這裡面的風險在於冗餘高有效率上的缺點，但是冗餘高也保證相關數據的安全性相對高一些，丟失的風險相對低一些。如果發了隱私Token的合約放在TEE裡，只有這一個TEE設備裡才有狀態和邏輯，這樣一個TEE有沒有可能成為單點風險？ Phala 項目會不會因此設計一些適當的冗餘保證在單點故障情況下出現的數據保護。
尹航
這是我們設計整套系統的核心問題之一，首先要確定的一點是TEE內部所有的數據都只有同一個CPU訪問才能拿到。比如說這個TEE裡產生數據，因為它是加密的，我把這份數據拿到另外的電腦裡，肯定是訪問不到的。基本上只要這個TEE消失了，使用它來加密的數據也消失了，這肯定是大家都不能接受的情況，因為必須要保證可用性。
對於任何區塊鏈來講，如果只是保證正確性是不行的，還要保證可用性的特點。怎麼解決這個問題？首先，要允許礦工自由地進出，不是把數據跟礦工綁定，而是為每一個合約都分配一個密鑰，密鑰可以用來加密合約相關的所有數據，但是如果礦工掉線了，沒有關係，可以引入另外一個TEE節點，只要它可以得到之前的密鑰，就可以接替上一個TEE接著執行。
我們不依賴礦工來保證系統的可用性，只要一個礦工掉線可以拿另一個礦工頂上。怎麼來保證密鑰的可用性？密鑰相對於所有數據來講量是比較小的，所以說設計是在鏈裡有三種角色，第一個角色是區塊鏈，第二個角色是TEE的worker（礦工），第三個角色比較特殊，和礦工有點像，把它叫Gatekeeper，但是它的責任和礦工是不同的。
我們會從全網中選出大概幾十個Gatekeeper，這個數量大概和NPoS的Validater是類似的，它們需要時刻保持在線。我們會把所有合約的密鑰都保存在Gatekeeper的TEE內部，這樣只要保證Gatekeeper在線的概率，在線比例比較高，沒有全部同時下線，整個系統就可以恢復。
具體來講，這就有點涉及到裡面一些密碼學的細節。會在幾十個Gatekeeper之間做Shamir密鑰分享協議，會把所有的密鑰拆成很多份，大概可以理解成只要幾十個節點裡，最少保證幾個節點時刻在線就可以恢復出原始的密鑰。
通常情況下會用一些Staking的方式確保節點，會激勵他一直保持在線，如果他不保持在線會去Slash它，希望在很長的時間裡Gatekeeper至少有一定的數量保持在線，就可以保證可用性。
張衛（主持人）
通過秘密分享來保證N&M，只要N個節點裡面M在線就可以保證系統的可用性。時間過的很快，三位之間還有想要互相了解的問題或者對對方項目的疑問點嗎？
Deli
我其實有個問題想問Maskbook，你們下一步對插件的發展方向大概是什麼樣的？
劉懌斯
現在很多詬病都是說用戶使用的門檻還是蠻高的。首先，我們給他生成了一對私鑰，需要把公鑰貼在Twitter或者放在公開可見的Twitter上，之後所有的發帖過程都是需要有學習成本的。因為我們面對的更希望是小白用戶，也希望看看有什麼樣的方法可以將門檻降低下去。
第二，我們本身可能沒有那麼區塊鏈，但我們認為自己是橋樑，連接傳統互聯網和區塊鏈的“橋樑”。之前用紅包做了demo，證明我們完全可以讓大家在Twitter上執行一段智能合約，實現了在微信或者QQ群裡給別人發紅包的事情。也希望看看未來有沒有其他的像Advanca、Phala Network（的地方）。
你們肯定也希望用戶能夠更簡單地access到你們的服務，比如說你們也希望用戶可以通過很簡單的點擊就可以直接使用到TEE，或者說直接使用到你們的一些服務了，我覺得我們的插件可以幫助大家做到這件事情。之前講了，我們算是權限系統，可以讓應該能看到結果的人看到結果，看不到結果的人看不到結果，這算是我們未來想做的事情。
尹航
非常有意思，我們也希望能夠把隱私保護技術用到用戶更容易能夠接觸到的地方，畢竟大家都在開玩笑說，搞了這麼多區塊鏈，到底用戶能用它做點什麼。
你們確實是非常非常不錯的嘗試，我們也在做我們這邊的嘗試。我有一個問題給Advanca的Deli，我想知道你有非常強大的隱私保護計算系統/存儲系統，能做很多很多非常複雜的應用，你們會把應用落地放在哪個方向上做嘗試？
Deli
重點還是面向用戶，比如說提供平台應用直接面向終端用戶。我們認為這種具有非常高隱私的技術，最大的價值還是在保護每個普通人的隱私上。當然了，如果是公司級的應用也是非常有用的。相對來說，個人的隱私保護更關鍵一點。我們團隊本身也很信奉每個人自己要控制自己數據的理念，這也是未來我們努力的方向。
張衛（主持人）
基於Deli剛剛的回答我有一點疑問，像我們在做商業項目以及各種各樣項目的時候，不單想要保護用戶的隱私，還想要基於保護用戶隱私的基礎上做些數據可用性。就基於這些數據想做分析、推送，數據分析的同時不想侵犯用戶的隱私性。用TEE是不是比較好的解決方法？
Deli
在這種情況下TEE是有機會的，比如說你有一個開源的分析查詢的應用部署在TEE裡，這個應用是沒有做壞事的，因為代碼已經被大家審核過了。只要代碼邏輯裡不把大家的隱私發送出去，大家就可以相信它是可信的服務。重點是把最終要實現的功能所用到的數據拿出來，而不是直接把用戶數據暴露出去。
張衛（主持人）
感謝三位的分享，隱私保護是個很有意思的話題，期待後面有更多的探討和碰撞，也謝謝大家。
End
※———長按識別下方二維碼關注我們———※
長按識別下方二維碼，加入萬向區塊鏈
多個核心崗位在招，薪資福利優厚
▼
