Talk about the smart contract on Bitcoin BSV-Oracle (Oracle)

Content

In the previous article, we talked about the problems of pure one-tier contracts and second-tier contracts. The main problem of second-tier contracts is that it is difficult to reach consensus, while the problems of first-tier contracts are the inability to expand and transaction inflation. Students who haven’t seen it review the previous article first

When talking about the first-level contract, we concluded that the main contradiction of the first-level contract is the inability to identify counterfeit coins and the inability to sense other contracts in the same transaction. Essentially, it is because the Bitcoin script cannot read data other than the script code. The information about whether a token utxo is a real currency actually contains a large amount of information (it needs to be traced to the first transaction to determine this information).
If all this information is included in the Bitcoin script, then this script It will grow bigger and bigger, and finally swell to be unusable. If this information is not included in the script (the second-layer contract), only one layer of miners will not be able to determine whether a utxo is a real currency.
This is an unsolvable problem, including Ethereum. If you want to rely on yourself (without relying on external APIs or service providers) to obtain the correct token balance of an account, you need to run a full node that occupies about 5TB SSD hard drives. Then execute all the smart contracts in Ethereum's history, and finally calculate whether there are so many token balances in this account.

So since the amount of information required to determine the real currency is so large, and it will become larger and larger, which will cause utxo to expand to be unusable, is there a way to save only a part of the information, or the fingerprint summary of the information, without causing the utxo to expand? In the case of quickly verifying whether a utxo is a real currency?

In fact, similar methods have been widely used in blockchains. Students who understand the Bitcoin protocol should know a method to quickly verify the authenticity of Bitcoin, called SPV (simple payment verification). How can the wallet determine whether a received utxo is a real Bitcoin transaction? The conventional approach is to run a full node, then rebuild all utxo, and then determine whether our utxo is a real currency. Bitcoin provides a fast and safe judgment method that allows us to have only one summary information (block header) of the blockchain without the need for the full amount of blockchain data, plus the merkle path, and we can Very low cost to judge whether utxo is legal or not. The SPV and Merkle tree designs are carefully designed by Bitcoin to support unlimited expansion. This content will be mentioned later.

In the SPV scenario, because we only have the block header, we essentially have only a summary of the full amount of blockchain data, or a simplified version of the data extracted from the full amount of blockchain data, we cannot restore it based on the summary data alone. With the full amount of data, it is impossible to reconstruct the complete state of the blockchain by itself, and it is impossible to judge the authenticity of the summary itself. Therefore, the SPV wallet must "fully trust" the server (or full node) that provides itself with the block header and merkle path. In other words, when we choose to lose some information in exchange for convenience, we must use "trust" to make up for this part of the lost information.

We call this kind of credible server that has external data that we don't have, and provides summary information and its certification as an oracle. The English name is Oracle. The original intent of the oracle refers to a credible data source that can provide some external information for the contract that the contract itself does not have. Let's refine and extend its meaning here, and conclude that it has the following characteristics:

Oracle has some information (such as off-chain information or full data) that our contract or SPV wallet does not own or cannot obtain by itself
Oracle is credible, we trust Oracle to make up for the missing part of the verification information
The information provided by Oracle can be judged externally. If Oracle provides false information, it will be discovered immediately (for example, compare with other Oracles)
Oracle only provides a source of information about real events, without any secrets, and is open to access. Anyone or entity who knows the real events can act as an Oracle.
Through these three characteristics, we know that because Oracle must be trusted, it cannot prevent Oracle from doing evil, but because Oracle only provides information about what actually happened, it is very easy to verify the authenticity of the information provided by Oracle, for example, Oracle provides The result of a certain game of the du ball contract, for example, the SPV server provides the wallet block header.
These events can be learned from other sources. Therefore, once the oracle commits a crime, it will be discovered immediately, and because the oracle needs to provide its own signature, There is no denying the evidence of evil.

The way Oracle uses trust for convenience is everywhere. There are a large number of contracts in Ethereum that require Oracle to input data from the outside. Most developers need to rely on and trust data service providers like Etherscan and Infura to query the state of the contract. It is difficult for anyone to confirm the state of the contract through the blockchain.

Inspired by SPV, we can solve the counterfeit currency problem and induction problem as follows:

The summary information is passed into the contract for verification. The summary information includes the source transaction id of the utxo and the source of the source (previously verified 2 layers), and this verification is not to verify with complete data, but to verify The authenticity of the token can be passed on by verifying the oracle's signature on the digest. In other words, as long as you get the oracle's signature, oracle says that a certain utxo is legal, the contract can use the oracle's signature to unlock the utxo.

Oracle can also identify whether other contracts in the same transaction are real utxo, which allows multiple types of tokens to collaborate in the same transaction (this is the basis for token swap).

The actual operation is as follows: if the wallet wants to spend a certain token, it needs to request a signature from one or more Oracles, and ask Oracle if the utxo is real currency, and at the same time require Oracle to provide SPV proof of real currency.

If these Oracles all sign to prove that the utxo is Real currency, then the wallet can determine that this utxo is real currency, and use the signature provided by oracle to unlock the contract and send the transaction. Miners will also participate when packaging transactions to verify whether the signature provided by oracle is correct.

In the case that Oracle does not do evil, counterfeit currency cannot be spent at all because it does not have the signature of Oracle (guaranteed by the first-tier miners). This is essentially different from the second-tier contract. The counterfeit currency utxo is completely locked and spent. stay home. If the wallet wants to counterfeit coins, even if the counterfeit utxo is created, it cannot be spent because it does not have the signature of Oracle.

If Oracle does evil, there are two situations depending on how the wallet is handled.

One is that the wallet does not do evil. The wallet requests multiple Oracles to obtain signatures. If there is a message provided by an individual Oracle that is different from other Oracles (such as marking the real currency as fake or marking the fake currency as real), the wallet will immediately discover this situation and interrupt the transaction structure. So that the transaction cannot be constructed, nor can it be broadcasted. Avoid it before causing possible damage. And will find out what the real information is through other sources, quickly identify the malicious Oracle, and keep the signature message of the malicious Oracle as evidence (you can also disclose the Oracle's malicious behavior to the outside world and remind other wallets for early warning). No longer trust any information provided by this Oracle.

Another situation is that the wallet cooperates with Oracle to do evil. When the wallet receives the fake message signed by Oracle, it neither verifies the authenticity itself nor compares it with other Oracles. Instead, it directly cooperates with the fake Oracle to construct the transaction. This situation is very serious. It will introduce counterfeit coins to the entire utxo collection and destroy the state of the entire contract. And in theory, as long as Oracle deliberately does evil, it has the ability to destroy the entire contract and cause great losses.

Similarly, according to the description just now, Oracle's evil will be discovered immediately, and the evidence will be preserved, but the entire contract and token signed by this Oracle will be destroyed. The only thing the token issuer can do is to replace the Oracle to reissue the Token, airdrop to all the addresses of the old Token, and map the old token to the new one 1:1 to recover the loss, while retaining evidence of Oracle’s evil, which will affect the economy Recourse to law for losses.

It can be seen that, because it is not a pure one-layer contract, Oracle plays a vital role in the normal operation of a contract. Once Oracle is compromised, or the main action of the Oracle is evil (it can only be stolen or the main action is bad, it is unlikely to be caused by a bug. Do evil, because the conditions for wanting to do evil are still very harsh.) It can completely destroy the operation of a contract. Although it is not difficult to rebuild the exact same contract, it will definitely bring economic losses. Therefore, the issuer must be cautious when choosing Oracle, neither can completely close the entry barrier, nor open it unconditionally.

Oracle operators are a business that can make money by hosting contracts, but they need to do reputation guarantees. Generally, large exchanges, large miners or service providers with good reputation will provide professional Oracle services. Some technical and economic measures can be used to avoid or reduce the risk of Oracle doing evil.

Oracle will be caught for evil, and it will be discovered immediately from the moment the evil transaction is issued, and the evidence is conclusive and irresistible. In fact, many criminals commit crimes only by chance. If 100% of the crimes will be caught, then the crime rate Will drop a lot
If Oracle does evil, it will lose credit and potential business. No one will trust the contract to such an Oracle again, and no one will use the contract tokens hosted by such an Oracle.
Oracle doing evil may face legal risks and need to compensate for economic losses.
You can use some technical means, such as let Oracle lock a part of the money as a deposit, and use Oracle's malicious transactions to unlock the deposit compensation to the loss (the specific implementation has not been planned). If you do not do evil, the deposit cannot be taken out, and you do evil. At the same time, the deposit was lost.