problem
BSV has a layer-to-token scheme based on UTXO , but this scheme cannot completely distinguish the authenticity of the token at layer one. There are two ways to solve this problem:
- The historical tx chain is carried in tx , but this solution introduces the problem of tx size expansion.
- Identifying the correct UTXO set on the second floor is equivalent to putting a large part of the anti-counterfeiting work on the second floor.
Principle of the new scheme
The Oracle solution to be introduced here is the second way of thinking. The principle of the program is as follows:
- Oracle maintains a legal token UTXO collection.
- When the wallet receives a token UTXO, it applies to Oracle for the legality signature of the UTXO.
- When Oracle receives a token UTXO signature request, if the UTXO is legal, it signs the outpoint and returns it to the requester.
Through the above analysis, because the legality of token UTXO can be completely handed over to layer 2, then the script of layer 1 can be made very simple, and even only need to add one after the ordinary script template such as P2PKH OP_RETURNand carry the token ID, quantity and other description data That's it. Of course, in order to increase interoperability, a unified description data format standard is required.
Potential problems and solutions
safe question
If there is only one Oracle, then there will be a single point of failure or security issues of Oracle doing evil. Consider introducing multiple Oracle service providers to form market competition. In this way, it can not only ensure that a single Oracle service failure does not affect the overall service, but also can cross-validate the validity of the token through different Oracles.
Performance issues
Because the token also adopts the UTXO format, the sender and receiver can directly transfer it in P2P mode, and the sender provides the legal signature of the token as input. The receiver can verify the legitimacy by itself, and obtain the output new token UTXO legitimacy signature from Oracle immediately or delay as needed.
token recognition problem
Developers may develop various contracts to be used with token schemes. Various contracts may hold one or more tokens. How does Oracle identify the types and quantities of tokens in the contract?
It is unrealistic for Oracle to identify each type of contract template, because there are many types of contracts, and the types of templates are increasing at any time. But it is possible for Oracle to only identify the standard token description data in different contracts. Oracle can extract the token description data in the input and output, judge the flow direction and quantity of the token, judge the legitimacy based on this, and maintain the legal token UTXO set.
In other words, token description data is the key to identifying tokens, and this data can be embedded in UTXOs for various purposes. Oracle maintains the token UTXO set by identifying token description data, regardless of the contract template.
Smart contract based on Oracle token
Smart contracts can use Oracle signatures to determine the authenticity of the token input. In order to increase security, the contract can use n/m to verify the signatures from multiple Oracles. On this basis, contract theory can support various functions such as token transfer, contract distribution token, and atomic swap. These functions can be combined to achieve more complex functions similar to the uniswap contract on Ethereum.