1703878261
TLSNotary在三方（服务端、审计方和被审计方）之间分解对称加密密钥和MAC密钥。TLSNotary的基本思想是被审计方可以向审计方证明某一个给定结果是由服务端在某个给定时间返回的。
1703878262
1703878263
TLSNotary实现上述功能的过程为：审计方计算对称密钥和MAC密钥，并且只向被审计方提供对称密钥。被审计方不需要MAC密钥，因为MAC签名检测确保来自服务端的TLS数据在传输过程中不被篡改。有了对称密钥，被审计方可以解码来自服务端的数据。因为银行使用MAC密钥“签署”所有信息，而且只有服务端和审计方知道MAC密钥，因此正确的MAC签名可以被当作特定信息来自银行且未经被审计方篡改的证明。
1703878264
1703878265
在Oraclize服务情况下，Oraclize是被审计方，而审计方是一个特别设计的开源Amazon机器图像锁定的AWS实例。
1703878266
1703878267
它们提供的证明数据是一个正常TLSNotaryproof确实已发生的AWS实例的已签名证明。它们还提供一些涉及AWS实例中软件运行的其他证明，即自初始化之后它是否被修改过。
1703878268
1703878269
1703878270
1703878271
1703878272
区块链项目开发指南 [:1703875371]
1703878273
区块链项目开发指南 7.1.4 定价
1703878274
1703878275
来自任意以太坊地址的第一个Oraclize查询调用都是完全免费的。Oraclize调用在测试网中都是免费的！这只适合在测试环境进行适度使用。
1703878276
1703878277
从第二个调用起，要进行查询就必须支付以太币了。在发送查询到Oraclize（即进行内部交易调用）时，会扣除一定费用（从调用合约向Oraclize合约转账以太币）。扣除的以太币数量取决于数据源和证明类型。
1703878278
1703878279
表7-1显示了发送查询时扣除的以太币数量。
1703878280
1703878281
表7-1 发送查询时扣除的以太币数量
1703878282
1703878283
1703878284
1703878285
1703878286
所以如果正在发出HTTP请求，而且想要有TLSNotary proof，则调用合约必须有价值$0.05的以太币；否则，就返回异常。
1703878287
1703878288
1703878289
1703878290
1703878291
区块链项目开发指南 [:1703875372]
1703878292
区块链项目开发指南 7.1.5 开始使用Oraclize API
1703878293
1703878294
为了让合约使用Oraclize服务，它需要继承usingOraclize合约。用户可以在https://github.com/Oraclize/Ethereum-api找到该合约。
1703878295
1703878296
usingOraclize合约可以代替OraclizeI和OraclizeAddrResolverI合约。事实上，usingOraclize使得OraclizeI和OraclizeAddrResolverI合约的调用变得方便，也就是说，它提供了更简单的API。也可以直接调用OraclizeI和OraclizeAddrResolverI合约。读者可以学习这些合约的源代码以发现所有可用API，本书中，我们只学习最必需的那些。
1703878297
1703878298
下面来看设定proof类型、设定proof存储位置、进行查询、获取查询费用等的方法。
1703878299
1703878300
1.设置证明类型和存储位置
1703878301
1703878302
无论是否需要来自TLSNotary的proof，必须在发出查询之前指定proof类型和proof存储位置。
1703878303
1703878304
如果不需要proof，就把下面的代码放入合约：
1703878305
1703878306
1703878307
1703878308
1703878309
如果需要proof，就把下面的代码放入合约：
1703878310