Best Practices for Using Message Input Mechanisms on Ethereum
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
, author: Tellor Core, translation & proofreading: Chen Liang & A Jian, reprinted with authorization by Odaily.
Decentralized financial applications are a nascent and fast-growing category in the Ethereum ecosystem, but a key part of it - the information input mechanism (Oracle, old translation "information input mechanism") - has attracted everyone's attention. Without an information input mechanism, decentralized financial applications can only obtain on-chain data, and their adaptability to real application scenarios will be greatly limited. Many people may also know that many projects are already using off-chain information input mechanisms, but everyone lacks understanding of the use of information input mechanisms and related security measures. With more and more new projects and existing projects being re-architected for greater security, hopefully this article will serve as a best practice reference for how the information input mechanism should be used. We won't talk too much about the best design principles and security models for the message input mechanism, but only how to use the message input mechanism if you build applications on Ethereum. If you also hope that the applications you develop can achieve security, censorship resistance and decentralization, the following are some suggestions for you when building Ethereum smart contracts:
Recommendation 1: Information input mechanism design and interaction must be a priority in your protocol
The simplest form of information input mechanism is a centralized input mechanism, where you (the project creator) enter the price information, you can see many protocols do this at startup, and only use a simple multi-signature to ensure safety. These protocols claim to choose the route of "progressive decentralization" (we have a lot of problems with this statement), and declare that they will switch to a decentralized information input mechanism in the future. If you just want to participate in the hackathon, there is no problem, but at the beginning of the project, because the performance of the centralized information input mechanism is higher than that of any decentralized information input mechanism, it is too easy to start a new project. up. If your assumption is that exact values are always committed to the chain instantly, your design decisions on system capacity and user experience will be very different.
Projects that practice this idea of progressive decentralization are now in the awkward situation where users expect a certain experience, but their product simply doesn't work securely on top of the existing decentralized tech stack. They are forced to feign decentralization by including multiple parties in a centralized multisig, or they kick the can mentality down the road and hope that the impossible triangle of public chain scalability will be lucky successfully resolved. The point here is that unless the decentralized information input mechanism is considered from the very beginning of the protocol design, it is difficult to update the decentralized information input mechanism to the existing protocol.
Advice 2: Don't trust your information input mechanism to always respond quickly
Ethereum is still a new thing. Although a block can often be generated in a few seconds, it may take a long time for transactions to be confirmed during periods of frequent transfers. If you remember the block chain blockage incident caused by the blockchain game "Cat Obsession", and the recent "Black Thursday" incident that caused the transfer fee to skyrocket, users had to pay unbelievably high transfer miner fees at this time In order to allow their transactions to be confirmed smoothly. Even if you think users of the protocol have an economic incentive to pay these fees, do you really want them to be forced to pay them?
In addition to network congestion issues, developers should also consider the corner case of Ethereum crashing. Long-term outages of blockchain networks are unlikely, but short-term outages are possible, so consideration must be given to the impact of on-chain and off-chain (often) rapid information input mechanisms that lack finality. We always hope that the protocol can maintain normal and timely operation, but sometimes this cannot be done. For example, the protocol needs to run for a few minutes to confirm the finality, then your information input mechanism may not be able to input information. This is not to say that all schemes for designing a time frame for the information input mechanism are not advisable. It is good to design a pragmatic operation interval for the information input mechanism, but a stable decentralized financial protocol should provide for these sudden extreme situations. Be prepared. One of them is:
secondary title
Recommendation 3: Assume that your information input mechanism may be broken
Don't assume finality in your information input mechanism. Many protocols make the mistake of having information feeds updated to drive certain operations (e.g. a derivatives contract only settles when the information feed is updated). This is a mistake. You should have a standard operating procedure in place to prevent situations where information is entered into the mechanism incorrectly, even if we hope this never happens.
To recap, there are two types of errors that can occur with the information input mechanism:
Your message input mechanism submitted an incorrect value.
Your message input mechanism is down and not pushing messages to the chain
The first type of problem, for example, if you are using a centralized price feed mechanism, and the price provider accidentally multiplies the price by 10,000, you definitely don’t want to settle with this value, and even the feed mechanism itself will be deleted This value (in the Tellor message input mechanism this would cause a dispute and be canceled), but the question remains - how long do you wait for the data to be validated?
This ultimately depends on the stability of your protocol, as some smart contracts may require a slower/more robust check and confirmation mechanism than others. A good example of this mechanism is the Maker protocol, where the information passed in by the information input mechanism takes effect with a delay of one hour. But we need to think carefully, and not assume that this is necessarily true.
The second way of undermining the mechanism of information input mechanism is more roundabout. An example is that the centralized information input mechanism loses the private key and the contract cannot be updated. What will happen to your derivatives smart contract at this time? Another thing that affects the activity of the information input mechanism is the unwillingness of the information provider to provide information quickly. Assuming that the Ethereum network is congested, the miner fee per transaction is $20, and your information input mechanism only provides a transaction fee of $1 per transaction, then the smart contract may take several hours to update, back to suggestion 2. From a perspective, you may need to be prepared for this, but you should also know if your information provider has the ability to unilaterally control this delay. In the Tellor information input mechanism, we put the data on the chain through the competition of POW, so its activity is guaranteed by the incentive mechanism. Some more centralized information input mechanisms do not have such guarantees, and information input mechanism providers can tolerate delayed transactions, and even censor data based on bribes or their own positions.
When an information input mechanism is suspected of corruption or involves centralized review, we have many countermeasures (of course we hope it is best not to use it), including:
Stop the contract execution and wait for the information input mechanism to feedback the correct value
Utilize multiple information entry mechanisms
Return all funds / complete settlement with default values
The backup and security of the information input mechanism we refer to mainly emphasizes the protocol level. It is difficult to express how the backup options should be used in each case with a unified paradigm, but it must be ensured that all parties have no incentive to take these backups individually. option, the purpose of the backup mechanism is to keep the network safe, not to provide another path for malicious attacks.
Whether you admit it or not, there is always a way for an attacker to compromise the information input mechanism, but the cost is different. Sometimes this cost is the cost of buying reputation or buying tickets, sometimes it is a part of the market value of tokens issued by the project, and perhaps more often it is the cost of corrupting information providers or the cost of reviewing relevant participants (such as traditional centralized model). No matter how high the cost of breaking the information input mechanism is actually, or even if the cost of breaking the information input mechanism is not constant, you should have a general understanding of the security of your protocol. For projects that hope to hold millions or even billions of dollars in funds one day, using a token with a market value of only a few million dollars to endorse the security of the information input mechanism, or to endorse the reputation of certain groups It's a big risk.
in conclusion
Knowing the cost of breaking the information input mechanism can let the protocol developer understand how much security measures are needed to ensure the stability of the system. Using one information input mechanism may not guarantee the security of smart contract assets, but using multiple information input mechanisms or taking some backups The scheme will greatly increase the cost of attacking the contract. At present, some people have started to submit an Ethereum upgrade proposal (EIP2362), which standardizes price and data flow information so that new protocols can easily and quickly integrate multiple information input mechanisms into their contracts.
