張衛（主持人）
大家晚上好，我是萬向區塊鏈通用架構技術部負責人張衛，今天很高興作為蜂巢學院線上公開課直播間第十五期的主持人。歡迎大家來到直播間，很高興邀請到了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裡，這個應用是沒有做壞事的，因為程式碼已經被大家稽覈過了。只要程式碼邏輯裡不把大家的隱私傳送出去，大家就可以相信它是可信的服務。重點是把最終要實現的功能所用到的資料拿出來，而不是直接把使用者資料暴露出去。
張衛（主持人）
感謝三位的分享，隱私保護是個很有意思的話題，期待後面有更多的探討和碰撞，也謝謝大家。
