预言机理解：A Scalable Architecture for On-Demand, Untrusted Delivery of Entropy

阅读背景

由于要做智能合约随机数监测相关的内容，所以也需要调研清楚目前智能合约随机数生成的手段之一：预言机。
本文来自链接智能合约预言机随机数生成案例的github主页，感兴趣也可以阅读。

概览

This paper presents a scalable software architecture enabling delivery of on-demand entropy by an untrusted third-party, henceforth the data carrier, without risks of front-running or tampering. The entropy is generated by one or more trusted, secure-element based devices featuring remote attestation.
本文提出了一种可扩展的软件体系结构，使得不可信的第三方（即数据载体）能够按需提供熵，而不存在前端运行或篡改的风险。熵是由一个或多个具有远程认证功能的可信、安全的基于元素的设备生成的。
The proposed scalable architecture accommodates the different hardware limitations of embedded Trusted Execution Environments (TEEs) and more modern trusted computing technologies as Intel SGX, and to easily adapt to different use contexts.
提出的可扩展体系结构可适应嵌入式可信执行环境(TEEs)和更现代的可信计算技术(如Intel SGX)的不同硬件限制，并易于适应不同的使用环境。
In particular, the use in the context of applications interacting with blockchain protocols and smart contracts had a primary role in shaping our design, but the applicability of the technology is not limited to this context only.
特别是，在与区块链协议和智能合约交互的应用程序中的使用对我们的设计有着重要的影响，但该技术的适用性并不局限于此。

Introduction

One of the most compelling and unsolved problems in the context of blockchain protocols and smart contracts is the trustless generation of random numbers. Different methods, some of which will be surveyed later, have been proposed but fell short of their stated goal due to the complexity of the economic incentives infrastructure and the strictly deterministic nature of blockchain protocols.
区块链协议和智能合约中最引人注目和未解决的问题之一是随机数的无信任生成。由于经济激励基础设施的复杂性和区块链协议的严格确定性，已经提出了不同的方法，其中一些方法将在稍后进行调查，但没有达到其既定目标。
The lack of a solution to this problem is limiting what smart contracts can accomplish today. Besides the obvious applications of random number generation to provably-fair gaming and gambling systems, there are many others: e.g efficient probabilistic payment channels, random ballots systems and possibly some yet to be invented. Unfortunately, a theoretical solution seems nowhere near of being discovered.
这一问题的解决方案的缺乏限制了智能合约在今天所能实现的目标。除了随机数生成在可证明公平的游戏和赌博系统中的明显应用之外，还有许多其他的应用：例如有效的概率支付渠道、随机投票系统和可能还有一些尚未发明的系统。不幸的是，理论上的解决方案似乎离被发现还很遥远。
As a data carrier, Oraclize is well familiar with the concept: any party interacting with a data-dependent smart contract must trust the data source. The aim of a service like Oraclize is to remove itself completely from the trust equation, by providing cryptographically binding data authenticity proofs, leveraging attestation technologies provided by widely recognized actors.
作为一个数据载体，Oraclize非常熟悉这样一个概念：与数据相关的智能合约交互的任何一方都必须信任数据源。像Oraclize这样的服务的目的是通过提供加密绑定的数据真实性证明，利用广泛认可的参与者提供的认证技术，将自己从信任等式中完全移除。
The applicability of the architecture is not limited to blockchain space only. Thanks to its flexibility, it can be used by any type of applications requiring a random input, while retaining the same security guarantees.
该体系结构的适用性不限于区块链空间。由于它的灵活性，它可以被任何类型的应用程序使用，需要随机输入，同时保留相同的安全保障。
These processes can fail badly and leave no accountability as it has happened more than once in the gambling industry. Oraclize’s team believes that the model presented in the paper offers far higher, mathematically binding guarantees of fairness, thanks to open and third-party auditable authenticity proofs.
这些过程可能会严重失败，并没有留下任何责任，因为它已经发生了不止一次在赌博业。Oraclize的团队认为，由于公开的第三方可审计的真实性证明，论文中提出的模型提供了更高的、具有数学约束力的公平性保证。

小结

智能合约的随机数生成解决方案仍存在很大困难。
每个和智能合约交互的一方都需要信任数据源，Oraclize需要提供加密绑定的数据的真实性证明。
随机数服务目前在很多领域都很失败，Oraclize的模型提供了更高更具有数学约束力的公平性保证。

背景

术语

Oracle架构

数据载体（也称为Oracle）使用Oracle体系结构来执行其功能。体系结构中可以确定三个不同的参与者：
- 数据源(Data Source)： 在设计范围内，是参与者创建数据流，并使数据载体能够访问数据流：例如kraken.com、weather.com、WolframAlpha等。像Bloomberg这样的数据聚合器本身就是数据源，因为聚合是在内部进行的，并且基于信任。数据载体可以支持不同类型的数据源。
- 数据携带者(Data Carrier): 它获取数据并将其与数据真实性证明一起转发给应用程序。
- 数据消费者：(Data Consumer): 数据的最终接收器。在区块链协议的情况下，它可以是智能合约或比特币脚本，但可以设想利用真实性证明提供的某些属性的非区块链应用程序。
When the data consumer application needs a data piece from a data source, it creates a request to the data carrier. The request is called query and each datasource type has different parameters which can be passed as arguments.
当数据使用者应用程序需要来自数据源的数据块时，它会创建对数据载体的请求。请求被调用查询并且每个数据源类型都有不同的参数，这些参数可以作为参数传递。
The data carrier returns immediately a queryId, which is an unique identifier that can be used by the data consumer application to check the status of its query.
数据载体立即返回查询ID，它是唯一的标识符，数据使用者应用程序可以使用它来检查其查询的状态。
Once the data has been retrieved and the authenticity proof created, the query’s status is updated and the data carrier execute the expected action: it can sends a transaction, called callback transaction, to a smart contract on Ethereum or Rootstock; create and send a transaction on Bitcoin; simple return the results along with the proofs as an HTTP response.
一旦检索到数据并创建了真实性证明，查询的状态就会更新，数据载体就会执行预期的操作：它可以向以太坊或根库上的智能合约发送一个称为回调事务的事务；创建并发送比特币交易；简单返回结果和证明作为HTTP响应。
On Ethereum-based blockchain protocols, the query can be created automatically when the user send a transaction to the data consumer smart contract.
在基于以太坊的区块链协议上，当用户向数据消费者智能合约发送交易时，可以自动创建查询。
Upon receiving the transaction, the smart contract executes a call to the Oraclize’s Connector contract, passing all the query arguments as parameters. The call immediately returns the queryId.
收到交易后，智能合约执行对Oraclize连接器合约的调用，将所有查询参数作为参数传递。该调用立即返回查询ID。
The data carrier continuously monitors the blockchain for such event, and it starts computing the query upon seeing one.
数据载体持续监控区块链中的此类事件，并在看到一个事件时开始计算查询。

小结：

数据使用者需要数据源的数据块时，会创建对数据载体的请求，被调用的每个查询的数据类型有不同的参数。(好像在网站上有)。
返回查询ID，作为唯一标识符。
检索到数据，并创建真实性证明，查询的状态则更新，数据载体就会执行预期操作。
在以太坊上，用户想数据消费者发交易，就能自动创建查询。
数据消费者收到交易后，它的智能合约执行对Oraclize连接器的合约调用，将查询参数触动你，并返回查询ID。

可信执行环境

A Trusted Execution Environment (TEE) is a computational environment strongly isolated from the main operating system running on a given device. The isolation is achieved through software and hardware enforced mechanisms.
可信执行环境（TEE）4是与在给定设备上运行的主操作系统强烈隔离的计算环境。隔离是通过软件和硬件强制机制实现的。
A TEE runs a small-footprint operative system, which exposes a minimal interface to the main operative system running on the device in order to reduce the attack surface. TEEs can run special applications with high-security requirements, such as cryptographic key management, biometric authentication, secure payment processing and DRM.
TEE可以运行具有高安全性要求的特殊应用程序，例如加密密钥管理、生物认证、安全支付处理和数字版权管理。

远程证明(Remote Attension)

Remote attestation is a method by which a device authenticates its hardware and software configuration to a remote host. The goal of remote attestation is to enable a remote party to determine the level of trust in the integrity of the platform running on the device.
远程认证是一种设备向远程主机验证其硬件和软件配置的方法。远程认证的目标是使远程方能够确定设备上运行的平台的完整性的信任级别。
Remote attestation is often implemented by having the device produce a signed document, attesting the state of the system. Signing is performed by a special attesting key, embedded in the device during manufacturing and over which the third-party application running on the platform as no arbitrary control. The attesting key is known by the manufacturer of the device, which can therefore verify the signed integrity document and return the status of the platform to the party who initiated the attestation request.
远程认证通常是通过让设备生成一个签名的文档来实现的，以证明系统的状态。签名是由一个特殊的认证密钥执行的，该密钥在制造过程中嵌入到设备中，运行在平台上的第三方应用程序不会对其进行任意控制。设备制造商知道认证密钥，因此可以验证已签名的完整性文档，并将平台的状态返回给发起认证请求的一方。

小结

已知方法

通过blockhash作为熵源

Ethereum is a generalized state machine public blockchain with a global state. Smart contracts are constituted of a number of instructions taken from a predefined set, known as EVM Assembly.
以太坊是一个具有全局状态的通用状态机公共区块链。智能合约由许多来自预定义集合(称为EVM Assembly)的指令组成。
When a smart contract is involved in a transaction, its instructions are translated into updates to the global state by the execution of the Ethereum Virtual Machine.
当智能合约涉及到交易时，它的指令通过以太坊虚拟机的执行被转换为对全局状态的更新。
Since all nodes must converge to the same final state after each transaction, the execution is strictly deterministic. The only residual non-determinism accessible from within the EVM is the block hash of previous blocks, retrievable through the specific BLOCKHASH instruction, and some additional informations regarding the current block, such as the timestamp.
因为所有节点在每个事务之后都必须收敛到相同的最终状态，所以执行是严格确定的。从EVM中唯一可访问的剩余不确定性是以前块的块哈希，可通过特定的BLOCKHASH指令检索，以及一些关于当前块的附加信息，如时间戳。
A simple example of an end-user application that could use the block hash as a source of randomness is a decentralized lottery: a smart contract could be in charge of selling tickets, collecting the funds and awarding the winner based on the block hash at a specific blockchain height.
终端用户应用程序可以使用块哈希作为随机性来源的一个简单例子是去中心化彩票:智能合约可以负责销售彩票，收集资金，并基于特定区块链高度的块哈希奖励获奖者。
Unfortunately, the previous block hash is a poor source of randomness, since the miner of such a block could decide to discard it and try their luck by mining a second block at the same height. If unsuccessful, by doing so, it will incur in the loss of the block reward. In Ethereum, this loss is reduced by up to 87.5% because of the uncle incentivization mechanism: a child-less block, called uncle, included in the heaviest chain, is rewarded but the transactions within the block are not executed and therefore have no effect on the global state.
不幸的是，前面的块哈希是一个很差的随机性来源，因为这样一个块的矿工可能决定放弃它，并通过挖掘相同高度的第二个块来碰碰运气。如果不成功，那么它将失去块奖励。在以太坊，由于叔父激励机制，这种损失减少了87.5%:一个名为叔父的无子块包含在最重的链中，会得到奖励，但区块内的交易不会执行，因此对全局状态没有影响。
A miner would then act rationally by attempting an attack to lottery if the probability P of winning times the expected payout E would be higher than the difference between the full and reduced block reward R:
然后，如果中奖概率P乘以预期奖金E高于完整块奖励和减少块奖励之间的差值R，矿工就会理性地采取行动，试图攻击彩票: $R−78∗R<P∗ER-\frac{7}{8}*R<P*E$
To be consistently successful, the attacks require a miner or a coordinated group of miners to have a significant share of the total network hashrate. The higher the expected payout, the greater are the incentives to reach the level of required coordination, limiting the possibility of having large prizes for on-chain lottery or other types of entropy-based games through the block hash method.
为了持续成功地进行攻击，需要一个矿工或一个协调的矿工组在整个网络哈希率中占有相当大的份额。期望支付的金额越高，达到所需协调水平的动机就越大，通过块哈希方法限制了链上彩票或其他类型基于熵的游戏获得大额奖金的可能性。

小结

blockhash不是一个好的熵源，在收益很大的情况下，矿工或者一个协调的矿工组是能够

Commit & Reveal 方案

An alternative method to generate entropy in a deterministic state machine, such as Ethereum’s, is to delegate it to an interactive protocol involving many economically incentivized anonymous users. These type of protocols are generally known as commit and reveal schemes and they are composed of three phases:
在确定性状态机(比如以太坊的状态机)中生成熵的另一种方法是将其委托给包含许多经济激励匿名用户的交互式协议。这些类型的协议通常被称为Commit & Reveal方案，它们由三个阶段组成:
- Commit: Each of the involved users sends to a delegated smart contract a cryptographically secure hash of a bytes sequence of his choice, which is saved in storage. To incentivize pre-image reveals and continuation of the protocol, users are forced to send a deposit which can be redeemed at reveal time.
- Commit: 每个涉及到的用户向委托的智能合约发送他所选择的字节序列的加密安全散列，该散列保存在存储中。为了激励预图像显示和协议的延续，用户必须支付押金，押金可以在显示时间兑换。
- Reveal: After a predefined number of blocks have been mined, the users can reveal the original bytes by sending another transaction to the smart contract. The bytes sequence is validated against the initial digest.
- Reveal: 在挖出预定义数量的区块后，用户可以通过向智能合约发送另一个交易来显示原始字节。根据初始摘要验证字节序列。
- Generation: All the users values are taken as inputs for a function, whose output is the requested number.
- Generation: 所有用户值都作为函数的输入，函数的输出是所请求的数字。
This approach has been implemented in the RandDAO smart contract but it suffers of a number of drawbacks. In particular, it is expensive to manage and to run. The participating users must incur in gas costs and opportunity costs, reducing the number of users willing to participate. To date, the RandDAO project is not yet used in any production smart contracts based application.
此方法已在RandDAO智能合约中实现，但它存在许多缺陷。特别是，它的管理和运行成本很高。参与的用户必须承担Gas成本和抵押成本，这减少了愿意参与的用户数量。到目前为止，RandDAO项目还没有在任何基于生产智能合约的应用程序中使用。[我观察也很少人使用]。
Lately, two-party partial commit and reveal scheme have gained popularity.12 13 In this type of schemes, the consumer application operator generates and commits to the hash of a random seed before receiving a second random seed from the user and generating the resulting number from both. This solution resolves some of the costs of the decentralized approach, but it has some additional drawbacks:
最近，two-party partial commit & reveal”方案越来越受欢迎。在这种类型的方案中，消费者应用程序操作符在从用户接收第二个随机种子并从两者生成结果数字之前生成一个随机种子并提交给哈希。这个解决方案解决了去中心化方法的一些成本，但它有一些附加的缺点:
- Constant online key management for publishing the hash of random seed by the smart contract operator can be dangerous.
- 由智能合约操作员用于发布随机种子哈希的持续在线密钥管理可能是危险的。
- Additional hassle for the user to generate client side, safely, a random number. If the generation is delegated to client-side UI crafted by the application developer, then the user is trusting that the code is not compromised. Even delegating it to external services open the user to a potential collusion attack between the external service and the smart contract operator.
- 额外的麻烦为用户生成客户端，安全地，一个随机数。如果将生成委托给应用程序开发人员精心设计的客户端UI，那么用户就相信代码不会受到损害。即使将其委托给外部服务，用户也可能受到外部服务和智能合约运营商之间的合谋攻击。
- It doesn’t adapt well to wide-spread use cases: for example, most smart contract games are backed by investors. If the casino operator is acting as one of the two party in the scheme, then he could rig the fairness of the game at their expenses.
- 它并不能很好地适应广泛的使用案例:例如，大多数智能合约游戏都得到了投资者的支持。如果赌场经营者是该计划的两方之一，那么他就可以操纵游戏的公平性，以牺牲他们的利益为代价。

从第三方获得预言机服务

Another way to access entropy from within Ethereum, it is to fetch it from dedicated, trusted third-party services through an oracle service. For example, random.org provides cryptographically signed random numbers, but as of today the RSA-based signature is not verifiable directly from within an Ethereum smart contract.
从以太坊内部访问熵的另一种方式是通过oracle服务从专用的、可信的第三方服务获取熵。例如，random.org提供加密签名的随机数，但到目前为止，基于rsa的签名还不能直接从以太坊智能合约中验证。
By carefully designing the smart contract, it is possible to reduce the attack surface available to the oracle service against it. Oracle services such as Oraclize offer additional guarantees that the data is correct through HTTPS-based authenticity proofs, but today the verification has to be done off-chain and ex-post.
通过仔细设计智能合约，可以减少对oracle服务的攻击面。Oracle服务(如Oraclize)通过基于http的真实性证明提供了额外的保证，以确保数据是正确的，但目前这种验证必须在链下和事后进行。
Authenticity proofs make it easier to detect occurrences of cheating, but do not provide the ability to prevent it.
If the expected payout is extremely large, only reputational damage can stop the oracle service from cheating, which is a poor security guarantee for a smart contract system. Moreover, the third party service could cheat without any consequences or risk of being discovered.
真实性证明使检测作弊行为变得更容易，但不提供防止作弊的能力。
如果预期支付非常大，只有声誉损害才能阻止oracle服务作弊，这对智能合约系统来说是一个很差的安全保证。此外，第三方服务可以作弊而不会有任何后果或被发现的风险。

架构

概览

The architecture presented in the paper will require to use one or more physical devices featuring: a Trusted Execution Environment (TEE); a cryptographic-quality hardware-based Random Number Generator (RNG); support for remote attestation of the device and local attestation of code execution, which will be needed to generate the authenticity proofs. If these requirements are fulfilled, the final user of the data consumer application, will have to trust only the following parties:
本文提出的体系结构将要求使用一个或多个具有以下特征的物理设备:可信执行环境(TEE); 一个cryptographic-quality基于硬件的随机数发生器;支持设备的远程认证和代码执行的本地认证，这将需要生成真实性证明。如果这些要求得到满足，数据使用者应用程序的最终用户只能信任以下各方:
- The trusted execution environment designer who could easily introduce a backdoor or create a flawed design, hampering the integrity guarantees of the TEE.
- 可信的执行环境设计人员，他们可以很容易地引入后门或创建有缺陷的设计，从而妨碍TEE的完整性保证。
- The chip manufacturer who can introduce a physical backdoor during the fabrication process.
- 可以在制造过程中引入物理后门的芯片制造商。
- The trusted execution environment firmware developer: the firmware could be backdoored or be exploitable by third parties due to an implementation flaw. The vast majority of TEEs have closed-source firmware and require extensive NDAs to be signed with the chip producers, so it is not possible to audit and scrutinize their firmware.
- 可信的执行环境固件开发人员:由于实现缺陷，固件可能被后门或被第三方利用。绝大多数的TEE都有封闭源代码的固件，并要求与芯片生产商签署大量的保密协议，因此不可能对它们的固件进行审核。
In the large majority of cases, the aforementioned roles can be overlapping and therefore reduced to two or even only one trusted party. This is the case with Intel SGX, where the designer, the manufacturer and the firmware developer are the same actor; namely Intel.
在大多数情况下，上述角色可能是重叠的，因此减少到两个甚至只有一个受信任方。英特尔SGX的情况就是这样，它的设计者、制造商和固件开发者是同一个人;即英特尔。
The data consumer application can create a query by: accessing the data carrier’s HTTP APIs or, in the case of smart contracts running on Ethereum-based blockchain protocols, by a transaction executing a call to the Oracle’s Connector.
数据消费者应用程序可以通过以下方式创建查询:访问数据运营商的HTTP api，或者在基于以太坊区块链协议上运行智能合约的情况下，通过一个事务执行对Oracle连接器的调用。
Each data source has its own query parameters. This data source requires the following:
每个数据源都有自己的查询参数。该数据源需要以下内容:
- A 32-byte long commitmentNonce, which it should be a piece of information not accessible by the data carrier before the creation of the query.
- 一个32字节长的commitnonce，它应该是一个在创建查询之前数据载体不能访问的信息。
- A time $d T$ , expressed in seconds, which is the minimal time which has to elapse before the query can be served by the secure application and the random bytes requested returned.
- 时间 $d T$ ，以秒为单位表示，这是安全应用程序为查询提供服务和请求返回的随机字节所需要的最小时间。
- A public key deviceSessionPubKey, which is the public part of the deviceSessionKeyPair generated by the secure application and which uniquely identifies a device.
- 公钥deviceSessionPubKey，它是由安全应用程序生成的deviceSessionKeyPair的公共部分，它唯一地标识一个设备。
- A number nRandomBytes between 1 and 32, which is the number of random bytes to be returned to the application.
- 一个介于1到32之间的数字nRandomBytes，这是要返回给应用程序的随机字节数。
Upon reception of the query, the data carrier will issue a request for the random data to the secure application running on the TEE-enabled device.
在接收到查询后，数据载体将向在启用TEE的设备上运行的安全应用程序发出对随机数据的请求

实现细节

As mentioned before, the scope of the paper is to present a scalable architecture that can run both on embedded devices and more powerful trusted computing platforms.
如前所述，本文的范围是提供一个可伸缩的体系结构，它既可以在嵌入式设备上运行，也可以在更强大的可信计算平台上运行。
The first device used to implement the architecture is the Ledger Nano S, a cryptocurrency hardware wallet designed and assembled by Ledger Co.
用于实现该架构的第一个设备是Ledger Nano S，这是Ledger Co.设计和组装的加密货币硬件钱包。
BOLOS is developed internally by Ledger and it is partially closed-source, mainly due to the many NDAs required by hardware manufacturer.
Ledger的设备很有趣，因为它们运行一个名为BOLOS的操作系统，不同于许多其他TEE操作系统，它支持第三方开发的应用程序、远程认证和代码认证。
The Nano S uses in fact a ST31M chip as the secure element, a chip developed and produced by STMicroelectronics. Therefore the user of the data consumer application has to trust that neither Ledger nor STMicroelectronics collaborate with the data carrier with the aim of rigging the random number generation.
Nano S实际上使用ST31M芯片作为安全元件，该芯片由意法半导体公司开发和生产。因此，数据消费者应用程序的用户必须相信，无论Ledger还是STMicroelectronics都不会与数据载体协作，目的是操纵随机数的生成。
The relevant limitationns of the Ledger Nano S specifications to the architecture design are:
Ledger Nano S规格对架构设计的相关限制是:
- 4kb可用的易失性内存
- 高达256kb可用的非易失性内存
- NVM的生命周期是每个64字节扇区写500,000次。目前设备的固件不支持磨损均衡，所以安全应用程序实现了一个简单的。
On the base of the these specifications, the secure application should be engineered to minimize memory footprint, reduce the number of writes, the storage occupied by the persistent state and reduce the number of messages exchanged with the host.
在这些规范的基础上，应该将安全应用程序设计为最小化内存占用、减少写操作次数、持久状态占用的存储以及减少与主机交换的消息数量。
The application code should be open-sourced to enable third-party auditability of its functions and independent verification of the binary hash present in the device code attestation.
应用程序代码应该是开源的，以使其功能的第三方审计和设备代码认证中存在的二进制哈希的独立验证成为可能。

安全应用

The secure application can be decomposed into three functional components:
安全应用可以被分解成三个函数式组件：
- A timer, incremented during application execution, so that we can guarantee that the time dT specified by the query has elapsed.
- 一个计时器，在应用程序执行期间增加，这样我们就可以保证查询指定的时间 $d T$ 已经过去。
- A tamper-resistant, persistent state used to hold: the private key of an elliptic curve key pair, generated at application initialization; an append-only data-structure for storing the queries; the last value of the timer.
- 一种抗篡改的持久状态，用于保存:在应用程序初始化时生成的椭圆曲线密钥对的私钥;仅用于存储查询的追加数据结构;定时器的最后一个值。
- An asymmetric key pair management component with signing and verification capability, used for authenticating any piece of data exported from the device.
- 一个具有签名和验证功能的非对称密钥对管理组件，用于验证从设备导出的任何数据。
Once verified that the signing keys are not revoked by Ledger and that the binary hash computed from the compiled application source-code matches the signed code hash one, valid signatures prove that the application is running in the secure environment as expected.
一旦验证了签名密钥没有被Ledger撤销，并且从已编译的应用程序源代码计算出的二进制哈希与已签名的代码hash one匹配，有效的签名就证明应用程序如预期的那样在安全环境中运行。

插入Query

This function, exposed by the secure application to the host, inserts a new query in the tamper-resistant state.
这个函数由安全应用程序公开给主机，插入一个处于抗篡改状态的新查询。
In order to avoid cheating or unfair behavior from the data carrier, it must be enforced that only one query for a determined queryId can exist. Any additional query with the same queryId, no matter if including different commitmentNonces or dTs, will be rejected by the application and won’t be appended to the state.
为了避免数据载体的欺骗或不公平行为，必须强制对一个确定的queryId只能存在一个查询。任何具有相同查询Id的附加查询，无论是否包含不同的commitnces或 $d T$ ，都将被应用程序拒绝，不会被附加到状态中。
This effectively makes the data structure held within the tamper-resistant state, a table of explicit commitments of the type:
这有效地使数据结构保持在抗篡改状态，一个类型的显式承诺表:
$q u e r y I d - > C o m m i t (c o m m i t e m e n t N o n c e, d T, n R a n d o m B y t e s)$
That’s it, for each id only one query can be served and only after deltaT time has passed. Each queryId is also implicitly committed to a specific deviceSessionPubKey, because the returned data will be signed by the corresponding private key. If the signature verification fails, the data must be rejected by the data consumer application.
就是这样，对于每个id，只能提供一个查询，而且只能在deltaT时间过后。每个queryId也隐式地提交到特定的deviceSessionPubKey，因为返回的数据将由相应的私钥进行签名。如果签名验证失败，数据必须被数据使用者应用程序拒绝。
The data to be stored can be therefore represented by a key:value pair of the form:
因此，要存储的数据可以用如下形式的键值对表示: $H (q u e r y I d) : H (c u r r e n t T i m e r, c o m m i t m e n t N o n c e, d T, n R a n d o m B y t e s)$
where H is a cryptographic hash function and currentTimer is the value of the secure application timer at insertion.
其中H是一个加密散列函数，currentTimer是插入时安全应用程序计时器的值。
Clearly, with the limited persistent storage available in the trusted execution environment it is impossible to store a state increasing linearly with the number of queries. But thanks to cryptographically authenticated data structures 15, most of the state can be kept off the device. The secure application assumes the role of verifier and keeps only a small digest in memory. The role of the prover is taken by the host, the physical machine in the Oracle Architecture connected to the device, which keeps the entire device state in a key:value database.
显然，由于受信任执行环境中可用的持久存储有限，不可能存储随着查询数量线性增长的状态。但多亏了加密认证的数据结构，大部分状态可以远离设备。安全应用程序承担验证者的角色，并且只在内存中保存一小部分摘要。验证者的角色由连接设备的主机(Oracle架构中的物理机)承担，该主机将整个设备状态保存在一个 $k e y : v a l u e$ 数据库中。
Every computation or operation performed on the data requires the prover to send the result along with a proof of correct computation, which can be used by the verifier to validate the result and eventually update the digest kept in memory for insertion or deletion operations.
对数据执行的每一次计算或操作都要求验证者将结果与正确计算的证明一起发送，验证者可以使用这个证明来验证结果，并最终更新保存在内存中用于插入或删除操作的摘要。
or simplicity of implementation and as a starting point, the secure Ledger application uses a modified trie16 as an authenticated data structure. The inspiration was taken from the Merkle Patricia Trie used by Ethereum, with some modification to reduce the complexity of the implementation. To summarize the properties of the trie implemented:
或者简单的实现和作为一个起点，安全的Ledger应用程序使用一个修改过的try16作为一个经过验证的数据结构。灵感来自于以太坊使用的Merkle Patricia Trie，通过一些修改来降低实现的复杂性。总结一下trie实现的特性:
- The key is fixed length (64-chars) and it is the hex representation of the H(queryId).
- 键是固定长度(64字符)，它是H(queryId)的十六进制表示。
- It’s a nibble-wise trie, where a nibble is an half-byte, so one char of an hexadecimal string. Each node has 16 entries, as 16 are the entries in the hexadecimal alphabet. Traversing the Trie would mean testing each subsequent nibble in the key and choosing child[0] … child[15] appropriately until the item is found.
- 这是一种微调的尝试，微调是半字节，也就是一个十六进制字符串的一个字符。每个节点有16个条目，16是十六进制字母表中的条目。遍历Trie树意味着测试每一个随后的微调(nibble)键并选择children[0]…children[15]直到找到项。
- The node’s entries contain the hash of next node required to continue the search.
- 节点的条目包含继续搜索所需的下一个节点的散列。
- The leaf node, containing the hash of the values, is reached by following the key till the end.
- 通过跟踪该键直到结束，可以到达包含值散列的叶节点。
Therefore this trie can be called a Merkle Nibble-wise Trie. Thanks to this data structure, the application only needs to keep two pieces of data in the volatile memory at runtime:
因此，这种尝试可以被称为默克尔微调式的尝试。多亏了这种数据结构，应用程序在运行时只需要在volatile内存中保存两段数据:
- The relative timer, which is incremented every second the application is running.
- 相对计时器，应用程序每运行一秒增加一次。
- The hash of the trie root node, also known as roothash.
- trie根节点的散列，也称为roothash。
The insertion of query starts by computing the hash of the parameters values and creating the leaf node. Then, for each node traversed by reversing the key:
查询的插入首先计算参数值的散列并创建叶节点。然后，对于通过反转键遍历的每个节点:
- The current node hash is saved in a temporary variable
- 当前节点散列保存在一个临时变量中
- The hash at the i-th decimal(key[i]) entry is replaced with the child hash
- 第i个小数(key[i])项的哈希值被替换为子哈希值
- The new hash of the current node is computed and saved in a temp variable used in the next iteration.
- 当前节点的新哈希值将被计算并保存在一个临时变量中，用于下一次迭代。
- If once reached the root node, the current node hash and the roothash diverge, the insertion is aborted; if they match, the root hash is updated with the new value and the insertion is completed.
- 如果到达根节点后，当前节点散列和roothash出现分歧，则终止插入;如果匹配，根散列将使用新值更新，插入就完成了。

内存状态导出和导入

As the device could serve more than one application or simply be restarted, the secure application requires functions which can be used to export and import the volatile memory state. To guarantee its integrity, the state is signed with the device session private key: only states with a verified signature made by such key can be imported. The freshness of the memory state is ensured by including the last value of the storageNonce in the signature.
由于设备可以服务于多个应用程序或简单地重新启动，安全应用程序需要可以用于导出和导入易失性内存状态的功能。为了保证状态的完整性，该状态使用设备会话私钥进行签名:只有经过会话私钥签名验证的状态才能被导入。通过在签名中包含storageNonce的最后一个值来保证内存状态的新鲜度。
When the application reloads, the signature is verified and the storageNonce must match the internal value so that the data carrier cannot import memory states older than the last one.
当应用程序重新加载时，该签名将被验证，storageNonce必须与内部值匹配，这样数据载体就不能导入比上次更老的内存状态。

执行Query

A query can be executed only after its time $d T$ has elapsed. The process of executing a query is simple: the secure application signs with the ECDSA deterministic k signature algorithm over the hash of the query parameters with the application session private key.
查询只有在时间 $d T$ 过后才能执行。执行查询的过程很简单:安全应用程序使用ECDSA确定性k签名算法对查询参数的哈希进行签名，并使用应用程序会话私钥。
This signing algorithm always produces the same signature for a determined message, in this case the hash of the query parameters, while the regular ECDSA signing algorithm requires a random number k to be generated for each signing operation: the signature obtained is different every time.
此签名算法总是为确定的消息(在本例中为查询参数的散列)生成相同的签名，而常规的ECDSA签名算法要求为每个签名操作生成随机数k:每次获得的签名都是不同的。
The k used in the ECDSA deterministic algorithm is instead computed from the message by applying an HMAC construction using the private key as an HMAC key. The signature bytes are not determinable a priori from the inputs, if not with previous knowledge of the private key which is inaccessible to the data carrier. The requested nRandomBytes are the truncated hash of the signature, while the signature itself is returned by the data carrier as part of the authenticity proof.
此签名算法总是为确定的消息(在本例中为查询参数的散列)生成相同的签名，而常规的ECDSA签名算法要求为每个签名操作生成随机数 $k$ :每次获得的签名都是不同的。

本章总结

Ledger Nano S是一个可以放入应用的TEE，我们的预言机就放在上面。
我们插入一个Query到这个应用中。
查询过 $d T$ 时间后执行难，通过操作，生成随机数 $k$ 。
随机数 $k$ 通过内存状态导出，展示给外部。

应用

The architecture presented in the paper will be offered as a new type of data source offered by the Oraclize’s Oracle Architecture: the random datasource.
本文中提出的架构将作为Oraclize的Oracle架构提供的一种新型数据源:随机数据源。

以太坊随机数源

A smart contract using the random datasource will include, in addition to the Oraclize’s API, the following code:

oraclize_query(“random”, commitmentNonce, deviceSessionPubKey, dT,
nRandomBytes);

where the commitmentNonce recommended value is the hash of the current block coinbase, timestamp, gas limit and previous block hash. The next session, dedicated to security consideration, will explain the reason.
其中commitnonce推荐值是当前区块coinbase、时间戳、气体限制和之前的区块哈希。下一章专门讨论安全问题的部分将解释原因。
All parameters must be saved and stored by the smart contract to verify the authenticity proof sends with the result.
所有参数必须被智能合约保存和存储，以验证与结果发送的真实性证明。
The smart contract developer can decide to either commit all the queries to the same session public key or instead to commit each query to a different key among the ones available in the Connector. In case of high-volume contracts the second option should guarantee faster response time, but at the cost of being more expensive since each query must be linked to a session key in the smart contract storage.
智能合约开发人员可以决定将所有查询提交给同一个会话公钥，或者将每个查询提交给Connector中可用的密钥中的不同密钥。对于大容量契约，第二种选择应该保证更快的响应时间，但代价是更昂贵，因为每个查询都必须链接到智能契约存储中的会话密钥。
Since devices can become unavailable or new versions of the application can be released, the data carrier can add new session keys to the Connector. The process of adding an application session key requires the verification of its attestation chain and that the codehash matches a list of on-chain whitelisted codehashes. Ultimately, the codehashes should be verified off-chain against the open-source secure application code.
由于设备可能不可用，或者可以发布应用程序的新版本，数据载体可以向连接器添加新的会话密钥。添加应用程序会话密钥的过程需要验证其认证链，以及该代码散列是否与链上白名单代码散列列表匹配。最终，代码散列应该在链下根据开源安全应用程序代码进行验证。

讨论

安全考虑和准则

This section will addresses a series of attacks that the data carrier and external collaborating actors could attempt against a smart contract using the random datasource.
本节将讨论数据载体和外部协作参与者可以使用随机数据源对智能合约进行的一系列攻击。

Data Carrier抢跑(Front-Runnning by the Data Carrier)

Once the time dT has elapsed and the query has been executed, the data carrier can know the result before sending it on-chain.
一旦 $d T$ 经过时间并执行了查询，数据载体就可以在将结果发送到链上之前知道结果。
The data consumer application developer should make sure that having knowledge of the generated entropy before it’s public, cannot affect the fairness of the application. This is easily enforceable by making it impossible for the data carrier to act on behalf of this knowledge. For example, in the case of a lottery, the application should close the sale of tickets before the query can be executed by the data carrier.
数据消费者应用程序开发人员应该确保在生成的熵公开之前就知道它，不会影响应用程序的公平性。通过使数据载体不可能代表这种知识行事，这很容易实现。例如，对于彩票，应用程序应该在数据载体执行查询之前关闭彩票销售。

选择性公开(Selective Publishing)

The data carrier could selectively publish only results which are in his favour. The smart contract should protect against this scenario: for example, in the case of a betting game, by not returning the amount wagered to the player when the data carrier doesn’t publish the result.
数据载体可以有选择地只发表对他有利的结果。智能合约应该防止这种情况:例如，在博彩游戏中，当Data Carrier没有公布结果时，不向玩家返回所押注的金额。

Computationn之前进行预测(Computation of a Query before Time)

In a similar way, the data carrier could try to precompute the query using the last block hash and guess the timestamp, coinbase and the gas limit parameters of the next block, and only participate if the result is in his favour. Without collusion of a miner, the probability of success is low because only one try can be done: in the secure application state there can be only one queryId. The probability can be reduced to negligible by setting an appropriate minimal elapse time higher than the current time between blocks. Even if a winning result is found, the authenticity proof will be invalid, because it doesn’t include the correct block parameters.
以类似的方式，数据载体可以尝试使用最后一个块哈希预计算查询，并猜测下一个块的时间戳、coinbase和gas限制参数，只有在结果对他有利时才参与。如果没有矿机串通，成功的概率很低，因为只能进行一次尝试:在安全应用程序状态下，只能有一个queryId。通过将块之间的当前时间设置为大于当前时间的适当最小流逝时间，可以将这种可能性降低到可以忽略不计。即使找到了获胜的结果，真实性证明也将是无效的，因为它没有包含正确的块参数。

生成多个值(Generating Multiple Values)

The secure application allows the insertions of only one query for a specific queryId in the application state: therefore, the data carrier cannot arbitrarily add queries with the same queryId trying to generate more than one result.
安全应用程序只允许在应用程序状态下对特定的queryId插入一个查询:因此，数据载体不能任意添加具有相同queryId的查询以试图生成多个结果。
Since the execution of a query is a deterministic signing process, the data carrier cannot even alter the results by repeatedly asking for new signatures over the same data, as it would be possible with the standard, non-deterministic ECDSA algorithm.
由于查询的执行是一个确定性签名过程，因此数据载体甚至不能通过反复请求对相同数据的新签名来改变结果，而使用标准的、不确定性的ECDSA算法是可能的。
It is therefore impossible for the data carrier to generate more than one output for a given queryId, and then select which output to send to the data consumer’s application. The same queryId and parameters could be inserted on more than device, but the smart contract will accept only the authenticity proof signed by the session key to which the specific query has committed.
因此，数据载体不可能为给定的queryId生成多个输出，然后选择将哪个输出发送给数据使用者的应用程序。相同的queryId和参数可以插入到多个设备上，但是智能合约将只接受由特定查询提交的会话密钥签名的真实性证明。

矿工篡改结果(Tampering of the Result by Miners)

As outlined before, the miners can tamper with the fairness of a smart contract, which uses the block hash as a form of randomness, by dropping a mined block if the result is not in their favour. The architecture presented here enables application developers to solve the problem, since block parameters are not the only element which defines the random bytes result.
如前所述，挖矿者可以篡改智能合约的公平性，如果结果对他们不利，则丢弃被挖出的块。智能合约使用块哈希作为一种随机形式。这里提供的体系结构使应用程序开发人员能够解决这个问题，因为块参数并不是定义随机字节结果的唯一元素。

数据载体和矿工交互(Data Carrier and Miners Interactions)

There are two potential scenarios involving interactions between the data carrier and miner to affect the outcome of the generation:
有两种可能的情况涉及数据载体和矿机之间的交互，以影响生成的结果:
- The data carrier broadcasting node is unknowingly surrounded by malicious nodes and the transaction returning the data is not broadcast to the whole network. The miner can then try to mine a block to verify that the result is in their favour, and it will only make the block public if it’s so.
- 数据载体广播节点不知不觉地被恶意节点包围，返回数据的事务不会广播到整个网络。然后，矿工可以尝试开采一个区块，以验证结果对他们有利，并且只有当结果对他们有利时，它才会将区块公开。
- The miner can directly bribe the data carrier to obtain the result before the transaction is broadcasted.
- 矿机可以直接贿赂数据载体，在交易广播之前获取结果。
Both attacks can be avoided thanks to the minimal elapsed time dT and queryId commitment to various block information. By having the queryId commit to a specific set of information of a block at a given height, such as the coinbase, the timestamp and the gas limit, the queryId is implicitly committed to the blockchain history which includes that block.
这两种攻击都可以避免，因为dT和queryId对各种块信息的占用时间很短。通过将queryId提交到给定高度的块的特定信息集，例如coinbase、时间戳和气体限制，queryId将隐式提交到包含该块的区块链历史记录中。
The minimal elapsed time which has to pass before the query is executed, makes it exponentially more costly to the miner to try these attacks, as the probability of successfully publishing a chain heavier than the most of the network becomes exponentially lower as time passes. The final application developers should take this in consideration when writing smart contracts and pass as a query parameter a dT proportional to the amount which is at stake. Future iterations of the paper will include a quantitative analysis, in order to help developers to set an appropriate time.
在执行查询之前所经过的时间最短，这使得矿工尝试这些攻击的代价呈指数级上升，因为随着时间的推移，成功发布比网络中大多数链更重的链的概率呈指数级下降。最后的应用程序开发人员在编写智能合约时应该考虑到这一点，并将dT作为与风险大小成比例的查询参数传递。未来的迭代论文将包括定量分析，以帮助开发人员设定适当的时间。

拒绝服务攻击(Deninal of Service)

The presented architecture doesn’t aim to protect the data consumer application from denial of service, intentional or unintentional, by the data carrier.
所提出的体系结构并不旨在保护数据使用者应用程序免受数据载体有意或无意的拒绝服务。
An application developer may be tempted to resolve the issue by letting the users recollect the amount wagered after a predefined time has elapsed without an action by the data carrier: here be dragons(表示这里很危险，中世纪古语); the data carrier would be incentivized to place bets and only publish on-chain transactions containing a winning result, knowing that he could collect back the amount wagered of the unpublished, losing results.
应用程序开发人员可能会试图通过让用户在预定义的时间过去后回收押注的金额来解决这个问题，而数据运营商没有采取任何行动: 这是非常危险的;数据载体将被鼓励下赌注，并且只发布包含获胜结果的链上交易，知道他可以收回未发布的、失败的结果的赌注。
The application developer could decide to resolve it either implicitly, by not setting a time limit and de facto locking the amount wagered until the data carrier provides a callback transaction, or by actively making the amount wagered not collectable, for example sending it to a burn address.
应用程序开发人员可以决定隐式地解决这个问题，不设置时间限制并事实上锁定赌注金额，直到数据运营商提供回调事务，或者主动地使赌注金额不可收集，例如将其发送到一个烧地址(废地址，找不到私钥的地址)。

赢家赎回(Ransoming a Winning Player)

The data carrier can calculate the outcome of a result before sending it to the smart contract. Potentially, in the case of a lottery, he could ask for a ransom from the winning player to publish the result. The smart contract developer can defend from this attack by allowing anyone to execute the callback function: since only valid result will be executed, there is no need to limit the access only to the data carrier. This makes the authenticity proof fully transferable and the data carrier would have no way of ransoming the winning player without the facto publishing the proof.
数据载体可以在将结果发送到智能合约之前计算结果。在抽奖的情况下，他可能会向中奖者索要赎金，以便公布结果。智能合约开发者可以通过允许任何人执行回调函数来抵御这种攻击:因为只有有效的结果会被执行，所以不需要限制只访问数据载体。这使得真实性证明完全可转移，如果没有事实公布证据，数据载体将无法赎回获胜玩家。

设备的物理攻击(Physical Attacks Against the Device)

Our architecture bases its security guarantees on the existence of a tamper-resistant state internal to the TEE of the device. Physical attacks against hardware devices are always possible, but for this class of devices they are extremely costly, ranging from many hundreds of thousands dollars to millions, and without success guarantee.
我们的体系结构将其安全性保证建立在设备TEE内部存在抗篡改状态的基础上。对硬件设备的物理攻击总是可能的，但是对于这类设备来说，它们非常昂贵，从几十万美元到几百万美元不等，而且没有成功的保证。
If the consumer application is extremely successful and it is handling an expected payout much larger than the figure reported here, the application developer should ask for more than a single dedicated device, which should linearly increase the cost of attack, and more than one type of device, when available, to increase the security guarantees. Using more than one source of randomness must be carefully planned to avoid exposing the application to additional attacks, as for example dependency from transaction ordering. The application developers should remember than the transaction ordering within a block is selected by miners.
如果消费者应用程序是非常成功的,处理的预期支出远远大于这个数字公布在这里,应用程序开发人员应该问超过一个单一的专用设备,它应该线性增加攻击的成本,以及超过一种类型的设备,可用时,增加安全保障。必须仔细计划使用多个随机性来源，以避免将应用程序暴露给其他攻击，例如依赖于事务排序。应用程序开发人员应该记住，区块内的事务排序是由矿工选择的。

小结：

上面总结了Oraclize可能遭遇的攻击：
- Data carrier抢跑： data carrier可能提前知道结果，要确保Data carrier提前知道结果的情况下不影响结果执行。
- 选择性公开：data carrier可能选择性公开它想公开的结果。
- 预计算结果：猜测链上变量，然后伪造queryID。
- 矿工通过操控链上变量篡改结果。
- 开发人员可能会让参与者在固定时间回收赌资，这是非常危险的，这会使得参与方在了解到失败后收回失败的赌注。

结论

In this paper we have presented a scalable architecture for untrusted third-party data delivery of trusted generated entropy.
在本文中，我们提出了一个可扩展的体系结构，用于可信生成熵的不可信第三方数据交付。
The architecture leverages trusted computing technologies and remote attestation of code execution to run in a secure, tamper-resistant environment an application whose source is published and third-party auditable.
该体系结构利用可信的计算技术和代码执行的远程认证，在一个安全的、抗篡改的环境中运行一个应用程序，该应用程序的源代码是已发布的，且可由第三方审计。
The secure application is used to update in a defined manner a tamper-resistant state, in a way to guarantee that each queryId is unique, and to generate the requested random bytes by deriving them from a private key held within the inaccessible storage. The receiving party, which can be a smart contract, possesses the associated public key and can verify, thanks to the accompanying authenticity proof, the origin and the nature of the random bytes sequence before accepting it.
安全应用程序用于以一种已定义的方式更新抗篡改状态，以确保每个queryId都是惟一的，并通过从不可访问存储中持有的私钥派生所请求的随机字节来生成它们。接收方可以是一个智能合约，它拥有相关的公钥，并且可以在接受随机字节序列之前验证它的来源和性质，这要归功于附带的真实性证明。
The architecture has been designed to protect the data consumer application of the generated entropy from a number of attacks the data carrier could attempt. Additionally, the paper also suggests a set of good security practices which data consumer applications should follow in order to protect the fairness of any draw when using the presented solution.
该体系结构旨在保护数据消费者应用生成的熵免受数据载体可能尝试的许多攻击。此外，本文还提出了一套良好的安全实践，数据消费者应用程序应该遵循，以保护任何抽取的公平性时，使用提出的解决方案。
According to their own threat model and to the stake, application developers will be able to set the minimal elapsed time whose passing is enforced by the secure application, before the random bytes are returned.
根据他们自己的威胁模型和利害关系，应用程序开发人员将能够在返回随机字节之前设置由安全应用程序强制传递的最小运行时间。

预言机理解：A Scalable Architecture for On-Demand, Untrusted Delivery of Entropy相关推荐

区块链预言机（2）预言机概念
1. 概念预言机的功能就是将外界信息写入到区块链内,完成区块链与现实世界的数据互通.它允许确定的智能合约对不确定的外部世界作出反应,是智能合约与外部进行数据交互的唯一途径,也是区块链与现实世界进行数 ...
预言机、预言机网络、预测市场
阅读本文需要以下知识储备 1.理解区块链的基本原理 2.了解智能合同和共识机制概念我很好奇,在区块链的网络体系下,如何与外部世界(传统互联网系统)进行数据交换,简而言之,区块链体系内的智能合同如何与 ...
什么是区块链预言机（BlockChain Oracle）
预言机 Oracle 是区块链中非常重要的一个功能,但我发现很少有人讨论,也可能很多人对此并不了解.而网上关于预言机的文章很少,很多也没有讲明白,甚至有些还是错误的.所以我整理了一篇详细的文章,分享给 ...
区块链Oracle预言机实现教程【含代码】
区块链本身是封闭的.区块链的确定性模型基于这样一个事实:在交易执行时区块链不能执行任何来自外部的逻辑,所有的外部数据只能通过交易进入到系统中.预言机/Oracle就是通过交易为智能合约提供可信数据的服 ...
《精通以太坊》预言机
[本文摘自<精通以太坊>一书第11章预言机部分] 在本章中,我们将讨论预言机(oracle),它是可以为以太坊智能合约提供外部数据源的系统. "oracle"一词来自希 ...
一文详解 Band Protocol ：预言机博弈中的价值输出
"DeFi项目的持续火热,带动了预言机项目的大火.同为预言机项目,Band能否撼动LINK的霸主地位?" 本文谨代表作者个人观点,不代表火星财经立场,该内容旨在传递更多市场信息,不 ...
Chainlink 预言机的原理解析
本文来自于 8 月19 日 Chainlink 开发者社区中国负责人 Frank ,在 DApp Learning 分享会上对于 Chainlink 预言机的原理的讲解,以下是这节分享会的总结内容.有 ...
预言机或成补齐DApp爆发的最后一片拼图？ |链捕手
DApp市场经历过高峰和低谷,虽涌现出几款不错的应用产品,但距离DApp开发者曾畅想的「去中心化」应用场景仍距离颇远,甚至更残酷的现实是--上千种DApp无人问津,市场尚处蓝海,却是一片落寞. 链捕手 ...
Neutrino追问AMA第13期|DOS NETWORK 王琦：预言机只是一个数据的搬运工，而非产生者
Neutrino追问AMA第13期|DOS NETWORK 王琦 :预言机只是一个数据的搬运工,而非产生者在2月20日 Neutrino 追问 AMA 第13期交流中,我们邀请到了来自DOS Net ...

预言机理解：A Scalable Architecture for On-Demand, Untrusted Delivery of Entropy

阅读背景

概览

Introduction

小结

背景

术语

Oracle架构

小结：

可信执行环境

远程证明(Remote Attension)

小结

已知方法

通过blockhash作为熵源

小结

Commit & Reveal 方案

从第三方获得预言机服务

架构

概览

实现细节

安全应用

插入Query

内存状态导出和导入

执行Query

本章总结

应用

以太坊随机数源

讨论

安全考虑和准则

Data Carrier抢跑(Front-Runnning by the Data Carrier)

选择性公开(Selective Publishing)

Computationn之前进行预测(Computation of a Query before Time)

生成多个值(Generating Multiple Values)

矿工篡改结果(Tampering of the Result by Miners)

数据载体和矿工交互(Data Carrier and Miners Interactions)

拒绝服务攻击(Deninal of Service)

赢家赎回(Ransoming a Winning Player)

设备的物理攻击(Physical Attacks Against the Device)

小结：

结论

预言机理解：A Scalable Architecture for On-Demand, Untrusted Delivery of Entropy相关推荐

最新文章

热门文章