初學者的一些粗略理解，如果有錯，歡迎指正，
論文地址
TC官方網站（里面有作者提供的案例）
本文參考了這篇解讀，尤其是前半部分，刪改不多，感謝作者

1. INTRODUCTION

這篇論文主要針對的是智能合約，為智能合約提供一個經過身份驗證的資料饋送（data feeds），
（個人理解有點像快遞員，把經過驗證打包的資料遞送給智能合約，它提供驗證和傳遞，但是不會改變資料的內容，）

首先我們了解一下背景資訊，智能合約是自動執行合同條款的計算機程式，比如日常的汽車貸款付款、保險等都可以通過智能合約自動完成，
但這意味著，智能合約的執行離不開真實生活中的資料，比如執行汽車貸款支付的智能合約需要知道車主是否及時付款，以確定車主取消是否依舊享有實際訪問權限等等，

另一個問題則是資料的隱私性，區塊鏈的分布式的特點能夠讓每個人都去記賬，從而達到防抵賴、防篡改的目的，但從另一個角度來看也是區塊鏈的缺點，所有區塊狀態都是公開可見的，data feeds可能會暴露出用戶的請求，隱私性被破壞，

針對以上兩個問題，作者提出了Town Crier——為智能合約提供一個經過身份驗證的data feed，在智能合約和外部網路（論文假設外部的資料是可信的、真實的）中構建一座資料流通的橋梁，

Town Crier

1. Town Crier檢索網站資料，然后將其作為依賴于區塊鏈上的合同的資料，稱之為資料報（datagrams），
2. 小販利用Intel可信組件SGX（ Software Guard Extensions）作為后端，智能合約作為前端，以SGX安全區中受信任的代碼段的形式執行其核心功能，從而保護其免受惡意行程和OS的侵擾，并可以向遠程客戶端證明該客戶端正在與SGX支持的合法TC實體進行互動，(這個Software Guard Extensions是一項針對應用程式開發人員的英特爾技術，旨在保護選擇的代碼和資料不被泄露或修改，SGX通過使用圍圈，或者稱之為飛地（enclave），即記憶體中受保護的執行區域，使這種保護成為可能，)
3. 小販也支持私密資料報請求（private datagram requests）和自定義資料報請求（ custom datagram requests），用戶請求private datagram requests時，引數被小販的公鑰加密，加密程序在SGX中完成，因此資料報和資料的請求在區塊鏈上是被隱藏起來的，用戶請求custom datagram requests時，TC通過接收加密的用戶憑據，安全地訪問請求者的在線資源（如在線帳戶），從而允許TC安全地檢索訪問控制資料，

Contributions
論文的主要奉獻有以下4點：

1. 論文介紹并報告了Town Crier的端到端實施，這是一種經過身份驗證的資料饋送系統，可解決采用分散式智能合約的關鍵障礙，TC將以太坊中的智能合約前端和基于SGX的可信硬體后端結合在一起，以在沒有可信服務運營商的情況下將經過身份驗證的資料提供給智能合約，以及支持私有和自定義資料請求，支持加密請求和安全使用訪問控制的鏈下資料源，
2. 論文在通用組合（UC）框架內正式分析TC的安全性，定義了代表鏈上和鏈外組件的功能， 正式定義并證明資料報真實性和公平支出以及gas可持續性的基本屬性，這是任何以太坊服務的基本可用性屬性，
3. 論文引入了跨區塊鏈和SGX enclave的混合可信計算基（TCB），這是可信賴系統組成的強大新范例， 我們提供了有助于在此模型中縮小TCB代碼大小的通用技術，以及彌補各個SGX平臺漏洞的技術，（可信計算基（英語：Trusted computing base, TCB）是指為實作計算機系統安全保護的所有安全保護機制的集合，機制可以硬體、韌體和軟體的形式出現，一旦可信計算機基的某個構件出現程式錯誤或者安全隱患，就對整個系統的安全造成危害， 與之相反，如果除可信計算基之外的系統的其他部分出現問題，也只是泄漏了系統安全策略賦予它們的相關權限而已，這些權限一般都是比較低的，）
4. 論文探索了三種TC應用程式，這些應用程式顯示了TC能夠支持遠遠超出當今以太坊的服務范圍的能力， 這些應用程式的實驗還表明，TC可以輕松滿足現代分散式區塊鏈的延遲和吞吐量要求，

論文實作的三種智能合約實體為：

1. 使用股票報價器資料的金融衍生產品；
2. 依賴于有關航班取消的私人資料請求的飛行保險合同；
3. 使用自定義資料請求訪問用戶帳戶的以太坊貨幣以太幣（通過Steam Marketplace）銷售虛擬商品和在線游戲的合同，

2. BACKGROUND

TC主要引入的技術包括可信執行環境（論文使用的是Intel的SGX，我的老師建議也了解一下TEE）、TLS/HTTPS以及智能合約，

1. 可信執行環境SGX是通過硬體實作或者軟體技術實作的一個安全的代碼運行環境，可以理解為一個黑盒子，將執行的代碼放在黑盒子里，提供輸入最后獲取輸出，整個執行的程序不能被外界更改，也不能被觀察到，可以認為是安全的模型，
2. HTTPS （全稱：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全為目標的 HTTP 通道，在HTTP的基礎上通過傳輸加密和身份認證保證了傳輸程序的安全性，TLS，安全傳輸層協議，用于在兩個通信應用程式之間提供保密性和資料完整性，該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake），TC利用了HTTPS的重要功能，即可以將其劃分為可互操作的層：與Web服務器互動的HTTP層，處理握手和安全通信的TLS層以及提供可靠資料流的TCP層，
3. 智能合約（Smart contract ）是一種旨在以資訊化方式傳播、驗證或執行合同的計算機協議，智能合約允許在沒有第三方的情況下進行可信交易，這些交易可追蹤且不可逆轉，

3. ARCHITECTURE AND SECURITY MODEL

Architecture

TC包含三個主要組件：The TC Contract (C_TC), the Enclave (代碼標記為prog_encl), and the Relay (R).

這個圖給出了TC的架構示意圖，顯示了它與外部物體的互動，綠色的部分是被信任的組件，
我們看看它的三個主要組件：

1. Tc contract：TC智能合約，C_TC是一種智能合約，充當TC的區塊鏈前端， 它旨在為依賴合同C_U提供一個簡單的API，以向TC提出請求， 其接受來自C_U的資料報請求，并從TC回傳相應的資料報，
2. Enclave：飛地，在SGX enclave中運行的TC智能代碼實體簡稱為Enclave，并用prog_encl表示代碼本身，Enclave提取并完成來自區塊鏈的資料報請求， 為了獲取要包含在資料報中的資料，它查詢外部資料源，特別是啟用HTTPS的Internet服務， 它將資料報作為數字簽名的區塊鏈訊息回傳到請求合同C_U，
3. Relay：中繼器，由于在SGX中缺少直接的網路訪問，因此將R布置在enclave中代替其處理雙向的資料流量處理，提供了從飛地到三個不同物體的資料連接，即區塊鏈、客戶和資料源，
   注意：圖中R作為TC Server的一部分，不受到SGX的保護，可以被外部攻擊，從而導致延遲和失敗，但根據TC實際的初衷，R一般不會產生錯誤的資料（因為這樣他們可能會支付gas），只會產生拒絕服務攻擊，

需要注意的是Enclave和Relay都是部署在TC服務器上的，而TC智能合約是部署在區塊鏈上的，

另外我們將利用Town Crier服務作為請求者或依賴合同的智能合約稱為“用戶智能合約”，表示為C_U，并將其所有者稱為客戶或用戶，資料源是一個在線服務器（運行HTTPS），該服務器為TC提供用來構成資料報的資料，

Security model

• TC Contract，TC智能合約全域可見，且源代碼被客戶共享，因此假設C_TC行為誠實可信，
• Data Source，假設客戶信任從HTTPS上獲得的資料報，同時假設資料源穩定、在特定的時間間隔可以產生請求者所需要的資料，
• Enclave，作者做了三個假設：1）飛地程式正確執行合約代碼；2）每個飛地產生的公私鑰對（sk_TC，pk_TC），私鑰只有飛地自己知道；3）飛地程式內部有確切的時間，
• Blockchain communication，交易和訊息源是可驗證的，即，接收方帳戶將從錢包W_X發送的交易m標識為源自X，交易和訊息受到完整性保護，但不是機密資訊，
• NetWork comunication， 中繼可能會篡改或延遲與Enclave之間的通信， 正如我們在SGX安全模型中所解釋的那樣，中繼不能以其他方式觀察或改變安全區的行為，因此，中繼可以被控制網路的對手所占領，

4. TC PROTOCOL OVERVIEW

TC的整體流程相對簡單，一個用戶合約C_U向TC智能合約C_TC請求資料，C_TC將請求轉發給Enclave，并將結果回傳到C_U，

4.1 Datagram Lifecycle

資料報周期大致可以分為以下幾個步驟：

• 初始化請求，C_U給C_TC發送一個資料報請求，
• 監視和中繼， 中繼監視C_TC，并將帶有引數params的資料報請求中繼到飛地，
• 飛地獲取資料， 為了處理在params中指定的請求，Enclave通過HTTPS與資料源聯系并獲取請求的資料報，它通過中繼將資料報轉發到C_TC，
• 回傳資料報， C_TC將資料報回傳給C_U，

4.2 Data Flows

資料流分為以下4步：

1. C_U發出的資料報請求采用訊息m1=(params, callback)的形式發送給區塊鏈上的C_TC， params指定所請求的資料報，例如params=(url，spec，T），其中url是目標資料源，spec指定要檢索的資料報的內容（例如，特定時間的股票行情自動收錄器），以及T指定資料報的傳遞時間（通過抓取資料源啟動）， m1中的引數callback指示資料報將回傳到的入口點，
2. C_TC生成一個新的唯一ID，并將m2=（id，params）轉發給Enclave，
3. 作為回應，它從TC服務接收m3 =（id，params，data），其中data是所請求的資料報（例如所需的股票行情價格)，
4. C_TC檢查請求和回應上的引數的一致性，如果匹配，則將資料轉發到訊息m4中的回呼入口點，為了簡單起見，我們假設CU發出一次資料報請求，因此，它可以簡單地將m4與m1匹配，

論文的完整協議包含一個優化，通過該優化，C_TC在m1之后將ID作為所有資料流的一致，可信賴的識別符號回傳給C_U，這使得直接處理來自相同C_U實體的多個資料報請求成為可能，

圖2顯示了處理資料報請求所涉及的資料流，為簡單起見，該圖省略了中繼，該中繼僅負責資料傳遞，需要數字簽名來驗證訊息，例如m3，這些訊息將從外部來源進入區塊鏈，我們讓（sk_TC，pk_TC）表示與Enclave關聯的用于此訊息身份驗證的私鑰/公鑰對，為了簡單起見，圖2假定Enclave可以將簽名的訊息直接發送到C_TC，

5. TWO KEY SECURITY PROPERTIES

5.1 Gas Sustainability

以太坊的費用模型要求gas費用由發起交易的用戶支付，包括因交易確認不斷呼叫而產生的所有費用，這意味著發起對以太坊合約的呼叫服務必須花費金錢來執行那些呼叫，如果沒有精心設計，這可能會導致財務耗盡，并導致應用程式層拒絕服務攻擊，因此，對于基于以太坊的服務的可用性至關重要的是，始終向其發起的區塊鏈計算報銷它們的費用，
為了確保服務不會受到此類攻擊的影響，作者定義了gas可持續性，這是基于區塊鏈合同的服務的活力所必需的新條件，gas可持續性是任何以太坊服務永續發展的基本要求，它也可以推廣到以太坊之外；任何基于分散式區塊鏈的智能合約系統都必須收取某種費用，以補償礦工進行和驗證計算的費用，

令bal(W)表示以太坊錢包W的余額，
定義1（K-Gas可持續性) 具有錢包W和區塊鏈功能f1,…,fn的服務是K-gas可持續的充分條件是：

1. 如果在執行任何fi之前bal(W)≥K；且服務誠實運行
2. 則在每次執行由W發起的fi時，bal(W)≥K，

在以太坊進行的gas不足的呼叫將會中止，但依然會消耗所有提供的gas，所以如果錢包提交的交易資金不足，錢包的余額將降至0，因此，要使K-gas在K>0的情況下可持續，服務發出的每個區塊鏈呼叫都必須補償gas支出，此外，該服務必須為每次呼叫或者與交易的其他部分一起恢復的補償提供足夠的gas，

5.2 Hybrid TCB Minimization

在涉及智能合約與鏈下可信計算環境（例如SGX）互動的系統中，TCB是具有不同屬性的兩個組件的混合體，智能合約中的計算速度慢，成本高且完全透明，這意味著它不隱秘， SGX飛地具有強大的計算功能并可以私下執行，但是所有外部互動（尤其是與合同的通信）都必須經過不受信任的中介，盡管此混合TCB的功能強大且遠超過TC，但仍帶來了挑戰：如何在組件之間建立安全的通信，同時最大程度地減少TCB中的代碼，

作者在這個圖中定義了兩個TCB組件的抽象，
為了將這些抽象與形式化的理想功能區分開來，作者使用T表示可信組件，
T_Off：鏈外TCB的抽象
T_On：鏈內TCB的抽象
O_Auth：資訊饋送，用來對鏈上訊息的身份驗證進行建模，如果輸入是有效的區塊鏈事務，該模型將回傳true，

由于以太坊塊是使用Merkle樹進行自我認證的，因此原則上我們可以通過在TCB中包含以太坊客戶端來實作O_Auth，但是這樣做極大地增加了代碼占用空間，以太坊的核心實作大約是5萬行C ++，類似地，智能合約可以通過檢查證明來驗證來自SGX的訊息，但是在智能合約中實作認證將很容易出錯，并且在計算上（因此在經濟上）昂貴，

在鏈外TCB（T_Off），我們需要驗證收到的區塊鏈請求是否有效；在鏈內TCB（T_On），我們需要驗證請求，資訊和簽名，這兩個是開銷最大的地方（圖片4中標紅的函式），

所以作者提出了兩種通用技術來避免這些呼叫，從而最大程度地減少TCB中的代碼大小，第一種適用于任何TCB組件為區塊鏈合同的混合系統，第二個適用于TCB組件僅通信以發出和回應請求的任何混合系統，

Binding T_Off to W_TC，將T_Off系結到W_TC，

由于鏈上TCB的計算速度快且成本高，我們希望避免實施簽名驗證，確實存在一個預編譯的以太坊合同，以驗證ECDSA簽名，但是操作需要高昂的gas費用，
取而代之的是，作者將T_Off的身份系結到以太坊錢包，這使TOn可以簡單地檢查訊息發件人，該訊息發件人已經作為以太坊交易協議的一部分進行了驗證，這其中的關鍵是資訊只能作為來自錢包的交易插入以太坊區塊鏈，因此，中繼器將訊息從T_Off中繼到T_On的唯一方法是通過錢包W_TC，由于以太坊本身已經驗證了交易上的簽名（即用戶通過經過身份驗證的渠道與以太坊進行互動），因此我們可以在現有交易簽名驗證機制的基礎上執行帶T_Off簽名的驗證，
簡而言之，T_Off使用新的公鑰pk_Off創建W_TC，該公鑰的密鑰只有T_Off知道，為了使這個想法充分發揮作用，必須將公鑰pk_Off硬編碼到T_On中，創建或依賴使用T_On的合同的客戶負責確保與T_On互動之前，此硬編碼的pk_Off具有適當的SGX證明，
通過假設依賴客戶端已經驗證了T_Off的證明，我們可以假定從W_TC發送的資料報被信任為源自T_Off，這樣就無需在T_On中進行昂貴的EPID簽名驗證，
另外，SGX可以將pk_Off密封在非易失性存盤中，同時保護完整性和機密性，使我們可以通過服務器重啟來保持相同的系結，

具體我們可以看一下圖5，它是用戶的SGX認證離線驗證，它要求客戶端檢查飛地代碼T_Off和公鑰pk_Off的SGX認證，同時在使用T_On之前檢查pk_Off是否硬編碼到區塊鏈合約T_On中，
如果三個認證都能通過的話就認為T_On是可信的，

Eliminating O_Auth，消除O_Auth，
為了消除從T_Off呼叫O_Auth的需要，作者利用這樣一個事實：從T_Off到T_On的所有訊息都是對現有請求的回應，我們不需要在T_Off中驗證請求引數，而是可以在T_On中驗證T_Off是否回應了正確的請求，
對于每個請求，T_On存盤該請求的引數，在每個回應中，T_Off都包含它用來完成請求的引數，然后，T_On可以檢查回應中的引數是否與存盤的引數匹配，如果不匹配，則直接拒絕，存盤引數和檢查相等性是簡單的操作，比在T_Off中呼叫O_Auth要簡單得多，
這種方法可能會開啟新的攻擊（例如，中繼可以發送TOff回應的虛假請求），但是作者在第7節中所證明了，所有此類攻擊都會減少為來自網路的DoS攻擊或中繼攻擊，而混合TCB系統本身就很容易受到這些攻擊的影響，并且作者并不打算在TC中對它們進行保護，

6. TOWN CRIER PROTOCOL

為了了解TC協議，我們需要進行一些預備作業，為簡單起見，我們假設只有一個飛地實體，其實這個系統是可以擴展多個飛地，甚至多個主機的，
為了確保gas可持續性，TC要求申請人提前支付gas費用，然后TC智能合約償還TC的gas費用，通過讓可信組件執行補償，我們還可以保證惡意TC在不提供有效資料的情況下無法竊取誠實用戶的資金，

Notation.
首先是符號說明，
我們使用符號m_i標記與圖2中的訊息相對應的訊息，
付款時，$g表示gas，$f表示非gas貨幣，為簡單起見，作者假設gas和貨幣采用相同的單位（這樣可以避免顯式轉換），我們使用以下識別符號來表示貨幣和gas，

Initialization. 初始化， TC向W_TC至少存入$G_max，

The TC Contract C_TC. TC智能合約， TC合約接受來自C_U的資料報請求和費用$f，為其分配一個唯一id，并對其進行記錄，然后中繼器R監視請求并把它們轉發到Enclave，在收到W_TC的回應后，C_TC驗證引數以確保有效性，如果請求有效，C_TC通過呼叫初始請求中指定的callback來轉發生成的資料報，為了確保所有花費的gas都可以報銷，C_TC在這個子呼叫中設定$g_clbk:=$f-$G_min，（可以報銷的最大值=押金-不包含callback的deliver需要的gas），然后把這個值連同資料報一起回傳給callback，

The Relay R. 中繼器R， 如前面所述，R通過三種方式架起了Enclave和區塊鏈之間的橋梁，
1 它從C_TC里獲得新請求 (id, params)，
2 使用這兩個命令prog_encl.Initialize() 和prog_encl.Resume(id, params) 向飛地傳入請求，
3 它將資料報從Enclave轉發到區塊鏈，
它將已經簽署的交易作為W_TC轉發給區塊鏈，函式AuthSend將交易插入區塊鏈，以W_TC的形式，表示交易已被TC私鑰簽名，誠實的中繼器只會為每個有效請求的引數呼叫一次prog_encl.Resume，

The Enclave prog_encl. 飛地， 當通過 Initialize()初始化時，prog_encl接收當前的掛鐘時間；通過存盤該時間并設定時鐘參考點，它校準其絕對時鐘，它生成一個ECDSA密鑰對（pk_TC，sk_TC）（在以太坊中引數化），其中pk_TC通過插入到證明中系結到prog_encl實體，在呼叫Resume(id, params) 時，prog_encl通過HTTPS聯系params指定的資料源，并檢查相應的證書是否有效，然后prog_encl獲取請求的資料報，并將其回傳給中繼器R，包含params*、id和GASLIMIT $g_dvr:=$G_max，所有這些都是用sk_TC數字簽名的，

The Requester Contract C_U . 用戶智能合約， 誠實的請求者首先遵循圖5中的協議來驗證SGX證明，然后她準備params和callback，用params將$g_req設定為Request的開銷，將$f設定為$G_min加上執行callback的開銷，并用GASLIMIT$g_req呼叫Request(params, callback, $f)，
如果沒有執行callback，她可以使用GASLIMIT$g_cncl呼叫Cancel(id)來接收部分退款，一個誠實的請求者將為她的每個請求最多呼叫一次Cancel，且不會為任何其他用戶的請求呼叫Cancel，

Money Flow，紅色箭頭表示資金流動，棕色箭頭表示gas limits，線條的粗細表示資源的數量，$g_clbk箭頭很細，因為$g_clbk被限制為$f?$G_min，
（我個人理解$f就是用戶墊付的用于支付Deliver所需的gas的費用，）

6.1 Private and Custom Datagrams

• 除了普通資料報之外，TC還支持私密資料報（private datagrams），私密資料報是pk_TC下params包含密文的請求，因此，盡管區塊鏈具有公共可讀性，但私密資料報可以實作保密應用，
• TC也支持自定義資料報（Custom datagrams），它允許合約指定特定的web抓取目標，可能涉及多個互動，從而大大擴展了TC可能依賴的合約的范圍，

6.2 Enhanced Robustness via Replication

• 為了防止單個SGX實體的危害，TC可以從多個SGX實體請求資料報，并在回應之間實作多數投票，這種對沖需要增加額外請求和存盤回傳資料的gas支出，
• TC可以通過為相同的資料抓取多個資料源并選擇多數回應來避免資料源的損害，

7. SECURITY ANALYSIS

Authenticity. 可靠性， 直觀地說，可靠性意味著對手（包括惡意的用戶、中繼或其兩者結合起來）無法說服C_TC接受與在指定時間抓取指定資料源獲得的預期內容不同的資料報，
在我們的正式定義中，我們假設用戶和C_TC的行為是誠實的，回想一下，用戶必須預先驗證為飛地公鑰pk_TC擔保的證明σ_att，

定義2（ Data Feed的可靠性) 對于能與任意F_sgx互動的多項式時間A，當data不是時間T時具有公鑰pk_url的url中的內容時，A無法讓誠實的驗證者接受(pk_TC, σ_att, params := (url, pk_url, T), data, σ)，(在這個模型中是prog_encl.Resume(id, params) )
// negl()指可忽略不計的，

定理1 (可靠性)
假設∑_sgx和∑是安全簽名方案，那么，TC協議在定義2中實作了Data Feed的可靠性，

Fee Safety. 收費安全，

一個誠實的用戶應該只需要為代表她誠實執行的計算付費，如果傳遞了有效的資料報，則這是一個常量值加上執行callback的成本，否則，請求者應該能夠識訓執行Deliver的成本，為了使定理2成立，C_TC必須在取消時保留少量費用，但我們允許用戶識訓除此少量固定金額之外的所有費用，我們現在將這種直覺形式化，

定理3 (誠實請求者的公平支出)
對于任何params和callback，在提交請求（params，callback，$f，$g_req）時，$G_req和$F分別是誠實選擇的$g_req和$f值，對于誠實用戶提交的任何此類請求，有以下情況之一:

• 當有效資料報成功匹配請求引數params， callback被呼叫時，請求者最多花費$G_req+$G_cncl+$F；
• 請求者最多花費$G_req+$G_cncl+$G₀，

Other security concerns. 其他安全問題， 在第6.2節中，我們討論了對基本TC協議中包含的SGX隔離模型之外的攻擊的關注，雖然我們在第8.1節中簡要討論了這一問題，但我們在TC中沒有提到的威脅是網路對手進行流量分析的風隙訓針對機密應用程式（例如，使用private datagrams）的中繼泄露的風險，我們還注意到，雖然TC假設資料源的正確性，但如果發生刮取故障，TC會傳遞一個空資料報，從而使依賴的合約失敗，（即使傳遞了無效的空資料報，但依然會花費使用者的gas，）

8. EXPERIMENTS

8.1 Requesting Contracts

• Financial Derivative (CashSettledPut). 金融衍生工具是最常被參考的智能合約應用之一，也是金融工具 data feed需求的例證，我們為現金結算看跌期權實作了一個示例合約CashSettledPut，這是一方在特定日期或之前以約定的價格從另一方購買資產的協議，這是“現金結算”，因為銷售是隱性的，即沒有資產變動，只有反映資產價值的現金，
• Flight Insurance (FlightIns). 航班延誤或取消時的航班保險賠償，我們實施了一個簡單的飛行保險合約，叫做飛行保險，我們的實作展示了TC的private-datagram特性，以解決一個明顯的問題：客戶可能不希望在區塊鏈上公開他們的旅行計劃，客戶向C_TC提交了一個在Town Crier 飛地公鑰pk_TC下加密的請求Enc_pkTC(req)，飛地解密req并檢查其格式是否正確（例如，是否在起飛時間之前很久提交），飛地隨后將在指定的時間從目標網站獲取飛行資訊，并向C_TC發送一份資料報，表明飛行是否延遲或取消，最后，為了避免通過計時（例如，訪問飛行資訊網站或發送資料報時）泄露資訊，引入了隨機延遲，
• Steam Marketplace (SteamTrade). 經過身份驗證的資料源和智能合約可以在沒有預先建立信任的互聯網用戶之間公平地交換資料商品，我們為Steam開發了一個支持虛擬物品公平交易的示例應用程式，Steam是一個在線游戲平臺，支持數千個游戲并維護自己的市場，用戶可以在這里交易、購買和銷售游戲和其他虛擬物品，我們實作了一個銷售以太游戲和物品的合同，展示了TC通過使用steam的訪問控制API對定制資料報的支持，在我們的實作中，賣家將Enc_pkTC(account credentials，req)發送給C_TC，這樣Enclave就可以作為賣家登錄，并從網頁上判斷虛擬物品是否已經發貨，

8.2 Measurements

TCB Size. TCB大小， Town-Crier的TCB包括Enclave和TC-Contract，Enclave包括大約46.4K的C/C++代碼行，其中絕大多數（42.7K行）是修改的mbedTLS庫，mbedTLS的源代碼已經被廣泛部署和測驗，而Enclave代碼庫的其余部分足夠小，可以進行正式驗證，TC合約也很緊湊；它由大約120行物體代碼組成，

Enclave Response Time. 飛地回應時間， 它的定義為（1）中繼向enclave發送請求和（2）中繼從enclave接收回應之間的間隔，
表1總結了飛地的總回應時間及其在500次運行中的細分情況，所有時間都以毫秒為單位，包括平均值（mean）、比例（%）、最大值（tmax）、最小值（tmin）和標準差（σt），注意，Total是端到端回應時間，定義為非沖突回應時間，由于較小的開銷沒有計入，時間總和可能不等于這個總數，對于作者實作的三個應用程式，enclave回應時間從180 ms到599 ms不等，回應時間顯然是從網站獲取請求的資訊所需的時間，在評估的三個應用程式中，SteamTrade的web scraper時間最長，因為它通過多次往返與目標網站互動以獲取所需的資料報，

Transaction Throughput. 吞吐量， 我們執行了一系列實驗，測量交易吞吐量，同時將單個支持SGX的主機上并發運行的Enclave的數量從1擴展到20，20 TC enclaves是我們使用的特定機型上的enclave記憶體限制的最大可能值，圖10顯示，對于所評估的三個應用，單個SGX機器可以處理15到65 tx/秒，
幾個重要的資料點顯示了TC如何有效地滿足當今區塊鏈對認證資料的需求：以太坊目前平均處理低于1tx/秒，位元幣目前的處理速度略高于3tx/秒，其最大吞吐量（在全塊利用率下）約為7tx/秒，據我們所知，還沒有對以太坊對等網路的吞吐量界限進行測量研究，最近的研究[19]表明，如果不重新設計協議，位元幣不能擴展到26 tx/秒以上，因此，使用很少的主機，TC可以很容易地滿足分散區塊鏈的資料饋送需求，
（我的老師說這里的資料有點問題，以太坊的處理速度應該是比位元幣要快的，）

Gas Costs. Gas花費， 從TC獲取資料報的總callback獨立成本（即，資料報的成本，而不是應用程式的成本）范圍為11.9￠ (CashSettledPut）至12.9￠ (SteamTrade），（差不多人民幣7-8毛錢），這種變化是由不同的引數長度引起的，

Component-Compromise Resilience. 組件折損彈性， 對于CashSettledPut應用程式，我們實作并評估了兩種多數表決模式（如第6.2節所示）：

• enclave內三取二多數投票，針對資料源出錯提供健壯性，在我們的實驗中，enclave從三個不同的資料源（彭博社、谷歌財經和雅虎財經）對當前的股價進行了簡單的順序刮取，在這種情況下，會導致飛地回應時間變長，但gas成本沒有變化，
• 請求者合同中三取二多數投票，這提供了針對SGX出錯的穩健性，我們運行了三個SGX enclaves實體，所有實體都使用相同的資料源，在這種情況下，gas成本將增加3倍，再增加5.85￠，

Offline Measurements. 離線測量， 因為clock()在SGX中只產生相對時間，所以TC的絕對時鐘通過外部提供的掛鐘時間戳進行校準，用戶可以通過請求數字簽名的時間戳來驗證Enclave絕對時鐘的正確性，實驗表明，中繼發送時鐘校準請求到飛地和接收到回應之間的時間是11.4（1.9）ms，其中10.5（1.9）ms用于簽署時間戳，除此之外，還必須加上廣域網的往返延遲，很少超過幾百毫秒，

————————
感覺這篇論文有意思的點就在于把SGX和智能合約兩個完全不相干的東西聯系在了一起，有時候就應該多多擴展思維，往不同的方向嘗試，