Author: NestCore
Recently, it was mentioned that the price of NEST oracle machine may be copied, making it impossible to charge. We dont think this question is valid, because there are various problems in these replication methods, and NEST can manage these replication behaviors in some ways.
There are two main methods of copying, one is technical copying, which reads data off-chain, and then verifies on-chain to ensure that it comes from the NEST oracle machine; the other is shared use, through a shared contract, anyone who calls NEST After the oracle, the price data is copied into the contract for free use by others. There is another category that requires a centralized organization to trigger or upload prices (to ensure that prices are real and effective), because there is a risk of centralization, which is not in our discussion. We only consider two decentralized solutions:
Option 1: Read off-chain and verify on-chain.
This method utilizes the verification relationship of the data on the Ethereum chain. In principle, the effective NEST price can be obtained, and then it can be verified on the Ethereum that the price is indeed generated by the NEST oracle, so that it can be used by DeFi. This method has the following fatal problems:
1) The cost of verifying data in this way is extremely high. Taking the current network as an example, it takes close to 0.01ETH to verify only one data, and only 0.001ETH (tentative) to call the NEST oracle machine. If the NEST contract slightly modifies the data structure, such as storing price data in two units, the cost of this method will double to 0.02ETH (more extreme modifications will make the verification cost exceed the upper limit of the block gas limit and become Impossible), for DeFi users, it is meaningless to steal the NEST price in this way.
2) In order to match the stolen price, the downstream DeFi will be designed into a new structure. The interaction that was originally completed in one step is divided into two steps: the off-chain first obtains the data on the chain, and then uploads it to ETH for verification, and at the same time triggers the contract interaction, which prevents DeFi from obtaining dynamic real-time prices, so it is necessary to formulate rules, which prices can be What cannot be used for this DeFi interaction. There will be two problems in the formulation of such rules: either it is easy to cause transaction failure due to accidents such as packaging delays, or a price range is set, such as the price in the last 5 blocks can trigger the contract, resulting in a stable arbitrage. Both of these situations completely disrupt the continuity of DeFi.
3) The price is not an isolated point, but a time series. In this way, a verifiable single-point price data is barely obtained, but statistics such as average price and volatility cannot be obtained in a transaction, and these are indispensable for many DeFi, so this stolen It does not meet the needs of financial product design.
Option 2: Shared contract replication.
Centralized sharing is not considered: that is, a specific organization calls the NEST price and then copies it into the contract, and then lowers the fee or makes it free for everyone to use. This method has great risks. Once the uploader has an accident or subjective malice, the The blow of downstream DEFI is fatal, which is why the oracle machine must be distributed, because there is no longer a single point of risk and trust risk.
Distributed shared contract replication, mainly on-chain call replication, and off-chain embezzlement replication in 1, are explained separately:
1) Call copying on the chain: Design such a contract that the caller copies the price he called into the shared contract for free use by others. If every participant does this, the participant who calls the price can use the following logic to reduce the NEST fee: first check whether the shared contract has a price that meets their needs (such as the price corresponding to the latest block); if there is, it is free Use; if not, call the NEST price and copy to the shared contract (it can also be called directly through the shared contract).
This method makes the cost of each call less than or equal to the NEST fee. If all DeFi is implemented through the shared contract, each price of NEST can only be charged once. On the basis of this scheme, there is also a more dynamic copy scheme, which provides a price entry through a mapping, and then if necessary, the user can dynamically generate a price copy sharing contract at any time to call the NEST price, so that no matter what happens in the following contract The problem is that the mapping contract cannot be banned. As long as there is a contract below (the user can generate it when the price is needed), the price can be copied continuously.
NEST’s response to this solution: First, increase the verification mechanism. If downstream DeFi wants to call the price, it must destroy or mortgage a number of NESTs, and activate the oracle machine within X days after the completion of this operation; secondly, set up a blacklist mechanism, as long as any copy, Pirated contracts or shared contracts that use NEST prices can be banned by voting through the NEST system.
Since the downstream of these contracts are all DeFi applications, once the shared contract or the downstream DeFi contract is banned by voting, it will have a huge impact on the assets and contract services in the contract, making the entire DeFi need to re-introduce new oracles (and NEST takes time to take effect, so Impossible to quickly access the new NEST price), which is almost fatal for uncustodial DeFi (disregarding any centralized price source). However, users who copy NEST prices through mapping must continue to generate copy contracts in order to maintain price continuity, which will cause the cost of copying to be much higher than the cost of direct calls (need to destroy NEST and time costs), and it is impossible for users to complete it spontaneously This operation.
2) Off-chain misappropriation and copying: through the method mentioned in 1), and then copying the price to a shared contract, it is impossible to be banned by the blacklist in principle. But this approach has its own huge problems:
A. If the shared contract has the price that the user needs, the user is free. If not, the user needs to go through the embezzlement process from the off-chain and copy it to the contract. This cost has been described in 1), which is 10 times the price of simply calling NEST Even higher, which means that when the user calls the price, at least 9 out of 10 operations are uploaded by others, otherwise it is better to call NEST. This condition cannot be guaranteed, especially in the initial stage.
B. If the NEST contract is upgraded and the storage structure is changed according to the method in 1), so that off-chain theft becomes infeasible, the entire shared contract will be completely invalidated, and NEST restricts the voting of DeFi using the shared contract, then these DeFi will be Lose the price source, and fall into the same deadlock as in 1).
Summary: Since DeFi is uncustodial, it needs a very stable price source in principle, and should not try to achieve it by copying and sharing, which can be proven to steal the benefits of the NEST system; if so, it is likely to be voted by the consensus of the NEST community Prohibited, with fatal effects. For all normal use that increases the value of the NEST system, rational people will not restrict it by voting.
