Talking about the prophecy machine again: How Oracle is redefining smart contracts

To ensure security, blockchain only trusts data on its own chain and does not accept data streams from outside the chain. The prophecy machine, on the other hand, can record real-world data in the form of transactions on the blockchain to broaden the application scenarios of the blockchain.

Talking about the prophecy machine again: How Oracle is redefining smart contracts

How the prophecy machine achieves

“record real-world data as transactions on the blockchain”?

What are the problems with the N3 Prophecy Machine?

What are the problems with the N3 prophecy machine that need to be solved? What are the problems with the N3 Prophecy Machine?

Let’s take a look, shall we?

One of the major factors limiting the development of blockchain is the landing, that is, the use of blockchain technology in real life. For this reason, we need to keep envisioning various scenarios that may need to use blockchain, such as games, such as invoices, such as non-homogeneous passwords. However, these scenarios are still very thin and cannot support everyone’s expectation of blockchain technology at all, not to mention the strength of blockchain technology. Just like the current 5G technology, which is empty, in the end, everyone just uses it for Speedtest.

But why can’t we find more suitable scenarios for blockchain? Because blockchain technology is too closed, for security, blockchain only trusts its own data on the chain and does not accept data flow outside the chain, for example, UTXO is all constructed by transactions on the chain, such as the execution of smart contracts in Neo Legacy can only access the data on the chain through a few interfaces. So if you want to deal with blockchain, then you can’t have reliance on outside information in your scenario. But most scenarios in the real world require a lot of information interaction, you open your phone, which application does not need to be connected.

For example, booking software, you need real-time information on the remaining tickets and prices of airline tickets.

For example, trading software, you need price information.

For example, courier software, you need the latest logistics information.

There is no way to use blockchain to do all these.

Therefore, in order to broaden the application scenario of blockchain and give full play to the potential of blockchain, the interaction method that can feed off-chain data flow to blockchain – prophecy machine – was born. A prophecy machine is a mechanism that can record data from the real world in the form of transactions on the blockchain. For those who are familiar with computers, the prophecy machine can be understood as a huge cache between the real world and the blockchain. since there is a huge gap between the real world data semantically and the blockchain, for example, the real world data may change in real time, there may be multiple data sources, and complex calculations or conversions may be required, which cannot be solved in the process of blockchain consensus, otherwise different However, if the consensus nodes do not take data directly from the real world, but from the “cache”, then the consistency of the data input by each node when verifying the transaction can be guaranteed. Therefore, before writing the data into the blockchain, there is a process to process the data into a form acceptable to the blockchain, such as sampling the real-time data into a current fixed data.

There are three broad implementations of prophecy machines, one is a centralized third party, the second is a trusted data provider, and the third is a decentralized consensus mechanism-based prophecy machine. In N3, a decentralized prophecy machine mechanism with better scalability is used in a local context.

According to the documentation, N3 designates a number of prophecy machine nodes to perform consensus on the results of data requests for transactions as a way to avoid the possible problem of prophecy machine falsification of data. The process is: the user initiates a transaction, which triggers a prophecy machine request in the smart contract. The request is essentially a call to the request method in N3’s built-in native prophecy machine contract: .


Create Oracle Request request data

The path to the access resource, up to 256 bytes long.

Filter to filter out useful information in the results returned from the data source

Callback function method name

User-defined data</param

Callback function to perform prepayment</param

void Request(string url, string filter, string callback, object userData, long gasForResponse);

The native contract will construct a request based on the parameters, and then the preverter node will fetch the data based on the request. After the preverter node finishes collecting the data, it will generate a new transaction and call the callback function in the user contract in the transaction. Therefore, if the N3 prophecy machine is triggered once, two transactions will be written to the blockchain, one for triggering the prophecy machine and the other for the callback. This gives the choice of data source to the contract developer or data caller through the URL mechanism, thus circumventing the problem of trusting the data source by the prophecy machine itself, and the asynchronous callback mechanism solves the problem that the smart contract may block the consensus process if the prophecy machine is invoked with too much delay.

According to this logic, in theory, if we want to trigger the prophecy machine, then the execution of the current contract should be terminated after calling the prophecy machine, so the code written in a contract method after triggering the prophecy machine statement should not be executed. However, I have not been able to verify this due to some environmental configuration issues.

Although the prophecy machine is defined as a tool to get data, it can also be used to do some more fascinating operations. Because the process of calling the prophecy machine is essentially not much different from calling another contract asynchronously, even N3 has the prophecy machine built in as a native contract. This means that we can use the prophecy machine as an external interface to the smart contract, and write some logic that should be written into the smart contract outside the contract. For example, if the task is very computationally intensive, we can send the task off-chain through the prophecy machine, and then execute it off-chain and return the result. For example, if we want to hide some logic, such as random number generation algorithm, we can also migrate this part of the function off-chain through the prophecy machine.

Existing problems with the N3 prophecy machine system

Talking about the prophecy machine again: How Oracle is redefining smart contracts

Although the N3 native prophecy machine system is very good and powerful, there are still some problems that have not been solved perfectly.

N3’s prophecy machine is a distributed system, and it has trouble handling data that changes too often. The price of Bitcoin, for example, basically changes in real time, so when different prophecy machine nodes get the price of Bitcoin, it is likely that different nodes will get a fraction of a percent different price, leading to prophecy machine consensus failure. Although this can be solved to some extent by user-optimized data formats.

The prophecy machine system is an asynchronous callback system, coupled with the existence of a consensus process, so there is a large delay in the data it obtains compared to the trigger transaction. For example, if you look at the low price of a ticket and immediately send a transaction to the chain, your transaction is executed immediately, but this does not mean that the price you can get is the price when the transaction is executed, after all, the callback transaction of the prophecy machine does not happen simultaneously with your trigger transaction.

Another big issue is the trustworthiness of the data source. We allow users to introduce data from outside the chain into the chain through the prophecy machine, which introduces the untrustworthiness of the chain to the blockchain to a considerable extent. Previously, the only way to attack the blockchain would be to attack the blockchain nodes themselves, a process protected by the consensus protocol. But when we introduced the prophecy machine, the ways to attack the blockchain became diverse, because hackers can radiate the impact of the attack into the blockchain by attacking the prophecy machine data source specified in the contract. In addition, unreliable contract developers may also introduce unknowable backdoors into smart contracts through the prophecy machine mechanism. After all, some of the functions invoked through the prophecy machine are not written in the blockchain, so unreliable developers can completely change the system logic without knowing it.

One final issue is the redundancy of data. In the previous article, I mentioned that the prophecy machine functions like a data cache between the blockchain and the data source to ensure data trustworthiness. In fact, the cache is just an abstraction I made to make it easier to understand. In fact, N3’s prophecy machine does not save data for subsequent requests when processing data like a cache. On the contrary, N3’s prophecy machine requests are only related to user-initiated trigger transactions, and there are as many prophecy machine requests as there are user-initiated trigger transactions.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-05-07 07:38
Next 2021-05-07 08:32

Related articles